Date: Wed, 1 Jan 1997 22:25:35 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] At 5:40 PM 1/1/97, Steven R. Newcomb wrote: >> 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). I changed the terminology, not for its own sake, but because I am not convinced that a HyTime BOS meets the explicitness requirements I think we require. I could also argue that "working set" is a commonly understood term in storage management, and in this case the analogy reveals the intention of the term better. I have another reason as well, which we will get to later on. >> My contention is that the notion of (even restricted) recursive document >> requirement could be harmful. > >How so, if it's restricted? Because think that any restriction that's more general than the explicit selection of indiviual files for inclusion is leaving too many files open for inclusion. There's a big difference between what I want to reference, and what I want to tell a browser to download -- they may sometime be the same, but they are at least as frequently different. HyTime BOS is defined in terms of entity references, and not all XML links will be via an external entity. At least, I take it as axiomatic that we are dead in the water if we don't _at least allow_ the creation of links that contain just a URL in an attribute value. So some references will not be part of the BOS. I am also one of the people who argued vociferously (and successfully) that an XML parser _must not_ be required to follow all entity references. This also makes the BOS potentially problematic, even for the entities making up a single document. >> 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?) As noted above, and for the same reasons we have been re-arguing here for links, XML processors are _not_ required to pull in a whole entity tree at once. >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. Well, my problem is that I think that the term that we need does _not_ match BOS in every particular, but only in some particulars. So I can gain both perspicuity (my opinion) and accuracy. > 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. There is a working example of interconnecting the world's knowledge bases. It is the WWW. This is in some ways sad, but undeniably true. >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? I don't have an explicit goal either way with respect to HyTime. The brief of the group does _not_ include HyTime compatibility. Personally, for functionality, I am applying a standard to HyTime that I describe as "no gratuitous incompatibility". I see no reason, technical or offical, why we should stick to HyTime if we think that HyTime got something wrong. On the other hand, there is a large amount of good work on the relationship of hypertext to markup in HyTime. So I think the semantics are mostly right. I think we can manage to be mostly compatible with the standard as well (modulo a few PIs a user can add if they need them). I only say mostly in case there are places (I feel anchor roles are one) where HyTime may impose a restriction that we can avoid. As to terminology, I am not so convinced. Most HyTime (and SGML) technical terms are rather long idiosyncratic phrases. I would really have no problem using terminology tailored to our application and providing a HyTime glossary for those who want one. Some of the terms like clink, ilink, and location seem clear to me. Further, because they describe ways of tagging hypertext features, there are no pre-existing terms for those concepts (or closely analogous terms). I also want to avoid using uniquely HyTime terminology in a sloppy or different sense than HyTime does. So now we come to another beef with the term BOS: >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). I think we will only need 1 of these senses (Application BOS). This reflects the reality that an application can do what it wants. We also need a method (to be determined, though I suggested one route) for an author to suggest a minimal set of documents that should be in the (application BOS, Working Document Set) for a document to be at its best. So I don't want to just say BOS, since that is confusing to those who know that there are other senses, and I don't want to say "application BOS" because then we will be using a modifier ("application") on every occurrence of a realtively recondite term none of whose other senses need come into our standard. >> 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. I don't think that there's a conceptual difference in the motivation, but there are practical differences in the execution: in my suggested scheme you become a companion only by explicit designation. Other forms of reference do _not_ cause any necessary change in the working document set -- and there is no work required to make this so. This means that the typical table-of contents page on the web can have no untoward working-set effects. A document must _explicitly_ ask that another document be processed along with it. >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: But that's not what I said. I suggested that for the BOS case you could cite _one_ directory document that would be responsible for tracking the BOS. >* 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 don't understand this. Or rather, I don't want the "convenience" of automatically fetched entity trees, eliminate that "conventience" and the two schemes are the same amount of work. >* 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. You could change it in the "hub" or in the local companion declaration. But you have to change it _somewhere_, and only in _one_ place. The orginal problem was to centralize address management, I showed how to do that. If you just list companions in each document directly, you can ease local maintenance, but you lose central control. I don't see that this tradeoff can be different in any system whatsoever. On my proposal, the companion of a companion is a companion (we take the transitive closure of the companion relation). So we get the same ability to express things that we have following entity tree. What we have gained is decoupling of "companionship declaration" from entity declaration. I can imagine authors who want to do a lot of linking, but not use entity declarations -- they would be accommodated by this. I can also imagine that many authors will have links that should _not_ indicate companions. > >> 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. No, It means that if we want centralized control of a companion set, we make a document that represents the set, and then an individual document, can indicate the hub for that set to have all its members as companions. That's one declaration in each document (that never changes unless you move the hub, and didn't use FPIs), and one delcaration for each member stored in the Hub document. No redundancy. If you don't want centralized control, you can arrange things differently. I was answering that charge that document by document specification does not let you centralize control. I think it's obvious how to use it to _de_-centralize control. >Happy New Year (1997 has *got* to be better than 1996)! Kalh' Xronia' (Happy New Year) to all. So far it's looking good. We'll see what the morning brings! -- 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, 1 Jan 1997 22:35:07 -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:09 AM 1/1/97, Martin Bryan wrote: >At 13:12 31/12/96 -0500, David G. Durand wrote: >>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. I expect that authors will see the redundancy: most static documents are sent verbatim by servers -- this is mostly an efficiency issue, but it does not seem to be changing. I doubt that most servers will add attributes to document instances when the DTD is not being processed. I certainly would not want to end up making such server processing a de-facto requirement for linking to work. And, there is currently no way that we can tell whether an application has (or intends to fetch) the DTD for a document unless we add new DTD intention parameters to HTTP. In other words, if there is no DTD, we will have no default attribute values. We decided that this was OK for graphical rendering because we are assuming that the stylesheet can work without that explicit information. I propose that we follow the same strategy for linking. In both cases, certain errors can occur, especially if the attribute definitions change and the stylesheet does not. In both cases we have a mandatorily interpreted set of _declarative_ information (DTD or link architecture specification). This means that non-rendering applications do not have to try to deduce the functions of stylesheet code, but can read the DTD. It also offers authors the option to require the DTD for correct operation of the stylesheet (by simply not assuming default values for undefined attributes). The market and users will decide if and when these separate strategies are most useful. >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. No, but we can make reasonable assumptions about what certain implementors are likely to do... If Netscape were to immediately see the value of rigorous DTDs I would fall down dead from shock. Separate stylesheets => two HTTP hits already. This will be a tough sell... The chance people would accept 3 hits per document seems very low to me. We may yet have to bite the bullet and allow stylesheets within documents: which is a very bad idea, I think. But I don't see how we can require DTDs for linking, and claim to have eliminated them from XML -- at least in the web context, linking is a hard requirement. -- 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, 1 Jan 1997 20:42:25 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org cc: bosak@atlantic-83.eng.sun.com Subject: XML Phase II co-editors To more evenly distribute the workload on our XML draft editors, we are breaking out the (as yet unwritten) XML hypertext specification as a document separate from the core XML syntax draft. The ERB has decided by unanimous vote that for the XML hypertext effort, the draft co-editors will be Tim Bray and Steve DeRose. Steve's extensive hypertext experience makes him a natural choice for co-editorship of the Phase II draft, and I am very pleased that his managers at EBT have allowed him to take on this responsibility. Tim Bray and Michael Sperberg-McQueen will continue to maintain WD-xml, the first draft of which was released in November as WD-xml-961114. Jon Bosak Chair, SGML ERB and WG Date: Wed, 1 Jan 1997 20:57:06 -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: Charter amendment: hypertext experts In order to allow certain selected hypertext experts to participate in Phase II of the XML effort, the SGML ERB voted last week to amend Section 2.1 of the WG/ERB charter document tr-1996-01 to change one of the two criteria for WG membership from "persons with SGML expertise" to "persons with expertise in SGML or hypertext". A two-thirds vote of the ERB is required to make such amendments. The vote was as follows: Yes: Bosak, Bray, Magliery, Paoli, DeRose, Kimber, Maler, Hollander, Sperberg-McQueen, Sharpe No: Clark Section 2.1 before amendment:

2.1 Membership

Members of the SGML Working Group (WG) are persons with SGML expertise who wish to promote the use of generic SGML on the Internet. SGML WG members need not be employees of W3C member organizations.

Section 2.1 after amendment:

2.1 Membership

Members of the SGML Working Group (WG) are persons with expertise in SGML or hypertext who wish to promote the use of generic SGML on the Internet. SGML WG members need not be employees of W3C member organizations.

Note that the requirement that new WG members can only be proposed by the Chair or by W3C member organizations still applies and that I will be very reluctant to add persons with no SGML experience unless they can make uniquely useful contributions to our discussion of hypertext mechanisms. Jon Bosak Chair, SGML ERB and WG Date: Thu, 02 Jan 1997 10:43:46 +0000 To: "Steven R. Newcomb" , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] At 17:40 1/1/97 -0500, Steven R. Newcomb wrote: >Thanks for your help, David. I've been pretty boggled by that >discussion, and I'd like to apologize to Martin for any offense. No offence given or taken Steve. I enjoy a good argument, especially when I am in the role of the Devil's advocate, as I often am:-) >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. This is why I want the link information decoupled from the rest of the document in a way that will allow it to be referenced from any start-point (hub) document that needs to reference it. That way I can set up one easily maintainable link set and point all my documents to it. Ideally what I would then love to be able to do is to prune this application BOS from within the called document so that I can get the most efficient effective BOS for the current user. For my, somewhat unusual, web pages I would want this done under author control rather than user control as I can easily identify how to prune the well-maintained tree. >Ouch! Also, doesn't this mean that an author can't specify companion >documents that he can't write on? Sounds impractical. To me there is a clear distinction between "what is essential" (i.e. defined in the application BOS as documents that are specifically referenced as transclusion type references) and what could be added if the user has time to get them in the background (i.e. defined in the companion documents). The first list defines the set of entities that must be retrieved before starting the session (i.e. those likely to result in delay), the second defines the set that the system can usefully pre-fetch during any spare system cycles while the author is reading the file. The second set of documents may not have links pointed at specifically from the hub document: it could just be a set of files that are referenced in bibliographic entries. In this case you don't need to write on the second set. (There will of course, be cases where you do, so we need some mechanism to whereby we have dynamic linking to documents once they have been retrieved, as a background operation.) Martin ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 02 Jan 1997 11:49:55 +0000 To: w3c-sgml-wg@www10.w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re:Can we be more concrete... [David Durand] >No, but we can make reasonable assumptions about what certain implementors >are likely to do... If Netscape were to immediately see the value of >rigorous DTDs I would fall down dead from shock. Separate stylesheets => >two HTTP hits already. This will be a tough sell... The chance people would >accept 3 hits per document seems very low to me. >We may yet have to bite the bullet and allow stylesheets within >documents: which is a very bad idea, I think. Can you explain why David? >But I don't see how we can >require DTDs for linking, and claim to have eliminated them from XML -- at >least in the web context, linking is a hard requirement. (Trying to anticipate the though processes of non-SGML savvy developers:-) XML describes a tree structure. A sub-tree, when considered a root is a perfectly valid tree. Simple to understand stuff. "Technology FOO used to describe Technology FOO". Most developers grin when they read things like that. It occurs all over the place in software they use on a daily basis. Going further:- . A single XML tree can cleanly contain multiple trees. One for "real" data. Others for data about data. Bits about bits (in Negroponte-speak) . Hypertext info. (i.e. AF stuff) can be encoded in XML and housed in a sub-tree. This sub-tree serves to express how the body sub tree is decorated with attributes for Hypertext semantics. . Rendering Style info can be encoded in a sub-tree. . Hitherto-unthought-of-killer-application semantics can be encoded in a sub-tree. For *valid* as distinct from well-formed XML I have the option of achieving this via fixed attributes in the DTD as per HyTime approach. Pros:- Single HTTP hit. Developer friendly (IMO) No need for the DTD at Browser end in order to do Hypertext or any other document architecture. Cons:- Duplication of hypertext info in every instance of a given AF set. How is the hypertext sub-tree recognised. Reserved GI names? How do browsers distinguish between data and meta-data for rendering purposes? >From a document management perspective, could meta-data XML docs be stored as separate entities on the server side and merged with the main doc for HTTP "on-demand". (I remember Eliot talking on CTS about using SPAM to do this with HTML). Given that displaying a document with hypertext links is a "rendering" do we have to consider how Hypertext functionality will impact on rendering functionality? An XML savvy browser will receive its Hypertext meta-data somehow. It needs to know that it should not be rendered. Finally, now that I am loosing the run of myself completely, why not allow an XML encoding of the DTD to be an optional way of creating valid XML??? Happy new year to all, Sean Mc Grath digitome@iol.ie Sean Mc Grath digitome@iol.ie Digitome Electronic Publishing Developers of IDM - Next Generation SGML Transformation Technology http://www.screen.ie/digitome Date: Thu, 2 Jan 1997 08:29:31 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: URLs/MIME only? >> /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. ... >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. Why? I think this depends upon whether you see documents or (p)elements as the atomic objects. I think there is a *very* strong strong case for looking at elements as atoms, especially when we start thinking about transclusion etc. We can build an awful lot upon the two forms above in a *simple* and *standard* way. Points 2-4 are red herrings, and fall out of point 1. I do *not* consider these to be XML specific: they are just tree/list-of-lists-specific (a list is a degenerate tree, or a tree is a list-of-lists POV). This is certainly no worse than current URL's. > 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've dealt with all these folk too (and more!), and again, I think that if you look at elements as atomic, all conditions are met. >>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? God forbid. That would (logically) mean that you could switch encoding mid-stream... which is precisely how this fellow interpreted it!! Date: Thu, 2 Jan 1997 11:57:13 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: URLs/MIME only? Cc: w3c-sgml-wg@www10.w3.org At 8:29 AM 1/2/97, Gavin Nicol wrote: >>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. >Why? I think this depends upon whether you see documents or >(p)elements as the atomic objects. I think there is a *very* strong >strong case for looking at elements as atoms, especially when we start >thinking about transclusion etc. We can build an awful lot upon the >two forms above in a *simple* and *standard* way. The problem that I see is that HTTP and current implementations make a pretty strong URL<->transmission unit equivalence. XML has a notion of transmission unit that is a natural one, and that is the entity. So we are making entities into findamental addressable units. Now we could also make elements into addressable units, but doing so makes some pretty hard requirements on servers, if those URLs are to be resolvable. Now I agree that a dynabase-like approach is the "right" way to build sophisticated servers, but I think the demands of document parsing, etc. that are entailed by making that approach mandatory will prevent the implementation of the lightweight, quick-hack servers that have driven the evolution of the web. So, I agree that we can do as your ask, if we make elements into the base level of structure. But I disagree that we can expect most server implementors to implement XML servers if they have to implement this kind of sub-element addressing. > >Points 2-4 are red herrings, and fall out of point 1. They may not be logically independent, but I don't think they are red-herrings, either. Doing as you ask requires a rather different model >from the one we have been implictly using: XML entities <-> URLs to access them XML elements must be parsed to be detected. >I do *not* consider these to be XML specific: they are just >tree/list-of-lists-specific (a list is a degenerate tree, or a tree is >a list-of-lists POV). This is certainly no worse than current URL's. Yes, but it prevents the "slap XML files into an existing server, with a new mime type" deployment apporach. It may be one hell of a convoluted noun phrase, but it is going to be a common implementation strategy. >> 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've dealt with all these folk too (and more!), and again, I think >that if you look at elements as atomic, all conditions are met. Agreed, but.... >>>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? > >God forbid. That would (logically) mean that you could switch encoding >mid-stream... which is precisely how this fellow interpreted it!! Unless I'm wrong, PIs are still legal in XML in general, and they are unconstrained as to functionality: (though we might want to state that PIs _cannot_ change parsing behavior, if we don't already). So he might even _have_ a conforming extension to XML, albeit a pretty vile one. -- 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, 02 Jan 1997 09:49:21 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: XML Link Sticks Proposal --=====================_852263361==_ All, Attached to this note is my initial draft of a "house of sticks" (as opposed to straw man) XML linking proposal. It is drafted using the DTD used for the original XML spec. It's not complete enough for publication (and I never intended that it would just be picked up and used), but I tried to make it as formal and complete as I could in the time I had. I think it meets the requirements for which a concensus seems to have emerged >from the discussion so far. I do expect that this proposal is larger than the minimum limits suggested by Tim: I would expect it to be trimmed down as necessary. I have not addressed issues specifying hyperlink behavior or presentation style. The basic points of the proposal are: 1. Three linking forms (or "templates", if you prefer): hlink, for general independent or "anchored" hyperlinks with arbitrary link end roles; alink, "anchored link", for links that are always one of their own link ends (and are thus always "anchored" in the sense that we have defined anchor here, provides default link end roles; and llink, "list link", which simply links to a list of objects. 2. Four addressing forms: name-space loc, treeloc, dataloc, and queryloc. URL is required, TEI extended pointers recommended (but not required). HyTime "refloc" facility included so that location address mechanisms can be associated with any attributes that are semantically references (this lets you explicitly associate query notations with referential attributes in a general way). Explict refloc to URLs is not required for any XML-defined referential attribute that is declared with a value prescription of "CDATA" (in other words, an XML processor assumes XML-defined referential attributes are URLs unless declared to be IDREF(S), ENTITY(IES), or refloced to something else). I have probably provided more addressing functions that absolutely necessary--I expect them to be trimmed down. Cheers, E. --=====================_852263361==_ " > ]> Architectural Definition

An architecture is a general set of rules to which an application must conform. For XML, architectures are used to define "meta document types" to which individual documents conform. These meta document types define the XML-specific rules and semantics for things like hyperlinks without completely constraining how specific documents are constructed. In particular, individual documents can use whatever element types and content models they want as long as they meet the minimal requirements of the XML architecture.

Architectures are formally defined using the same element and attribute declaration syntax used for document types. These declarations form the meta-document type for the architecture. An element type declared in a meta-DTD is called an architectural form, meaning that it defines the architectural form of an element type, from which element types in individual documents. (You can think of the term "form" in the sense of creating things with molds, where the form is a template or pattern from which new objects are made.)

Documents are said to be derived >from architectures. The derivation of a document from a particular architecture is indicated by the use of a special processing instruction, <?ArcBase ?>, which lists the architectures from which a document is derived, e.g.: <!DOCTYPE MyDoc > <?ArcBase XML-Link ?>

You can think of the element and attribute declarations in the meta-DTD as templates for the elements in you own document. You can create new element types from meta element types by literally copying the declarations from the meta-DTD and then modifying them as needed to reflect your own documents.

Deriving Element Types from Architectural Types

When you derive element types from architectural types, you can make any of the following changes:

Change the element type name to be different from the architectural type.

Declare multiple element types derived from the same architectural type.

Make content models that are more restrictive than the architectural content model.

Omit elements derived from architectural types that are optional.

Omit any attributes for which there is a default value in the architectural DTD. This means you must only include those attributes that are either required or have constant values in the meta-DTD.

Change the default values for any attributes.

Restrict the keywords allowed for keyword attributes.

Add additional attributes not defined in the meta-DTD.

You may not do any of the following:

Omit required attributes or attributes.

Omit required elements.

Define content models that are less restrictive than the meta content model if doing so would allow instances that do not conform to the architectural restrictions.

XML Linking and Addressing

Linking is the process of connecting two or more objects together for the purpose of relating them together. Addressing is the process of specifying the locations of objects. Linking uses addressing as you must address objects in order to link them together. However, the relationships represented by links are insensitive to the methods by which the objects linked are addressed. Thus, linking and addressing, while related, are separate tasks.

Keeping linking and addressing distinct is important for at least two reasons:

It allows the addressing method to be changed without affecting the link

It allows addressing to be used in situations that are not considered linking.

XML Linking

While all possible relationships that might exist among objects can be considered "links," XML limits the term "link" to those relationships that are not inherent in the structure of SGML markup (hierarchy and property-of relationships). In addition, XML assumes that most hyperlinks are created to enable navigation of information at reader preference, rather than defining a fixed presentation order of the information (although it is possible to define static presentations of XML documents that depend, in part, on hyperlinks, e.g. "transclusion" relationships or presentation styles).

Links connect link ends. For example, in the typical HTML "A" link, the A element is one end of the link and the page or named A element addressed by the HREF attribute is the other link end. Link ends may, potentially, consist of multiple objects. For example, a link that relates a glossary entry to all of the mentions of the term defined would be a two-end link where one end is the glossary entry and the other end is a multi-object link end consisting of all the mentions.

XML reserves the term anchor for elements or other objects that are primarily intended or otherwise enabled for addressing as link ends, usually by putting a unique identifier on the anchor element. Anchors may be elements that have no purpose other that to serve as an anchor or may be elements with other purposes that also serve as anchors (such as a paragraph that also has an ID).

Each end of a link has an associated "link end role", which describes the role the link end plays in the relationship represented by the hyperlink, much as an element type describes the role the element plays in the document type. Link end roles may be more or less general depending on the generality of the link type. Link end role names must be unique within a given link type.

Movement from one end of a link to another end of the same link is called traversal. Link ends accessed by traversal are said to be traversed to. Traversal is typically enabled by making a link end selectable (say by clicking). However, traversal need not be interactive but could be done automatically, for example to provide a "transclusion" behavior for a particular link type. If initial traversal is allowed from a particular link end it is called an initiation link end, meaning that traversal may be initiated >from it. For example, for the HTML A link type, the A element is an initiation link end, but the other link end is not. Whether or not an end of a link is an initiation link end may be defined either through the link's built-in traversal rules or by a processing application or style sheet.

In XML, hyperlinks are first-class objects represented by XML elements. The element type of the linking element is the "link type" of the link. Link types may be more or less general as needed.

A link may use itself as one of its own link ends. The HTML A element is an example of such a link, where the link is between the A element itself and whatever the HREF attribute addresses. Alternatively, a link need not name itself as an link end, in which case the relationship is among the link ends addressed, but not between the link element and its link ends. In other words, in the first case, the link element itself is an initiation link end but in the second case the link is not a link end and therefore would not normally be selectable for traversal.

Links that are not one of their own link ends are independent links, meaning that they are independent of any of their link ends. Links that are one of their own link ends are anchored links, meaning that the link itself is anchored in the document in which it occurs (specifically, the link acts as an anchor in the sense of an element intended to be used as a link end).

Note that for independent link the link element, as a normal XML element, would still be potentially accessible as part of the document in which it occurs, irrespective of any links it defines. In addition, XML processors are free to provide services for examining independent links they may want to provide, including allowing movement from a link to its link ends (although such movement would not be considered link traversal in the strict sense).

Not all links need to represent a formal semantic relationship, sometimes it is enough to simply connect things together in a list to enable traversal among the members of the list. For this purpose, XML defines a special form of anchored link, the list link. A list link simply relates the link element (the "list") to one or more objects to be listed together (the "members"). Traversal among the members is enabled by specifying the appropriate list traversal rules. The members of the list are treated as a linked list of objects. The order of the members of list is determined by the order in which they are addressed.

Traversal is either between the list of all the members and any member or from one member to either of its adjacent members. The list traversal rules may allow "wrapping" from one end of the list to the other. List traversal can be disallowed entirely or be forward, backward, or bi-directional. When list traversal is disallowed, traversal is always from the aggregate to a member or from a member to the list (in other words, when selecting a member as an initiation link end, you are always presented with the list of the other members).

An end of any link, not just list links, may be a list, in which case list traversal rules can be defined as for list links.

Hyperlink (hlink) Element Form

The hlink element form is the most general form of hyperlink and is the model from which anchored links and list links are derived. The attributes of the hlink form are:

Names the link end roles for the link type. Each link end role name must be unique within the link type. Each link end role name can be followed by one of the keywords #SELF or #LIST. The keyword #SELF indicates that the link end role is satisfied by the link element itself. The keyword #LIST indicates that the link end may be a list of objects.

The -xml-roles attribute is required and must be the same for all instances of a link type. Each link end role name is used as the name of an attribute that will specify the address of the members of the link end.

Specifies which link end or link ends are traversal initiation link ends. One of the keywords FIRST, LAST, or ALL. The default is ALL.

The -xml-init attribute is optional.

For link end roles that allow lists, specifies the list traversal rules. The attribute value is either one keyword, which applies to all #LIST link ends, or one for each #LIST link end, in the order specified on the link end-roles attribute.

The list traversal keywords are:

No list traversal. Movement always between list of members and a single member.

Movement is from a member to the preceding member in the list

Movement is from a member to the next member in the list

Movement is from a member to either adjacent member in the list

Movement is from a member to the preceding member in the list, wrapping from first to last at the beginning of the list.

Movement is from a member to the following member in the list, wrapping from last to first at the end of the list.

Movement is from a member to either adjacent member in the list, wrapping from first to last or last to first.

For each link end role named in the -xml-roles attribute, there must be an attribute declared with the same name (or a name mapped to an link end role name using the general -xml-names renaming attribute). The attributes so declared may be declared as IDREF, IDREFS, ENTITY, ENTITIES, or as CDATA attributes whose value must be a URL. Other addressing methods can also be used by using a refloc attribute to associate an attribute with the addressing method (see Refloc Attribute Form).

The XML meta-DTD declaration for the hlink form is: ]]>

Anchored link (alink) Element Form

The alink (anchored link) element form is a special case of hyperlink where the link element is always a self link end and the link end roles are defaulted by XML. It is useful for representing cross-reference and simple link elements in typical document types.

The alink form has the same attributes as hlink except that the link end-roles attribute has the architectural default value "refmark #SELF refsub #LIST", where "refmark" is the "reference mark" (i.e., the cross-reference element) and "refsub" is the "reference subject", the thing or things being referred to.

The default -xml-init value for clink is "FIRST".

The default listtrav value for clink is "AW", adjacent with wrap.

The architectural meta-declaration for alink-form elements is: ]]>

List Link (llink) Element Form

The list link element form represents simple aggregation of objects purely for the purpose of enabling list traversal among the members of the list. It can be combined with other link elements to form more complex selection or navigation structures.

The list link form has the same attributes as hlink except that the link end-roles attribute cannot be specified and is taken to have the fixed value "list #SELF members #LIST", where "list" is the link end representing the entire list of members of the members link end.

The default -xml-init value for clink is "FIRST". If the value is set to "LAST" then the list itself cannot be selected for traversal (but may be traversed to via list traversal).

The default listtrav value for agglink is "AW", adjacent with wrap.

The architectural meta-declaration for llink is: ]]>

Addressing

Addressing is the process of specifying the location in some address space of an object or objects. Objects in XML may be addressed by name (element ID or entity name), by position in a tree or list (node addressing), or by a query of their defined properties (query addressing). Objects may be addressed directly (say by normal ID reference), or indirectly. Indirect addresses make addresses more flexible and easier to maintain.

Location Address Element Forms

Any of the addressing methods defined by XML may be used as direct addresses or as indirect addresses. The use of addressing methods other than ID references or URLs requires the use of the refloc attribute to associate a specific addressing method with an attribute (see Refloc Attribute Form).

The indirect addressing elements are "resources" in the sense that they only have meaning when used by reference; they have no meaningful existence in isolation. In particular, addressing elements are not hyperlinks and are never used for traversal or navigation. Each of the indirect addressing forms has an equivalent SDQL specification, meaning that anything that can be done with indirect addressing elements can be done with an equivalent SDQL query.

Every location address element has a location source, which is the object or objects against which the address is applied. In most cases the location source can be omitted and is implied to be the document element of the document that contains the location address element. However, the implied location source can also be specified as being the non-location address element that refers to the location address element (the referrer).

The location source is specified using the the location-source attribute. The location-source attribute addresses the object or objects that are the location source. If the location-source attribute is omitted, the location source is implied according to the rule indicated by the implied-location-source attribute.

The implied-location-source attribute takes one of the values REFERRER or DOCELEM. The value REFERRER indicates that the implied location source is the referrer element. The value DOCELEM indicates that the location source is the document element, the document's root element.

The default value for implied-location-source is "DOCELEM".

The location source for a location address element may be another location address. The first location address thus selects objects from the list of objects addressed by the second location address. Using one location address as the location source for another location address creates a location ladder.

The meta-declaration for location source attributes is: ]]>

Name Addressing

Objects can be addressed by name directly or indirectly. Direct name addressing is done with attributes declared as IDREF, IDREFS, ENTITY, or ENTITIES.

Objects may be addressed indirectly by name using the name-space location address element form (nmsploc). The content of the nmsploc element is a blank-delimited list of zero or more names (names that contain blanks must be enclosed in LIT or LITA delimiters).

The name space to which the names apply is indicated by the namespace attribute, one of the keywords ELEMENTS or ENTITIES. The default name space is ELEMENTS. When the name space is "elements", the names are interpreted as element unique identifiers in the document that is the location source for the name-space location (by default, the document it occurs in). When the name space is "entities", the names are interpreted as the names of data entities declared in the document that is the location source for the name-space location.

If a location source is specified for nmsploc, it must be either a document element or an XML document entity.

The meta-declaration for the nmsploc element form is: ]]>

Query Addressing

Objects can be addressed by queries. Any query notation may be used with query location addresses. However, XML requires support for URLs and recommends support for TEI extended pointers. Reference attributes that use URLs are declared as CDATA attributes and do not need to be indicated as referential attributes using the common refloc attribute (in other words, XML processors assume that any referential attribute that is not an ID or entity reference and that is not otherwise mapped with refloc is a URL).

Objects may be addressed indirectly by query using the query location address element form (queryloc). The content of the queryloc element is a query conforming to the query notation specified by the notation attribute. The query notation may or may not allow subelements depending on the definition of the notation. In any case, the entire content of the queryloc element is provided to the query notation processor for interpretation following parsing of the document (in other words, the content of the queryloc must be valid XML regardless of any additional semantics or constraints the notation specification may impose on the data). Query specifications that cannot be parsed as valid XML may be contained in <![CDATA[ blocks.

A query location address must indicate the notation to which the query conforms using the notation attribute. XML pre-defines the notation "URL", representing HTTP URL addresses. Other values must be notations declared in the document.

When the TEI notation (or its equivalent) is supported, query location addresses may be used in place of combinations of other location address forms.

The meta-declaration for the queryloc element form is: ]]>

Tree Addressing

Objects can be addressed by position in a tree. Objects may be addressed directly by tree position by using the common refloc attribute to map the referential attribute to the addressing method "treeloc".

Objects may be addressed indirectly by tree position using the tree location address element form (treeloc). The content of the treeloc element is a list of integers, one for each level of the tree, starting with the tree root (the location source of the tree location address), and specifying the child numbers of the ancestor of the object addressed. For example, the third child of the fourth child of the root of the tree would be addressed as "1 4 3". The child number of the tree root is normally "1" (but may be other than one if the location source for the treeloc is a list of nodes).

The objects addressable by a tree location address are determined by the tree rooted at the location source. When the location source is an XML element, the objects addressed are either elements or pseudo-elements. Psuedo-elements are contiguous sequences of character data in the content of elements, spanning from a tag close to a tag open (start tag close to end tag open, start tag close to start tag open, end tag close to start tag open, or end tag close to end tag open). The children of pseudo-elements are the individual characters making up the pseudo-elements.

When the location source of a tree location consists of multiple objects, the tree location is applied to each object in turn. The result is a list of nodes, one from each tree.

The meta-declaration for the treeloc element form is: ]]>

Data Addressing

The character data content of elements is normally only addressable as complete pseudo-elements or as individual characters. However, it is often useful to address character data as a list of tokens, derived through some tokenization processes. For example, the content of an element might be tokenized into blank-delimited words, a list of numbers, or some other token type. Addressing data in this way requires first tokenizing it and then addressing the resulting list of tokens. The data location address (dataloc) element form combines both steps into a single element.

The data to be addressed is the location source of the dataloc element. The tokenization process is indicated by the value of the filter attribute. XML defines the following filter types:

Unnormalized string. The "tokens" are the individual data characters of the location source.

Normalized text. Tokens are contiguous strings separated by white space. Norm is the default filter.

Tokens that consist only of name characters.

Tokens that are SGML names (start with a name start character and consist only of name characters).

Signed integer.

UTC date.

UTC time.

UTC data and time pairs.

Each token is a "line" of data as determined by the record end or line break rules for the location source.

The meta-declaration for the dataloc element form is: ]]>

Reference Location Attribute Form

For referential attributes that are not ID references, entity references, or URLs, an XML processor must be told what form of address is being used for a particular attribute. This is done with the common reference location address (refloc) attribute form. The refloc attribute may be used for any element type that has attributes that are, semantically, referential.

The value of the refloc attribute is a list of name/value pairs where the name is the name of an attribute declared for the element type and the value is one of the location type keywords defined below. If the location type is a query, the value is followed by the name of the notation to which the query conforms.

The location type keywords are:

The value of the attribute is one or more ID references, resulting in a single list of elements. Equivalent to referring to a nmsploc with a namespace value of "elements" where the nmsploc contains the IDs in the attribute value.

The value of the attribute is one or more entity names, resulting in a single list of entities. Equivalent to referring to a nmsploc with a namespace value of "entities" where the nmsploc contains the entity names in the attribute value.

The value of the attribute is a tree location specification. Equivalent to referring to a treeloc whose implied location source is "referrer".

The value of the attribute is a query specification. The keyword QUERYLOC must be followed by either the name "URL" or the name of a query notation declared in the document. Equivalent to referring to a queryloc.

Using refloc with "query URL" is necessary only when the attribute named is not already defined as being referential by the XML-defined semantics of an XML-defined element form.
--=====================_852263361==_ -- 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" --=====================_852263361==_-- Date: Thu, 2 Jan 1997 11:57:26 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re:Can we be more concrete... At 6:49 AM 1/2/97, Digitome Ltd. wrote: >>We may yet have to bite the bullet and allow stylesheets within >>documents: which is a very bad idea, I think. I think this is a bullet we can leave unbitten after all -- HTTP 1.1 and persistent connections should be comonplace by the time XML is actually deployed. So we should assume that HTTP GETs != HTTP session establishments. This makes the issue of separate operations _much_ less of a problem. >Can you explain why [dgd: it's a bad idea] David? Well, it's a bit of a philosophical issue, so we should probably not waste too much time here. The basic idea of SGML is to decouple processing >from document instances as completely as possible: if we put a stylesheet directly into a document, we have recoupled processing and the document. This means that at the least we have an implicit notion of _right_ stylesheet, since there is one distinguished stylesheet that has to be explicitly overridden. This will wamr the cockles of the hearts of ad-men, but acts to impair document re-use. If we are comitting to processing-time binding of processing specifications, I'd rather not mix that with authoring-time binding of such specs. There's also the more minor question of whether it will encourage a presentational style of markup by contributing to a troff-macro mindset on authors' parts. Basically, it offends my sense that architectural separations should be a separate as possible, so that components are trivial to replace. >>But I don't see how we can >>require DTDs for linking, and claim to have eliminated them from XML -- at >>least in the web context, linking is a hard requirement. > >(Trying to anticipate the though processes of non-SGML savvy developers:-) > >XML describes a tree structure. >A sub-tree, when considered a root is a perfectly valid tree. > >Simple to understand stuff. "Technology FOO used to describe Technology FOO". >Most developers grin when they read things like that. It occurs all over >the place in software they use on a daily basis. This is why we finally allowed delayed processing of entities. For well-formed documents this is now true (as it is not, for SGML), and for valid documents it is also true, though you can't validate when parsing a subtree without additional knowledge of the subtree's position in the larger structure. >Going further:- > >. A single XML tree can cleanly contain multiple trees. One for > "real" data. Others for data about data. Bits about bits (in >Negroponte-speak) My little discourse at the beginning expresses why I don't like this. It's the mxing of document semantics and content with processing information that bothers me. >. Hypertext info. (i.e. AF stuff) can be encoded in XML and housed in > a sub-tree. This sub-tree serves to express how the body sub tree is > decorated with attributes for Hypertext semantics. If we put only what I have called the "declarative" parts of hypertext information in the document this might be acceptable, though is likely to be confusing if we put some type information (attribute declarations) in the DTD, and some in the instance (declarations about what they mean). Logically, we haven't violated declarative markup, and processing-independent instances by this, though it it still messy. >. Rendering Style info can be encoded in a sub-tree. I'd rather not. Style info is processing and not semantic, and so belongs outside the document. >. Hitherto-unthought-of-killer-application semantics can be > encoded in a sub-tree. Semantics maybe, processing specs, preferably not. But of course we are here out of the standards realm and into opinion on _good_ styles of XML authoring and application development. >For *valid* as distinct from well-formed XML I have the option of achieving >this via fixed attributes in the DTD as per HyTime approach. > >Pros:- > Single HTTP hit. HTTP 1.1 should fix this. > Developer friendly (IMO) I don't know that separate entities are actually that unfriendly. Parsing with several special-purpose parsers is sometimes easier than parsing the union of the languages... > No need for the DTD at Browser end in order to do Hypertext or any > other document architecture. True. But if we are only worried about rendering without a DTD, > >Cons:- > Duplication of hypertext info in every instance of a given AF set. Another advantage of loose coupling. > How is the hypertext sub-tree recognised. Reserved GI names? Reseved attributes, presumably. Using HT this way would also require a DTD specially constructed not only to declare how links are, but also to declare how the the descriptions of how links are tagged are tagged. This could get confusing. > How do browsers distinguish between data and meta-data for rendering > purposes? This is why splitting information between the DTD and the instance could be annoying. Of course the stylesheet could describe the non-rendering of meta-tags pretty easily, so it would not be a severe problem (though the description might get confusing). >Given that displaying a document with hypertext links is a "rendering" do >we have to consider how Hypertext functionality will impact on rendering >functionality? An XML savvy browser will receive its Hypertext meta-data >somehow. It needs to know that it should not be rendered. This is why the stylesheet may be the best place for both rendering _and_ linking behavior. > >Finally, now that I am loosing the run of myself completely, why not allow >an XML encoding of the DTD to be an optional way of creating valid XML??? This was considered and abandoned as too incompatible with SGML. It would have made adding meta-information easier in some ways, but this is not a decision that is likely to be revisited. -- 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 \__________________________ To: w3c-sgml-wg@www10.w3.org Subject: Re: More proposals -- and some critical implementation issues Date: Thu, 02 Jan 1997 10:06:59 -0800 From: Joe English dgd@cs.bu.edu (David G. Durand) wrote: > [...] > And, there is currently no way that we can > tell whether an application has (or intends to fetch) the DTD for a > document unless we add new DTD intention parameters to HTTP. In other > words, if there is no DTD, we will have no default attribute values. We > decided that this was OK for graphical rendering because we are assuming > that the stylesheet can work without that explicit information. I propose > that we follow the same strategy for linking. [...] > > We may yet have to bite the bullet and allow stylesheets within > documents: which is a very bad idea, I think. But I don't see how we can > require DTDs for linking, and claim to have eliminated them from XML -- at > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > least in the web context, linking is a hard requirement. It was not my impression that one of the goals of XML was to eliminate DTDs altogether; I thought we were only trying to enable "naked parsing". "Naked processing" is a different matter -- it seems pretty clear to me that some applications are going to need to parse (at least part of) the DTD in any case, e.g., in order to process external entity references. I don't see how parsing declarations is any harder than parsing "the stylesheet" -- depending of course on what notation we end up using for "the stylesheet", but if it's DSSSL I'd guess that implementors would have an easier time with a DTD. If bullet-biting looks inevitable, I suggest that we should use SGML's constructs for associating information with element types (#FIXED attributes) over other, as-yet undefined solutions (embedded stylesheets). --Joe English jenglish@crl.com Date: Thu, 2 Jan 1997 11:26:54 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org, peter@techno.com, vtn@techno.com Martin Bryan on Thu, 02 Jan 1997 10:43:46 +0000) Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] (Martin Bryan:) > This is why I want the link information decoupled from the rest of the > document in a way that will allow it to be referenced from any start-point > (hub) document that needs to reference it. That way I can set up one easily > maintainable link set and point all my documents to it. Ideally what I would > then love to be able to do is to prune this application BOS from within the > called document so that I can get the most efficient effective BOS for the > current user. For my, somewhat unusual, web pages I would want this done > under author control rather than user control as I can easily identify how > to prune the well-maintained tree. The light finally dawns. Aha! I think you have an _excellent_ set of ideas here, Martin, if I understand what you're saying. Please check my playback (expressed using HyTime terminology so as to avoid any unnecessary ambiguity or misunderstanding between Martin and me, of which I have had a bellyful): 1. The HyTime bounded object set (HyTime BOS) list specification facilities should permit a session-start ("hub") document to specify that another document actually specifies something I'm going to call, for a moment, the "base" HyTime BOS list. I'm going to call this phenomenon "delegation" of the HyTime BOS specification. (The fact that this other document might also contain all the links in the HyTime hyperdocument is a reasonable and possible scenario, but it is only important that such a scenario be supported; it is neither necessary nor desirable that it be required.) 2. The hub document should then be able to make adjustments to the base HyTime BOS list thus specified, perhaps adding objects to it, and perhaps subtracting objects from it. Such addition and subtraction might be done in terms of the entity tree rooted in the delegated-to document, and it also might be done on an object-by-object basis. 3. After the base HyTime BOS list is assembled and various hub-document-specific adjustments have been made to the list, only then is the resulting HyTime BOS actually loaded by the application, thus becoming the effective BOS. Is that right so far? If so, I have some comments that may be relevant to both XML and HyTime. If not, the following comments may be irrelevant to our XML discussion, but they are still mighty interesting (to me, anyway) on account of their implications for HyTime. (I hope nobody on this list minds if HyTime benefits from the XML discussion!) I think you can do almost all of this with HyTime now, but I think not well enough. The hub document can, in effect, delegate specification of the BOS to another document simply by saying that the other document is in the BOS, and simply not saying that any other document is in the BOS. The hub document can prune the resulting BOS by limiting the number of recursions permitted, once the entity-tree-discovery process has already moved to the delegated-to BOS specification document. But this lacks the kind of surgical finesse needed in the real world, since the entity-tree-discovery process must abort itself at the same recursion level for all branches. Not good for HyTime. So, first of all, I conjecture that the HyTime BOS-entity-tree-discovery process needs to be capable of recognizing, optionally, pruning instructions that occur at some point (or maybe points) other than the root (the hub document). Once the "base" BOS list is established, using the hub document to add objects to the BOS is trivially easy; you just declare them along with the delegated-to document in the same way. However, you can't subtract arbitrary members from the "delegated base" BOS list in HyTime as it stands today; all you can do is prune the entire delegated base at the same level of recursion. These are problems that need to be fixed, I think. So here are some thoughts to ponder. They are intended to be useful for XML as well as HyTime, but, again, they are expressed in HyTime terms. I propose a new concept (and yet another de novo term, sorry): "subhub document". A subhub is regarded by a HyTime application's BOS entity-tree-discovery process as if it were a hub document, in that its declared HyTime BOS (that would have resulted from a BOS discovery process had it been the session-start document) is added to the HyTime BOS declared by the hub document. The hub document delegates such control by designating all subhubs using a special new common notation attribute, "subhub (subhub|nosubhub) nosubhub". In the entity declarations of subhubs, the subhub attribute has a value of subhub. I think Martin's scenario also demonstrates that HyTime users might benefit from having a way to have hub (and subhub) documents not only be able to add entities to the BOS on a case-by-case basis, but also to exclude them from the BOS in a similar way, after the entity-tree-discovery process (the BOS list building process) is over. Maybe to do it by a pathlist of recursively declared entity names, each path leading to an entity to be excluded? I think we'd better avoid specifying these things by physical address, because their physical addresses might by subject to change without notice to the hub document owner, and, more to the point, there is often no easy way of determining whether two physical addresses in fact address the same object. Would we attach the list of excluded entity pathlists to the document element of the hub document? > >Ouch! Also, doesn't this mean that an author can't specify companion > >documents that he can't write on? Sounds impractical. > > To me there is a clear distinction between "what is essential" (i.e. defined > in the application BOS as documents that are specifically referenced as > transclusion type references) and what could be added if the user has time > to get them in the background (i.e. defined in the companion documents). The > first list defines the set of entities that must be retrieved before > starting the session (i.e. those likely to result in delay), the second > defines the set that the system can usefully pre-fetch during any spare > system cycles while the author is reading the file. The second set of > documents may not have links pointed at specifically from the hub document: > it could just be a set of files that are referenced in bibliographic > entries. In this case you don't need to write on the second set. (There will > of course, be cases where you do, so we need some mechanism to whereby we > have dynamic linking to documents once they have been retrieved, as a > background operation.) I like this requirement because it's real. I hesitate to recommend doing something about it in HyTime because it's in the gray zone of almost application-specific-ness. If making this distinction is needed only because some links in some applications indicate transclusions, I'd say we shouldn't make a change in HyTime to cover it. If, however, (as I believe), some associated objects are critical for proper operation of a document (such as legal notices, maybe?), and some aren't so critical, then maybe we do need a two-tiered BOS, one "foreground" BOS to be assembled prior to the giving of any access whatsoever, and the other "background" BOS to be assembled in background time. Is that right? Would this need be answered by yet another HyTime common notation attribute on external entity declarations: foregnd (foregnd|backgnd) backgnd ? I think that would give an author everything necessary without requiring write access to anything but the hub document. (If I understand the requirement, that is.) What do you 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: Thu, 2 Jan 1997 14:46:33 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] > I changed the terminology, not for its own sake, but because I am not > convinced that a HyTime BOS meets the explicitness requirements I think we > require. I could also argue that "working set" is a commonly understood > term in storage management, and in this case the analogy reveals the > intention of the term better. I have another reason as well, which we will > get to later on. > > >> My contention is that the notion of (even restricted) recursive document > >> requirement could be harmful. > > > >How so, if it's restricted? > > Because think that any restriction that's more general than the explicit > selection of indiviual files for inclusion is leaving too many files open > for inclusion. And I think you're asking everyone to accept the idea that they can never delegate responsibility for keeping track of the changing physical addresses of any linked-to or linked-from documents. To me your position seems untenable, simply as a policy matter. It's already too expensive to maintain hyperlinks, and you seem to want to make it even more expensive. And I still fail to see any significant increase in the risk of the BOS getting too large. You can't control the sheer size of linked-to or linked-from documents, or the number of links they contain, even if you list each one separately. So, control-of-overhead horse has already left the barn as soon as you allow any document that you don't control to participate in your BOS. > There's a big difference between what I want to reference, > and what I want to tell a browser to download -- they may sometime be the > same, but they are at least as frequently different. All too true. I think the HyTime BOS management facilities need some judicious tweaking. See my note today in this list on that subject. I'd be interested to know if the two-tiered BOS idea answers obviates your concerns. > HyTime BOS is defined in terms of entity references, and not all XML links > will be via an external entity. At least, I take it as axiomatic that we > are dead in the water if we don't _at least allow_ the creation of links > that contain just a URL in an attribute value. True enough, but URLs that are not backed up by entity declarations will still work just fine in the same way that they already do in HTML -- in one direction only. (However, if you want applications to be aware of the fact that an object is the anchor of some particular external link, you do have to declare where the application should look for that external link.) In HyTime, it's perfectly OK for a link to refer to an anchor that is outside the BOS, and it's perfectly OK for an application to support traversal to such an anchor. The act of traversing such a link means bringing the document or object in which the anchor exists into the effective BOS on an ad hoc basis, that's all. > So some references will not be part of the BOS. I am also one of the > people who argued vociferously (and successfully) that an XML parser _must > not_ be required to follow all entity references. This also makes the BOS > potentially problematic, even for the entities making up a single document. ...but not if you can declare entities without having them automatically wind up in the BOS, right? Again, does the two-tiered BOS idea answer your concern? > As noted above, and for the same reasons we have been re-arguing here for > links, XML processors are _not_ required to pull in a whole entity tree at > once. ...and that's absolutely reasonable. No argument. > Well, my problem is that I think that the term that we need does _not_ > match BOS in every particular, but only in some particulars. So I can gain > both perspicuity (my opinion) and accuracy. Well, David, as you can see, I'm trying to get the best match I can. For whatever it's worth, I'm willing to propose changes to HyTime's BOS notion that will make it work for all of us. The whole question of what exactly constitutes the subject of hyperdocument processing is so terrifyingly fundamental that neither XML nor HyTime can afford to get it wrong. > > 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. > > There is a working example of interconnecting the world's knowledge > bases. It is the WWW. This is in some ways sad, but undeniably true. I can't believe that you mean to imply that the game is already lost and there's nothing to be done. If you thought that, you wouldn't be reading my tedious letters to this list. > I don't have an explicit goal either way with respect to HyTime. The > brief of the group does _not_ include HyTime compatibility. Personally, for > functionality, I am applying a standard to HyTime that I describe as "no > gratuitous incompatibility". I see no reason, technical or offical, why we > should stick to HyTime if we think that HyTime got something wrong. Amen. But you'll forgive me if I keep working to make HyTime right, I hope. (And since that's the primary focus and goal of my working life, I'd have to be crazy to ignore what the most amazing aggregation of hardworking smart people I've ever been privileged to observe has to say on the matter.) > On the > other hand, there is a large amount of good work on the relationship of > hypertext to markup in HyTime. So I think the semantics are mostly right. I > think we can manage to be mostly compatible with the standard as well > (modulo a few PIs a user can add if they need them). I only say mostly in > case there are places (I feel anchor roles are one) where HyTime may impose > a restriction that we can avoid. That happens to be an issue that I have been passionately on both sides of. (As most HyTime committee people can attest.) I think I'm content to allow XML and HyTime to go their separate ways on the question of whether anchor roles should be #FIXED (or effectively #FIXED). XML intentionally does *not* require that the information it expresses conform to a particular model (a DTD). SGML, on the other hand, very solidly (and with extremely good reasons) insists that everything that is expressed conforms with an a priori model (DTD). When you have a conforming SGML document, you know it meets the terms of an explicit "contract" between document authors and application software developers. It means something, therefore, to say "SGML". It's the same situation with the question of fixing anchroles. In the case of XML, evidently there is a requirement that there be no consistency in terms of the semantic roles played by the linkends. In the case of HyTime, however, I want to be able to say that there is a similar contract in effect between applications developers and hyperdocument authors: that it means something to say "HyTime". This does not mean that I am any less interested in XML; on the contrary, the on-ramp may not be the same as the highway, but the highway is pointless unless people can get access to it. My hope is that XML will help make HyTime accessible. (I'm already satisfied that XML is helping HyTime immeasurably in other ways.) > I think we will only need 1 of these senses (Application BOS). This > reflects the reality that an application can do what it wants. Ah, but it can't. What if somebody's server is down, and the BOS that the application would like to assemble can't be fully assembled? You need all three concepts: the one the author specified, the one the application wanted to assemble, and the one the application actually did assemble for use in this session. > We also need > a method (to be determined, though I suggested one route) for an author to > suggest a minimal set of documents that should be in the (application BOS, > Working Document Set) for a document to be at its best. Absolutely. > So I don't want to just say BOS, since that is confusing to those who > know that there are other senses, and I don't want to say "application BOS" > because then we will be using a modifier ("application") on every > occurrence of a realtively recondite term none of whose other senses need > come into our standard. OK, David. I'm certainly not going to make trouble over what to name the baby. I just wanted to make everyone aware that there are lots of things to consider when doing the naming. I didn't mean to imply that you are egomaniacally wedded to the terms you yourself invent. Far >from it. I hate that kind of thing and it offends me when I'm accused of it, which is all too often. If I thought you had that attitude, there would be no doubt in your mind about that that was how I felt. Precision is everything. As long as it's got an agreed-upon definition, we can call it "baldoolifling" for all I care. > You could change it in the "hub" or in the local companion declaration. > But you have to change it _somewhere_, and only in _one_ place. Does the "subhub" concept I proposed in my other note today answer this concern? It doesn't demand that there be exactly one subhub, but I think it would make it possible to do what you want to do, without constraining everyone to use exactly one subhub. > On my proposal, the companion of a companion is a companion (we take > the transitive closure of the companion relation). So we get the same > ability to express things that we have following entity tree. What we have > gained is decoupling of "companionship declaration" from entity > declaration. I can imagine authors who want to do a lot of linking, but not > use entity declarations -- they would be accommodated by this. I can also > imagine that many authors will have links that should _not_ indicate > companions. I detect a possible difference here between what I've proposed in my other note today (subhubs) and what you seem to want. The difference I detect is that you want to declare the physical addresses of companion documents in some fashion other than SGML entity declarations. Perhaps by using UR{L|N}s. Is that right? 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: Thu, 2 Jan 1997 17:39:55 -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:06 AM 1/2/97, Joe English wrote: >It was not my impression that one of the goals of XML >was to eliminate DTDs altogether; I thought we were >only trying to enable "naked parsing". Well, I didn't mean eliminate them for all purposes, but certainly I think an application like MSIE or Navigator should be able to work without a DTD. And that means that linking can't depend on the DTD. >"Naked processing" >is a different matter -- it seems pretty clear to me that >some applications are going to need to parse (at least part of) >the DTD in any case, e.g., in order to process external >entity references. And so I think we can't satisfy the goals of naked parsing (easy implementation of simple processing) unless we can implement naked processing (at least for documents with links and a stylesheet). So we _do_ need naked processing. I have always assumed that many external entity references would live in the DTD subset for exactly this reason. Did I miss something so that this doesn't work? >I don't see how parsing declarations >is any harder than parsing "the stylesheet" -- depending >of course on what notation we end up using for "the >stylesheet", but if it's DSSSL I'd guess that implementors >would have an easier time with a DTD. It's the dowloading of DTDs that people have objected to, not the parsing, per se, although skipping the DTD parser does simplify things by a detectable amount. > If bullet-biting >looks inevitable, I suggest that we should use SGML's >constructs for associating information with element types >(#FIXED attributes) over other, as-yet undefined solutions >(embedded stylesheets). After thinking through the implications of HTTP 1.1's persistent connections I think we may be able to live without biting any bullets at all. I must say that it's going to be hard to fit a whole DSSSL stylesheet into #FIXED attributes. But I agree that this is the best bet for declaring link semantics in the DTD. And stylesheets that can guess these values (say from the element name) need not access DTDs to find their values. -- 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, 2 Jan 1997 17:39:44 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] At 2:46 PM 1/2/97, Steven R. Newcomb wrote (quoting me occasionally): >> >> My contention is that the notion of (even restricted) recursive >>document >> >> requirement could be harmful. >> > >> >How so, if it's restricted? >> >> Because think that any restriction that's more general than the explicit >> selection of indiviual files for inclusion is leaving too many files open >> for inclusion. > >And I think you're asking everyone to accept the idea that they can >never delegate responsibility for keeping track of the changing >physical addresses of any linked-to or linked-from documents. I am baffled. I have shown how this can be delegated to an arbitrary document, or not delegated, depending on the author's desires. I just don't think you understood the proposal in my last posting. Noe last time: Each document should be able to have a list of documents that clients _should_ process along with it (separate from link declarations, entity references or entity declarations). If the documents referenced in this list make a similar requirement of other documents, then the set required expands. _Only_ those documents referenced in this way are suggested for such simultaneous processing, regardless of entity declarations or link occurences. This is recursive inclusion, but along a brand new, author controlled, independent set of references. No-one who is not using ilinks will ever need to use this, as far as I can tell, but it may provide helpful hints as to when _not_ to apply "lazy fetch" policies. > To me >your position seems untenable, simply as a policy matter. I think it would be untenable if that were my position. I want to increse the precision of the author, not decrease it. > It's >already too expensive to maintain hyperlinks, and you seem to want to >make it even more expensive. And I still fail to see any significant >increase in the risk of the BOS getting too large. You can't control >the sheer size of linked-to or linked-from documents, or the number of >links they contain, even if you list each one separately. Yes, but the linked-to documents are irrelevant to my proposal. Only explicit "companion documents" would be included. The notion of pre-fetching along links is what I don't like. It is both incomplete (in the case that I want to include a set of ilinks stored externally without creating an explicit navigational link between them), and over-zealous (I have to do work to exclude documents that I link, so that they don't end up in the BOS). > So, >control-of-overhead horse has already left the barn as soon as you >allow any document that you don't control to participate in your BOS. But if I only allow documents that I do control to be explicit companions of my document, this is not a problem. I don't control the BOS, but merely suggest that the document working set _should_ include certain documents (because they make sense only in relation to one another). >> There's a big difference between what I want to reference, >> and what I want to tell a browser to download -- they may sometime be the >> same, but they are at least as frequently different. > >All too true. I think the HyTime BOS management facilities need some >judicious tweaking. See my note today in this list on that subject. >I'd be interested to know if the two-tiered BOS idea answers obviates >your concerns. It seems too complex to me, because it requires tagging every link with whether or not it is a "BOS0-augmenting" link or note. I don't want to have to control my BOS every time I make a link. And I don't want to have to make "user-invisible" links when I want to control by BOS. And since the notion I am defining is not the HyTime BOS (based as it is on entity reference trees), I find a new term clearer. >.... URLs that are not backed up by entity declarations >will still work just fine in the same way that they already do in HTML >-- in one direction only. (However, if you want applications to be >aware of the fact that an object is the anchor of some particular >external link, you do have to declare where the application should >look for that external link.) Yes, I do. I want to separate that process from link creation entirely, because I don't see that they are closely related. My other point about URLs is that I think we are foolish if we make an important facility like this depend on the use of entity declarations -- most current users will find this indirection quite onerous. In fact, _I_ think that it is onerous for some kinds of simple document reference. > In HyTime, it's perfectly OK for a link >to refer to an anchor that is outside the BOS, and it's perfectly OK >for an application to support traversal to such an anchor. The act of >traversing such a link means bringing the document or object in which >the anchor exists into the effective BOS on an ad hoc basis, that's >all. But I have to declare notation attributes to accomplish this, don't I? Do we even have notation attributes in XML? > >> So some references will not be part of the BOS. I am also one of the >> people who argued vociferously (and successfully) that an XML parser _must >> not_ be required to follow all entity references. This also makes the BOS >> potentially problematic, even for the entities making up a single document. > > ...but not if you can declare entities without having them >automatically wind up in the BOS, right? Again, does the two-tiered >BOS idea answer your concern? I don't want most entities to end up there, and I don't see why I need to declare an entity just to get this behaviour: All I want to say is >> Well, my problem is that I think that the term that we need does _not_ >> match BOS in every particular, but only in some particulars. So I can gain >> both perspicuity (my opinion) and accuracy. > >Well, David, as you can see, I'm trying to get the best match I can. >For whatever it's worth, I'm willing to propose changes to HyTime's >BOS notion that will make it work for all of us. The whole question >of what exactly constitutes the subject of hyperdocument processing is >so terrifyingly fundamental that neither XML nor HyTime can afford to >get it wrong. If you're willing to decouple BOS from entity references, then maybe we're on the same wavelength. Personally, I'm not convinced that there is a unique right answer, which is why I emphasise suggesting co-processing and not requiring it. >> > 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. >> >> There is a working example of interconnecting the world's knowledge >> bases. It is the WWW. This is in some ways sad, but undeniably true. > >I can't believe that you mean to imply that the game is already lost >and there's nothing to be done. If you thought that, you wouldn't >be reading my tedious letters to this list. I just mean what I say. We have already seen an object example that getting basic functionality correct and _as easy as possible_ seems to beat getting the details right. So I want to keep things as simple and orthogonal as possible. And I want to preserve the kinds of simplicity that people expect from the web -- ie. any operation that refers to a document should possible by naming the operation and a URL, without any other stuff intervening. That means _no mandatory entity declarations_ in the definition of linking. >> I don't have an explicit goal either way with respect to HyTime. The >> brief of the group does _not_ include HyTime compatibility. Personally, for >> functionality, I am applying a standard to HyTime that I describe as "no >> gratuitous incompatibility". I see no reason, technical or offical, why we >> should stick to HyTime if we think that HyTime got something wrong. > >Amen. But you'll forgive me if I keep working to make HyTime right, I >hope. (And since that's the primary focus and goal of my working >life, I'd have to be crazy to ignore what the most amazing aggregation >of hardworking smart people I've ever been privileged to observe has >to say on the matter.) I have no objections to improving HyTime, as you should know. In fact, that's one of the reasons I keep paying attention to it -- even attention that I can't afford to spare. > I only say mostly in >> case there are places (I feel anchor roles are one) where HyTime may impose >> a restriction that we can avoid. The rest >That happens to be an issue that I have been passionately on both >sides of. (As most HyTime committee people can attest.) I think I'm >content to allow XML and HyTime to go their separate ways on the >question of whether anchor roles should be #FIXED (or effectively >#FIXED). XML intentionally does *not* require that the information it >expresses conform to a particular model (a DTD). SGML, on the other >hand, very solidly (and with extremely good reasons) insists that >everything that is expressed conforms with an a priori model (DTD). >When you have a conforming SGML document, you know it meets the terms >of an explicit "contract" between document authors and application >software developers. It means something, therefore, to say "SGML". >It's the same situation with the question of fixing anchroles. In the >case of XML, evidently there is a requirement that there be no >consistency in terms of the semantic roles played by the linkends. In >the case of HyTime, however, I want to be able to say that there is a >similar contract in effect between applications developers and >hyperdocument authors: that it means something to say "HyTime". This >does not mean that I am any less interested in XML; on the contrary, >the on-ramp may not be the same as the highway, but the highway is >pointless unless people can get access to it. My hope is that XML >will help make HyTime accessible. (I'm already satisfied that XML is >helping HyTime immeasurably in other ways.) > >> I think we will only need 1 of these senses (Application BOS). This >> reflects the reality that an application can do what it wants. > >Ah, but it can't. What if somebody's server is down, and the BOS that >the application would like to assemble can't be fully assembled? You >need all three concepts: the one the author specified, the one the >application wanted to assemble, and the one the application actually >did assemble for use in this session. Sorry, the one the application _didn't assemble_ has no effect on any behavior that we can specify. There are two concepts still: what the author specified, and what the application did. What can we suggest a processor do with the set of documents that it didn't assemble? The production of error messages is one possibility, but the application can presumably already detect that it failed to access a document, so that base is already covered. >> So I don't want to just say BOS, since that is confusing to those who >> know that there are other senses, and I don't want to say "application BOS" >> because then we will be using a modifier ("application") on every >> occurrence of a realtively recondite term none of whose other senses need >> come into our standard. >OK, David. I'm certainly not going to make trouble over what to name >the baby. I just wanted to make everyone aware that there are lots of >things to consider when doing the naming. I didn't mean to imply that >you are egomaniacally wedded to the terms you yourself invent. Far >from it. I hate that kind of thing and it offends me when I'm accused >of it, which is all too often. If I thought you had that attitude, >there would be no doubt in your mind about that that was how I felt. >Precision is everything. As long as it's got an agreed-upon >definition, we can call it "baldoolifling" for all I care. For that matter, I could live with "Application BOS" as long as the definition is clear. I am partly using a separate term because I want to differentiate my companion proposal from HyTime facts, until I am sure that they are the same thing. So far I am not convinced they are the same. >> You could change it in the "hub" or in the local companion declaration. >> But you have to change it _somewhere_, and only in _one_ place. > >Does the "subhub" concept I proposed in my other note today answer >this concern? It doesn't demand that there be exactly one subhub, >but I think it would make it possible to do what you want to do, >without constraining everyone to use exactly one subhub. I am proposing that every document mentioned as a companion is a "subhub" in the sense that you proposed (I think) and that the current document being processed is always the "hub" (but only respect to explicitly listed companions). And that subhubs can recursively include their companions (if any) as sub-subhubs. Rub-a-dub-dub a sub-subhub in a tub. I just want to keep refrencing, linking, entity declaration, and working set specification orthogonal. The examples are only intended to show that we don't need any additional mechanisms than I have proposed. >> On my proposal, the companion of a companion is a companion (we take >> the transitive closure of the companion relation). So we get the same >> ability to express things that we have following entity tree. What we have >> gained is decoupling of "companionship declaration" from entity >> declaration. I can imagine authors who want to do a lot of linking, but not >> use entity declarations -- they would be accommodated by this. I can also >> imagine that many authors will have links that should _not_ indicate >> companions. >I detect a possible difference here between what I've proposed in my >other note today (subhubs) and what you seem to want. The difference >I detect is that you want to declare the physical addresses of >companion documents in some fashion other than SGML entity >declarations. Perhaps by using UR{L|N}s. Is that right? yes. yes. yes. Hey, we may be getting somewhere! -- 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, 02 Jan 1997 16:03:38 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: My House of Sticks XML Link Proposal All, If you prefer, you can now get an RTF version of my paper at "http://www.isogen.com/papers/xmllink.rtf.gz". The only obvious problem with it is that the element declarations are flowed--not sure which element I should have used to hold the declarations. The file's about 8K. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 02 Jan 1997 17:27:28 -0900 To: Terry Allen From: "W. Eliot Kimber" Subject: Re: My House of Sticks XML Link Proposal Cc: w3c-sgml-wg@www10.w3.org At 03:34 PM 1/2/97 -0800, you wrote: >How about posting it again in ASCII? Try "http://www.isogen.com/papers/xmllink.html". This is an ascii version wrapped in HTML. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 02 Jan 1997 19:29:09 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: My House of Sticks XML Link Proposal At 05:27 PM 1/2/97 -0900, W. Eliot Kimber wrote: >>How about posting it again in ASCII? > >Try "http://www.isogen.com/papers/xmllink.html". This is an ascii version >wrapped in HTML. Thanks to Tim Bray, the location above is now a real HTML document, derived >from the XML source. I also fixed a couple of typos (forgot about the minimization flags and hosed up a global change of "anchor" to "link end"). Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 2 Jan 1997 12:47:37 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu Cc: w3c-sgml-wg@www10.w3.org, w3c-sgml-wg@www10.w3.org Subject: Re: URLs/MIME only? >>Why? I think this depends upon whether you see documents or >>(p)elements as the atomic objects. I think there is a *very* strong >>strong case for looking at elements as atoms, especially when we start >>thinking about transclusion etc. We can build an awful lot upon the >>two forms above in a *simple* and *standard* way. > >The problem that I see is that HTTP and current implementations make a >pretty strong URL<->transmission unit equivalence. XML has a notion of >transmission unit that is a natural one, and that is the entity. So we are >making entities into findamental addressable units. Now we could also make >elements into addressable units, but doing so makes some pretty hard >requirements on servers, if those URLs are to be resolvable. Then I would suggest that linking to servers that do *not* support such a capability be done only with the URL's that that server can understand. Each server has a list of addresses that it manages, and it controls the addresses (ie. servers that don't support sub-document addressing never serve out URL's implying they do). >Now I agree that a dynabase-like approach is the "right" way to build >sophisticated servers, but I think the demands of document parsing, >etc. that are entailed by making that approach mandatory will prevent >the implementation of the lightweight, quick-hack servers that have >driven the evolution of the web. I don't think so. Again, each server controls it's own address space. However, I also think that any XML document that you *could* address directly, will also be small enough so that you can parse it on the fly, and serve out chunks, without significant delays (especially in the face of caching proxies, and client-side caching). For larger documents (SGML/XML), you're going to need something like DynaWeb (not DynaBase) because nothing else will scale as well (ie, linear parsing becomes a real loser after a few hundred kilobytes). Then there is also the question of adressing vs retrieval. Being able to address something is entirely different from being able to retrieve it, and in many cases, you do wish to adress something, but *not* retrieve it, except in the context of the original base document. >>Points 2-4 are red herrings, and fall out of point 1. > >They may not be logically independent, but I don't think they are >red-herrings, either. Doing as you ask requires a rather different model >from the one we have been implictly using: > XML entities <-> URLs to access them > XML elements must be parsed to be detected. I have never seen it explicitly stated that there must be a 1-1 correspondence between a URL and a single given entity. In fact, given content negotiation and whatnot, I doubt that you could actually guarantee it anyway (ever seen a URL that retrieves different objects based on HTTP fields?). While I do agree that this is the *assumed* method, I (a) cannot see such a big problem in creating servers that can serve out elements, and, (b) never argued that all servers *must* have this capability. Rather, I was suggetsing a URL format that is generally applicable to heirarchical data structures. If your server doesn't *have* a heirarchical structure, then it doesn't need to use such heirarchical addresses (I should note that this is a sub-class of the heirarchical case, so the same adress format handles both cases). >Yes, but it prevents the "slap XML files into an existing server, with a >new mime type" deployment apporach. It may be one hell of a convoluted noun >phrase, but it is going to be a common implementation strategy. It doesn't hinder such deployment at all (and in fact, I fully expect that most *initial* implementations will be precisely this). >>God forbid. That would (logically) mean that you could switch encoding >>mid-stream... which is precisely how this fellow interpreted it!! > >Unless I'm wrong, PIs are still legal in XML in general, and they are >unconstrained as to functionality: (though we might want to state that PIs >_cannot_ change parsing behavior, if we don't already). So he might even >_have_ a conforming extension to XML, albeit a pretty vile one. We probably need more language discussing the properties of the PI, or better, get the encoding stuff removed from it (especially as now we have quite a bit of parsing to do before we can even come to the supposed encoding declaration). Date: Fri, 03 Jan 1997 09:53:12 +0000 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] David >>.... URLs that are not backed up by entity declarations >>will still work just fine in the same way that they already do in HTML >>-- in one direction only. (However, if you want applications to be >>aware of the fact that an object is the anchor of some particular >>external link, you do have to declare where the application should >>look for that external link.) > >Yes, I do. I want to separate that process from link creation entirely, >because I don't see that they are closely related. My other point about >URLs is that I think we are foolish if we make an important facility like >this depend on the use of entity declarations -- most current users will >find this indirection quite onerous. In fact, _I_ think that it is onerous >for some kinds of simple document reference. The point is that if we are using HyTime links then we need an entity declaration that can be used to name the link source for a chain of links (we don't want to repeat the same 1024 character URL hundreds of times, we want to give it an id in a well controlled namespace). This is how HyTime works. That entity declaration will contain the URL of the page we want. If you have links to more than one point in that page this method is more efficient than having to respecify the URL on each link. (Otherwise there is an unnecessary overhead.) If the same URL is referenced by multiple documents it should be stored in a subhub BOS that can be referenced by all documents that refer to it. Seems to me that this helps URL management greatly. This is the real bugbear of existing web applications. > That means _no mandatory entity declarations_ in the >definition of linking. But this would make the use of link sources for link chains impossible. Link chains are one of the real gains that HyTime has to offer. If we drop them >from XML we are dead. Without a formally defined sources in the BOS you cannot have a start point for the chain. ---- 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, 03 Jan 1997 09:53:07 +0000 To: "Steven R. Newcomb" , w3c-sgml-wg@www10.w3.org, peter@techno.com, vtn@techno.com From: Martin Bryan Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] Steve Newcomb wrote: >The light finally dawns. Aha! I think you have an _excellent_ set of >ideas here, Martin, if I understand what you're saying. You seem to have grasped exactly what I am saying, though I am going to mention one new thing that may require a minor extension >1. The HyTime bounded object set (HyTime BOS) list specification > facilities should permit a session-start ("hub") document to > specify that another document actually specifies something I'm > going to call, for a moment, the "base" HyTime BOS list. I'm > going to call this phenomenon "delegation" of the HyTime BOS > specification. (The fact that this other document might also > contain all the links in the HyTime hyperdocument is a reasonable > and possible scenario, but it is only important that such a > scenario be supported; it is neither necessary nor desirable that > it be required.) The only thing that I would ask is that it not be restricted to one other document. In my data set I have a section on electronic conferencing standards, and separate sections on video encoding and audio encoding. The electronic conferencing standards section only makes sense if you know about the available video and audio codings, therefore I need to pre-fetch both sets of information links into the conferencing section. Now I could make a separate document that in turn calls both the sets, but it would be neater if I could specify a list of subhubs. (Reading your comments to David I suspect that I've read too much into the phrases "that another document" and "this other document". We need to clarify that multiple subhubs can be applied.) >2. The hub document should then be able to make adjustments to the > base HyTime BOS list thus specified, perhaps adding objects to it, > and perhaps subtracting objects from it. Such addition and > subtraction might be done in terms of the entity tree rooted in > the delegated-to document, and it also might be done on an > object-by-object basis. > >3. After the base HyTime BOS list is assembled and various > hub-document-specific adjustments have been made to the list, only > then is the resulting HyTime BOS actually loaded by the > application, thus becoming the effective BOS. > >Is that right so far? Great summary > So, first of all, I conjecture that >the HyTime BOS-entity-tree-discovery process needs to be capable of >recognizing, optionally, pruning instructions that occur at some point >(or maybe points) other than the root (the hub document). Definitely points rather than point >Once the "base" BOS list is established, using the hub >document to add objects to the BOS is trivially easy; you just declare >them along with the delegated-to document in the same way. > >However, you can't subtract arbitrary members from the "delegated >base" BOS list in HyTime as it stands today; all you can do is prune >the entire delegated base at the same level of recursion. These are >problems that need to be fixed, I think. Agreed >So here are some thoughts to ponder. They are intended to be useful >for XML as well as HyTime, but, again, they are expressed in HyTime >terms. > >I propose a new concept (and yet another de novo term, sorry): "subhub >document". A subhub is regarded by a HyTime application's BOS >entity-tree-discovery process as if it were a hub document, in that >its declared HyTime BOS (that would have resulted from a BOS discovery >process had it been the session-start document) is added to the HyTime >BOS declared by the hub document. The hub document delegates such >control by designating all subhubs using a special new common notation >attribute, "subhub (subhub|nosubhub) nosubhub". In the entity >declarations of subhubs, the subhub attribute has a value of subhub. There is one thing I am not clear on here Steve. My video and audio sections would be subhubs of the video conferencing section, but would be hubs in their own right when called in different contexts. If the subhub attribute is a data entity associated with the entity call used to call the subhub >from the hub document I have no problems. If it is an attribute of the document element of the section being used as a subhub I would have problems. >I think Martin's scenario also demonstrates that HyTime users might >benefit from having a way to have hub (and subhub) documents not only >be able to add entities to the BOS on a case-by-case basis, but also >to exclude them from the BOS in a similar way, after the >entity-tree-discovery process (the BOS list building process) is over. >Maybe to do it by a pathlist of recursively declared entity names, >each path leading to an entity to be excluded? I think we'd better >avoid specifying these things by physical address, because their >physical addresses might by subject to change without notice to the >hub document owner, and, more to the point, there is often no easy way >of determining whether two physical addresses in fact address the same >object. I know in my case that the physical addresses do change. I develop the pages on one system then port them to another systems. All internal addresses are, therefore, expressed in terms of relative addresses from the site home directory. > Would we attach the list of excluded entity pathlists to the >document element of the hub document? I'm not clear how we could do this. Could you give an example please. > >Ouch! Also, doesn't this mean that an author can't specify companion >> >documents that he can't write on? Sounds impractical. >> >> To me there is a clear distinction between "what is essential" (i.e. defined >> in the application BOS as documents that are specifically referenced as >> transclusion type references) and what could be added if the user has time >> to get them in the background (i.e. defined in the companion documents). The >> first list defines the set of entities that must be retrieved before >> starting the session (i.e. those likely to result in delay), the second >> defines the set that the system can usefully pre-fetch during any spare >> system cycles while the author is reading the file. The second set of >> documents may not have links pointed at specifically from the hub document: >> it could just be a set of files that are referenced in bibliographic >> entries. In this case you don't need to write on the second set. (There will >> of course, be cases where you do, so we need some mechanism to whereby we >> have dynamic linking to documents once they have been retrieved, as a >> background operation.) > >I like this requirement because it's real. I hesitate to recommend >doing something about it in HyTime because it's in the gray zone of >almost application-specific-ness. If making this distinction is >needed only because some links in some applications indicate >transclusions, I'd say we shouldn't make a change in HyTime to cover >it. This distinction is independent of whether or not there are transclusions. I simply mentioned the possibility of using it for transclusions because that had been mentioned as a roll for links in earlier discussions. > If, however, (as I believe), some associated objects are critical >for proper operation of a document (such as legal notices, maybe?), Or the audio/video inclusions for electronic conferencing! >and some aren't so critical, Like using XML/SGML to associate text with electronic conference whiteboards! >then maybe we do need a two-tiered BOS, >one "foreground" BOS to be assembled prior to the giving of any access >whatsoever, and the other "background" BOS to be assembled in >background time. Is that right? Exactly what I was after. > Would this need be answered by yet >another HyTime common notation attribute on external entity >declarations: > >foregnd (foregnd|backgnd) backgnd >? Seems a nice simple solution. >I think that would give an author everything necessary without >requiring write access to anything but the hub document. (If I >understand the requirement, that is.) What do you think? Many thanks for formalizing my needs statement Steve. ---- 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, 3 Jan 1997 10:10:14 -0500 To: Martin Bryan , w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] At 4:53 AM 1/3/97, Martin Bryan wrote: >David >The point is that if we are using HyTime links then we need an entity >declaration that can be used to name the link source for a chain of links >(we don't want to repeat the same 1024 character URL hundreds of times, we >want to give it an id in a well controlled namespace). This is how HyTime >works. Well, if it _requires the entity reference,_ then we should not use HyTime. >> That means _no mandatory entity declarations_ in the >>definition of linking. > >But this would make the use of link sources for link chains impossible. Link >chains are one of the real gains that HyTime has to offer. If we drop them >from XML we are dead. Without a formally defined sources in the BOS you >cannot have a start point for the chain.] No, it would make the use of link sources _optional_. I don't have a problem with using entities -- after all we want the advantages. But we cannot have a solution that requires entity delcarations to make simple links. We need to provide the same simplicity people have now, though we can add complexity, where it also adds power. I like chains, but my inclination is to keep them short anyway... Like 1 or two levels. This also means that we don't have to explain to browser manufacturers how to implement cyle-detection in their link-following module. -- 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, 03 Jan 1997 08:34:49 -0900 To: dgd@cs.bu.edu (David G. Durand), Martin Bryan , w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] At 10:10 AM 1/3/97 -0500, David G. Durand wrote: >At 4:53 AM 1/3/97, Martin Bryan wrote: >>David >>The point is that if we are using HyTime links then we need an entity >>declaration that can be used to name the link source for a chain of links >>(we don't want to repeat the same 1024 character URL hundreds of times, we >>want to give it an id in a well controlled namespace). This is how HyTime >>works. > >Well, if it _requires the entity reference,_ then we should not use HyTime. It doesn't require an entity reference. Using my proposed scheme, you could use a queryloc to contain the URL, e.g.: http://www.drmacro.com/bookrev

See my book review site for a draft introduction to HyTime. >>> That means _no mandatory entity declarations_ in the >>>definition of linking. >> >>But this would make the use of link sources for link chains impossible. Link >>chains are one of the real gains that HyTime has to offer. If we drop them >>from XML we are dead. Without a formally defined sources in the BOS you >>cannot have a start point for the chain.] I don't know what Martin means by "link chains". This is not a HyTime term. If he means "location ladders", then you can have location ladders without requiring entity declarations (although the use of entities would be the SGML/HyTime recommended method). If he means "location paths" (a location address that addresses other location address elements), then entities have nothing to do with their support. If he means "a series of links where each link (except possibly for the first and last) share link ends with two other links", then again, supporting that sort of structure is completely independent of how the link ends might be addressed. 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, 3 Jan 1997 12:20:22 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] At 8:34 AM 1/3/97, W. Eliot Kimber wrote: >At 10:10 AM 1/3/97 -0500, David G. Durand wrote: >>Well, if it _requires the entity reference,_ then we should not use HyTime. > >It doesn't require an entity reference. Great! This is important! > Using my proposed scheme, you >could use a queryloc to contain the URL, e.g.: > > http://www.drmacro.com/bookrev >

> See my book review site for > a draft introduction to HyTime. But surely you can also do something like:

See my book review site for ... If not, we still have a problem, because that extra element is not acceptable for simple links. It's not a problem as an option to support TEI linking, or some esoteric linking method. I also think we need to look at the #-sign hack. I've as yet seen no justification for _not_ using URL-compatible link formats. Gavin has argued for a different kind of URL-compatibility, but it still has a real flaw: We can't make link formats depend on the server: so if we have path extensions on URLs, like his proposed "/chapter=4/p=23" then we need browsers to be able to parse these addresses -- and I think that violates the URL opaqueness condition that I stated, along with its consequencs. I want to make clear that I am not saying that extra elements or entity references _cannot_ be used in XML linking, they almost certainly will be needed. However, nothing that can currently be done in HTML should become any harder when using XML -- that would be a prescription for failure. Call me reactionary, but I'm just trying to speak for the people who already know HTML who just want to get the job done -- they may accept additional complexity for additional power, but if what they can already do becomes harder, they won't necessarily take the trouble to enter our brave new world of descriptive markup. -- 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, 03 Jan 1997 17:42:45 +0000 To: "W. Eliot Kimber" , dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] >I don't know what Martin means by "link chains". This is not a HyTime term. >If he means "location ladders", then you can have location ladders without >requiring entity declarations (although the use of entities would be the >SGML/HyTime recommended method). I did mean location ladders. The HyTime TC says (twice, so you have to believe it!) that "The ultimate location source for any location ladder is the root of a grove". It also says "If the location source is a document, subdocument or data entity, the location source is within the grove constructed from that entity". (Note the use of the term entity!) In XML terms, where application dependent groves are not likely to be permitted, this in practice means the root of the file being referenced if no finer resolution is given in the pointer as it has to be presumed that the reference is to a free-standing XML document. While this reference could be done indirectly using a query that contains a URL the SGML way of identifying files is by having the root of the document identified via a uniquely named entity declaration. What I am unclear about is what would constitute a the grove of something pointed to using a URL of the form report.html#point1 if the HTML page pointed to was constructed as follows:

The points raised were: