- From: Martin Bryan <mtbryan@sgml.u-net.com>
- Date: Fri, 03 Jan 1997 09:53:07 +0000
- To: "Steven R. Newcomb" <srn@techno.com>, w3c-sgml-wg@www10.w3.org, peter@techno.com, vtn@techno.com
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/
Received on Friday, 3 January 1997 04:54:52 UTC