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:
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: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"
An
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
Documents are said to be <?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.
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.
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.
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
XML reserves the term
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
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
Links that are not one of their own link ends are
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
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.
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
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 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.
#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.
FIRST, LAST, or ALL.
The default is ALL.
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:
]]>
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:
]]>
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 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.
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).
Every location address element has a
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
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
The meta-declaration for location source attributes is:
]]>
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:
]]>
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.
The meta-declaration for the queryloc element form is:
]]>
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
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:
]]>
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 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.
filter
attribute. XML defines the following filter types:
The meta-declaration for the dataloc element form is:
]]>
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.
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.:
>
>
> 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" The points raised were:
>> 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 ...
Certainly you can do this (it's the whole point of the refloc facility).
But I was trying to satisfy Martin's requirement for a re-uable ID
reference to a URL.
>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:
I think the #-sign hack is a reasonable solution. A similar facility has
been proposed for the SGML revision (but not designed to the point where we
are confident in the final sytax) where you can combine an entity name with
an ID to do simple direct cross-document ID references. I think the #-sign
hack is consistent semantically with this proposal: in both cases you're
binding a name to the object that defines the name space. The only
difference is the way you name the name space (entity vs. direct URL
reference).
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 14:08:17 -0500
From: gtn@ebt.com (Gavin Nicol)
To: w3c-sgml-wg@www10.w3.org
Subject: Re: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)]
>>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:
>
>I think the #-sign hack is a reasonable solution.
I have no problem with the # hack being used by servers that
can process it. I do not think it should be standardised.
Date: Fri, 03 Jan 1997 12:03:06 -0900
To: w3c-sgml-wg@www10.w3.org
From: "W. Eliot Kimber" The points raised were:
> The points raised were:
>> The points raised were:
See my book review site for
a draft introduction to HyTime.
I see two problems here:
a. the current paradigm (however faulty or misleading) is that
element _content_ is destined for display/formatting: browser
authors will need a shift if they are to handle content which
gets used for some other purpose;
b. the extra level of indirection is going to be a major
stumbling-block for authors accustomed to HREFs.
I have always favored the principle that if you strip away all element
markup from an instance, you should be left with readable continuous
prose -- unformatted, yes, but essentially "the text" of the document.
I've run up against this before -- Eve and Terry know my mixed
feelings about the way DocBook expects INDEXTERM to be used -- but I
am still left with a very uneasy feeling about DTDs which expect
indirect referential material to be inserted as element content
instead of attribute values.
But surely you can also do something like:
See my book review
site for ...
This is the obvious way to do it for simple one-way links where the
return unspecified, and presumed to be the function of the browser's
BACK button: it may not have the formal elegance of a queryloc, but to
someone whose business is the text, not the markup, it seems to make
more sense. For more complex associations, I agree completely that we
absolutely need the more powerful methods of HyTime or TEI or whatever.
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.
If I read this right, we have three choices for implementing the more
complex addressing:
i) break and rewrite the rules for URLs (and probably HTTP as well)
and allow arbitrary strings including spaces -- somehow;
ii) stick to the existing rules, hexify [^A-Za-z0-9], and either
educate authors to do it in their sleep, or someone write nice
little pop-up editor functions that do x-www-urlencoding on the
fly;
iii) extend the existing mechanisms (in transmission as well as at
the server end) to catch TEI-EPN or whatever, and pass it to an
embedded parser-searcher which will perform the relevant
functions.
David wrote:
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.
I think you're right to be concerned, and I think we do need two
levels: a transitional level which provides essentially what we can be
done with HTML functionality, but on a more structured and rational
basis; in preparation for a higher level which allows the
implementation of much greater things.
///Peter
Date: Sat, 04 Jan 1997 13:24:58 -0900
To: Peter Flynn
> See my book review site for
> a draft introduction to HyTime.
>
>I see two problems here:
>
> a. the current paradigm (however faulty or misleading) is that
> element _content_ is destined for display/formatting: browser
> authors will need a shift if they are to handle content which
> gets used for some other purpose;
>
> b. the extra level of indirection is going to be a major
> stumbling-block for authors accustomed to HREFs.
The general architectural name remapping feature lets you map content to
attributes (and visa versa), so you can easily have this form of URLLoc:
, ...
Aaa....
The figure entity doesn't contain links (that's not to say graphics can't,
just that fig349 does not). But my-ilinks contains all kinds of crucial info
-- like maybe 99% of the links applicable to this document! It seems to me
we most definitely want a way to say "that entity over there has links that
you really should make available when viewing this document". This is not hard.
You sure don't want to have to fetch every entity a document may mention,
just *in case* it has links in it. This would be enormously slow and
painful, and the time is wasted, because the user probably isn't going to
actually follow *most* of the links that are around. Imagine the Web if
every time you followed a link your browser starting going off to fetch all
the document that are 4 links away or les... Being able to bound recursion
levels is only an illusion of help -- even one level is way too much of a
performance penalty (not to mention that integers other than zero and one
are almost always a sign of design problems in computing systems).
Steve D
Date: Mon, 06 Jan 1997 18:11:00 -0600
From: len bullard
Qqq.
Bbb.Q2q2.