Date: Sat, 1 Mar 1997 14:40:33 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: ERB decisions on the LINKTYPE proposal >At 01:22 25.02.97 +0100, Tim Bray wrote (in his posting entitled "ERB >I would like to thank the ERB for its serious discussion of my proposal, >and Tim especially for his thorough report. However, I am disappointed >that none of those members of the ERB that are opposed to the proposal >have seen fit to explain their reasons in this forum. Is that not what >this list is for? > >Up to now, the only counterarguments that have been presented have been >David Durand's (by his own admission) knee-jerk objection that "LINK is >widely avoided" and "controversial", Well, I was trying to lighten up the tone of my objection, not discredit it. I think that LINK in SGML is poorly designed, inflexible, under-defined -- to the point that few have dared to implement it -- and in addition strongly detested by a lot of knowledgeable SGML users. Now we can certainly steal the (by your own admission below, needlessly verbose) syntax of LINK to mean something well-defined, but given the forgoing, why should we? >Neither of these arguments disprove my contention that the LINK-based >mechanism is a powerful and elegant way of rendering a very large class of >existing documents XML-processable without having to modify either the >DTD or the instance. (I do not suggest that this should be the *only* >mechanism allowed: Obviously, specifying the attributes in the document >and/or declaring them in the internal subset are suitable alternatives >where the problem of multiple attlist declarations doesn't arise.) Since LINK attributes are specifically defined to be in a separate namespace from normal attributes, this mechanism will require additional verbiage to make it work for SGML systems. Naturally, it also raises the practical bar for SGMl processing of XML documents to include the rarely implemented, widely detested feature. Elegant and powerful are not the words that come to my mind. >There remains the objection (brought to us second-hand by Tim) of >"several members" of the ERB who "find the syntax [of the technique], and the prospect of explaining it, repellent." > >I find this argument so unlikely that I have it under suspicion of being >vicarious. Look once more at the difference between the syntax which >the consensus on this list would regard as ideal (if it were not for >the problem of multiple attlists), and the LINK-based syntax I have >proposed: I can think of several on the ERB who might react that way ... but they can speak for themselves... I certainly find Tim's statement eminently beliveable. >"Ideal": > > xml-link CDATA #fixed "xml-tlink" > > ]> > >LINK-based: > > > xml-link CDATA #fixed "xml-tlink"> > (2) > ]> > >Now, while I agree that we could and would have come up with a simpler syntax >if all we wanted to do was declare additional attributes, I do not see that >this is so verbose, complicated or hard to explain that it should be rejected >for that reason alone. We have to deal with the two namespaces... We have a whole new construct, we now have 2 kinds of attribute declaration (are they equivalent or not?). And we have a construct that for many committed SGML users is a red-flag. Seems technically and politically inferior to me... >The only real difference lies in the two lines marked (1) and (2). The ONLY >parts of these two lines which are variable (and need to be "explained") are >the document type name ("tei.2") in line (1), and the list of element types >("xref") in line (2). EVERYTHING ELSE would be fixed in the xml-link spec. >(Over and above this, a note explaining that the exact choice of syntax was >governed by the requirement to keep XML 100% SGML conformant, would probably >be in advisable.) > >That's all that is required, and it can be done with just one additional >production. And perhaps the confusion of using the keyword LINK as part of the hypertext mechanisms for XML, where it will NOT identify a hypertext link will also be significant and detrimental. >Remember too, that most of the people we will be explaining this to will be >those that already have a substantial body of SGML-encoded information that >they want to deliver using XML. They will have no problem appreciating the >aptness of the LINK-based solution (unless, of course, they too suffer from >mindless LINKophobia). I'ma afraid that I've spent many hours trying to understand LINK and I have never seen that it meets a critical need, or has a coherent meaning, semantic or operational. I have a _mindful_ LINKaphobia, as do many. Don't put words in my mouth. >So please, members of the ERB: Present some well-founded counterarguments >before rejecting this proposal out of hand. The foregoing are _perhaps_ more ill-tempered than they are well founded, but I think they are both. Chip-cheerio, -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 1 Mar 1997 15:40:49 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: ERB decisions on the LINKTYPE proposal [Steve Pepper:] | I would like to thank the ERB for its serious discussion of my | proposal, and Tim especially for his thorough report. However, I am | disappointed that none of those members of the ERB that are opposed to | the proposal have seen fit to explain their reasons in this forum. Is | that not what this list is for? Not primarily, no. The WG list is primarily for input to the ERB, not output from it. The primary ERB outputs are draft specifications, and we are meeting double-time in order to get them done. | "Ideal": | | | ]> I note that you agree with the ERB that this is the ideal solution. | LINK-based: | | | | (2) | ]> | | Now, while I agree that we could and would have come up with a simpler | syntax if all we wanted to do was declare additional attributes, That is all we want to do. | I do not see that this is so verbose, complicated or hard to explain | that it should be rejected for that reason alone. It's not being rejected for any reason. It's being put on the list of technically sound but less-than-ideal alternatives that will be considered if we can't have the ideal. We have good reason to think that we will have the ideal because (a) it is among a short list of changes to 8879 that we are in the process of proposing to ISO and (b) the necessary revision is intelligent, obvious, and noncontroversial. If for some reason the ideal solution is not incorporated into 8879 so that we can use it in XML, then we will consider the less-than-ideal alternatives. Two such are your LINK proposal (for which many thanks) and something based on a PI. I personally am among those who would prefer the PI to the LINK proposal. A large part of the target audience for XML over the long run will consist of people who don't know SGML. For these people, the lines | (2) are just voodoo and will be considered ISO obfuscation at its worst. Those of us who are going to be in the position of explaining the invocation of this gibberish at the top of every document fragment don't much relish having to tell our students to shut up and stop asking questions. (Telling someone who doesn't know about SGML and doesn't need to know about SGML that this apparent nonsense is "governed by the requirement to keep XML 100% SGML conformant" is just a polite way of telling them to shut up and stop asking questions.) Perhaps one has to have had the experience of explaining to highly competent computer scientists why adherance to a standard they don't like requires them to define HTML constructs in contorted ways in order to fully appreciate this point, but I can tell you that such experiences are not pleasant. This prospect would incline me to oppose the LINK solution even if it did not contain the extraordinarily unfortunate word LINK, which in my opinion is confusing enough in an Internet context to eliminate the proposal from consideration on that basis alone. Happily, the chances of our getting the form that we all agree would be ideal look pretty good at the moment, so if our luck holds, this issue will be moot. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Mar 1997 18:28:55 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.1 b-h: ROLE & LOCATOR attributes Dimension 1: Which pieces of information should be specified for possible inclusion in linking elements? b. Type c. Role d. locator e. caption f. behavior g. locator scheme (e.g. URL, FPI, TEI locator) h. others [nominations encouraged] ERB consensus: - A linking element may have a LINK ROLE attribute - There may, per resource, be RESOURCE ROLE attributes - LOCATOR attributes are obviously required per resource The decision on LOCATOR SCHEME is deferred until we tackle addressing The question of whether these are optional or required remains undecided. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Mar 1997 18:29:03 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.1 b-h: BEHAVIOR Dimension 1: Which pieces of information should be specified for possible inclusion in linking elements? ... f. behavior ... This one has been tough. Since we put in immense amounts of time, I will try to reproduce some of our discussions. Some of the options: a. say nothing about behavior; leave it to the apps and to stylesheeting b. provide a behavior bucket; an attribute in which to pass behavior info, but specify nothing about what goes in there c. provide one or two attributes governing simple abstract axes of link behavior policy, with lots of room for user-agents/clients to devise mechanisms to meet the policies d. provide a rich, detailed, set of behavior specification rules that people such as users of EBT products, TEI, and HyTime have come to expect. (a) and (b) seem the safest in terms of avoiding doing something really stupid. However, there was stringent opposition from those speaking on behalf of the authors, who wanted some (even if only abstract) way to signal whether a link, when activated, should cause the replacement of the current display, or transclusion behavior; they claimed that without this, there was no interoperability. It is also material that on the WWW, there are at least two well-defined link behaviors, that of the Subject: 3.1.a All linkage info in markup not data? 3.1.a Should we have a principle that all linkage information is encoded in GIs and/or attribute values, never in character data? No. ERB Consensus was that this doesn't need saying and may unduly constrain design decisions. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Mar 1997 18:28:59 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.1 b-h: LABEL attributes Dimension 1: Which pieces of information should be specified for possible inclusion in linking elements? ... e. caption ... ERB consensus: - we will refer to this as a Label, not an explainer or caption - there is strong support for having labels. However, the ERB is unhappy with allowing only a simple character string; how does one support multilingual labeling, or labels which are graphic? Our provisional solution is to support both a RESOURCE LABEL attribute and/or a RESOURCE LABEL LOCATOR attribute, the latter being used to locate and retrieve a structured label. But then do we need a LABEL LOCATOR SCHEME? Or make it use the same scheme as the resource locator? We decided to defer this until we had a better understanding of linktypes and addresses. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Mar 1997 18:29:09 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.2.b Locators in attributes or elements? 3.2.b Should the locators of a general link be packaged in attributes as in HyTime, or as child elements as in the initial draft? Consensus of the ERB is to use subelements to package up locators in extended links. The simplicity of doing it all with attributes was appealing, but there are two big problems: - it becomes awkward to associate locators with individual metadata - it becomes necessary to overload attribute values with space-separated tokens or some such that are used to help interpret the rest of the attribute values. Eliot assures us that this is legal HyTime, given the right grove plan. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Mar 1997 18:29:13 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.4 New Item: unify simple and extended links During the meeting of March 1st, the ERB agreed to package up xlink locators in subelements. Jean Paoli pointed out [but I have agreed to bring this forward since he's on the road] that the declarations and attlists for simple and extended links are VERY similar; and it might be appealing to allow one locator to exist within the start-tag of an extended link, such that an extended link is just a simple link with child elements. E.g. One virtue of this is that we can go to the web-heads and say "not only have we given you a powerful extended link facility, but you can do it just by adding children to your existing is different from an extended link, we'd still need the archform-like attribute to tell them apart - it would be appealing, in an xlink with locators in child elements, to use ROLE or HRTYPE attributes in the parent linking element to establish defaults for all the child elements... does having a locator in the parent screw this up? Input requested. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Mar 1997 18:29:07 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.2.a Name for generalized multilink 3.2.a What should the generalized multiway link be called? Multilink, General Link, Independent link, anything else? There has been no vote in the ERB on this. But "Extended Link" seems to have taken the world by storm, and that's what we say in ERB discussions now; if anyone has a problem with this they should holler now or it will just become a de fact choice. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Mar 1997 18:28:37 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: ERB decisions on the LINKTYPE proposal At 05:46 PM 01/03/97 +0100, Steve Pepper wrote: >There remains the objection (brought to us second-hand by Tim) of >"several members" of the ERB who "find the syntax [of the technique], and the prospect of explaining it, repellent." ... >Remember too, that most of the people we will be explaining this to will be >those that already have a substantial body of SGML-encoded information that >they want to deliver using XML. They will have no problem appreciating the >aptness of the LINK-based solution (unless, of course, they too suffer from >mindless LINKophobia). ... >So please, members of the ERB: Present some well-founded counterarguments >before rejecting this proposal out of hand. Well, *I* was one of the people in the ERB unhappy with the Subject: 3.a List link required? 3.a. The initial draft does not have any construct analogous to the "List Link" construct in Eliot's proposal. Do we need one? The ERB detects no strong requirement to proceed on this in the near term. Once the shape of the Extended Link is better-defined, we may wish to revisit this. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Mar 1997 18:39:22 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: ERB work on 3.* (Linking Elements) issues The ERB has now put two meetings work in on this set of issues and is nowhere near done. Not surprising, given the importance of the issues. One of the factors holding us back a bit has been the fact that the discussion in the WG on the 3.* issues has been lacking in both volume and depth. Reasons for this might be (a) that the WG is tired (the ERB is), (b) that the WG is busy on other things, and (c) that the WG has substantially less experience in these issues than in those that came up in the XML language discussion. Partially as a consequence, the following decisions include some constructs and ideas that were made up on-the-spot in the ERB without WG discussion. For these reasons, this set of decisions would benefit from particularly close review by the WG. Unfortunately, due to workload and brain dysfunction caused by illness, I do not have ERB attendence rosters and votes. However I *believe* that none of the decisions below had any dissenters; if I've missed any I'd appreciate corrections from the wronged ERB members. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 02 Mar 1997 08:03:27 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.4 New Item: unify simple and extended links At 18:29 1/3/97 -0800, Tim Bray wrote: >Some problems come up: > >- is the locator that's in the parent element somehow distinguished > or special, as opposed to all those in the child elements? In some cases they will have a different significance, in others they may not. One useful difference I could envisage is that fragment identifiers in the embedded elements could refer to the document identified by the container, rather than to the document they are embedded within. e.g. OII Standards and Specification List SGML XML The list of pointers to relevant places in the OII Standards and Specification List could then be displayed as a menu whose title was the contents of the containing link and whose entries were the contained anchors. >- since a link containing another link > is different from an extended link, we'd still need the archform-like > attribute to tell them apart A simple FORM=SIMPLE and FORM=EXTENDED attribute that defaults to SIMPLE is all that is needed. All extended links need the extra attribute to trigger the embedding. The problem of what to do with existing HTML links that include embedded images is difficult in that such elements need to be identified as FORM=EXTENDED, which can only be done by analyzing the context. (This can be done easily on any SGML parser that supports LINK!) >- it would be appealing, in an xlink with locators in child elements, to > use ROLE or HRTYPE attributes in the parent linking element to > establish defaults for all the child elements... does having a > locator in the parent screw this up? Given the above example I would use role as follow: OII Standards and Specification List SGML XML I would contend that role and locator can serve a useful role in all situation. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 02 Mar 1997 15:23:47 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Re: 3.1 b-h: BEHAVIOR At 18:29 01/03/97 -0800, Tim Bray wrote: >There will be an attribute named ACTUATE, which may have one of three values: > >AUTO - means that the link should be traversed and used when encountered; > that the display or processing of the resource where the traversal > started is not considered complete until this is done (e.g. HTML USER - means that the link should not be traversed until there is an > explicit external request for this to happen (e.g. HTML PUSH - means that the resource is volatile, subject to change, and > should be processed immediately and continuously. [I wasn't at the ERB meeting where this was decided.] I have two problems with this: - I'm not convinced that all combinations of SHOW and ACTUATE make sense, for example, SHOW=REPLACE ACTUATE=AUTO. - I think PUSH is on a slightly different axis. If I can have SHOW=NEW and ACTUATE=PUSH, which presumably means the browser pops up a new window automatically and then keeps refreshing it, why can't I also have something that means the browser pops up a new windows when the user asks and then keeps refreshing it. PUSH seems to be saying something about the volatility of resource which is a different issue from what the appropriate behaviour is for links to the resource. James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 14:52:16 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: ERB decisions on the LINKTYPE proposal At 20:40 01.03.97 +0100, David Durand wrote: >>They will have no problem appreciating the >>aptness of the LINK-based solution (unless, of course, they too suffer from >>mindless LINKophobia). > >I'm afraid that I've spent many hours trying to understand LINK and I have >never seen that it meets a critical need, or has a coherent meaning, >semantic or operational. I have a _mindful_ LINKaphobia, as do many. Don't >put words in my mouth. I'm sorry if David (or anyone else) thought I was accusing him personally of mindless LINKophobia. That certainly wasn't my intention. (For the record, neither was I accusing Martin, who has been an advocate of LINK for a long time.) Actually, there are many kinds of LINKophobia, including the _myopic_ form, found amongst otherwise quite thoughtful people. David is not the only one who has "spent many hours trying to understand LINK". I did so myself, without getting very far. I have yet to see an exposition of LINK which provides more enlightenment for the uninitiated than it does confusion. For me, the basic idea fell into place when I was doing some work on ISO 12083 and the ICADD SDA mechanism. That led to an article about LINK that some people have found helpful. If anyone's interested they can find it at http://www.falch.no/people/pepper/link.htm. In fact LINK is extremely simple. Its basic purpose is to allow us to separate and algorithmically associate structure and processing. Or as Goldfarb puts it in the handbook (p.93): "In a nutshell, LINK lets you associate processing-oriented attributes with a start-tag without actually putting them there." (Actually, the chapter from which this is taken, "Link in a Nutshell", _is_ a pretty good exposition provided you don't let yourself get distracted by his choice of examples.) But it wasn't my intention to provide a tutorial here. All I really wanted to say is that I have yet to come across someone who really _understands_ LINK and still doesn't appreciate its value. Now, regarding David's arguments, they fall into two broad categories: There are the merely assertive... > LINK in SGML is poorly designed, inflexible, under-defined >-- to the point that few have dared to implement it -- and in addition >strongly detested by a lot of knowledgeable SGML users. >... >And we have a construct that for many committed SGML users is a red-flag. >Seems technically and politically inferior to me... I see no point in bandying adjectives here. I want to know *why* people think LINK is all those nasty things. *Why* it is detested. *Why* a red flag. [The Norwegian flag is red, by the way.] >Elegant and powerful are not the words that come to my mind. Adjectives again. I plead guilty to having used them without further explanation. If anyone wants to know *why* [I think] LINK is powerful, just ask. I will be happy to attempt a clear, concise and (hopefully) convincing explanation -- with XML-related examples. ...and there are arguments of more substance: >Since LINK attributes are specifically defined to be in a separate >namespace from normal attributes, this mechanism will require additional >verbiage to make it work for SGML systems. Naturally, it also raises the >practical bar for SGMl processing of XML documents to include the rarely >implemented, widely detested feature. I'm not quite sure what David's objection is here. As I already pointed out, SP (and nsgmls) already support LINK, so it will not be a major task for any systems based on this parser to add the required capability. LINK is also supported by another important parser, Mark-It, upon which many other products are built (including at least one pre-eminent SGML editor, as far as I know). Systems that don't support LINK today will have to be enhanced to cover the very restricted subset that I am proposing. That shouldn't come as any surprise: Most SGML systems that want also to become XML systems will need some slight adjustments anyway. (For example, I just tried opening a simple, valid XML document containing a self-identifying empty element in three different SGML editors. They all croaked.) >I can think of several on the ERB who might react that way ... but they can >speak for themselves... I certainly find Tim's statement eminently >beliveable. Me too. I do hope they speak for themselves. >We have to deal with the two namespaces... We have a whole new construct, >we now have 2 kinds of attribute declaration (are they equivalent or not?). * We do have two namespaces. Is that a major problem? I am not enough of a programmer to be sure, but I don't think so. * We do have a new construct which isn't in the November draft. However, it is just a one-production, simple wrapper around an existing construct. * We don't have 2 kinds of attribute declaration. Both are [141] attribute definition list declarations (in SGML terms) and [48] Attribute list declarations (in XML terms), but there is obviously a difference in the groves that will result from using one rather than the other. >And perhaps the confusion of using the keyword LINK as part of the >hypertext mechanisms for XML, where it will NOT identify a hypertext link >will also be significant and detrimental. Ah, yes. I was expecting that objection. I didn't want to confuse the discussion at this point, but what I really intend to propose is something more along the following lines: ]> (This is still 100% 8879, of course.) What we would then be talking about would not be the "link type", but the "processing specification". Would that allay people's fears of confusion? In sum: I do not believe that any of David's arguments of substance provide sufficient grounds for rejecting the proposal. Best regards, Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 07:34:07 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 3.4 New Item: unify simple and extended links Tim wrote: | which is slightly confusing in the context of talk about pointing off to labels, but in this context I take the hrefs to be the actual clinks (now called xlinks?). So there isn't any label in this example. Without it, isn't cleaner? And if you add in labels, it's much cleaner: foo bar baz But I suspect I'm missing something. What is it? Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 07:55:44 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Tim wrote: | So, we ended up with (c). The ERB consensus is that there will be two | attributes specified to control behavior; the names and values given | below are provisional. | NEW - means that upon traversal of the link, the indicated resource should | be displayed or processed in a new context, not affecting that of the | resource where the traversal started (e.g. like HTML To: w3c-sgml-wg@w3.org Subject: Couldn't XML allow and ignore omitted tag minimization When this was brought up at Tuesday's SGML Open Technical Committee meeting, Jon suggested I post this despite the fact that this issue was decided once (and despite the fact that Jon appeared to disagree with me on this). Although I thought I was following all our discussions, I missed the fact that XML as currently defined would not parse a DTD that contained omitted tag minimization (those "- -" and "- O" things in element declarations). I understand that XML has nothing to do with omitted tag minimization since it uses OMITTAG NO. I also understand that it cannot be a goal of XML to be defined in such a way that all existing SGML is valid XML. However, this is one case, for me, where we can gain a large practical advantage for what seems to me to be a very minimal addition to the spec and to implementations. Since OMITTAG will always be NO, all I'm asking is that we define the XML grammar so that an optional omitted tag minimization field in an element declaration would be allowed but be ignored by an XML processor. Note that this doesn't affect what we think will be the great bulk of light weight read-only clients, since most of these implementations won't read the DTD at all. So all we're talking about are those XML tools (since SGML already works this way) that process a DTD, and all we are asking is that they allow (and ignore) a couple optional characters in an element declaration. The benefit here isn't that some (probably small) number of existing DTDs will now be valid XML DTDs without modification (though that is a true statement), but rather that a DTD can now be written that will work in multiple situations. It would now be possible to write a DTD that both works with an XML processor as well as works with an SGML tool that may use OMITTAG YES. If we don't allow omitted tag minimization, I fear we will increase the number of cases were people feel they must maintain two versions of every DTD (the fact that people like to have omitted tag minimization in their DTDs should be obvious given the fact that practically all common DTDs out there include this information). Can we reconsider allowing the omitted tag minimization in element declarations in XML? paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 02 Mar 1997 17:39:22 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: ERB work on 3.* (Linking Elements) Lines: 71 [crossposted to xml-dev in error] Forwarded message follows: > X-Mailer: PCElm 1.10 > Lines: 60 > Sender: owner-xml-dev@ic.ac.uk > Precedence: bulk > Reply-To: Peter@ursus.demon.co.uk (Peter Murray-Rust) > Status: R > > Tim, > I'd like you and the ERB to know how much I appreciate the work > the ERB is doing, and also that I think it's a very effective process. > Personally I'm happy to work with whatever comes out - I trust the ERB to > come out with the most workable solution that the associated brainpower > and experience can muster. [I think it's a credit that on xml-dev (which > is discussing how to implement PhaseI) no-one so far has suggested that > the spec got things wrong, or is ambiguously worded, or otherwise > unimplementable.] > > In message <3.0.32.19970301183622.00b3fb54@pop.intergate.bc.ca> Tim Bray writes: > > The ERB has now put two meetings work in on this set of issues and is > > nowhere near done. Not surprising, given the importance of the issues. > > One of the factors holding us back a bit has been the fact that the > > discussion in the WG on the 3.* issues has been lacking in both volume > > and depth. Reasons for this might be (a) that the WG is tired (the > > ERB is), (b) that the WG is busy on other things, and (c) that the WG > > has substantially less experience in these issues than in those that > > came up in the XML language discussion. > > I cannot answer for anyone else, but I am (c). [I think it's also > going to be a problem in PhaseIII.] I shall (I hope) have something to > say about addressing in PhaseII (I assume that's still to come). > > >From my own perspective as a web hacker, I can probably hack solutions to most > of the proposals so far, so what matters is whether: > (a) people outside the WG, outside SGML, will understand the result. > (b) any decision is more constraining than any other. > > At present I am implementing the simplest approaches (HREF-like and IMG-like) > in JUMBO and can probably manage your next lot (with a struggle, and not > very efficiently, but that's not the point). As long as the rules are > clear, whether we have link information in attributes, GIs, contents or the > whole lot is probably manageable. It's more a question of whether confusion > will result. > > [...] > > As I mentioned on xml-dev I was talking to an important organisation in our > community who were very keen on XML, but 'hoped [the ERB/EG] didn't make it > too complicated'. In a sense, therefore, there are already two levels of > indirection - people like me have to understand it and then carry the message > to a wider community. If _they_ in term have to educate staff, the system > needs to be fairly self-explanatory. Where possible, therefore, I will > cast a meta-vote in favour of the 'most obviously understandable solution > (without prior SGML/HyTime knowledge)'. > > To this end, any short example documents illustrating your conclusions so > far would be extremely valuable. Essentially: 'This is what we are > suggesting: can you (a) understand what it is meant to do? (b) think it > can be implemented? (c) do everything that you want to do? (even if some > solutions creak a bit).' We could then try to feed back on these (more > concrete) documents. > > P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 02 Mar 1997 12:01:32 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 3.1 b-h: BEHAVIOR At 03:23 PM 02/03/97 +0700, James Clark wrote: >I have two problems with this: >- I'm not convinced that all combinations of SHOW and ACTUATE make sense, >for example, SHOW=REPLACE ACTUATE=AUTO. I agree that this combination may not be useful, but it does "make sense" in that it's clean & clear what it means; as soon as you hit this link, traverse it and replace the current doc with the results. Actually, it might have a use - sort of a user-controlled redirect; consider what happens if you replace a document on the web with go to new location >- I think PUSH is on a slightly different axis.... > PUSH seems to be saying something about the volatility >of resource which is a different issue from what the appropriate behaviour >is for links to the resource. I agree; I would be happy either to lose PUSH or to put it on a separate axis named VOLATILITY or some such. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 12:41:55 -0800 From: Terry Allen To: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Tim wrote: | At 03:23 PM 02/03/97 +0700, James Clark wrote: | >I have two problems with this: | >- I'm not convinced that all combinations of SHOW and ACTUATE make sense, | >for example, SHOW=REPLACE ACTUATE=AUTO. | | I agree that this combination may not be useful, but it does "make | sense" in that it's clean & clear what it means; as soon as you hit | this link, traverse it and replace the current doc with the results. So only the first such link will ever be encountered, at least by the application? Unless the application is running disconnected >from the Internet (e.g., the document was received in email)? Then behavior is undefined? (Just asking.) On the same line, if SHOW=INCLUDE ACUTATE=AUTO, does the processor act on this info or does the application? Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 15:44:12 -0500 (EST) From: Sam Hunting To: Steve Pepper cc: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on the LINKTYPE proposal > In fact LINK is extremely simple. Its basic purpose is to allow us to > separate and algorithmically associate structure and processing. This sounds to me like a Good Thing, and precisely the sort of "extensible" functionality that will enable XML's rapid adoption. > If anyone wants to know *why* [I think] LINK is powerful, just > ask. I will be happy to attempt a clear, concise and (hopefully) convincing > explanation -- with XML-related examples. ^^^^^^^^^^^^^^^^^^^^ A practical focus to this discussion would be welcome for at least this reader. Please, Steve, go ahead. Also, you might consider cross-posting the discussion to the xml developers list, so that the procedural programmers can give their views on implementation. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org cc: elm@arbortext.com Subject: Re: Couldn't XML allow and ignore omitted tag minimization <199703021928.LAA27650@boethius.eng.sun.com> Date: Sun, 02 Mar 1997 16:21:39 -0500 From: Eve Maler At the time we first discussed this, I also argued for allowing OMITTAG specifications in element declarations. If we're going to revisit this issue, I support Paul in this. (If we're not going to revisit this issue, you can stop reading now. :-) For me, the reasoning goes like this: - SGML declarations are a characteristic of documents, not DTDs. - OMITTAG NO allows OMITTAG specifications in elem decls, so that a DTD written with tag omission in mind can still be used with a document that doesn't allow tag omission. - XML documents, by definition, don't allow tag omission, but can use a wide variety of DTDs. - This is the only area where the syntax of an XML markup declaration is related in any way to a particular SGML declaration setting. - All this makes me believe we should follow 8879's lead in allowing the specification when our intent is OMITTAG NO. Eve > Date: Fri, 28 Feb 97 17:36:53 CST > From: paul@arbortext.com (Paul Grosso) > Message-Id: <9702282336.AA12560@atiaus.arbortext.com> > To: w3c-sgml-wg@w3.org > Subject: Couldn't XML allow and ignore omitted tag minimization ... > Since OMITTAG will always be NO, all I'm asking is that we define > the XML grammar so that an optional omitted tag minimization field > in an element declaration would be allowed but be ignored by an > XML processor. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 02 Mar 1997 22:44:24 +0000 (GMT) From: Peter Flynn Subject: Re: Couldn't XML allow and ignore omitted tag minimization To: w3c-sgml-wg@w3.org At 11:28 02/03/97 -0800, Paul Grosso wrote: >[JB: I'm forwarding the following message at the request of Paul Grosso,] > [...] I missed > the fact that XML as currently defined would not parse a DTD > that contained omitted tag minimization [...] I'm asking is that we define > the XML grammar so that an optional omitted tag minimization field > in an element declaration would be allowed but be ignored by an > XML processor. As I understand it, the XML spec currently assumes an element dec of and you're suggesting XML should also permit , right? > If we don't allow omitted tag minimization, I fear we will increase > the number of cases were people feel they must maintain two versions > of every DTD [...] I agree. Doesn't this come under the category of "for compatibility: A feature of XML included solely to ensure that XML remains compatible with SGML"? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 02 Mar 1997 15:57:11 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Couldn't XML allow and ignore omitted tag minimization At 11:28 AM 02/03/97 -0800, Paul Grosso wrote: > The benefit here is ... that a DTD can now be written that will > work in multiple situations. It would now be possible to write a DTD > that both works with an XML processor as well as works with an SGML > tool that may use OMITTAG YES. I must be missing something. If the DTD is to work with XML, it *must* have "- - " before all content models of non-empty elements, and "- O " before empty elements, if you were to put in OMITTAG YES. So you might as well put in OMITTAG NO. So you might as well lose the -'s and O's. Can you outline a scenario where you'd want to have OMITTAG YES and still be working with XML? - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 16:19:39 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: Couldn't XML allow and ignore omitted tag minimization Tim writes: >Can you outline a scenario where you'd want to have OMITTAG YES and still be working with XML? - Tim Docbook allows tag minimization in the DTD but sets OMITTAG NO in the sdecl. Eve and I think that with some effort we could make an XML-compliant version of Docbook, toward which the formal version could be made to converge (no sooner than version 5.0 because of our policy wrt backward-incompatible changes). If we were eventually to rid Docbook of stuff XML has ruled out, such as inclusion exceptions, we'd want it to be usable for SGML and XML. But for those users who want to substitute their own sdecl with OMITTAG YES, we'd want to keep the tag minimization. I think this is a case where a little bit of ISO formalism can be swallowed (and in fact it might be easier to explain to DTD-heads that XML just ignores tag minimization specification than to explain that it's just like SGML except ...). We finally allowed tag minimization when it was clear that reliable tools existed to normalize (thank you, James), and still prefer OMITTAG NO for interchange. But some people persist in writing SGML in vi; for them and other lost souls, tag minimization is a boon. For that matter, HTML may have replaced Rainbow as a descriptive hub DTD; if the HTML DTD can be XML-compliant as is, that would be very useful. Regards Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 02 Mar 1997 15:57:05 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 3.1 b-h: BEHAVIOR At 12:41 PM 02/03/97 -0800, Terry Allen wrote: >| >for example, SHOW=REPLACE ACTUATE=AUTO. >| I agree that this combination may not be useful, but it does "make >| sense" in that it's clean & clear what it means; as soon as you hit >| this link, traverse it and replace the current doc with the results. >So only the first such link will ever be encountered, at least by >the application? Good question. In fact if there is more than one of these it is almost certainly an error; but I suppose the spec should point out that the effect would be as you describe. It's important to realize that these attributes are very coarse-grained and abstract, and can only serve to signal requested *policy*; the mechanism has to be left to the user-agent. [This is a good thing.] >On the same line, if SHOW=INCLUDE ACUTATE=AUTO, does the processor >act on this info or does the application? So far we haven't dragged the processor into the XML-LINK spec. All we have discussed is the semantics that can be expressed and the syntax for expressing them. There is an open question as to whether we should discuss not just the processor, but also the division of labor between client and server. My preference would be to stay with semantics and syntax; let the implementors work out the rest. -Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 16:57:25 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Tim responds to my query: | >On the same line, if SHOW=INCLUDE ACUTATE=AUTO, does the processor | >act on this info or does the application? | | So far we haven't dragged the processor into the XML-LINK spec. | All we have discussed is the semantics that can be expressed and | the syntax for expressing them. There is an open question as to | whether we should discuss not just the processor, but also the | division of labor between client and server. My preference would | be to stay with semantics and syntax; let the implementors work | out the rest. -Tim Let me press harder. Are XML-link semantics expressed to the processor or to the application, or to both, or is it up to designers of apps and processors to decide? If it's not clear which, are you relying on the market to develop a common solution or are you punting? Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 20:08:43 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: Couldn't XML allow and ignore omitted tag minimization > Date: Fri, 28 Feb 97 17:36:53 CST > From: paul@arbortext.com (Paul Grosso) > If we don't allow omitted tag minimization, I fear we will increase > the number of cases were people feel they must maintain two versions > of every DTD (the fact that people like to have omitted tag minimization > in their DTDs should be obvious given the fact that practically all > common DTDs out there include this information). > > Can we reconsider allowing the omitted tag minimization in element > declarations in XML? We ought to. Why go out of our way to make it difficult to live in both worlds. Surely anyone who can write an XML parser at all can handle this trivially. Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 17:48:26 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Call for WWW6 demos As most of you know, the World Wide Web conference in Santa Clara (April 7-11) is a major event for XML and DSSSL. The XML-link draft spec will be announced, and the Web community will for the first time be made aware that alternative delivery strategies for structured documents are becoming a possibility. In addition to a report on the SGML Activity in the W3C track during the conference itself, there is going to be a full-day workshop on structured document delivery on the Monday beginning the conference week and a full-day session on XML and DSSSL during Developer's Day on the Friday of that week. Another basic component of this introduction to structured document alternatives will be a forum in which experimenters and companies taking an early lead in XML or DSSSL can demonstrate their products and projects. Early in conference planning I arranged with the WWW6 coordinators to hold open Thursday evening for a session that would showcase current efforts for the relatively small but important subset of conference attendees actively involved in Web development. Now it's time to see just who intends to be there and what they will need in the way of facilities so that an appropriate room assignment can be made. If you or your organization have an XML- or DSSSL-related product or technology to present at the conference -- an XML parser, an XML editor, a DSSSL browser, or what-have-you -- please send me a message with the following information: Name of organization (if any) Contact information for responsible person Description of product or technology for my information Description of product or technology for public announcement (if different from above -- please be clear about what can and can't be stated publicly) Facilities needed to demonstrate the technology (e.g., lcd projector, Internet connection) Whether you or a person from your organization will be demonstrating the technology or whether you want someone else to demonstrate it in your absence (I can't make any guarantees in the latter case, but I'll see what can be arranged) Try to have this information to me by Sunday evening, March 9, so that I can make room arrangements and public announcements. If you contact me after that time, I will make every effort to accommodate you, but it may not be possible to fit you into the schedule. Unless you tell me otherwise, I will assume that it is OK to include a description of your product or project in public announcements and on the conference Web site. If you are among the half-dozen people who indicated to me earlier that you intended to have something to demonstrate, please send me a message anyway to confirm your intention and provide the information I need in a uniform format. For maximum coverage I am posting this message to both the sgml-wg and xml-dev lists. Please use the xml-dev list for followups, if any. I will post a summary of what I've received to the xml-dev list at the beginning of next week. Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, | Best is he that inuents, Mountain View, California 94043 | the next he that followes Davenport Group::SGML Open::ANSI X3V1 | forth and eekes out a good ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB | inuention. ---------------------------------------------------------------------- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 19:07:25 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Re: Couldn't XML allow and ignore omitted tag minimization (I sent this earlier but misaddressed it.) [Paul Grosso:] | When this was brought up at Tuesday's SGML Open Technical Committee | meeting, Jon suggested I post this despite the fact that this issue | was decided once (and despite the fact that Jon appeared to disagree | with me on this). Actually, I wasn't so much disagreeing as trying to represent what I seemed to recall as the reason we didn't allow "- -" in element declarations: pure Occam's Razor -- since we don't allow minimization, that syntax is unnecessary. If I understand Paul correctly, he's arguing that conforming XML applications should ignore the omitted tag minimizations without getting sick on them, so that "O O" (for example) would just be ignored. This would make it easier, presumably, to grandfather existing SGML DTDs and maintain single versions that would work for both SGML and XML applications. I am made uneasy by the thought that a legal DTD would then be stating specifically something that would not be true in XML, namely that certain omissions were allowed when, in fact, they would not be. But I'm willing at least to entertain the argument that this tradeoff makes DTD maintenance a lot easier. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Mar 1997 19:18:15 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: ERB decisions on the LINKTYPE proposal [Sam Hunting:] | Also, you might consider cross-posting the discussion to the xml | developers list, so that the procedural programmers can give their | views on implementation. Please DO NOT cross-post between the two lists. The whole idea of having two lists is to enable people to discuss different kinds of issues in different places. Also, attempts to reply to cross-posted messages by people not on the WG will get bounced by the W3C mailer, and the bounces will end up in my mailbox. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: Couldn't XML allow and ignore omitted tag minimization Date: Sun, 02 Mar 1997 19:20:32 -0800 From: Joe English Tim Bray wrote: > > I must be missing something. If the DTD is to work with XML, it > *must* have "- - " before all content models of non-empty elements, > and "- O " before empty elements, if you were to put in OMITTAG YES. No: The DTD can use whatever tag omissibility declarations it wants, as long as the _instance_ doesn't omit any tags. > So you might as well put in OMITTAG NO. So you might as well lose > the -'s and O's. > > Can you outline a scenario where you'd want to have OMITTAG YES and > still be working with XML? - Tim You might want to create documents in "full SGML", then run them through a normalizer before publishing them as XML. Converting an SGML document instance to XML-compatible syntax is fairly straightforward, but rewriting an SGML DTD to be XML-compliant is quite complicated; there are many, many subtle differences in syntax. This might not be an issue though: there are so many other restrictions in XML that writing a DTD that is simultaneously legal XML and useful SGML might not be possible even if XML did allow "[-o] [-o]" in ELEMENT declarations. --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 14:25:34 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Re: 3.1 b-h: BEHAVIOR At 12:01 02/03/97 -0800, Tim Bray wrote: >At 03:23 PM 02/03/97 +0700, James Clark wrote: >>I have two problems with this: >>- I'm not convinced that all combinations of SHOW and ACTUATE make sense, >>for example, SHOW=REPLACE ACTUATE=AUTO. > >I agree that this combination may not be useful, but it does "make >sense" in that it's clean & clear what it means; as soon as you hit >this link, traverse it and replace the current doc with the results. >Actually, it might have a use - sort of a user-controlled redirect; >consider what happens if you replace a document on the web with > >go to new location > HREF="http://new.com/new-location-of-this-doc.html"> It seems pretty bizarre to me. If the user puts this pair of values in a link accidentally, they are going to be pretty suprised to find it behaving like a redirect, especially if the link is buried somewhere in the middle of the document. Since you agree that PUSH should be separated out from ACTUATE, that leaves 6 combinations of SHOW and ACTUATE. There doesn't seem any need for the functionality of SHOW=REPLACE ACTUATE=AUTO, which leaves at most 5 useful combinations. It would seem simpler to me to have a single attribute with 5 possible values. James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 14:25:28 +0700 To: Tim Bray From: James Clark Subject: Re: 3.1 b-h: BEHAVIOR Cc: w3c-sgml-wg@w3.org At 12:01 02/03/97 -0800, Tim Bray wrote: >At 03:23 PM 02/03/97 +0700, James Clark wrote: >>I have two problems with this: >>- I'm not convinced that all combinations of SHOW and ACTUATE make sense, >>for example, SHOW=REPLACE ACTUATE=AUTO. > >I agree that this combination may not be useful, but it does "make >sense" in that it's clean & clear what it means; as soon as you hit >this link, traverse it and replace the current doc with the results. >Actually, it might have a use - sort of a user-controlled redirect; >consider what happens if you replace a document on the web with > >go to new location > HREF="http://new.com/new-location-of-this-doc.html"> > >>- I think PUSH is on a slightly different axis.... >> PUSH seems to be saying something about the volatility >>of resource which is a different issue from what the appropriate behaviour >>is for links to the resource. > >I agree; I would be happy either to lose PUSH or to put it on a >separate axis named VOLATILITY or some such. - Tim > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Mon, 3 Mar 97 09:28:17 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.4 New Item: unify simple and extended links Tim writes: > During the meeting of March 1st, the ERB agreed to package up xlink > locators in subelements. Jean Paoli pointed out [but I have agreed > to bring this forward since he's on the road] that the declarations > and attlists for simple and extended links are VERY similar; and it > might be appealing to allow one locator to exist within the > start-tag of an extended link, such that an extended link is just > a simple link with child elements. E.g. > > I appreciate Jean's observation, but I think it's an opportunity we'd do better to pass up. As I read this, depending on the declaration in force, EITHER a is of metatype XML-LINK=link, in which case it's a simple, two-resource link, one of which is #lab1 and the other itself, OR it's of metatype XML-LINK=xlink, in which case it's an extended, three-resource link, resources #lab[1-3]. I think that's seriously confusing -- the improvement in clarity of being able to read the metatype off the instance syntax seems to me to be worth a lot, and we'd lose that if we take Jean's suggestion. ht [Note: Once again I'm getting mail from this list in a VERY disorganised and delayed fashion, so I may be out of sync. here, if so, sorry.] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Mon, 3 Mar 97 10:18:41 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Tim writes: > f. behavior > > . . . > > There will be an attribute named SHOW, which may have one of three values: > > INCLUDE - means that upon traversal of the link, the indicated resource > should be embedded, for the purposes of display or processing, in the body > of the resource where the traversal started. (e.g. like HTML REPLACE - means that upon traversal of the link, the indicated resource > should, for the purposes of display or processing, replace the > resource where the traversal started. (e.g. like HTML NEW - means that upon traversal of the link, the indicated resource should > be displayed or processed in a new context, not affecting that of the > resource where the traversal started (e.g. like HTML think]) Sorry, same old song: I have trouble with this outside the browser application context, although I appreciate the attempt to consider the broader application context which is evident in this post. Let's take this in pure SGML terms. Turns out REPLACE is the easiest: it's just super-CONREF, right? I.e. ...[arbitrary content]... . . . ...[foo content]... ---> ...[arbitrary content]... . . . ...[arbitrary content]... Note that with ACTUATE=AUTO, the processor can [should?] implement this one, it means what it says, you get the target resource IN PLACE OF the source resource, which is never seen by the application. [sub-note: this inclines me more towards James's suggestion that the multiplication should be expanded out]. Now I realise I've probably willfully misinterpreted what Tim wrote, which was "replace the resource". That's what I've just described, but it's NOT what HTML ...[arbitrary content]... . . . ...[foo content]... ---> ...[arbitrary content]... . . . ...[arbitrary content]... Two things to note: foo's content is gone, and so are its link-related attributes. Wrt the first of these, seems to me we might actually want to enforce the CONREF parallel, and require that at least in cases with ACTUATE=AUTO, the linking element must be empty, i.e. The link-related attributes go as a concommitant of the fact that their semantics have been realised. Finally NEW -- that's essentially a SUBDOC entity in an attribute. Sorry to go on so long, but if we're going to do this at all we need to be clear what we're doing. I think in fact groves provide the only sensible way to specify what we mean in an application-neutral way. So let's try that, using the name SNODE for the node in the grove of class Element which instantiates the linking element we're concerned with: INCLUDE: On actuation, replace the content of SNODE with the grove fragment (one or more nodes) which instantiates the target resource. REPLACE: On actuation, replace SNODE (or (grove-root SNODE), see above) with the node (must be exactly one) which instantiates the target resource. NEW: On actuation, construct a new grove which instantiates the target resource. One useful point this throws up is that in the case of NEW and REPLACE, the target resource better be a single element == a single node, whereas for INCLUDE it can be a sequence thereof (this turns out to be exactly what I need for an existing application which uses INCLUDE semantics). A final point: NONE of this makes any sense for extended links, as far as I can see. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lex@www.copsol.com (Alex Milowski) Subject: XML at www.w3.org To: w3c-sgml-wg@w3.org Date: Mon, 3 Mar 1997 11:19:13 -0600 (CST) Hello all, I just thought I'd send my frustrations along to you all: Why isn't XML at the W3C's web site on the main page as "XML"? This is an important thing to do... ;-) I'd love to be able to refer people to the "official" place but you have to dig into SGML on the web. Now, we all know to look at the SGML activities for XML information, but everyone else? I think they would get lost and give up. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 19:57:31 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: ERB decisions on the LINKTYPE proposal Thanks to Jon and Tim for providing some rationale for the ERB decisions. The arguments against using LINK syntax seem to be falling into a number of distinct categories: 1) Malediction 2) Confusion caused by the very word LINK 3) "Nobody understands it" 4) "LINK can't do the job anyway" 5) Verbosity and lack of clarity of the syntax 6) Difficulty of implementation 7) "LINK is unnecessary if WG8 gives us multiple attlists" 1) Malediction -------------- Although this is currently the largest category, I sincerely hope we all agree that we should be looking for the reasons behind LINK's bad image, rather than indulging in name calling. 2) Confusion caused by the very word LINK ----------------------------------------- David, Jon and Tim have all raised this issue, and it is quite pertinent. I have already considered it and explained my solution in my reply to David. Just as a reminder: ]> I am in other words proposing that we exploit the fact that XML uses a fixed SGML declaration to change the reserved names LINKTYPE and LINK to PROCSPEC and PROCDEF respectively. An XML document will then consist of an (optional) document type definition, an (optional) processing specification, and the instance itself. 3) "Nobody understands it" -------------------------- This is the key argument, I suppose. If as Tim says "only 17 people in the world understand LINK", I see that we have an uphill battle on our hands. The first question is, is this WG prepared to _try_ to understand it before rejecting it? The next question is, is it the _concepts_ that are problematic or the _syntax_? (Another interesting question is whether those that oppose my proposal number themselves among the 17...) I don't want to waste people's time if only Sam Hunting, one (unnamed) ERB member and I think this is worth pursuing. If there ARE others, I would like to ask them to show their hands; otherwise I will shut up and go back into hibernation! 4) "LINK can't do the job anyway" --------------------------------- This was Martin Bryan's argument and it is off the mark for the simple reason that the LINK-based solution is intended to solve the problem at the document type (or element type) level, not at the level of the individual elements. (That is why my example uses a FIXED attribute -- as did Steve DeRose's original example of the so-called "ideal" solution.) Now, I appreciate that there will be a need to specify values for xml-link attributes at the individual element level in some documents, in which case we are no longer talking about algorithmically associating processing information with structure (i.e. LINK). But I still contend that there is and will continue to be a very important class of documents for which useful XML functionality can be added at the element type level. Examples of this could be something like Jon's Solaris documentation and some of the vast corpora of TEI based information. 5) Verbosity and lack of clarity of the syntax ---------------------------------------------- Jon talks about "voodoo", "ISO obfuscation at its worst", "gibberish" and "apparent nonsense" because of the two lines I submit that we have already accepted at least as much "gibberish" in order to keep XML SGML-compliant. Take for example from processing. They will have implemented LINK, albeit in an uncontrolled and informal way. How much easier if the formal distinction between structure and processing had been built into the XML spec from the word go, so that they could arrive directly at the correct solution instead of beating around the bush! Then they would have the flexibility to deliver: - just the well-formed instance (WFI), - the WFI and the DTD, - the WFI and the XML processing specification (LPD) - the WFI, the DTD *and* the LPD depending on the requirements of the processor. And they would have the freedom to define different XML processing specs for the _same_document_type_ and plug them in and out as needed. For these reasons, I believe the LINK-based approach is *vastly superior* to the multiple attlist approach. Finally: A NEW PROPOSAL ----------------------- So is there anything that can be done that will give us all this power, and remove the syntax-related objections raised by Jon and Tim? I think there is: Instead of lobbying WG8 for multiple attlists (OK, then: as well as doing that), we lobby for a simplification of the LINK syntax that would allow my example to be expressed as simply as follows: ]> I believe this is possible. Would it bring anyone around? Regards, Steve [1] http://www.falch.no/people/pepper/link.htm -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 11:23:52 -0800 From: Terry Allen To: pepper@falch.no, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on the LINKTYPE proposal Steve Pepper writes: | 3) "Nobody understands it" | -------------------------- | This is the key argument, I suppose. If as Tim says "only 17 people in | the world understand LINK", I see that we have an uphill battle on our | hands. The first question is, is this WG prepared to _try_ to understand | it before rejecting it? The next question is, is it the _concepts_ that | are problematic or the _syntax_? (Another interesting question is whether | those that oppose my proposal number themselves among the 17...) | | I don't want to waste people's time if only Sam Hunting, one (unnamed) ERB | member and I think this is worth pursuing. If there ARE others, I would | like to ask them to show their hands; otherwise I will shut up and go back | into hibernation! I think it is hard to understand as described; however, I found that I could construct a simple example that apparently associates ICADD semantics with Docbook GIs (Steve or someone else mentioned using LINK for ICADD in just this way). Perhaps describing just the use of it required for XML would clarify matters. So no, I don't fully understand LINK and don't expect ever to, but I do see that it's useful and have actually been able to use it at least to the extent of constructing a demo. It's worth pursuing. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 11:31:50 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: XML at www.w3.org [Alex Milowski:] | Why isn't XML at the W3C's web site on the main page as "XML"? There are lots of things that need organizational revision, but I'd like to defer them all until after the WWW6 conference. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg 3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA Date: Mon, 03 Mar 1997 11:13:09 -0800 To: w3c-sgml-wg@w3.org From: Derek Denny-Brown Subject: Re: 3.1 b-h: BEHAVIOR At 06:29 PM 3/1/97 -0800, Tim Bray wrote: >There will be an attribute named SHOW, which may have one of three values: >INCLUDE >REPLACE >NEW This assumes that links will only be used for directly browsable relationships. What of the case where the link is means as information for hte applications which is only indirectly related to the display of the information? For example consider a link to a style-sheet. What catagory does it fall under? What of a link which refers to resource SGML Datafile which the application needs... For example a document which is really a script may refer to an API Spec (done in SGML) which defines how to map it's scripting functions to the application's architecture (or an external architecture). I am not sure I understand what the difference between REPLACE and NEW is meant to be. Replace what? If it is replace the current resource, how is that different from a new context? (Note: This may be a confusion on my part as I was to busy to keep up with all of the XML mailing lists mail through much of January and into February.... If so, could someone explain it to me off-line?) -derek -------------------------------------------------------------- ddb@criinc.com || software-engineer || www/sgml/java/perl/etc. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: ERB decisions on the LINKTYPE proposal To: pepper@FALCH.NO (Steve Pepper) Date: Mon, 3 Mar 1997 14:48:48 -0500 (EST) Cc: w3c-sgml-wg@w3.org > I am in other words proposing that we exploit the fact that XML uses a > fixed SGML declaration to change the reserved names LINKTYPE and LINK to > PROCSPEC and PROCDEF respectively. An XML document will then consist of > an (optional) document type definition, an (optional) processing > specification, and the instance itself. #1. When you tell the application that an element is a link through an attribute, is that processing or structure? It seems like structure to me. #2. If I'm wrong, and it is processing, shouldn't it be outside of the document, in a stylesheet? I thought that that was part of the SGML "philosophy". Processing does not go in the document. #3. Isn't DSSSL now the ISO standard language for associating processing with documents? Wasn't it developed because LINK was not powerful enough? I would argue that now that DSSSL exists, ICADD should be re-done as one of a) a set of flow objects, b) a target format of the transformation language, or perhaps, c) a whole new language, parallel to the style language and transformation language. That does not mean that I think that the LINK feature is useless. I can understand the benefit of having a declarative mechanism for defining one DTD in terms of another (architectural forms), and I believe that LINK is necessary for this to work well, but I do not think of architectural forms as a mechanism for specifying processing any more than I think of a GI as a "command" to an application. To be honest, I have not been following closely enough to know if Steve has outlined a simple mechanism for bringing the full power of architectural forms to XML without requiring massive implementation time or author confusion. I think that a simple declarative model for defining one DTD in terms of another would be powerful and elegant, but architectural forms in SGML do not seem simple to me. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 21:29:50 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: Couldn't XML allow and ignore omitted tag minimization At 20:28 02.03.97 +0100, Jon Bosak (on behalf of Paul Grosso) wrote: > Can we reconsider allowing the omitted tag minimization in element > declarations in XML? > > paul I agree that this should be reconsidered. Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 12:43:07 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: ERB decisions on the LINKTYPE proposal [Steve Pepper:] | I am being facetious, of course. The serious point I want to make is | that I support this project because I care about SGML. I am willing to | take the trouble to explain why specifying a reduced subset of a | powerful language requires carrying a little extra baggage, and I | emphatically do *not* accept epithets like "voodoo" and "ISO | obfuscation". Careful: I never said that *I* considered this language "voodoo", etc.; I said that most *users* would see it that way. Nothing you have said contradicts this basic psychological fact. The biggest single problem we have had in selling SGML over the last 10 years is a refusal to recognize user psychology as a valid concern. Let's not make this mistake again. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 16:03:40 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: 3.1 b-h: BEHAVIOR At 10:18 AM 3/3/97 GMT, Henry S. Thompson wrote: ... >Same old song: I have trouble with this outside the browser >application context, although I appreciate the attempt to consider the >broader application context which is evident in this post. Let's take >this in pure SGML terms. Turns out REPLACE is the easiest: it's just >super-CONREF, right? I.e. ... >Two things to note: foo's content is gone, and so are its link-related >attributes. Wrt the first of these, seems to me we might >actually want to enforce the CONREF parallel, and require that at >least in cases with ACTUATE=AUTO, the linking element must be empty, >i.e. ... >Finally NEW -- that's essentially a SUBDOC entity in an attribute. I'm not sure it's helpful to make the connection to specific SGML constructs; nothing dictates precisely what behavior is supposed to happen when you use CONREF or SUBDOC. (Why couldn't SUBDOC have INCLUDE behavior?) But you make a good point about wanting the linking element to be empty. This would suggest a constrained AF/template/whatever for making those kinds of links. ... >A final point: NONE of this makes any sense for extended links, as >far as I can see. > >ht This is another really good point. If someone can make sense of these behaviors for xlinks, great. But if we can't do that, we shouldn't offer them as options on xlinks. Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 13:22:30 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: ERB decisions on the LINKTYPE proposal [Steve Pepper:] | Instead of lobbying WG8 for multiple attlists (OK, then: as well as doing | that), we lobby for a simplification of the LINK syntax that would allow | my example to be expressed as simply as follows: | | | | ]> | | I believe this is possible. Would it bring anyone around? It certainly goes a long way toward answering my particular objection. I will be interested to see what others think of this. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 15:15:02 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: Couldn't XML allow and ignore omitted tag minimization Steve Pepper wrote: > > At 20:28 02.03.97 +0100, Jon Bosak (on behalf of Paul Grosso) wrote: > > Can we reconsider allowing the omitted tag minimization in element > > declarations in XML? > > > > paul The only thing that bothers me about this is an active feature required of a system to ignore what it cannot use. OTH, that is precisely how many features are implemented either for compatibility (do nothing), or when that feature is finally implemented (stub). We do this with tags we don't recognize in our stylesheets, so the concept is not foreign to implementors or hard to explain. I agree that this should be reconsidered. Len Bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 15:14:34 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on the LINKTYPE proposal Rule of the Ricebowl: if only one or two people in an organization have the solution to a problem, they will defend the problem. Voodoo is making someone believe something to death. > Jon Bosak wrote: > > Careful: I never said that *I* considered this language "voodoo", > etc.; I said that most *users* would see it that way. Nothing you > have said contradicts this basic psychological fact. The biggest > single problem we have had in selling SGML over the last 10 years is a > refusal to recognize user psychology as a valid concern. Let's not > make this mistake again. The biggest mistake of the last ten years has been a failure to acknowledge that many "user psychologies" resulted from the self-fulfilling prophecies of companies who sold competing systems. One of the most damaging was: "SGML is too hard", when in fact, "The SGML Way" was too hard and the software sold to support it too expensive. Let's not make THAT mistake again. Most of the jujuMasters of SGML are here. HTML is SGML without "The SGML Way". It sells. Free software and a "roll your own" language that anyone with an ASCII editor can use always will sell particularly when attached to a world wide media that gets immediate attention and new sales. It is a lock-in phenomena of increasing returns: in street language, the power of a siphon hose. This isn't "superior technology and simple design" triumphing. This is "400 acres and a mule to the first couple to put down a flag". The Internet is the Oklahoma Teritory after the government sold the mining rights and decided the Indians weren't worth the soldiers. Selah. The adoption of XML will neither be rapid nor overwhelming. The immediate market for XML is in users with lots of SGML they want to deliver via the Web. Even if LINKTYPE is not the "ideal" answer, it won't scare anyone with that resource type. User psychology doesn't seem to be an adequate reason not to use LINKTYPE. len bullard lockheed martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 23:02:02 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: ERB decisions on the LINKTYPE proposal At 20:48 03.03.97 +0100, Paul Prescod wrote: > >#1. When you tell the application that an element is a link through an >attribute, is that processing or structure? It seems like structure to me. Perhaps I bent the stick a little too far in the interests of getting the argument across. I do think things are a little more complicated than "It's either structure and belongs in the DTD, or it's processing and belongs in the stylesheet." Are we talking about structure-related processing information or processing-related structural information? Does it matter? The important thing is to make sure that we have an association mechanism that is flexible and extensible. Maybe your way of looking at it is more appropriate. The architectural forms do not specify *processing*, but they do relate the structure to an architecture defined by a *processor*, and in that case, LINK (as you point out) is necessary for this to work well. Steve (not yet SGML Philosopher) -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "The Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ "Using LINK profitably": http://www.falch.no/people/pepper/link.htm %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 15:32:52 -0800 From: Terry Allen To: ht@cogsci.ed.ac.uk, w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Henry Thompson writes: | Sorry to go on so long, but if we're going to do this at all we need | to be clear what we're doing. I think in fact groves provide the only | sensible way to specify what we mean in an application-neutral way. | So let's try that, using the name SNODE for the node in the grove of | class Element which instantiates the linking element we're concerned with: | | INCLUDE: On actuation, replace the content of SNODE with the grove | fragment (one or more nodes) which instantiates the target resource. Does this make sense as following from the above: If these groves have already been built by the parser, then this is something the application does. If the link points to something that wasn't fetched and parsed when the original document was parsed, groved, and dealt with by the application, then the application has to obtain the resource, and pass it to the parser, then the application has to insert in the SNODE the grove fragment instantiating the target resource. However, if ACTUATE=AUTO, does the parser act upon this information without involving the application? | REPLACE: On actuation, replace SNODE (or (grove-root SNODE), see | above) with the node (must be exactly one) which instantiates the | target resource. Pretty much the same except that it's a wholesale swap. In both cases the link info is interpreted by the application. | NEW: On actuation, construct a new grove which instantiates the | target resource. Pretty much the same as obtaining a resource in the first place. (I am pressing on this issue because XML 1.0 say what a processor should do but not an application; here we seem to be talking about instructions to the application. That's okay with me, but I don't have a strong impression that my interpretation is widely shared. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 19:26:11 -0500 (EST) From: Sam Hunting To: Len Bullard cc: Jon Bosak , w3c-sgml-wg@w3.org Subject: Re: ERB decisions on the LINKTYPE proposal > User psychology doesn't seem to be an adequate reason > not to use LINKTYPE. If the psychology cannot be altered, and LINKTYPE (thus?) prevents XML's widespread adoption, then, yes,that is an adequate reason not to use it. Perhaps that's QWERTYism, but c'est la vie. However-- I'm hearing some statements that boil down to: "Even granting that LINKTYPE has technical advantages, we simply won't be able to communicate those advantages to others." It's very hard for me to believe that this marketing problem can't be solved, by the sort of people who are good at that sort of thing. The marketing genius -- I am not being ironic, rather, complimentary -- who wrote the XML Q&A distributed at SGML96 springs to mind: they made the results of a lot of hard thinking (and bitter experience) sound simple and easy. So for LINKTYPE. User psychology is something to be managed, not just accepted. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 19:28:08 -0500 (EST) From: Sam Hunting To: w3c-sgml-wg@w3.org Subject: Re: Couldn't XML allow and ignore omitted tag minimization > At 20:28 02.03.97 +0100, Jon Bosak (on behalf of Paul Grosso) wrote: > > Can we reconsider allowing the omitted tag minimization in element > > declarations in XML? > > > > paul > > I agree that this should be reconsidered. > Ditto. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 16:55:59 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 3.1 b-h: BEHAVIOR At 10:18 AM 3/3/97 GMT, Henry S. Thompson wrote: First off, I'm really glad to see some substantive discussion of this stuff finally get kicked off. To be fair, I guess we really needed the ERB to crystallize some options in order to give people something to grapple with. >Sorry to go on so long, but if we're going to do this at all we need >to be clear what we're doing. I think in fact groves provide the only >sensible way to specify what we mean in an application-neutral way. >So let's try that, using the name SNODE for the node in the grove of >class Element which instantiates the linking element we're concerned with: In fact, this is the core of the difficulty; and the reason why the terminology in my posting ["the resource where the link traversal started"] may seem non-intuitive. It has to be. In the discussion below, I'm using the new terminology (resource/locator/linking-element) carefully. I just spent a long time writing this, and find it hard to be both precise and readable; yet our final spec must be. A processor may notice the existence of a resource either because it hits a linking element that is in-line & is itself a resource, or because another doc in the extended link group (== BOS, go look at the draft spec) has a linking element with a locator indicating the resource (a paragraph, or section, or video subsequence, or whatever) that you've just hit. In the case where the linking element is the resource, INCLUDE, REPLACE, and NEW are all easy to understand. In the case where it is *not*, REPLACE and NEW are I think easy to understand; INCLUDE is tricky. I now realize that when we said INCLUDE we really meant "replace the linking element, which happens to be the resource, preserving the surrounding context", while by REPLACE we meant "replace the whole context". Well, I think this still works... if a paragraph is functioning as a resource, and SHOW=INCLUDE, I think the paragraph gets replaced by the result of the traversal; if SHOW=REPLACE, the whole current processing/display context gets replaced. Or in the spirit of Henry's note... I'm sorry, but I have to explain this to the world, and I do not believe that I will be able to require that they first understand the grove formalism. (I acknowledge that this is an open issue, and some may wish to argue that we *should* require use/understanding of groves). But for now, it's gonna have to be comprehensible standing on its own: INCLUDE: on actuation, replace the resource where the traversal started with the resource(s) resulting from the traversal. REPLACE: on actuation, replace the entire current display/processing context with the resource(s) resulting from the traversal. NEW: on actuation, create an entire new display/processing context with the resource(s) resulting from the traversal. Note - I am worried that I am forced to keep talking about "display/processing context" - it feels like there is another concept struggling to get out here. I am having a *hard* time freeing my thought processes from pictures of browser-like on-screen stuff; either I need to try harder, or we need to accept that since this is how people think of links being used, we might as well bite the bullet and explain things in terms of display. Henry: >One useful point this throws up is that in the case of NEW and >REPLACE, the target resource better be a single element == a single >node, whereas for INCLUDE it can be a sequence thereof Why? I agree that there are problems in dealing with the concept of "the result of a traversal" when the resource you're starting with is linked to 11 others; and this is a problem we're going to have to consider. Strategies we might consider include [a] ignoring the problem, leaving it to the user-agents [b] creating another axis of behavior for use in specifying multi-resource traversal behavior - note that HyTime has lots of this machinery [c] saying that for xml's purposes, traversal to more than one resource is never required [d] saying that for xml's purposes, traversal to all other resources is always required but when you get down to it, I think that whether the result of the traversal is one or many resources, this is kind of orthogonal to the SHOW issue; i.e. do you put your "new stuff" in the existing context, or replace the existing context, or create a new context? This final question remains, I think, a good question, one that providers are going to want to answer, and one that I think we should provide machinery to support. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 19:56:22 -0500 To: James Clark , w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 3.1 b-h: BEHAVIOR At 03:23 PM 03/02/97 +0700, James Clark wrote: >- I'm not convinced that all combinations of SHOW and ACTUATE make sense, >for example, SHOW=REPLACE ACTUATE=AUTO. Ithought that too, but then realized that is essentially the behavior that "forwarding" links on the WEb have: they show you a screen saying the data has moved, then take you there automatically. NOt my favorite behavior for a link in principle, but we get an existing feature for free. > >- I think PUSH is on a slightly different axis. If I can have SHOW=NEW and >ACTUATE=PUSH, which presumably means the browser pops up a new window >automatically and then keeps refreshing it, why can't I also have something >that means the browser pops up a new windows when the user asks and then >keeps refreshing it. PUSH seems to be saying something about the volatility >of resource which is a different issue from what the appropriate behaviour >is for links to the resource. Hmmmm. Interesting point. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 17:25:00 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Tim writes: >A processor may notice the existence of a resource either because it hits a linking element that is in-line & is itself a resource, or because another doc in the extended link group (== BOS, go look at the draft spec) has a linking element with a locator indicating the resource (a paragraph, or section, or video subsequence, or whatever) that you've just hit. I fail to understand how the linking element is a resource, but never mind that. What does "A processor may notice" mean, and what action must, should, or may be taken by the processor upon such notice? Separately, if we have documents that may grow by inclusion when the user clicks on a link, we need a very sturdy concept of what these documents are. Just to dip a toe into the ocean, is the URL of the document as displayed after I click on an INCLUDE link the same as the URL of the document before I clicked? (If anyone wants to take this up, it should have another thread title.) Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 17:36:48 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 3.1 b-h: BEHAVIOR At 02:25 PM 3/3/97 +0700, James Clark wrote: >At 12:01 02/03/97 -0800, Tim Bray wrote: >>>for example, SHOW=REPLACE ACTUATE=AUTO. >>I agree that this combination may not be useful, but it does "make >>sense" ... it might have a use - sort of a user-controlled redirect; >>> HREF="http://new.com/new-location-of-this-doc.html"> > >It seems pretty bizarre to me. If the user puts this pair of values in a >link accidentally, they are going to be pretty suprised to find it behaving >like a redirect... Sorry, I don't really buy that. If we document carefully what it means, I don't see how they can really complain about being surprised. Anyhow, a standard built-in way to do a redirect seems to me like a useful thing; Lord knows it's a common enough need out on the Web... question: is there a standard way to do this now in HTML (I used to know) or do you have to do it at the HTTP level via your server? >Since you agree that PUSH should be separated out from ACTUATE, that leaves >6 combinations of SHOW and ACTUATE. There doesn't seem any need for the >functionality of SHOW=REPLACE ACTUATE=AUTO, which leaves at most 5 useful >combinations. It would seem simpler to me to have a single attribute with 5 >possible values. I'm not with you yet on REPLACE/AUTO; even if I were, 2 axes of behavior seems cleaner to me, and allows better growth potential as our understanding improves. To help the debate, could someone think up the (6 please) possible values so we can see concrete alternatives? - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Mar 1997 21:59:17 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Tim Bray wrote: > Sorry, I don't really buy that. If we document carefully what it means, > I don't see how they can really complain about being surprised. Anyhow, > a standard built-in way to do a redirect seems to me like a useful thing; > Lord knows it's a common enough need out on the Web... question: is there > a standard way to do this now in HTML (I used to know) or do you have to > do it at the HTTP level via your server? Standard in what sense? Netscape has an HTML hack that Internet Explorer copies. Is that standard? Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 11:22:55 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: XML encoding names Is there some reason why XML encoding names are different from IANA registered MIME charset names? There seem some pretty gratuitous differences between the preferred MIME names and names listed in the spec. For example, XML Name Preferred MIME name ISO8859-1 ISO-8859-1 Shift-JIS Shift_JIS EUC-JIS EUC-JP There are also some syntactic differences between charset names and encoding names. Charset names are stated to be case insensitive, and allow any printable US ASCII character, although in the currently registered names the only two characters that occur frequently that aren't allowed in XML encoding names are underscore and colon. James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Mar 1997 21:08:49 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: XML in Infoworld This just in. It's clearly going to be an uphill struggle to explain that we're not trying to replace HTML. On the other hand, it sure is nice to see all those big companies endorsing our effort. :-) --- Date: 01-03-97 Source: InfoWorld Subject: W3C preps markup-language standards despite Netscape's snub A new Web standard is brewing that could help users better manage mountains of Web documents -- but the lack of support by market leader Netscape could dampen the standards-making process. Members of a World Wide Web Consortium (W3C) committee are in the process of writing specifications for Extensible Markup Language (XML), a new version of HTML that provides methods for defining Web-based content in a more granular manner than is possible today. The committee will present XML to the Web Consortium at its April 7 meeting in Santa Clara, Calif., and a new standard could be approved by late June or early July, said Marion Elledge, vice president of information technology for the Graphic Communications Association, a trade group that promoted Standard Generalized Markup Language, the father of HTML, and now supports XML. The drive behind XML is that HTML tags offer limited capability to define data. XML is a methodology that will allow Web publishers to create new tags in a standardized manner. The tags would allow content to be searched by document structure or content fields, as well as by text strings, as is done today. For instance, an automobile manufacturer could use XML to define tags for automobile parts so that content developed for a Web-based catalog could be extracted and then reused later to create an owner's manual, Elledge explained. Other supporters of XML are Digital, Hewlett-Packard, IBM, JavaSoft, Microsoft, Novell, Spyglass, and Sun. But notably missing is an endorsement from Netscape, which stated that it believes the extensions are not needed. One expert said Netscape's holdout highlights a classic standard's effort dilemma: the struggle to find common ground among vendors vs. the market leader's desire to assert its influence by developing its own additions. "Netscape has been trying to drive the market through proprietary extensions for some time," said Clay Ryder, an analyst at Zona Research, a Mountain View, Calif.-based company that tracks Internet trends. However, the Netscape extensions have helped drive innovation so a standards-based approach isn't necessarily the only right way to go, Ryder added. The Graphic Communications Association, based in Alexandria, Va., can be reached at (703) 519-8160 or http://www.gca.org/. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:14:37 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Re: 3.1 b-h: BEHAVIOR At 17:36 03/03/97 -0800, Tim Bray wrote: >Anyhow, >a standard built-in way to do a redirect seems to me like a useful thing; >Lord knows it's a common enough need out on the Web... question: is there >a standard way to do this now in HTML (I used to know) or do you have to >do it at the HTTP level via your server? Maybe, but surely the XML spec isn't the right place to provide such a thing. There's nothing specific to XML about redirection. People shouldn't have to have an XML client in order to do redirection. It should be something that's handled at the HTTP level: the HTTP server should be able to recognize when there is a redirection and should generate the appropriate 302 response, which the client can handle also at the HTTP level. >To help the debate, could someone think up >the (6 please) possible values so we can see concrete alternatives? I am sure these can be improved on: Behave Show Actuate Explanation REF REPLACE USER Like REF-NEW NEW USER Like HIDE INCLUDE USER Something you can click on to reveal REDIRECT REPLACE AUTO User-level redirect NEW NEW AUTO Creates a new window EMBED INCLUDE AUTO Like IMG I'm not very clear about the intended behaviour of SHOW=NEW ACTUATE=AUTO. Suppose I have one of these links at the end of a long document. Is the window created when the document is loaded or when I scroll down to the end of the document? If the latter, does it automatically disappear if I scroll back to the beginning? What user requirement are we trying to meet here? Unless there's a clear user requirement for this, I think we should dump it. My current feeling is we show have a single attribute with just four values: REF, REF-NEW, HIDE and EMBED. James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 13:52:49 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Re: 3.1 b-h: BEHAVIOR At 10:18 03/03/97 GMT, Henry S. Thompson wrote: >I think in fact groves provide the only >sensible way to specify what we mean in an application-neutral way. >So let's try that, using the name SNODE for the node in the grove of >class Element which instantiates the linking element we're concerned with: > >INCLUDE: On actuation, replace the content of SNODE with the grove >fragment (one or more nodes) which instantiates the target resource. > >REPLACE: On actuation, replace SNODE (or (grove-root SNODE), see >above) with the node (must be exactly one) which instantiates the >target resource. > >NEW: On actuation, construct a new grove which instantiates the >target resource. I don't like the idea of modelling link traversal as grove mutation. Suppose I have an XML editor and an XML document with a SHOW=INCLUDE link. We can imagine two distinct operations: a) traverse the link, and b) change the document, replacing the link element by the linked-to resource. I would suggest it is (b) rather than (a) that is appropriately modelled by mutating the grove. James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 08:27:46 -0500 To: Steve Pepper , w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: ERB decisions on the LINKTYPE proposal At 07:57 PM 03/03/97 +0100, Steve Pepper wrote: >Thanks to Jon and Tim for providing some rationale for the ERB decisions. > >The arguments against using LINK syntax seem to be falling into a number >of distinct categories: > >1) Malediction >2) Confusion caused by the very word LINK >3) "Nobody understands it" >4) "LINK can't do the job anyway" >5) Verbosity and lack of clarity of the syntax >6) Difficulty of implementation >7) "LINK is unnecessary if WG8 gives us multiple attlists" > There are several others: LINK poses problems because you can't override the value on particular instances; it's not just a default, like you can do with ATTLISTs. Which reminds me since the question was asked: one specific design flaw in LINK that I find fatal is that you can't address anything that isn't already an element. For example, if you want to apply processing attributes that indicate something is supposed to be set all in caps, or as a drop cap, you can't do it *unless the something is already an element*, which in those cases is unlikely ("set the first line of each section in bold"; "drop-cap the first character of every chapter", and so on). lack of ability to handle anything that isn't already an element means you *must* have *another* way to associate processing as well, that can do that. And if you have that, LINK is redundant. [I was going to leave out the obvious exception that you could add a link attribute reading something like "small-cap the character 30 bytes into the content of this element". Of course you can, but if you're going to build an addressing language there's no reason it has to go inside link attributes when it could go in the stylesheet in the first place (and there's a nice ISO standard with such a style and semantics language already, whereas whatever you packed into link attributes would be a new invention just to work around the link limitation)] Link also uses a baroque style of overriding its settings: changes at event boundaries, pretty much like troff. This leads to very subtle surprises when you try to maintain the settings as contexts change or expand, because LINK's set of distinguishable contexts is not organized quite like SGML's. Also, complexity of implementation is not so much an issue as is a decade's evidence that no one need bother. Link just hasn't proven itself useful enough for almost anyone to bother building or using. The things it *can* do can be done more powerfully by other tools (and now that DSSSL transforms are around, can be done by *ISO* standard methods far more powerful than LINK). Also, if indeed its main function is to adding processing-specific attributes without "actually" putting them on the tags, what advantage does it have over multiple attlists, which have countless *independent* reasons to exist? Eschew redundancy. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 08:38:16 -0500 From: gtn@ebt.com (Gavin Nicol) To: jjc@jclark.com CC: w3c-sgml-wg@w3.org Subject: Re: XML encoding names >Is there some reason why XML encoding names are different from IANA >registered MIME charset names? I noticed this too. It seems to me that referring to the IANA document is probably far more useful than specifying anything. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 07:11:39 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: XML encoding names At 11:22 AM 3/4/97 +0700, James Clark wrote: >Is there some reason why XML encoding names are different from IANA >registered MIME charset names? Yes; editorial slippage. Consider these errata in the to-fix column, I'd say. Gavin's idea of referencing IANA is also good; we should at least put them in the bibliography if they're not already. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Christopher R. Maden" Date: Tue, 4 Mar 1997 15:14:55 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR I like this idea! Here, load this in your XML client: -=- crash.xml -=- -=- end -=- Wasn't that fun? I have a real problem with this level of behavioral specification. I understand Len's desire for behavioral buckets, but I think there's a better way to do that. By way of reference, and not as a plug, let me talk about DynaText. In DynaText, the SGML may express relationships between elements, but no inherent behavior is generated. The DynaText stylesheet associates behavior with elements; a function language (including queries) with element addresses allows specification of target elements for hyperlinks. For instance, in a DynaText book of the XML language spec, the WFCs, VCs, and terms are all links to their definitions. I chose, in the stylesheet, to present the semantic relationship as a new-window hyperlink. I believe that redirects should be left to HTTP. For other links, the *relationship* should certainly be asserted in the XML source, but the *presentation* of that relationship should be left to the stylesheet. To again use DynaText as an example, it is a very common practice to provide alternate views of a book, one with tables and figures in-line, and another with the tables and figures represented as icons that are links to a new window containing the table or figure. With the current XML-link proposal, this would apparently require two copies of the source, or a stylesheet override of the source. If the stylesheet can override the source, why put the information in the source at all? For browsing, a stylesheet will be necessary anyway. Asserting links and establishing relationships, yes. Specifying behavior, no. -Chris -- Christopher R. Maden One Richmond Square DynaText SIT Technical Support Providence, RI 02906 USA Inso Corporation +1.401.421.9550 (voice) Electronic Publishing Solutions +1.401.521.2030 (facsimile) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 13:09:38 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 3.1 b-h: BEHAVIOR At 3:23 PM +0700 3/2/97, James Clark wrote: >I have two problems with this: > >- I'm not convinced that all combinations of SHOW and ACTUATE make sense, >for example, SHOW=REPLACE ACTUATE=AUTO. This is the equiovalent of an Entity reference. It's also the equivalent of a FRESS "Splice" for those who were using Hypertext at Brown in the 70's. The notion certainly has a pedigree... >- I think PUSH is on a slightly different axis. If I can have SHOW=NEW and >ACTUATE=PUSH, which presumably means the browser pops up a new window >automatically and then keeps refreshing it, why can't I also have something >that means the browser pops up a new windows when the user asks and then >keeps refreshing it. PUSH seems to be saying something about the volatility >of resource which is a different issue from what the appropriate behaviour >is for links to the resource. I agree, but I'd rather not have another axis at all. Actually I'd rather not have push at all -- there are HTTP ways to inform the browser of this without doing anything in markup, and it's certainly not abstract information, in my view. But I assume someone is deeply wedded to the idea, and we could certainly live with it... I tend to think this is a case of premature over-specification myself... -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 12:46:40 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 3.1 b-h: LABEL attributes At 6:28 PM -0800 3/1/97, Tim Bray wrote: > Dimension 1: Which pieces of information should be specified for > possible inclusion in linking elements? > ... > e. caption > ... >ERB consensus: > - we will refer to this as a Label, not an explainer or caption > - there is strong support for having labels. > >However, the ERB is unhappy with allowing only a simple character string; >how does one support multilingual labeling, or labels which are graphic? >Our provisional solution is to support both a RESOURCE LABEL attribute and/or >a RESOURCE LABEL LOCATOR attribute, the latter being used to locate and >retrieve a structured label. But then do we need a LABEL LOCATOR >SCHEME? Or make it use the same scheme as the resource locator? I think we had best have only one locator scheme for simplicity. So I say an enthusiastic _yes_ to the final question. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 12:58:54 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 3.1 b-h: BEHAVIOR At 6:29 PM -0800 3/1/97, Tim Bray wrote: >There will be an attribute named SHOW, which may have one of three values: > >INCLUDE - means that upon traversal of the link, the indicated resource > should be embedded, for the purposes of display or processing, in the body > of the resource where the traversal started. (e.g. like HTML REPLACE - means that upon traversal of the link, the indicated resource > should, for the purposes of display or processing, replace the > resource where the traversal started. (e.g. like HTML NEW - means that upon traversal of the link, the indicated resource should > be displayed or processed in a new context, not affecting that of the > resource where the traversal started (e.g. like HTML think]) > >There will be an attribute named ACTUATE, which may have one of three values: > >AUTO - means that the link should be traversed and used when encountered; > that the display or processing of the resource where the traversal > started is not considered complete until this is done (e.g. HTML USER - means that the link should not be traversed until there is an > explicit external request for this to happen (e.g. HTML PUSH - means that the resource is volatile, subject to change, and > should be processed immediately and continuously. > >Notes: > a. HTML b. HTML c. Obviously, it is legal for user-agents to ignore these settings and > do as they will; for example, turning image loading off. > >With reference to the values of the ACTUATE element, it may be >possible to use the event names that are being proposed for use in >the W3C's work in progress on the "Document Object Model"; we have >an action item to check this out and do so if possible. having argued vocifersously against anything like this, I would like to note that I find this an acceptable compromise... One thing that this does seem to imply for the future is that processing specs. need to be able to dispatch on these behavior attributes, so that sepcific renderings may be associated with them. This means that the processing spec. (stylesheet) needs the following hooks: 1. Attach default behavior for al links with specified ACTUATE/SHOW combinations. 2. Attach specific behaviors to specific elements with specific ACTUATE/SHOW combinations. Allow each of these sepcifications to include wildcards or sets of behaviors -- if we extend this to the element type, we can merge 1 + 2 into one kind of specification, with possible wildcards in any of its 3 "dispatch fields". This will imply some kind of resolution hierarchy for deciding which defaults apply where -- but we will probably need something similar for processing specifications (stylesheets) anyway. -- David "indirection 'til I die" Durand _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 13:06:03 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 3.4 New Item: unify simple and extended links At 8:03 AM +0000 3/2/97, Martin Bryan wrote: >In some cases they will have a different significance, in others they may >not. One useful difference I could envisage is that fragment identifiers in >the embedded elements could refer to the document identified by the >container, rather than to the document they are embedded within. e.g. > >OII Standards and Specification List >SGML >XML > This seems to complicate the model, and isn't necessary if we have an equivalent of BASE or LOCSRC. I would leave this out as being purely a convenience feature unless we don't have an equivalent way to specify an alternative addressing origin (or LOCSRC or base address or whatever you want to call it) -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 13:30:37 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: ERB decisions on the LINKTYPE proposal At 2:52 PM +0100 3/2/97, Steve Pepper wrote: >In fact LINK is extremely simple. Its basic purpose is to allow us to >separate and algorithmically associate structure and processing. Or as >Goldfarb puts it in the handbook (p.93): "In a nutshell, LINK lets you >associate processing-oriented attributes with a start-tag without actually >putting them there." (Actually, the chapter from which this is taken, "Link >in a Nutshell", _is_ a pretty good exposition provided you don't let >yourself get distracted by his choice of examples.) > >But it wasn't my intention to provide a tutorial here. All I really wanted >to say is that I have yet to come across someone who really _understands_ >LINK and still doesn't appreciate its value. It allows me to attach a separate attribute space to elements based on one of a number of predeclared (in the document) schemes. It allows me to dispatch to an external process with indefined semantics to establish those values. I understand it all right, but I think processing information should _never_ be in the document instance. And I think that the separate attribute space makes it much less useful, because there is no LINK-free meaning to LINK attributes. So in fact, I still don't really see the use. I read the "nutshell" description several times, but I still have not seen any use for the mechanism that an external stylesheet sould not satisfy better. If it attached _real_ attributes to elements it might be useful for situations like this, but separate attlist declarations are a much more transparent and clean way to get that benefit, so again, I fail to see the value. > >Now, regarding David's arguments, they fall into two broad categories: >There are the merely assertive... > >> LINK in SGML is poorly designed, inflexible, under-defined >>-- to the point that few have dared to implement it -- and in addition >>strongly detested by a lot of knowledgeable SGML users. If the Exoterica people claim that it's not well-defined enough to implement, I take that seriously. So my assertion has some support. >>... >>And we have a construct that for many committed SGML users is a red-flag. >>Seems technically and politically inferior to me... I presented a few arguments, and present a few more above. This was all gone over on c.t.s 3 years ago. You were in the discussion if I recall... Since the semantics of LINK are undefined, they are a blank slate on which presumable usefulness can be projected -- but to me it just looks blank. >I see no point in bandying adjectives here. I want to know *why* people >think LINK is all those nasty things. *Why* it is detested. *Why* a >red flag. [The Norwegian flag is red, by the way.] Well, a red cape to a bull then. I don't want to put processing information in my document instances -- so one use for LINK is anathema to me. Read the back issues of this list for many arguments on why processing should _not_ be part of documents. I don't believe that LINK solve the attribute attachment problem because it explicitly allows LINK attribute names to be the same as document attribute names -- so it just doesn't address the problem unless you mis-implement it. 2 concrete reasons. >>Elegant and powerful are not the words that come to my mind. > >Adjectives again. I plead guilty to having used them without further >explanation. If anyone wants to know *why* [I think] LINK is powerful, just >ask. I will be happy to attempt a clear, concise and (hopefully) convincing >explanation -- with XML-related examples. I find writing without adjectives rather boring. I also don't want to recpitulate the entire argument -- it never seems to resolve -- but that last fact of non-resolution is a good reason to avoid LINK in my opinion. >...and there are arguments of more substance: > >>Since LINK attributes are specifically defined to be in a separate >>namespace from normal attributes, this mechanism will require additional >>verbiage to make it work for SGML systems. Naturally, it also raises the >>practical bar for SGMl processing of XML documents to include the rarely >>implemented, widely detested feature. > >I'm not quite sure what David's objection is here. As I already pointed out, >SP (and nsgmls) already support LINK, so it will not be a major task for >any systems based on this parser to add the required capability. LINK is >also supported by another important parser, Mark-It, upon which many other >products are built (including at least one pre-eminent SGML editor, as far >as I know). And by no other parsers to my knowledge. A less than overwhelming showing. I note that you didn't address the separate namespace issue, which is the real stumbling block in the current proposed application. > >Systems that don't support LINK today will have to be enhanced to cover >the very restricted subset that I am proposing. That shouldn't come as >any surprise: Most SGML systems that want also to become XML systems will >need some slight adjustments anyway. (For example, I just tried opening a >simple, valid XML document containing a self-identifying empty element in >three different SGML editors. They all croaked.) > >>I can think of several on the ERB who might react that way ... but they can >>speak for themselves... I certainly find Tim's statement eminently >>beliveable. > >Me too. I do hope they speak for themselves. Well, you came close to accusing him of fabricating the position in your original post... the words were "I find this argument so unlikely that I have it under suspicion of being vicarious." Maybe you meant something else... >>We have to deal with the two namespaces... We have a whole new construct, >>we now have 2 kinds of attribute declaration (are they equivalent or not?). > >* We do have two namespaces. Is that a major problem? I am not enough of a > programmer to be sure, but I don't think so. What does an element with XML-link="xlink" and the LINK-attribute XML-link="foobar" mean? We have, at least, to state priority rules, and then explain why we _need_ priority rules, and pretty soon we've spent a couple of pages on stuff that doesn't contribute directly to the goal. Having 2 kinds of attributes means that we have to explain the difference, and so on. Not having 2 kinds makes us SGML-incompatible.... >* We do have a new construct which isn't in the November draft. However, it > is just a one-production, simple wrapper around an existing construct. Michael responded to this already. >* We don't have 2 kinds of attribute declaration. Both are [141] attribute > definition list declarations (in SGML terms) and [48] Attribute list > declarations (in XML terms), but there is obviously a difference in the > groves that will result from using one rather than the other. They may share syntax, but they have explicitly divergent semantics, and that is the issue. >Ah, yes. I was expecting that objection. I didn't want to confuse the >discussion at this point, but what I really intend to propose is something >more along the following lines: > > > xml-link CDATA #fixed "xml-tlink"> > > ]> > >(This is still 100% 8879, of course.) And still implies that processing should be specified in the document -- the other reason that I don't like LINK any more than PI -- it encourages the user to do _what should not be done_ -- mix processing and markup. >What we would then be talking about would not be the "link type", but the >"processing specification". Would that allay people's fears of confusion? But not the problem of it's being a bad idea to mix processing and markup, or the two attribute spaces (which is a fatal problem, in my view), Nor the problem of complexifying the syntax (new nonterminals, new semantic space, as well as new productions). -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 13:03:15 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: ERB work on 3.* (Linking Elements) issues At 6:39 PM -0800 3/1/97, Tim Bray wrote: >The ERB has now put two meetings work in on this set of issues and is >nowhere near done. Not surprising, given the importance of the issues. >One of the factors holding us back a bit has been the fact that the >discussion in the WG on the 3.* issues has been lacking in both volume >and depth. Reasons for this might be (a) that the WG is tired (the >ERB is), yes. (b) that the WG is busy on other things I want to finish my thesis... and it doesn't have any XML in it, more's the pity... and (c) that the WG >has substantially less experience in these issues than in those that >came up in the XML language discussion. Not really... Just substantially less time... -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 14:21:02 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: 3.1 b-h: LABEL attributes Cc: elm@arbortext.com At 6:28 PM -0800 3/1/97, Tim Bray wrote: > Dimension 1: Which pieces of information should be specified for > possible inclusion in linking elements? > ... > e. caption > ... >ERB consensus: > - we will refer to this as a Label, not an explainer or caption > - there is strong support for having labels. > >However, the ERB is unhappy with allowing only a simple character string; >how does one support multilingual labeling, or labels which are graphic? >Our provisional solution is to support both a RESOURCE LABEL attribute and/or >a RESOURCE LABEL LOCATOR attribute, the latter being used to locate and >retrieve a structured label. But then do we need a LABEL LOCATOR >SCHEME? Or make it use the same scheme as the resource locator? If we allow multiple locator schemes, it would be an unreasonable constraint to make a label locator use the same scheme; I think we'd have to have a label locator scheme attribute. If we don't allow multiple schemes, or (same thing, really) allow them to be self-identifying right there in the value, no extra attribute is needed. I think it should be possible to associate a complex label with the resource by containment in the simple linking element itself, or in the resource-specific subelement of an xlink. (Associating a label with the resource *by linking* is, to me, not a characteristic of a "simple" link...) For example, we could allow an XML-knowledgeable label subelement as follows: > Click here for... I don't know how much this complicates things. For example, would we want to constrain labels to appear as the *first* content inside the linking element, so that linear processing could easily pick it up before hitting the main content of the element? If we had all kinds of restrictions, it would hurt more than it helps. But given the issues that have been brought up about labels, I do like the idea of being able to structure your labeling information any way you like, using the full power of an eXtensible Markup Language. Eve p.s. I was looking at TimBL's old linking papers, and he called this label-thing a "link preview," which I thought was an excellent functional name for it. Not to parachute in with yet another choice or anything... :-) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 13:15:30 -0600 From: Len Bullard To: "Christopher R. Maden" CC: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Again: rule of ricebowl: owner of solution defends the problem. In this case, me, not Chris. >Christopher R. Maden wrote: > > I have a real problem with this level of behavioral specification. I > understand Len's desire for behavioral buckets, but I think there's a > better way to do that. [snip] > Asserting links and establishing relationships, yes. Specifying > behavior, no. I can fall on either side of this, but let me play devil's advocate because I've seen this done different ways in SGML systems. Stylesheets and behavior have nattered at us for a decade, so if we think we can solve this now, I guess phase III will be as noisy as Phase II. Ah so... First, the behavior attributes chosen for XML are confusing to me, so I'm just following the debate. I am probably influenced by the simpler notion of the MID that a behavior attribute is there to declare what to do with state and so, gosub/goto/spawn/other are sufficient. (I don't like "other": it is the black hole.) It is only useful if a link is specifying active traversal; not a passive relationship. It is necessary to understand that MID IS an application: a GUI scripting language over a database of anything, or in my words, a database sequencer. It's conceptual parent isn't HTML; it is Visual Basic and the Zinc and XVT portability toolkits. For what it was designed to do, it works because like HTML, the author has an easier time with scripts that correlate directly to screen objects. The trick was to make those as metaAsSensible, then get on with it. It is not a generic solution for the database information: it is reasonably generic for the navigation interface and declaring navigation of stateful relationships. Does XML need this, or is XML better seen as the language of the database an application like MID navigates? Should one consider rewriting MID-like apps as XML applications, or can they? There are other ways. There are sometimes better ways. Then there are THE ways this is expressed. Since no XML clients exist (publicly) but there are SGML browsers and HTML browsers that do use attributes to specify that a behavior is *expected* on a link: o name a bucket for it. make its use optional and warn that this attribute spawns subdomains XML doesn't constrain. o name the behaviors and be precise about what they do. o say that XML can be used to write languages with active objects if the behavior is added by a separate application architecture (eg. like MID uses a MID arch form and a HyTime ilink). Otherwise, what is to be done with action= tags that have already shown up in two SGML DTDs for web use? The Dynatext way is a way but to me, this is "The SGML Way" in a world in which too many users already do it other ways and some do it with SGML. If XML restricts that, it only narrows its own field of application. (Strange to be on this side of that argument, but...). There will be times when the stylesheet and the instance go down separate paths to separate destinations. 1. Should the user be restricted to fixed methods, or laissez faire, or is the behavior attribute just a flag for the middle way? IOW, here is what is expected, but not enforced. 2. Do I demand that a stylesheet is always archived with the XML instance? 3. What is easiest for the author (not a stylesheet designer) to use? I don't expect native DSSSL scripting to be a raging success. I expect point and click creation and modification will be. If DSSSL/Scheme is the export/import/ archival and under-the-scene processing language, great. Those are implementation issues, though, amenable to libraries. It could be C and production user shouldn't know the difference. It is the buyer of the system who needs to know if standardized stylesheet export and import is required. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 14:14:00 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: Couldn't XML allow and ignore omitted tag minimization >We ought to. Why go out of our way to make it difficult to live in >both worlds. Surely anyone who can write an XML parser at all can >handle this trivially. I am sympathetic to this, except for the SGML-imposed requirement that EMPTY tags must take minimization "- O" if they could be pure "noise" elements I wouldn't mind, but explaining that restriction in the context of "compatibility" is sure to be difficult. Could we get the "- O" minimization flag requirement removed in the SGML update? Then it would make sense to allow minimization flags in XML. Otherwise, I'm not sure that it is worth the verbiage. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 14:10:32 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 3.1 b-h: BEHAVIOR At 4:57 PM -0800 3/2/97, Terry Allen wrote: >Let me press harder. Are XML-link semantics expressed to the >processor or to the application, or to both, or is it up to >designers of apps and processors to decide? If it's not clear which, >are you relying on the market to develop a common solution or are >you punting? I think that this question is confused by having 2-levels where 3 are apopropriate. and XML parser implements the syntax, and XML-linking engine detects and flags linking constructs, and an application takes that information and implements behavior. _I_ think that he behavior options should be detected and flagged, and passed to the application for implementation. To take the two hoary examples we've been using, full-text indexing, and web mapping, are cases where direct implementation of behaviors by the XML linking engine would be actually harmful. So I think we must be conveying intended policy to the application rather than requiring things of the linking engine. Anyway, the meaning of "create a fresh display" is going to be inherently application dependent. I can think of at least 4 different ways to implement that off the top of my head. (New window, new pane, replace something in some no longer desired old pane, create a new icon on tracking map, prompt the user for a new filename to hold the next downloaded item, etc..) -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 11:49:54 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Lotsa discussion items coming atcha The ERB schedule originally called for voting on the 4.* items on March 5, which is tomorrow. So we're lagging a bit. Fortunately, we have a bit of slack time built into the schedule. Since we're well over halfway through the list, as of now, I'm going to issue all the remaining discussion points in 4.* and 5.*. The 4.* is the details of addressing; obviously pretty important in a discussion of hyperlinking. The 5.* is the Extended Link Group (== BOS) discussion, i.e. how do you find linking elements which don't live with their resources? Have fun. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 13:52:34 -0600 From: Len Bullard To: David Durand CC: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR David Durand wrote: > > At 4:57 PM -0800 3/2/97, Terry Allen wrote: > >Let me press harder. Are XML-link semantics expressed to the > >processor or to the application, or to both, or is it up to > >designers of apps and processors to decide? If it's not clear which, > >are you relying on the market to develop a common solution or are > >you punting? > > I think that this question is confused by having 2-levels where 3 are > apopropriate. > > and XML parser implements the syntax, and XML-linking engine detects and > flags linking constructs, and an application takes that information and > implements behavior. > Anyway, the meaning of "create a fresh display" is going to be > inherently application dependent. I can think of at least 4 different ways > to implement that off the top of my head. (New window, new pane, replace > something in some no longer desired old pane, create a new icon on tracking > map, prompt the user for a new filename to hold the next downloaded item, > etc..) I agree with David. This was why we had the bloody infoContainers in MID and specified a tree of display types to contain resources fetched by get links. Once one starts to specify display semantics (a requirement of MID because look and feel was what it was intended to convey), I could never figure out a way to express these without either 1. MID Vancouver - an object-oriented language for expressing the objects 2. MID I - express the objects in an interpreted script (HTML, HyperCard, lots of systems) We did a two layer design for soft, semi-soft and hard MIDs in the spec. In the actual implementations, the MID element types were subclasses (pane class, clientArea class, script class etc). So a GenCoded solution that works but is only reall "Gen" in the database. The linking engine was a HyTime engine (HyMinder). The design is documented on the Navy server, so no details here. But what we ended up with is similar to what David is describing, parser, linking engine, display engine (implementation of behavior). As far as I can tell, as soon as one needs to express the layout without the layout language, one has to separate the display application from the information database. Either could be expressed in XML, but they will be separate XML applications. So, yes, behavior is just a flag to pass off to the application engine. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: Couldn't XML allow and ignore omitted tag minimization Date: Tue, 04 Mar 1997 12:05:45 -0800 From: Joe English dgd@cs.bu.edu (David Durand) wrote: > I am sympathetic to this, except for the SGML-imposed requirement that > EMPTY tags must take minimization "- O" if they could be pure "noise" > elements I wouldn't mind, but explaining that restriction in the context of > "compatibility" is sure to be difficult. By my interpretation of the standard, this is not actually required, only recommended. SGMLS agrees: it issues a warning if it sees in the DTD but it does flag the document as non-conforming. According to 7.3.1 and 11.2.2, the parser doesn't even examine the tag omission parameters for EMPTY elements or those with a non-#IMPLIED CONREF attribute. (It would be nice to be able to turn this warning off in SGMLS/SP though, especially for elements with CONREF attributes; I'd like to be able to specify that the end-tag is always required if no content reference attribute is supplied. But that has nothing to do with XML...) --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:41 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.d Compulsory locator language(s)? 4.d The spec will describe some addressing types that we support. Should we declare support for one or more locator languages to be compulsory? Which? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:53 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 5.1 Extended Link Groups 5.1.a Shall we support a mechanism for a document to contain a list of other documents that someone thinks ought to processed with it, in order to find linking elements pointing into the first document, and in general create a web of related documents? 5.1.b If so, shall we say anything normative about whether this must be done? 5.1.c Should we use an SGML element, a PI, or some other construct to hold this list of documents? 5.1.d If we use an element, what should it be called? 5.1.e If we use an SGML element, should we have subelements per referenced doc or just a token-separated list of entity names in a single attribute? In either case what should the subelement (if any) and attributes be called? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:40 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.c Homegrown locator language? 4.c The spec will describe some addressing types that we support. Should we be open-ended and include a way to support other user-defined locator languages? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:43 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.2 Location-source/Base address 4.2.a Should we formalize at all the concept of a base address? 4.2.b If so, should we call it a location source or something else? 4.2.c Should we formalize the concept of the implied location source? 4.2.d If so, should the values be DOCELEM and REFERRER, defaulting to DOCELEM? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:52 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.6 Query Language Locators? 4.6.a Should we support this? 4.6.b If so, should we specify any query languages? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:56 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 7. Attribute remapping? We have decided that we will allow the use of any old GI's on XML linking elements, identifying by the use of reserved attribute names and values. We will be specifying the use of some attributes to support XML linking. Do we need to allow them to be remapped as well, so that when an HTML doc says HREF= and a TEI doc says PTR=, they can mean the same thing? If we don't do this, then either we call all locator attributes HREF= or we take a terrible loss in selling this to the web-folk. If we do do this, we add substantial complexity to the spec and the processing model. Eve suggested a mechanism for this in http://www.doctools.com/xml-link.html This involves pulling apart lists of things in attribute values. Yecch. The obvious alternative is simply to have an arcform-like attribute for every attribute we want to remap. Yecch also. Any other good ideas? - Tim Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:50 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.5 TEI Extended Pointer Locators? 4.5.a Should we support these? 4.5.b What portions of TEI extended pointers should be dropped from this spec? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:45 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.3 SGML addressing Background: the draft spec supports SGML-style addressing, traditional IDREF(S) and also by entity name. 4.3.a Should we support this type of locator? 4.3.b Should we support entity addressing by name? 4.3.c Should we support element addressing by ID attribute? 4.3.d Should we support a combination of these two? 4.3.e What syntax should we use? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:55 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 5.2 Linking element corrals? The premise is that since extended links are independent of their resources, they can be difficult to find. One solution is to corral them into one spot, either within a document or in a special external document. 5.2.a Should we provide an element to serve as a corral for extended linking elements? 5.2.b If so, should we require its use? 5.2.c If we allow but not require its use, should we require that if the corral is used, there be no extended linking elements outside it? 5.2.e Should we specify LINKSET documents, i.e. external entities existing only to contain extended link corrals. 5.2.f If we specify LINKS and/or LINKSETS, should we discuss the temporal effectivity and user-visibility of the links therein, in terms of the period the document is "open"? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:42 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.1 Address types 4.1.a Should we have a single attribute used for storing all locators, with another attribute expressing its type, as with the initial draft's HREF/HRTYPE? Note that this has the side-effect that a locator element can contain only one locator (which of course, could be a tokenized list). 4.1.b If so, what should the attribute be called? 4.1.c If not, should we use a different attribute for each type of locator? Note that this means we could in principle have multiple addresses per locator element although only one of each HRTYPE. 4.1.d If using different attributes for locator languages, can we have multiple locators packed into locator attribute values? 4.1.e Should we discard this scheme and adopt something wholly different for selecting among locator languages? 4.1.f Should we abandon the idea of different address types and assert that everything is a URL? Can we do this and retain support for good old IDREF(S) addressing? Does XML-LINK need to subsume IDREF(S)? This would require packing complex addresses (e.g. TEI locators) into URLs. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:37 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.a Can resources be plural? 4.a Should we make it clear that resources can point at a wide variety of things, and that some of the things can be plural? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:46 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.4 URL processing Very likely XML Link will use URLs (perhaps among things) for locators. Is this all we need to say? Do we need specific interpretation of '#' fragment handling for XML? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 12:33:38 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 4.b Links pointing at links? 4.b What should we say about the situation when a linking element points at a resource which is another linking element? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 14:02:56 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 4.a Can resources be plural? Where is the current linking draft? I don't see it at http://www.textuality.com/sgml-erb/ nor at http://www.w3.org/pub/WWW/MarkUp/SGML/Activity and I am confused by the use of "resource" in >4.a Should we make it clear that resources can point at a wide variety of things, and that some of the things can be plural? Is this the URI sense of "resource"? (which doesn't appear in drafts up through Feb 7) Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 14:04:09 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 4.c Homegrown locator language? >4.c The spec will describe some addressing types that we support. Should we be open-ended and include a way to support other user-defined locator languages? You already have it in XML 1.0, which doesn't forbid user-supplied semantics. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 14:06:24 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 7. Attribute remapping? >This involves pulling apart lists of things in attribute values. Yecch. The obvious alternative is simply to have an arcform-like attribute for every attribute we want to remap. Yecch also. Any other good ideas? Ilinks. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: altheim@jurassic.eng.sun.com Date: Tue, 4 Mar 1997 14:13:14 -0800 (PST) Subject: Re: ERB decisions on the LINKTYPE proposal To: David Durand Cc: pepper@FALCH.NO, w3c-sgml-wg@w3.org [Pardon coming into the middle of this -- I've been out of circuit for the last two weeks and haven't yet begun to catch up. But finding a (surprising) discussion of LINK that isn't part of the LINK(ing) discussion, I thought I'd interject. Pardon the length -- I want to address most of David's points.] David Durand writes: > At 2:52 PM +0100 3/2/97, Steve Pepper wrote: > >In fact LINK is extremely simple. Its basic purpose is to allow us to > >separate and algorithmically associate structure and processing. Or as > >Goldfarb puts it in the handbook (p.93): "In a nutshell, LINK lets you > >associate processing-oriented attributes with a start-tag without actually > >putting them there." (Actually, the chapter from which this is taken, "Link > >in a Nutshell", _is_ a pretty good exposition provided you don't let > >yourself get distracted by his choice of examples.) > > > >But it wasn't my intention to provide a tutorial here. All I really wanted > >to say is that I have yet to come across someone who really _understands_ > >LINK and still doesn't appreciate its value. Agreed. And coming into the SGML community without any preconceived notion that link is bad and evil and icky (which seems almost religious to many for reasons I still don't understand), I find LINK to be a fine solution for the problems it seems designed to solve. Certainly it has limitations, but they don't warrant throwing the baby out with the bathwater. The particular usage of LINK that led me earlier to propose its inclusion in XML is the same one as for HTML: attaching SDA attributes to a document instance for transformation to the ICADD DTD. The added features of LINK over the proposed alternative ATTLIST solution (context-sensitive processing for one) make me question why ATTLIST is even considered -- they are not a direct match functionally. > It allows me to attach a separate attribute space to elements based on one > of a number of predeclared (in the document) schemes. It allows me to > dispatch to an external process with indefined semantics to establish those > values. I'm not clear on what you mean by 'in the document', as LINK doesn't require anything different than ATTLIST as regards 'in the document': both can simply show up as a single declaration in the declaration subset. Nothing in the document instance needs modification. If the DS insertion is what's bothering you, nsgmls allows LPDs to be declared externally on the command line, so LINK has that advantage over DS-based ATTLISTs. > I understand it all right, but I think processing information should > _never_ be in the document instance. I agree completely (except when the document is part of a transform process). I still don't understand why there isn't more screaming about some of the extensive proposed XML uses of PIs. I find PIs as abhorrent as some do LPDs. Use of LINK doesn't require processing information be embedded in the document instance, which is precisely one of its benefits. The alternative proposed ICADD solution of using multiple ATTLISTs *does* require adding the ATTLIST declaration to the declaration subset, which I find less desireable for precisely the reason you state above. >[...] And I think that the separate > attribute space makes it much less useful, because there is no LINK-free > meaning to LINK attributes. If the purpose of LINK is either element-specific, context-sensitive, or document-global GI mapping of attributes onto a document instance, then essentially this argument is also true of stylesheets, yet I've never heard this argument applied there. I and others did make precisely this argument to the HTML-wg over adding STYLE attributes in the document instance, and look where that went. I think both Terry Allen and I were hoarse at the end. But this isn't about presentation, this is about assisting transformation between DTDs, which would seem to have wider application than simply ICADD. Given that transformation of existing HTML documents to ICADD via either ATTLIST or LINK requires more processing than is done by most browsers (which typically don't process a DTD), the actual source of the contextual mapping should contain the necessary information needed to perform the task without a DTD. This also makes sense with DTD-less XML documents. Provided with either an LPD or HTML-to-ICADD ATTLIST declaration, the LPD contains more of the necessary data for context-sensitive transformation, where the ATTLIST doesn't unless also accompanied by the DTD it is designed to modify. > So in fact, I still don't really see the use. I read the "nutshell" > description several times, but I still have not seen any use for the > mechanism that an external stylesheet sould not satisfy better. If it > attached _real_ attributes to elements it might be useful for situations > like this, but separate attlist declarations are a much more transparent > and clean way to get that benefit, so again, I fail to see the value. I don't understand your differentiation of 'real' attributes vs. 'fake' ones. An LPD could be written to exactly mirror an ATTLIST declaration, but not vice-versa, as ATTLISTs don't contain #USELINK parameters (to my knowledge), so there is no mechanism for context-sensitivity. > >Now, regarding David's arguments, they fall into two broad categories: > >There are the merely assertive... > > > >> LINK in SGML is poorly designed, inflexible, under-defined > >>-- to the point that few have dared to implement it -- and in addition > >>strongly detested by a lot of knowledgeable SGML users. The rhetoric is dogmatic, hence my use of 'religious.' I agree that almost all criticism I've heard in the past year (and I've heard a fair bit) amounts to either 'it doesn't do everything I want' or 'it's not implemented in enough products'. The former argument stresses that it's too simple, the latter that it's too complicated. It can't be both. IMO, it's a chicken and egg thing: nobody saw an immediate use for or paid enough attention to LINK to bother implementing it, therefore not enough people understand it well enough to know how it might be used. > If the Exoterica people claim that it's not well-defined enough to > implement, I take that seriously. So my assertion has some support. Huh? It's as 'well-defined' as anything else in 8879. A relative novice like myself can figure it out, and it was well-defined enough for James to implement it in SP. [And all I want is implicit links, not simple or explicit.] > >>And we have a construct that for many committed SGML users is a red-flag. > >>Seems technically and politically inferior to me... Politically, yes. Technically I don't see it as any different than any other aspect of 8879. > I presented a few arguments, and present a few more above. This was all > gone over on c.t.s 3 years ago. You were in the discussion if I recall... > Since the semantics of LINK are undefined, they are a blank slate on which > presumable usefulness can be projected -- but to me it just looks blank. ie., you haven't had a need for it. Fair enough. > >I see no point in bandying adjectives here. I want to know *why* people > >think LINK is all those nasty things. *Why* it is detested. *Why* a > >red flag. [The Norwegian flag is red, by the way.] > > Well, a red cape to a bull then. > > I don't want to put processing information in my document instances -- so > one use for LINK is anathema to me. Read the back issues of this list for > many arguments on why processing should _not_ be part of documents. I believe I addressed this above, although I'm open to being countered. > I don't believe that LINK solve the attribute attachment problem because it > explicitly allows LINK attribute names to be the same as document attribute > names -- so it just doesn't address the problem unless you mis-implement it. For the purposes of ICADD transformation, I don't see this as a problem at all. And with #USELINK this is reduced to a non-issue, non? > 2 concrete reasons. I could find more than two reasons to discard a substantial portion of HTML 3.2, but that doesn't mean that others don't find a valuable usage. LINK for HTML and XML has a usage regardless of whether people like it or not: ICADD transformation. As we get into more complex element/attribute mapping (specifically, document structure and complex tables) I don't see ATTLISTs as an adequate solution. And at the point we're at, I'd hate to cut XML out of what may be the best solution. > >>Elegant and powerful are not the words that come to my mind. > > > >Adjectives again. I plead guilty to having used them without further > >explanation. If anyone wants to know *why* [I think] LINK is powerful, just > >ask. I will be happy to attempt a clear, concise and (hopefully) convincing > >explanation -- with XML-related examples. > > I find writing without adjectives rather boring. I believe Steve was referring to usage of adjectives in the advertising sense. We could add 'whitens your teeth' too, but without proof it has no meaning. I certainly find an LPD more elegant than an ATTLIST declaration. I've been able to describe an LPD to completely SGML-illiterate people, so it can't be that obtuse. > I also don't want to recpitulate the entire argument -- it never seems to > resolve -- but that last fact of non-resolution is a good reason to avoid > LINK in my opinion. Filibustering? > >...and there are arguments of more substance: > > > >>Since LINK attributes are specifically defined to be in a separate > >>namespace from normal attributes, this mechanism will require additional > >>verbiage to make it work for SGML systems. Naturally, it also raises the > >>practical bar for SGMl processing of XML documents to include the rarely > >>implemented, widely detested feature. If so few people know about or use LINK, how could it be so 'widely detested'? I wouldn't make it a requirement of XML systems, I would simply *allow* it in the SGML declaration so that those who would like to use it may. It's certainly no more of a hack than multiple ATTLISTs. > >I'm not quite sure what David's objection is here. As I already pointed out, > >SP (and nsgmls) already support LINK, so it will not be a major task for > >any systems based on this parser to add the required capability. LINK is > >also supported by another important parser, Mark-It, upon which many other > >products are built (including at least one pre-eminent SGML editor, as far > >as I know). > > And by no other parsers to my knowledge. A less than overwhelming showing. Chicken and egg, as I said above. The argument that adding LINK to XML adds complexity to the specification is certainly valid, but only insofar as the specification, not a specific implementation. If LINKTYPE processing is allowed as an option (described in an addendum) rather than proscribed in the spec, even insofar as describing a subset such as simple and implicit links (with no explicit), we would avoid muddying the document instance and allow for context-sensitive transformations without putting the burden on stylesheet processing (which is certainly light years more complex than simply adding LINK to XML). Or we could simply allow the 8879 definition of LINK as an option and point to that specification. And yes, I do feel like I'm trying to revive a beaten, dead horse. I just don't understand why it was killed in the first place. Murray ---------------------------------------------------------------------- Murray Altheim, SGML Toolhead Tools Development & Online Production Sun Microsystems, Inc. Menlo Park, California %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: ERB decisions on the LINKTYPE proposal To: dgd@cs.bu.edu (David Durand) Date: Tue, 4 Mar 1997 17:24:08 -0500 (EST) Cc: w3c-sgml-wg@w3.org > So in fact, I still don't really see the use. I read the "nutshell" > description several times, but I still have not seen any use for the > mechanism that an external stylesheet sould not satisfy better. You can use LINK as an algorithmic, declarative mechanism for describing one DTD in terms of another. You can do something similar with a transformation engine (e.g. STTP), but there are two problems with that: a) if it is a half-way decent transformation engine, then you will run into the problem that transformations could fail to terminate. (imagine waiting a LONG time for your text-to-speech tool to start reading your document...) b) the link between a Instance->Parser->Input Grove->STTP Script->Output Grove seems much less direct than DTD->Praser->Output Grove. I don't just mean direct in steps, but in the semantic connection: if a document conforms to an architectural form, all information about that conformance should be in the document, not in an associated STTP script. In other words: archform conformance should be the job of the parser, not of a whole system of tools. I am not prescribing archforms and LINK for XML. But if they really are useful in SGML, and are going to become more popular now that SP supports them, then it makes sense to define XML features in terms of them for all of the regular reasons for trying to stay SGML conformant. It is also possible that XML 2.0 might support archforms, because Web-users are going to butt their heads against all of the same problems we have of trying to standardize DTDs and yet model documents "tightly". I have always hoped that archforms and LINK would be the solution to those problems, but have not had a chance yet to try them out in SP. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 14:23:13 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.a Can resources be plural? At 02:02 PM 3/4/97 -0800, Terry Allen wrote: >Where is the current linking draft? I don't see it at > http://www.textuality.com/sgml-erb/ >nor at > http://www.w3.org/pub/WWW/MarkUp/SGML/Activity Good point. Steve is just polishing up the latest and it should be out any moment. As regards the terminology, including "resource", there was a message on that on this list on Feb, 15, which I reproduce below, to tide us over until the draft is up: ============================================================= We spent most of the time on the issue of terminology detail. Although this was not articulated formally, some underlying design principles seem to have guided us: 1. We should re-use Web terminology where appropriate (thanks to Dan for this input) 2. We should not be afraid of lengthier English compound constructions as opposed to single words, when this makes things easier to understand and explain (thanks to Liora) 3. We should distinguish clearly between terms for the underlying Platonic concepts and those for the syntactic constructs (thanks to Henry) We had discovered that, even at this late date, there was still room for confusion as to which bits were which; so Steve and I, inspired by Henry, cooked up a simple picture that was very helpful: Click here |------------------------------p0-----------------------------------------| |------------------------p1----------------------------------| |----------p2-------------------| |----p3------------------| |----p4-------------| |p5| Thank you for clicking to get here. |------------------------------q0-----------------------------------| |------------------------q1----------------------------| 1. The relationship which the " >and I am confused by the use of "resource" in > >>4.a Should we make it clear that resources can point at a wide variety of >things, and that some of the things can be plural? > >Is this the URI sense of "resource"? (which doesn't appear in drafts >up through Feb 7) > >Regards, > Terry Allen Electronic Publishing Consultant tallen[at]sonic.net > specializing in Web publishing, SGML, and the DocBook DTD > http://www.sonic.net/~tallen/ > A Davenport Group Sponsor: http://www.ora.com/davenport/index.html > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Mar 1997 17:58:26 -0500 To: Terry Allen From: "Eve L. Maler" Subject: Re: 7. Attribute remapping? Cc: tbray@textuality.com, w3c-sgml-wg@w3.org At 02:06 PM 3/4/97 -0800, Terry Allen wrote: >>This involves pulling apart lists of things in attribute values. Yecch. >The obvious alternative is simply to have an arcform-like attribute >for every attribute we want to remap. Yecch also. Any other good ideas? > >Ilinks. For an in-the-document-entity solution, it doesn't seem so bad to have an NMTOKENS attribute that contains pairs of tokens (that admittedly are only "pairs" implicitly). XML processors already have to tokenize these attribute values, right? You could have something like this: Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: 4.3 SGML addressing Date: Tue, 04 Mar 1997 15:50:59 -0800 From: Joe English Tim Bray wrote: > Background: the draft spec supports SGML-style addressing, traditional > IDREF(S) and also by entity name. > > 4.3.a Should we support this type of locator? Yes. > 4.3.b Should we support entity addressing by name? Yes. > 4.3.c Should we support element addressing by ID attribute? Yes. > 4.3.d Should we support a combination of these two? No opinion. > 4.3.e What syntax should we use? Attributes with declared value IDREF, IDREFS, ENTITY, and ENTITIES, same as in SGML. --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 16:46:27 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 4.1 Address types | 4.1.a Should we have a single attribute used for storing all locators, | with another attribute expressing its type, as with the initial draft's | HREF/HRTYPE? Note that this has the side-effect that a locator element | can contain only one locator (which of course, could be a tokenized list). Could those who know what the XML sdecl really says comment on whether a list of URLs and URNs could be tokenized with white stuff in XML? Can it contain %, :, /, and that stuff? | 4.1.c If not, should we use a different attribute for each type of locator? If "type" means what HRTYPE used to mean ("identifies the interpretation fo the HREF"), the author should be able to do this. But I'm wondering about how I can do the following in the draft of 31 Jan 97: click to check on inflation specs if I can have only one HREF and one HRTYPE on each element. Apparently I would have to write: click to check on inflation specs which avoids using either href or hrtype more than once in any given start-tag. Or, if I can map the attributes of arbitrary GIs to their XML semantics outside the start-tag, I must have at least: click to check on inflation specs that is, I can't conflate in one attribute role and addressing. Seems to me that with any of the associative mechanisms proposed that should be possible (that is, I should be able to do what I showed in the first example). | 4.1.d If using different attributes for locator languages, can we have | multiple locators packed into locator attribute values? Same as 4.1.a's "tokenized list"? | 4.1.e Should we discard this scheme and adopt something wholly different | for selecting among locator languages? Provide a hook in the as-yet-completely-undefined general architecture for this information, specifying one small language, and specify the well known keyword for it. | 4.1.f Should we abandon the idea of different address types and assert that | everything is a URL? Can we do this and retain support for good old | IDREF(S) addressing? Does XML-LINK need to subsume IDREF(S)? This | would require packing complex addresses (e.g. TEI locators) into URLs. You won't be able to do very much with that which is not a URL. So far as I can see, IDs can be treated as fragment identifiers postpended to (possibly relative) URLs. It's URLs that subsume IDs. It would be possible to construct TEI locator encodings, or even Hytime locator encodings, using URLs and fragment identifiers. But there are many ways to do it. Turn the question around, and ask, "is there any reason for the SGML ERB to construct a way of encoding complex addresses if URLs will do instead?". I think further investigation will show you want to use queries, not fragment IDs (answering some other question in this train). Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 17:04:13 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 5.2 Linking element corrals? | The premise is that since extended links are independent of their | resources, they can be difficult to find. One solution is to | corral them into one spot, either within a document or in a special | external document. On the assumption that the question is about XML elements that are linking elements that are not in one or the other of the at least two (possibly identical) resources parts of which they link, or both ... | 5.2.a Should we provide an element to serve as a corral for extended | linking elements? How can I corral what is grazing on another man's range? What does this mean, specifically, in terms of 5.0 of the previous draft? | 5.2.b If so, should we require its use? | 5.2.c If we allow but not require its use, should we require that if the | corral is used, there be no extended linking elements outside it? XML 1.0 offers no such constraints. I suspect you mean "should the SGML ERB's linking language specify that conforming applications need process only those cattle already in the pen?", in which case you are talking about applications and the overall architecture. In the absence of any specification of application or architecture, it's hard to say. | 5.2.e Should we specify LINKSET documents, i.e. external entities | existing only to contain extended link corrals. Only the semantics of elements and attributes that may be contained within them, without excluding other content. | 5.2.f If we specify LINKS and/or LINKSETS, should we discuss the temporal | effectivity and user-visibility of the links therein, in terms of the | period the document is "open"? Please rephrase. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 17:14:23 -0800 From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 5.1 Extended Link Groups | 5.1.a Shall we support a mechanism for a document to contain a list of | other documents that someone thinks ought to processed with it, in order | to find linking elements pointing into the first document, and in general | create a web of related documents? "In general create a web" confuses an otherwise clearish question. Again, XML 1.0 allows this. You are asking not whether it should be supported in general, but whether one method should be specified. Yes. | 5.1.b If so, shall we say anything normative about whether this must be | done? No. | 5.1.c Should we use an SGML element, a PI, or some other construct to hold | this list of documents? An SGML DTD defined by the SGML ERB. | 5.1.d If we use an element, what should it be called? "-//W3C//DTD XML-omnistuff//EN", unless you're serious that the W3C doesn't own XML, in which case maybe "-//Everyman//DTD XML-omnistuff//EN". | 5.1.e If we use an SGML element, should we have subelements per referenced | doc or just a token-separated list of entity names in a single attribute? | In either case what should the subelement (if any) and attributes be | called? It would be so much more relaxing to write a DTD for this, wouldn't it? In any event you have to provide (what were) HRTYPEs for each doc referred to. (Still helping the SGML ERB with its inquiries) Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Mar 1997 23:11:11 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: ERB decisions on the LINKTYPE proposal At 2:13 PM -0800 3/4/97, altheim@jurassic.Eng.Sun.COM wrote: >[Pardon coming into the middle of this -- I've been out of circuit for the >last two weeks and haven't yet begun to catch up. But finding a (surprising) >discussion of LINK that isn't part of the LINK(ing) discussion, I thought I'd >interject. Pardon the length -- I want to address most of David's points.] You're forcing me to read the LINK specifications again, to cite the support for my assertions. This is fine, but the pain will not improve my humor, I'm afraid. >Agreed. And coming into the SGML community without any preconceived notion >that link is bad and evil and icky (which seems almost religious to many for >reasons I still don't understand), I find LINK to be a fine solution for the >problems it seems designed to solve. Certainly it has limitations, but they >don't warrant throwing the baby out with the bathwater. I've yet to see proof that there is a baby. >The particular usage of LINK that led me earlier to propose its inclusion in >XML is the same one as for HTML: attaching SDA attributes to a document >instance for transformation to the ICADD DTD. The added features of LINK over >the proposed alternative ATTLIST solution (context-sensitive processing for >one) make me question why ATTLIST is even considered -- they are not a direct >match functionally. The disadvantage is that the attributes are not "real" attributes, but are attributes in some "result document". This creates confusion when you have two attributes with the same name and different values. We need not even open that can of worms if we stay away from link... > >> It allows me to attach a separate attribute space to elements based on one >> of a number of predeclared (in the document) schemes. It allows me to >> dispatch to an external process with indefined semantics to establish those >> values. > >I'm not clear on what you mean by 'in the document', as LINK doesn't require >anything different than ATTLIST as regards 'in the document': both can simply >show up as a single declaration in the declaration subset. Nothing in the >document instance needs modification. If the DS insertion is what's bothering >you, nsgmls allows LPDs to be declared externally on the command line, so LINK >has that advantage over DS-based ATTLISTs. Well, this was an attempt to address the usefulness of what link claims to be useful for -- some form of processing. > >> I understand it all right, but I think processing information should >> _never_ be in the document instance. > >I agree completely (except when the document is part of a transform process). No, just never. The transform process is a separate thing, and should be stored separately. >I still don't understand why there isn't more screaming about some of the >extensive proposed XML uses of PIs. I find PIs as abhorrent as some do LPDs. I agree, but I decided that since I lost the battle against PIs, that I could rationalize XML PIs (only) as not too evil, since they have a defined semantics, and take advantage of the only syntactic extension hook we have. This latter is only a need because we opted for syntactic compatibility with DTDs rather than instance syntax. The thought that users (and Netscape and MS) can make their own PIs still makes me very nervous... >Use of LINK doesn't require processing information be embedded in the document >instance, which is precisely one of its benefits. The alternative proposed >ICADD solution of using multiple ATTLISTs *does* require adding the ATTLIST >declaration to the declaration subset, which I find less desireable for >precisely the reason you state above. I don't know from ICADD. The lack of multiple attlist delcarations is a continual thorn in the side of DTD authoring, well worthy on its own merits -- Once we have it, though, we no longer need another way to allow people to attach atributes to elements in documents. It's not the acme of elegance, but it uses no new syntax, no new semantics of output processing and LINK attributes, and has all the power that we need (as does IMPLICIT LINK). >>[...] And I think that the separate >> attribute space makes it much less useful, because there is no LINK-free >> meaning to LINK attributes. >If the purpose of LINK is either element-specific, context-sensitive, or >document-global GI mapping of attributes onto a document instance, then >essentially this argument is also true of stylesheets, yet I've never heard >this argument applied there. I and others did make precisely this argument to >the HTML-wg over adding STYLE attributes in the document instance, and look >where that went. I think both Terry Allen and I were hoarse at the end. But >this isn't about presentation, this is about assisting transformation between >DTDs, which would seem to have wider application than simply ICADD. No, it's about attaching architecture attributes to elements. Context sensitive processing in style sheets is in the style sheets, not in the document, so I don't see the relevance of the above. >Given that transformation of existing HTML documents to ICADD via either >ATTLIST or LINK requires more processing than is done by most browsers (which >typically don't process a DTD), the actual source of the contextual mapping >should contain the necessary information needed to perform the task without a >DTD. This also makes sense with DTD-less XML documents. Provided with either >an LPD or HTML-to-ICADD ATTLIST declaration, the LPD contains more of the >necessary data for context-sensitive transformation, where the ATTLIST doesn't >unless also accompanied by the DTD it is designed to modify. I don't see the relevance of compiling to ICADD. Sounds like an application for a DSSSL transformation, not a parser. We are trying to choose a mechanism to attach default attributes to instances without DTDs. >> So in fact, I still don't really see the use. I read the "nutshell" >> description several times, but I still have not seen any use for the >> mechanism that an external stylesheet sould not satisfy better. If it >> attached _real_ attributes to elements it might be useful for situations >> like this, but separate attlist declarations are a much more transparent >> and clean way to get that benefit, so again, I fail to see the value. > >I don't understand your differentiation of 'real' attributes vs. 'fake' ones. >An LPD could be written to exactly mirror an ATTLIST declaration, but not >vice-versa, as ATTLISTs don't contain #USELINK parameters (to my knowledge), >so there is no mechanism for context-sensitivity. The SGML standard differentiates LINK attibutes from regular atributes. They exist in two namespaces, and may have different values (since the idea is that the link attributes apply to some "output document type"). Now if this seems confusing that's because it it. LINK attributes are not the same as regular attributes, and you can even have link attributes with the same names as regular attributes and different values. SGML does not define a way for an element instance, to override a default LINK attribute declared in a LINK declaration. We would have to define rules of precedence for LINK attributes and regular attributes. >The rhetoric is dogmatic, hence my use of 'religious.' I agree that almost all >criticism I've heard in the past year (and I've heard a fair bit) amounts to >either 'it doesn't do everything I want' or 'it's not implemented in enough >products'. The former argument stresses that it's too simple, the latter that >it's too complicated. It can't be both. Sorry, but it can. LINK reminds me of assembly language. Not much there, but still hard to use. Of course LINK is not (even close to) turing-complete, so it's only an analogy. I think the method of doing context0-sensitivity in LINK is arcane, and hard to manage, and I still see no need for it once we have DSSSL (and lots of other transformation engines). So: hard to understand, and not very powerful. > IMO, it's a chicken and egg thing: >nobody saw an immediate use for or paid enough attention to LINK to bother >implementing it, therefore not enough people understand it well enough to know >how it might be used. I don't see anything that link can do that DSSSL can't do better, and it doesn't even solve the attribute assignment problem without adding further definitions of priority between "link attributes" and "attributes". (See 8879 4.165-4.171, 4.10. You can also look in Charles' book in chapters 5, 12). > > >>And we have a construct that for many committed SGML users is a red-flag. >> >>Seems technically and politically inferior to me... > >Politically, yes. Technically I don't see it as any different than any other >aspect of 8879. Well, it's less-clearly documented than any other part of 8879, DSSSL provides equivalent but more powerful features. And it is underspecified, at least according to Goldfarb (p. 172): "In particular, although the nominal result of processing is a document instance that conforms to the result DTD, this is merely a conceptual device to permit specification of the processing terms of the result document instead of, or in addition to, the source document, if that should be desirable. The actual result could be anything at all." At any rate, the result is not required to be _anything in particular_ -- certainly not the annotation of the ESIS (or whatever the application sees) with new attribute values not declared in the document. In other words conforming LINK implementations according to 8879 are _not_ required to look at, or even have access to, link attributes. This could create a compatibility problem even between the 3 applications that have implemented LINK. >> Since the semantics of LINK are undefined, they are a blank slate on which >> presumable usefulness can be projected -- but to me it just looks blank. > >ie., you haven't had a need for it. Fair enough. No, I don't see a guarantee in 8879 that an SGML application will _do_ anything predictable with a LINK specification -- just a specification of what LINK attribute lists will be visible to whatever it is that application decides to do. That's not enough to be more than a blank. It's a processing spec. that I can't even count on to process for me, because I can't tell what it's going to do with the link attributes. >> I don't want to put processing information in my document instances -- so >> one use for LINK is anathema to me. Read the back issues of this list for >> many arguments on why processing should _not_ be part of documents. > >I believe I addressed this above, although I'm open to being countered. I missed it, if so... >> I don't believe that LINK solve the attribute attachment problem because it >> explicitly allows LINK attribute names to be the same as document attribute >> names -- so it just doesn't address the problem unless you mis-implement it. > >For the purposes of ICADD transformation, I don't see this as a problem at >all. And with #USELINK this is reduced to a non-issue, non? What does ICADD transformation have to do with the price of long green beens in Bulgaria? >I could find more than two reasons to discard a substantial portion of HTML >3.2, but that doesn't mean that others don't find a valuable usage. LINK for >HTML and XML has a usage regardless of whether people like it or not: ICADD >transformation. As we get into more complex element/attribute mapping >(specifically, document structure and complex tables) I don't see ATTLISTs as >an adequate solution. And at the point we're at, I'd hate to cut XML out of >what may be the best solution. DSSSL transformation engines are the probable preferred mechanism for XML... > >> >>Elegant and powerful are not the words that come to my mind. >> > >> >Adjectives again. I plead guilty to having used them without further >> >explanation. If anyone wants to know *why* [I think] LINK is powerful, just >> >ask. I will be happy to attempt a clear, concise and (hopefully) convincing >> >explanation -- with XML-related examples. >> >> I find writing without adjectives rather boring. > >I believe Steve was referring to usage of adjectives in the advertising sense. I believe that his response came after a list of reasons I think LINK inadequate. I would also challenge anyone who claims that LINK can do _anything_ to show me how the language in the standard itself supports that claim. I can understand Charles' book, but nothing has ever made the normative text make sense to me. >We could add 'whitens your teeth' too, but without proof it has no meaning. I >certainly find an LPD more elegant than an ATTLIST declaration. I've been able >to describe an LPD to completely SGML-illiterate people, so it can't be that >obtuse. For specifying an attribute value (all we have called on LINK to do here), it is much less obvious why we need a new construct, when we can get the same effect (specifying a default attribute value, not transforming documents), by removing a limitation of ATTLIST declarations that many already find burdensome. >> I also don't want to recpitulate the entire argument -- it never seems to >> resolve -- but that last fact of non-resolution is a good reason to avoid >> LINK in my opinion. > >Filibustering? Don't laugh, but my fingers _are_ getting sore..... >If so few people know about or use LINK, how could it be so 'widely detested'? >I wouldn't make it a requirement of XML systems, I would simply *allow* it in >the SGML declaration so that those who would like to use it may. It's >certainly no more of a hack than multiple ATTLISTs. Lots of people try to read the standard or Charles' book, or Erik's book... None of these seems to have made LINK attractive. certainly it was 10 years or more from the issuance of the standard when I heard anyne do anything other than groan when LINK came up. It's only widely detested among people who know about it, true, but that might tell you something. >> >I'm not quite sure what David's objection is here. As I already pointed >>out, >> >SP (and nsgmls) already support LINK, so it will not be a major task for > >>any systems based on this parser to add the required capability. LINK is > >>also supported by another important parser, Mark-It, upon which many other > >>products are built (including at least one pre-eminent SGML editor, as far > >>as I know). > >> And by no other parsers to my knowledge. A less than overwhelming showing. And can you use LINK specs that work with one to get a repeatable effect with the other? I don't thing so. >Chicken and egg, as I said above. Underspecified, as I said above. >The argument that adding LINK to XML adds complexity to the specification is >certainly valid Yep. , but only insofar as the specification, not a specific >implementation. What, they don't have to implement what we specify? Seems that it complicates both. > If LINKTYPE processing is allowed as an option (described in >an addendum) rather than proscribed in the spec Wasn't _no optional features_ a design goal? > even insofar as describing a >subset such as simple and implicit links (with no explicit), we would avoid >muddying the document instance and allow for context-sensitive transformations >without putting the burden on stylesheet processing (which is certainly light >years more complex than simply adding LINK to XML). But we are going to have stylesheet processing anyway, and we are specifying a language, not a transformation engine -- there's no need to confuse the two, just because 8879 did... > Or we could simply allow >the 8879 definition of LINK as an option and point to that specification. Not acceptable because the XML specification must stand on its own. How many months of bitter argument do you think it would take to restate the LINK rules and reach agreement that they are compatible with the mangled prose of the standard? >And yes, I do feel like I'm trying to revive a beaten, dead horse. I just >don't understand why it was killed in the first place. Anyway, Jon said that LINK will only be considered if multiple ATTLISTs fail. so let's just give this a rest, or take it off the list. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 09:06:57 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.4 New Item: unify simple and extended links At 13:06 4/3/97 -0500, David Durand wrote: >This seems to complicate the model, and isn't necessary if we have an >equivalent of BASE or LOCSRC. I would leave this out as being purely a >convenience feature unless we don't have an equivalent way to specify an >alternative addressing origin (or LOCSRC or base address or whatever you >want to call it) I thought LOCSRC had been dropped, which is partly why I suggested the alternative based on nesting. If locrsrc is there you don't need this concept of redirecting fragment references, though the labelling of groups of tags is still important. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 09:07:02 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.d Compulsory locator language(s)? At 12:33 4/3/97 -0800, Tim Bray wrote: >4.d The spec will describe some addressing types that we support. Should >we declare support for one or more locator languages to be compulsory? >Which? Support for URL addressing should be compulsory, but not the only option. Ideally I would like to see SGML FSI support, or at least a subset of the default FSI set, with the presence of being implied at the start of the string if there is no other identifier for the type of locator being used. I would also like to see a TEI locator identified by a tag defined as a formal FSI. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 05 Mar 1997 09:20:24 +0000 (GMT) From: Peter Flynn Subject: Re: 7. Attribute remapping? To: w3c-sgml-wg@w3.org Tim Bray writes: > We have decided that we will allow the use of any old GI's on XML linking [...] > Do we need to allow them to be remapped as well, so that when an > HTML doc says HREF= and a TEI doc says PTR=, they can mean the same > thing? Yes. I prefer the AF-style remapping but it is not going to be warmly received by the webfolk because it involves additional effort even after the concept has been sold. To make it usable, we will have to provide templates, and educate the authors and implementors in its use. We ditched PIs, didn't we? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 07:48:41 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Kind of surprising commercial XML application Check out http://www.ile.com/opentag/ I don't understand the application domain enough to really be fully in tune with all the implications, but it's an interesting read. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:56:54 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.2 Location-source/Base address At 12:33 4/3/97 -0800, Tim Bray wrote: >4.2.a Should we formalize at all the concept of a base address? Yes > >4.2.b If so, should we call it a location source or something else? locsource (for locator source rather than location source) or just source > >4.2.c Should we formalize the concept of the implied location source? Yes - it should always be the referencing document >4.2.d If so, should the values be DOCELEM and REFERRER, defaulting to >DOCELEM? >From 4.2c, XML does not need to adopt the extra REFERRER functionality of HyTime. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:57:17 +0000 To: Tim Bray , w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.a Can resources be plural? At 12:33 4/3/97 -0800, Tim Bray wrote: >4.a Should we make it clear that resources can point at a wide variety of >things, and that some of the things can be plural? What do you mean by plural? Any resource with embedded links points to a wide variety of things. Most of these will also point to a wide variety of things. The question of pluralism is only interesting if you think of it in terms of: a) multiple copies that can be located via a public naming convention, e.g. URN b) multiple language options of the same document which can be offered to users based on a preference statement supplied with the document request. Mechanisms for both of these approaches would be useful. How about: locates="Martins's SGML Goodies | Michel's SGML balise | Jurgen's SGML dings | -//Your company//TEXT SGML info//EN"> ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:56:49 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 5.1 Extended Link Groups At 12:33 4/3/97 -0800, Tim Bray wrote: >5.1.a Shall we support a mechanism for a document to contain a list of >other documents that someone thinks ought to processed with it, in order >to find linking elements pointing into the first document, and in general >create a web of related documents? Yes >5.1.b If so, shall we say anything normative about whether this must be >done? There are two possibilities here: 1) Make it an optional feature of browsers and require that documents requiring this feature have an initial processing instruction that says that they require a browser that supports this option 2) Require all XML browsers to support the feature through normative text. > >5.1.c Should we use an SGML element, a PI, or some other construct to hold >this list of documents? An SGML element > >5.1.d If we use an element, what should it be called? or ? >5.1.e If we use an SGML element, should we have subelements per referenced >doc or just a token-separated list of entity names in a single attribute? >In either case what should the subelement (if any) and attributes be >called? > Subelements per referenced doc. or ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:57:03 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 7. Attribute remapping? At 12:33 4/3/97 -0800, Tim Bray wrote: >We have decided that we will allow the use of any old GI's on XML linking >elements, identifying by the use of reserved attribute names and values. >We will be specifying the use of some attributes to support XML linking. >Do we need to allow them to be remapped as well, so that when an >HTML doc says HREF= and a TEI doc says PTR=, they can mean the same >thing? > This is essential if we want to import existing data. >If we don't do this, then either we call all locator attributes HREF= >or we take a terrible loss in selling this to the web-folk. And then we cannot use ID/IDREF for locators! >If we do do this, we add substantial complexity to the spec and >the processing model. Why "substantial"? All we are talking about is a simple one-to-one look-up table. > >Eve suggested a mechanism for this in > > http://www.doctools.com/xml-link.html > >This involves pulling apart lists of things in attribute values. Yecch. Whats so difficult about processing a list of matched pairs of values to create look-up table entries? >The obvious alternative is simply to have an arcform-like attribute >for every attribute we want to remap. This would be twice as much work as you would need a table of arcform names as well as the resulting lookup table. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:56:57 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.5 TEI Extended Pointer Locators? At 12:33 4/3/97 -0800, Tim Bray wrote: >4.5.a Should we support these? Yes - though preferrably with the revised syntax that has been mooted, with url(......)id(......)path(....) ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:57:19 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.b Links pointing at links? At 12:33 4/3/97 -0800, Tim Bray wrote: >4.b What should we say about the situation when a linking element points >at a resource which is another linking element? Fetch boy:-) ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:56:52 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.c Homegrown locator language? At 12:33 4/3/97 -0800, Tim Bray wrote: >4.c The spec will describe some addressing types that we support. Should >we be open-ended and include a way to support other user-defined >locator languages? If possible, as this would save us having to revise the spec everytime someone comes up with a better way of identifying resources ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:57:13 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 5.2 Linking element corrals? At 12:33 4/3/97 -0800, Tim Bray wrote: >The premise is that since extended links are independent of their >resources, they can be difficult to find. One solution is to >corral them into one spot, either within a document or in a special >external document. > >5.2.a Should we provide an element to serve as a corral for extended >linking elements? Yes - as long as it is repeatable and can be used anywhere. (I want to build webs by saying add this web to that web) > >5.2.b If so, should we require its use? It or an element conforming to the same architectural form with an architectural attribute name that matches that of the element, the attribute being required for any user-named equivalent element. >5.2.c If we allow but not require its use, should we require that if the >corral is used, there be no extended linking elements outside it? This would make it impossible to have in-line extended links! >5.2.e Should we specify LINKSET documents, i.e. external entities >existing only to contain extended link corrals. Yes >5.2.f If we specify LINKS and/or LINKSETS, should we discuss the temporal >effectivity and user-visibility of the links therein, in terms of the >period the document is "open"? What is a document in this sense, and how can you "open" and, more importantly, "close" it? Where the LINKSET is used at the start point you can say it is effective while any document the set refers to is listed in the History/Go list (presuming this is minimized a la Netscape). But you cannot use the same rules if the LINKSET is "attached" to a document at some stage after its is first called. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:56:59 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.6 Query Language Locators? At 12:33 4/3/97 -0800, Tim Bray wrote: >4.6.a Should we support this? > >4.6.b If so, should we specify any query languages? This could be left to version 2.0. I suspect that the answer will be tied up to whether we will allow SDQL querying related to the style sheet. If so it would make sense to also be able to apply it to locators. If not then perhaps we should just stick to TEI level querying. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:57:10 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.3 SGML addressing At 12:33 4/3/97 -0800, Tim Bray wrote: >Background: the draft spec supports SGML-style addressing, traditional >IDREF(S) and also by entity name. > >4.3.a Should we support this type of locator? What form of SGML addressing exists other than IDREF? > >4.3.b Should we support entity addressing by name? Yes > >4.3.c Should we support element addressing by ID attribute? Yes > >4.3.d Should we support a combination of these two? Yes > >4.3.e What syntax should we use? The SGML one - #ENTITY entity-name ID ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:57:07 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 4.1 Address types At 12:33 4/3/97 -0800, Tim Bray wrote: >4.1.a Should we have a single attribute used for storing all locators, >with another attribute expressing its type, as with the initial draft's >HREF/HRTYPE? Note that this has the side-effect that a locator element >can contain only one locator (which of course, could be a tokenized list). Yes (though you don't need HRTYPE if you follow the suggestion below!) > >4.1.b If so, what should the attribute be called? locates > >4.1.c If not, should we use a different attribute for each type of locator? >Note that this means we could in principle have multiple addresses per >locator element although only one of each HRTYPE. Yecch > >4.1.d If using different attributes for locator languages, can we have >multiple locators packed into locator attribute values? >4.1.e Should we discard this scheme and adopt something wholly different >for selecting among locator languages? If by "this scheme" you mean the idea of having differently named locator elements for different HRTYPES then you should most definitely discard it. Why not adopt the FSI approach to identifying locator schemes, viz: locates="http://my.com/docname#findthis url(......)id(...)path(,...) /directory/file.ext rfc1234.txt" You get nicely delimited entries/tokens You get qualifying properties like FSIBase You get multiple types of locators without needing an HRTYPE attribute You can mix and match locator types You have a defined order in which to access locations All this using standarized SGML components with nothing invented specifically for XML. What's more you have a fully extensible scheme. > >4.1.f Should we abandon the idea of different address types and assert that >everything is a URL? Can we do this and retain support for good old >IDREF(S) addressing? Does XML-LINK need to subsume IDREF(S)? This >would require packing complex addresses (e.g. TEI locators) into URLs. NO, NO and NO. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 11:45:10 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: Kind of surprising commercial XML application At 07:48 AM 3/5/97 -0800, Tim Bray wrote: >Check out > > http://www.ile.com/opentag/ > >I don't understand the application domain enough to really be fully >in tune with all the implications, but it's an interesting read. - Tim In case anyone is curious, here are the ways in which the opentag.dtd isn't XML compliant (some of the ways are trivial, some not): - #PCDATA must come at the beginning of a content model (%paratxt;, u, ...) - #PCDATA must always use * occurrence indicator (u, ...) - #PCDATA can't be in a model with pernicious mixed content (lvl) - Exceptions not allowed (b, ...) - OMITTAG specifications not (yet :-) allowed - NUMBER declared value not allowed (p, ...) - Comments not (but this isn't in the spec version they used) Designing and implementing DTDs according to the XML constraints is a new discipline... Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Christopher R. Maden" Date: Wed, 5 Mar 1997 18:54:24 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR [Len Bullard] > Does XML need this, or is XML better seen as the language of the > database an application like MID navigates? I prefer to think of XML as the language for the database itself. XML is a markup language - that which is being marked up is data. An application could certainly use XML to mark up its specifications, but just because the same language can be used does not mean information should be stored in the same place. The data - textual content, metadata, and relationships between infoquanta - should be contained in the XML document. Suggested (or required) behavior should be stored separately. I should be able to open the document in SoftQuad XenoMetaL Style Editor and turn off the d*mn flashing bullets in front of every item in the Luddite Manifesto. If the transclusion of those bullets is hardcoded in the XML source, I can't do that - unless I can override the suggested behavior in the stylesheet, and if that's true, why not just use the stylesheet always, since browsing will be sort of useless without it? And yes, I don't expect many people to be editing DSSSL directly; I think there will be shared stylesheets for common DTDs, which people can tweak bits of by hand, and editors for creation of new ones. Most users of XML will either be able to deal with DSSSL or will be using simple DTDs they pulled off the 'net. -Chris -- Christopher R. Maden One Richmond Square DynaText SIT Technical Support Providence, RI 02906 USA Inso Corporation +1.401.421.9550 (voice) Electronic Publishing Solutions +1.401.521.2030 (facsimile) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 11:19:54 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Updated/reorganized spec As we agreed, http://www.textuality.com/sgml-erb/WD-xml.html is now a stub/hub document, pointing to the base XML spec, WD-xml-lang.html and our new baby, WD-xml-link.html. WD-xml-lang.html remains un-updated since November (bad, *bad*, editors!). WD-xml-link.html is now dated March 5, has been updated throughout for terminology, and sections 1 through 4 have been updated in line with ERB decisions over recent weeks. Input, as always, gratefully accepted, everything including general organization, style, presentation, and of course accuracy. As for the material design issues, if at all possible could we keep to the numbered discussion headings in order to keep this runaway omnibus headed in more or less the right direction. In offering editorial input, please use consideration in deciding whether to send input to the mailing list (recommended for technology issues) or just to Steve and me (recommended for style/typography/etc). Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: 4.b Links pointing at links? Date: Wed, 05 Mar 1997 11:44:53 -0800 From: Joe English Tim Bray wrote: > 4.b What should we say about the situation when a linking element points > at a resource which is another linking element? Please rephrase this question; it makes no sense at all to me. Perhaps I am hopelessly confused, but as I understand XML-LINK, a linking element does not "point at" anything at all. Links contain locators (either as attributes or as subelements, that seems still to be up in the air), and _locators_ point at resources. (Below I'll use the terminology in the 26-Jan-1997 XHL draft, since I'm not sure what vocabulary is in vogue this week :-) Now if a locator 'A' points to another locator 'B', I think the most sensible and useful interpretation would be indirection: the referent of 'A' should be resolved to whatever 'B' points to (and so on recursively, with the usual caveat that cycles are deemed illegal). This is assuming we decide to use locator elements instead of (or in addition to) locator attributes, since the latter are unaddressable in any of the addressing schemes proposed so far. If a link 'L' has as one of its anchors an element 'M' denoting an in-line link (HyTime: "clink"), then the link-end should resolve to 'M'; it should *not* follow the second link. Otherwise HTML-ers who are used to using ... will be in for a surprise... If a link has as one of its anchors an out-of-line link (with any number of link-ends), that situation seems to me sufficiently bizarre that the spec should say nothing at all, leaving its interpretation entirely up to the application. --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 13:47:48 -0600 From: Len Bullard To: "Christopher R. Maden" CC: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Christopher R. Maden wrote: > > [Len Bullard] > > Does XML need this, or is XML better seen as the language of the > > database an application like MID navigates? > > I prefer to think of XML as the language for the database itself. XML > is a markup language - that which is being marked up is data. An > application could certainly use XML to mark up its specifications, but > just because the same language can be used does not mean information > should be stored in the same place. Ok, and understood. I consider that position a religious one. Markup of data vs markup of text that an interpreter treats as instructions are still just markup. XML should neither prefer not prevent either. Too many designers find it useful or convenient to markup processes (e.g, action=) and include behavioral specifications for it to be disregarded by the WG for purely religious orientations. Separate church and *state*. > The data - textual content, metadata, and relationships between > infoquanta - should be contained in the XML document. Yes. But relationships are either passive records or active structures. They have a clickable interface or they don't. If the stylesheet is used to tell the system that an Suggested (or required) behavior should be stored separately. If there were a technical reason for that other than someone might prefer curly brackets over pointy brackets, it might be a good point. But when I open an HTML file and see function calls in attributes values, a script tag full of curly brackets, etc., I think this religion is out of style, out of date, and out of time. XML should be agnostic about that. > I should be able to > open the document in SoftQuad XenoMetaL Style Editor and turn off the > d*mn flashing bullets in front of every item in the Luddite Manifesto. Yes, well, depending on where you fall on the "author intention vs reader privilege" debates. > If the transclusion of those bullets is hardcoded in the XML source, I > can't do that - unless I can override the suggested behavior in the > stylesheet, and if that's true, why not just use the stylesheet > always, since browsing will be sort of useless without it? Because there are times when to repurpose data, or simply to make it smaller, no stylesheet will exist. Any tightly focused app such as CML, MID, etc. may not offer many style options, and even these, as with IADS, may be in a proprietary stylesheet format with a point and click interface because the application designer or the requirements specify that only the document is portable, archivable, etc. For these cases, as in HTML, it is convenient to indicate the behavior for active links. A static relationship link is only a record of a relationship. An active link (e.g, a hypertext link as common practice sees it) is a record and a control interface (clickable). This is probably the piece that keeps bothering everyone. While this can be achieved by indirection, it isn't the only way and in many cases, by empirical observation of existing systems, not always the best way. Again, XML should be agnostic about that. > And yes, I don't expect many people to be editing DSSSL directly; I > think there will be shared stylesheets for common DTDs, which people > can tweak bits of by hand, and editors for creation of new ones. Most > users of XML will either be able to deal with DSSSL or will be using > simple DTDs they pulled off the 'net. Some. Some will design ground up. Some will take bits and pieces and adapt them. I suspect a good number of DSSSL rendering processing specs will just be Jon's HTML version with different GIs and some additional attribute handlers. The main problem we will have selling the approach will be to convince someone that they can handle a laissez faire hypertext medium. We faced this with IADS and IDE/AS. If a user wants style freedom, they get style responsibility. If a designer wants to have behavior flagged in the markup, they get to implement the handlers for those *proprietary* tags. How one views the behavior attribute is exactly the same as how one views all of the other *application* features of XML Link. XML Link is an application of XML Markup. It is an application we are all agreeing on now to provide interoperability for XML applications of hypertext. Heck: Tornado warning. Time to sign off and hide in the middle of the building again. Later... len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 15:21:30 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.3 SGML addressing At 12:33 PM -0800 3/4/97, Tim Bray wrote: >Background: the draft spec supports SGML-style addressing, traditional >IDREF(S) and also by entity name. > >4.3.a Should we support this type of locator? At least. I think TEI xptr syntax should also be in there. > >4.3.b Should we support entity addressing by name? We should allow the use of entity addressing for LOCSRC or its equivalent, if we have one (and we probably should). I'm not sure that _linking_ to an entity itself makes that much sense (if we preserve the SGML notion that entities are basically abstractions of storage structures). is there a 1-1 correspondence between WWW "resources" (anything with a URL) and SGML entities? >4.3.c Should we support element addressing by ID attribute? yes. >4.3.d Should we support a combination of these two? I think that a LOCSRC facility accomplishes that. If we restrict LOCSRCs to be entities only, and entities to be used only as LOCSRC, I think we cover all the essential ground, though we do in fact lose some power. >4.3.e What syntax should we use? URL syntax for everything... I made one proposal, but others would probably serve aas well or better. I think that some servers will provide server-side fetching of sub-components, but that we should provide a fragment-based mechanism for accessing data withing a parsed sub-tree. As Gavin has noted, this means that an author's decision to use fragment-style querying will prevent certain efficiencies in the server/browser collaboration, but keeping the spec focused on the language and the client side seems like such an important simplification that we should do it. Nothing will prevent the use of external entities or specialized server link resolution, but we will not standardize such mechanisms -- any more than HTML has had to standardize server-includes, despite their great utility... -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 15:23:43 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.b Links pointing at links? At 12:33 PM -0800 3/4/97, Tim Bray wrote: >4.b What should we say about the situation when a linking element points >at a resource which is another linking element? we should allow (require) 1 level of indirection. So the first link you come to, you follow silently. You park at the second whatever it is, however. This gives us the flexibility of indirection without need for loop detection (remember processors where you could loop the microcode with indirection). It also makes targeting a link more difficult, but not excessively so. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 15:36:48 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.4 URL processing At 12:33 PM -0800 3/4/97, Tim Bray wrote: >Very likely XML Link will use URLs (perhaps among things) for locators. > >Is this all we need to say? Any URL is a valid locator, so we don't need to say more about that, but.... >Do we need specific interpretation of '#' fragment handling for XML? Yes, since all query-like things should be expressed by XML-specific fragment identifiers -- and we will need to explain the syntax that we choose for that. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 15:46:12 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.5 TEI Extended Pointer Locators? At 12:33 PM -0800 3/4/97, Tim Bray wrote: >4.5.a Should we support these? Yes. >4.5.b What portions of TEI extended >pointers should be dropped from this spec? Definitely: HYQ -- obsolete, and not that nice. FOREIGN -- in this context, I think extensibility is bad, not good. DITTO -- not worth the trouble, I think. TOKEN -- space delimited thingies is harder in Unicode, and probably not that useful anyway. Maybe: SPACE -- ranges in orthogonal coordinate spaces seem too limited -- We might want something suitable for implementing client-side imagemaps (and other image links), but SPACE doesn't give enough. PATTERN -- we all agree that this would be really useful, but it may be a bit of a bother to implement. I'm on the fence about this... Everything else should stay in (essentially basic tree addressing functions). -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:09 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.b Links pointing at links? At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >4.b What should we say about the situation when a linking element points >at a resource which is another linking element? Tough one. I see three choices: 1. duck, say nothing 2. say we indirect one level, as Durand proposes 3. make this another axis of behavior policy specification, a numeric-valued attribute, i.e. INDIRECT-CEILING=4? 4. say we never indirect, leaving it up to the application. I think we're going to get enough of TEI XPTR to have most of the goodness of location ladders. I go for #4. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:14 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.2 Location-source/Base address At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >4.2.a Should we formalize at all the concept of a base address? Yes, it's generally useful for a variety of reasons, e.g. replication support, it's a real pity that HTML BASE is in general not better defined and understood. >4.2.b If so, should we call it a location source or something else? Don't care. >4.2.c Should we formalize the concept of the implied location source? No, the cost-return ratio doesn't seem that good; perhaps Eliot has some killer examples though. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:19 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 5.1 Extended Link Groups At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >5.1.a Shall we support a mechanism for a document to contain a list of >other documents that someone thinks ought to processed with it, in order >to find linking elements pointing into the first document, and in general >create a web of related documents? Yes. We may not be able to specify the great BOS in the sky - in Steve Newcomb's terms, to assert that every resource must know it's a resource - but the benefits are immense and it's easy. >5.1.b If so, shall we say anything normative about whether this must be >done? Maybe not "must be done", but if done, I think it must be respected. Why not? Obviously unenforceable, but if we provide a mechanism for info-providers to assert their choices in this area, then products to be called compliant should respect those choices. >5.1.c Should we use an SGML element, a PI, or some other construct to hold >this list of documents? >5.1.d If we use an element, what should it be called? >5.1.e If we use an SGML element, should we have subelements per referenced >doc or just a token-separated list of entity names in a single attribute? >In either case what should the subelement (if any) and attributes be >called? I like the way it is in the draft spec. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:11 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.c Homegrown locator language? >4.c The spec will describe some addressing types that we support. Should >we be open-ended and include a way to support other user-defined >locator languages? I think we should try really hard to make everything a URL. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:08 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.a Can resources be plural? At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >4.a Should we make it clear that resources can point at a wide variety of >things, and that some of the things can be plural? OOps, resources should say "locators". Still, this is something that we have to do in order to declare victory, so we should make this clear up front. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 15:35:01 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.1 Address types At 12:33 PM -0800 3/4/97, Tim Bray wrote: >4.1.a Should we have a single attribute used for storing all locators, >with another attribute expressing its type, as with the initial draft's >HREF/HRTYPE? Note that this has the side-effect that a locator element >can contain only one locator (which of course, could be a tokenized list). I don't like locator types. We should define a fixed list of types, and leave it there -- interoperability and simplicity are not served by making obvious extension mechanisms that people should not use. I don't mind the single locator that much, but I'm not sure why it's an issue... Are locators going to appear in the content of elements? I think that's a bad idea because it violates many people's expectations that "tag stripping" makes sense. It doesn't always, but putting link addresses in content means that authors can no longer choose to use a tagging style in which tag-stripping does make sense. This seems a problem to me. > >4.1.b If so, what should the attribute be called? nonexistent >4.1.c If not, should we use a different attribute for each type of locator? >Note that this means we could in principle have multiple addresses per >locator element although only one of each HRTYPE. Seems too complicated. Locator syntax should differentiate locator type, via URL syntax. >4.1.d If using different attributes for locator languages, can we have >multiple locators packed into locator attribute values? This is a good reason for a single locator attribute -- although I strongly believe that we should _not_ have multiple locatore languages: if TEI is not enough, then XML should extend it, not add others in. >4.1.e Should we discard this scheme and adopt something wholly different >for selecting among locator languages? URL syntax, and self-indentifying fragment IDs. Possibly some LOCSRC-like way to spcify a base URL, or starting entity (for XML syntax-based location) >4.1.f Should we abandon the idea of different address types and assert that >everything is a URL? Can we do this and retain support for good old >IDREF(S) addressing? Does XML-LINK need to subsume IDREF(S)? This >would require packing complex addresses (e.g. TEI locators) into URLs. Yes, I think. We could require a declaration to tell the difference: CDATA link attributes would be URLs, and IDREF attributes would be IDREFs with the same properties as today. Worst case, we make IDREFS look like "#sdfds" and change the SGML concrete syntax slightly. replacing spaces with commas in the TEI locators makes soemthing that packs nicely, as Steve has pointed out to me before now... -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:16 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.3 SGML addressing At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >Background: the draft spec supports SGML-style addressing, traditional >IDREF(S) and also by entity name. > >4.3.a Should we support this type of locator? >4.3.b Should we support entity addressing by name? >4.3.c Should we support element addressing by ID attribute? >4.3.d Should we support a combination of these two? Yes to all the above. >4.3.e What syntax should we use? Whatever, as long as we can call it a URL. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:18 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.6 Query Language Locators? >4.6.a Should we support this? >4.6.b If so, should we specify any query languages? At the moment, I'd leave this for rev 2. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:13 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.1 Address types >4.1.a Should we have a single attribute >4.1.b If so, what should the attribute be called? >4.1.c If not, should we use a different attribute for each type >4.1.d If using different attributes for locator languages >4.1.e Should we discard this scheme and adopt something >4.1.f Should we abandon the idea of different address types and assert that >everything is a URL? 4.1.f for me; URLs demonstrably do the job, and already encapsulate a whole bunch of different schemes in a manner that if, inelegant, works. I'd figure out a way to squeeze anything else we need into URLs - we can do this with TEI XPTR's in one or two ways, and I suspect this would be a win for TEI too. That really leaves IDREF(S). So... do SGML IDREFs really need to be subsumed into XML Link? They're already part of base XML. If they do, must we retain the current syntax, or can we URL-i-fy them, by putting '#' in front of IDREFs and/or inventing a couple of new schemes? Someone said that per web rules, we have to formalize what the part after a '#' means in XML anyhow. Ooh, I'm gonna get scorched. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:21 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 5.2 Linking element corrals? At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >The premise is that since extended links are independent of their >resources, they can be difficult to find. One solution is to >corral them into one spot, either within a document or in a special >external document. > >5.2.a Should we provide an element to serve as a corral for extended >linking elements? Yes >5.2.b If so, should we require its use? No >5.2.c If we allow but not require its use, should we require that if the >corral is used, there be no extended linking elements outside it? Yes. Otherwise worthless >5.2.e Should we specify LINKSET documents, i.e. external entities >existing only to contain extended link corrals. Redundant... if you have an xlink corrall, then you can have a document containing just an xlink corrall - so you got this in effect. >5.2.f If we specify LINKS and/or LINKSETS, should we discuss the temporal >effectivity and user-visibility of the links therein, in terms of the >period the document is "open"? No. I think it's hard to get this right; if we're clean on the semantics of what it *means*, that should be enough. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:17 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.4 URL processing At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >Very likely XML Link will use URLs (perhaps among things) for locators. >Is this all we need to say? >Do we need specific interpretation of '#' fragment handling for XML? Yes. And we need to get this right. I think that we should say that if it's just a NAME after the #, this is an IDREF - if it's a '(', this is the start of a TEI locator. If < wasn't such a problem we could consider FSI syntax and so on too. -Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:23 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 7. Attribute remapping? At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >We have decided that we will allow the use of any old GI's on XML linking >elements, identifying by the use of reserved attribute names and values. >We will be specifying the use of some attributes to support XML linking. >Do we need to allow them to be remapped as well, so that when an >HTML doc says HREF= and a TEI doc says PTR=, they can mean the same >thing? I hate it, but I think we have to do this. Warning: this is going to be a *major* pain in the butt to explain/justify to the webheads who are used to GI-dependent semantics. A 2-phase teaching strategy will be required - first you explain XML links using hardwired GI's and attributes, then *later* you say "oh yes, and you can call 'em what you want". Eve's method is as good as any. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 12:53:12 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 4.d Compulsory locator language(s)? >4.d The spec will describe some addressing types that we support. Should >we declare support for one or more locator languages to be compulsory? >Which? We should make URL support compulsory, and try really hard to crush all other addressing modes into URLs. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:44:39 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: 4.b Links pointing at links? Tim Bray wrote: > > At 12:33 PM 3/4/97 -0800, Tim Bray wrote: > >4.b What should we say about the situation when a linking element points > >at a resource which is another linking element? > > Tough one. I see three choices: > > 1. duck, say nothing > 2. say we indirect one level, as Durand proposes > 3. make this another axis of behavior policy specification, a > numeric-valued attribute, i.e. INDIRECT-CEILING=4? > 4. say we never indirect, leaving it up to the application. I think we're > going to get enough of TEI XPTR to have most of the goodness of > location ladders. > > I go for #4. -T. 1. Can't do that. Location ladder concepts are showing up in other languages. Mark Pesce has this as the cornerstone of his CyberProtocol speech although he does not acknowledge the concept predates his papers. Indirection of this kind is far too common in even human speech to avoid it. 2. If that means, indirect to, which can, indirect to, fine. A rung in a ladder only has two neighbors with the exceptions of the ends. Why would only one level of indirection be more useful than none? 3. Kind of baroque. It won't prevent circularity, and it doesn't give us anything that we need. I think this is like the "let the links snap" decision made for URLs. If they point to a link to a link to the deep blue ocean, that is something they should find when they test the links. If they don't test their links, someone will. If no one does, it doesn't matter. 4. Same as one. I'll have to go back and look at TEI XPTR again to see. As I recall, location ladders are useful when the linkages have to mix types of locators in order to identify a resource. In a sense, that mixes the link with the scheme. Is that what we give up here? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Mar 1997 15:48:55 -0600 From: Len Bullard To: Tim Bray CC: w3c-sgml-wg@w3.org Subject: Re: 4.c Homegrown locator language? Tim Bray wrote: > > >4.c The spec will describe some addressing types that we support. Should > >we be open-ended and include a way to support other user-defined > >locator languages? > > I think we should try really hard to make everything a URL. -T. Absolute agreement. I have to write an object and addressing policy for some folks, and I want to base that strictly on the Internet identification, naming and location standards. OTW, it is very hard for these folks to buy anything commercial and get the level of interoperability they not only want, but have to have for mission critical apps. Selling the XML depends on the speed with which XML becomes a preferred commercial standard. They no longer want to write their own. Too expensive; no one listens anyway until big dollar procurements enter the picture. Stop the madness. No more charity work. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on the LINKTYPE proposal Date: Wed, 05 Mar 1997 13:15:17 -0800 From: Joe English Steve Pepper wrote: > > The arguments against using LINK syntax seem to be falling into a number > of distinct categories: > > 1) Malediction > 2) Confusion caused by the very word LINK > 3) "Nobody understands it" > 4) "LINK can't do the job anyway" > 5) Verbosity and lack of clarity of the syntax > 6) Difficulty of implementation > 7) "LINK is unnecessary if WG8 gives us multiple attlists" I'll add one more: The LINK feature is fatally flawed in a number of ways. I actually think LINK is an elegant concept, and your proposal is a good one, but LINK is specified so badly in 8879 that I'd hesitate recommending it as a "standard-conforming" solution to any problem. More on that below... > 3) "Nobody understands it" > -------------------------- > This is the key argument, I suppose. If as Tim says "only 17 people in > the world understand LINK", I see that we have an uphill battle on our > hands. The first question is, is this WG prepared to _try_ to understand > it before rejecting it? The next question is, is it the _concepts_ that > are problematic or the _syntax_? I think it's the concept; the syntax is rather straightforward IMO. Even the _concept_ is simple, it's just hard to get initially. I've observed that many people tend to conceptualize SGML processing with the mental model that element types are "procedures" and attributes "arguments"; or that element types are "classes", elements "objects" and attributes "data members"; or in some cases that start- and end-tags are "commands". In all of these models the GI is the "primary key" for specifying processing. With LINK, processing is directed primarily by attributes; GIs (and context) are only used to look up an attribute specification list. I remember this being a particularly difficult mental hurdle for some reason, but once I "got it" it turned out to be a much more useful way to do SGML processing. (I suspect that architectural forms are widely considered hard to understand for much the same reason, although there are some serious syntax problems with the AFDR too). > (Another interesting question is whether > those that oppose my proposal number themselves among the 17...) Speaking for myself, yes, I think. (That is: I think I understand LINK, and I think I oppose the proposal, but I'm not entirely sure of either :-) > 6) Difficulty of implementation > ------------------------------- > David drew attention to the fact that link attributes have their own name > space. I am not enough of a computer scientist to know how big a problem > this is, but I suspect that it is exaggerated in this case. Perhaps someone > more knowledgeable could provide some insight? This is actually an advantage of LINK, IMO. Why should one link process share its namespace with all other processes, or with the source document itself? As for difficulty of implementation, *most* of it really isn't that hard. The bizarre precedence and visibility rules for parameter entity declarations, however, are almost impossible to get right, and can even lead to paradoxical situations: ]]> ]> ]]> ]]> ]> Try running this through 'nsgmls -a lying'; it actually does something sensible, but I'll bet it took James a _lot_ of work to catch this condition... > 7) "LINK is unnecessary if WG8 gives us multiple attlists" > ---------------------------------------------------------- > I do not believe this is the case. [...] > > Why? Well, that isn't easy to explain to anyone who has not "understood" the > basic point of LINK: That it is a smart idea to separate the specification > of the structural relationships (the DTD) from the specification of the > structure-related processing to be performed for a particular purpose (the > LPD). > > Yesterday [1] I wanted to send my SGML document to an ICADD-aware processor. > To do so, I had to add a whole bunch of fixed attribute declarations to my > DTD. Today I want to send it to an XML processor and I am being told that > I must pile in yet more fixed attributes in order to accomplish this. > > Tomorrow and in the future I will think of ever new ways to process my > information: I don't want to have to revise the DTD every time I do this. This brings up LINK fatal flaw #1. If you use LINK, you have to modify every _document_ each time you want to support a new process. The only place you can put a declaration is between the declaration and the instance; this is the last place you want to put process-specific information. (You could I suppose move the and declarations into separate files, but it's usually a good idea to keep the declaration attached to the instance.) This is not an objection to your proposal, though, since in the case of XML we'd want the full declaration to be at the beginning of every instance anyway. > Finally: A NEW PROPOSAL > ----------------------- > So is there anything that can be done that will give us all this power, > and remove the syntax-related objections raised by Jon and Tim? I think > there is: > > Instead of lobbying WG8 for multiple attlists (OK, then: as well as doing > that), we lobby for a simplification of the LINK syntax that would allow > my example to be expressed as simply as follows: > > > xml-link CDATA #fixed "xml-tlink"> > ]> > > I believe this is possible. Would it bring anyone around? Yes: If we could get WG8 to fix LINK (and there are a lot of things that need fixing in addition to this simplification), I'd support the proposal. --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 15:40:12 -0800 (PST) From: Murray Altheim Subject: Re: ERB decisions on the LINKTYPE proposal To: David Durand Cc: w3c-sgml-wg@w3.org "David Durand" > >The particular usage of LINK that led me earlier to propose its inclusion in > >XML is the same one as for HTML: attaching SDA attributes to a document > >instance for transformation to the ICADD DTD. The added features of LINK > over >the proposed alternative ATTLIST solution (context-sensitive > processing for >one) make me question why ATTLIST is even considered -- they > are not a direct >match functionally. > > The disadvantage is that the attributes are not "real" attributes, but are > attributes in some "result document". This creates confusion when you have > two attributes with the same name and different values. We need not even > open that can of worms if we stay away from link... Sometimes I feel like I'm just sitting on a different planet, not necessarily Earth. The whole point of any transformation process, whether it be DTD to DTD or adding presentational information from a stylesheet, is to begin with one document and end with another. There is a source document and a result document. Yes, they may contain like-named elements and attributes. Why in the world this would be confusing is beyond me. [...] > >I agree completely (except when the document is part of a transform > >process). > > No, just never. The transform process is a separate thing, and should be > stored separately. I was not clear. There is a source document. There are [possibly] intermediate documents. And there is a result document. Some of these intermediate documents are stored permanently, some not. By design. A transformation process by definition. > >I still don't understand why there isn't more screaming about some of the > >extensive proposed XML uses of PIs. I find PIs as abhorrent as some do LPDs. > I agree, but I decided that since I lost the battle against PIs, that I > could rationalize XML PIs (only) as not too evil, since they have a defined > semantics, and take advantage of the only syntactic extension hook we have. > This latter is only a need because we opted for syntactic compatibility > with DTDs rather than instance syntax. > > The thought that users (and Netscape and MS) can make their own PIs still > makes me very nervous... This is the reason I don't want to see XML define link semantics that show up in the instance, specifically as PIs or as an agreed-upon set of attribute values. This was IMO one failure of the HTML REL/REV proposal: defining some portion of an attribute namespace. If we take either the PI or attribute value approach, once we see a completely i18n'd SGML and accompanying tools, Chinese authors can write XML instances using Chinese, *except* for the links that show up as something akin to I do believe we should agree on a minimal set of link behaviours, and define names for those behaviors in English. It is, after all, the language of the specification. But we need an indirection mechanism to abstract the link names so that Chinese documents won't need to include 'toc', 'previous', 'next', etc. which may have no meaning to them. This (from what I can gather) would be necessary if we used the PI or attribute namespace solution. > >Use of LINK doesn't require processing information be embedded in the > >document instance, which is precisely one of its benefits. The alternative > >proposed ICADD solution of using multiple ATTLISTs *does* require adding > >the ATTLIST declaration to the declaration subset, which I find less > >desireable for precisely the reason you state above. > > I don't know from ICADD. The lack of multiple attlist delcarations is a > continual thorn in the side of DTD authoring, well worthy on its own merits > -- Once we have it, though, we no longer need another way to allow people > to attach atributes to elements in documents. > > It's not the acme of elegance, but it uses no new syntax, no new semantics > of output processing and LINK attributes, and has all the power that we > need (as does IMPLICIT LINK). If you don't want the same processing for elements in differing contexts, ATTLISTs won't do it for you. As I mentioned before, ATTLISTs don't provide context-sensitive mapping, so it's only a partial solution. [time passes.] OK. I've just received a copy of the discussion leading up to this, so some of the questions and confusion falls away. >From what I can see, we are trying to provide an indirection mechanism for XML-LINK so that specific XML applications can tie their particular link elements to XML link elements. I believe this message comes from before Steve Pepper's LINKTYPE proposal was added as #5: At 21:08 20.02.97 +0100, Steve DeRose wrote: >We almost all agree that the best long-term solution is to allow multiple >ATTLIST decls, so a document can start > > xml-link CDATA #fixed "xml-tlink" > > ]> > >This documents that the tei element is a tlink in XML terms. > >We think we can have multiple attlists when the TC passes. It's not clear >what to do in the meantime. Choices include: > >1 Play it Safe... >2 Count on Utopian ATTLISTs... >3 Stopgap PI... >4 GI escape hatch... so we add 5 LINKTYPE which is 100% SGML compatible and available now. You said: > Anyway, Jon said that LINK will only be considered if multiple ATTLISTs > fail. so let's just give this a rest, or take it off the list. I'm not sure where this declaration comes from, but I don't understand it out of context. I believe the purpose of discussion is to locate the best solution, and apart from political arguments that I don't agree with, discussion of LINK as a possible solution seems within bounds. So where are we? 1. Play it safe... I don't know what Steve is meaning here, but I'm assuming nothing. If I did assume he meant a fixed attribute like XML-LINK, fine. I have no problem with that solution at all. I don't think that as an option is bad at all, but I want something better, something with indirection so that the GI can be mapped in the prologue rather than the instance. 2. Utopian ATTLISTs I imagine that multiple ATTLISTs will pass in the TC, but I find the fervent pointing to that as a solution just as fanatical as myself believing LINK is viable. They are not the same solution, and there are advantages of LINK over multiple ATTLISTs: for one, context sensitivity. I believe "design elegance" also applies here. From a purely human-readable context, if I want to point to a generalized mechanism for 1) transforming HTML to ICADD or 2) providing linkage between an XML application and XML-LINK, I can point to an LPD that is somewhat self-contained, and from appearance is a pretty good mapping between the set of GIs and attributes and what will happen to them in the transformation process. By contrast, the ATTLIST document is simply an addendum to an existing DTD, so one must have the DTD, and sit down and figure out (given all sorts of parameter entity indirection that shows up in many DTDs) where the ATTLISTs will be applied and in what context. By contrast, the context is set in the LPD so it's easier to see. For simple ATTLISTs, this is obviously not a problem. 3. Stopgap PI... Ugly at best, and requires authors to do precisely what many of us detest: add processing-specific material to our documents. 4. GI escape hatch... This is not much of a solution for XML versions of existing DTDs, nor for those who don't want their markup in strict XML GIs. and finally, 5. Steve Pepper's idea [Date: Fri, 21 Feb 1997 12:43:16 +0100] of specifying a restricted subset of SGML implicit links is fine by me -- this is probably obvious to those I've discussed this with before. His restrictions reduce the implementation burden substantially, especially when considering that the alternatives are either multiple ATTLISTs (not yet allowed, not guaranteed to be allowed, more difficult to human-read without a DTD for context, and no context-sensitivity) or a DSSSL transformation engine. Just in terms of complexity and footprint, I can't imagine requiring a DSSSL engine merely to use XML-LINK. My only change would be: > 1. Only one link type declaration is allowed. It must be called > "xml-link" and it is by definition an "active" link type for an > XML application. For purposes of ICADD transformation, this restriction would disallow transformation via LPD of any XML instance that already was using an LPD for link indirection. The restriction could be 'only one link type declaration of the same link type', so two LINKTYPEs would still be disallowed. Removing all the 'unnecessary' stuff from SGML is what XML is all about. Removing the unnecessary stuff from LINK might warrant its inclusion in XML, and I believe provide a much simpler method than a DSSSL engine for certain processes. Murray ---------------------------------------------------------------------- Murray Altheim, SGML Toolhead Tools Development & Online Production Sun Microsystems, Inc. Menlo Park, California %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 16:06:12 -0800 (PST) From: Murray Altheim Subject: Re: ERB decisions on the LINKTYPE proposal To: David Durand Cc: w3c-sgml-wg@w3.org Sorry -- that last post of mine was all chopped up. I don't think it warrants a repost, but if anything was really confusing* I'm willing to fix it. Murray *ie., more confusing than my regular posts. ---------------------------------------------------------------------- Murray Altheim, SGML Toolhead Tools Development & Online Production Sun Microsystems, Inc. Menlo Park, California %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: 4.2 Location-source/Base address <3.0.32.19970305124032.00978ab0@pop.intergate.bc.ca> Date: Wed, 05 Mar 1997 17:56:41 -0700 From: Dave Hollander > At 12:33 PM 3/4/97 -0800, Tim Bray wrote: > >4.2.a Should we formalize at all the concept of a base address? > > Yes, it's generally useful for a variety of reasons, e.g. replication > support, it's a real pity that HTML BASE is in general not better > defined and understood. True. It is a useful concept to formally define. However, if we do, we need to establish what is the resolution between discrepency between implied-resource-name (resource name used to reach this resource) and the "base" value. While we are at it, should we also build in the ability to have the document its prefered resource name? The one of many paths to that resource that is prefered to be remembered? >4.2.c Should we formalize the concept of the implied location source? Is this the same as: resource name used to reach this resource ? If so, we do need the concept to express priority policy re expressed location source. Dave %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: 4.1 Address types <3.0.32.19970305123828.00976340@pop.intergate.bc.ca> Date: Wed, 05 Mar 1997 18:01:42 -0700 From: Dave Hollander > >4.1.a Should we have a single attribute > >4.1.b If so, what should the attribute be called? > >4.1.c If not, should we use a different attribute for each type > >4.1.d If using different attributes for locator languages > >4.1.e Should we discard this scheme and adopt something > >4.1.f Should we abandon the idea of different address types and assert that > >everything is a URL? 4.1.f. I am looking for mine, too. > do SGML IDREFs really need to be subsumed into XML Link? I would be happy if it would work out that URL#IDREF is valid for XML. I do not see any reason it shouldn't > Ooh, I'm gonna get scorched. -T. Every one in the frying-pan! Dave %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 17:24:41 -0800 (PST) From: Murray Altheim Subject: Re: 4.2 Location-source/Base address To: Dave Hollander Cc: w3c-sgml-wg@w3.org "Dave Hollander" writes: > > At 12:33 PM 3/4/97 -0800, Tim Bray wrote: [...] > >4.2.c Should we formalize the concept of the implied location source? > > Is this the same as: resource name used to reach this resource ? > If so, we do need the concept to express priority policy re expressed > location source. Note that in the case of resources delivery based on client type (eg., 24bit GIF vs. 1 bit GIF) the implied location will depend on who is asking for the resource. We may have to allow for binding client-type information to the request. Murray ---------------------------------------------------------------------- Murray Altheim, SGML Toolhead Tools Development & Online Production Sun Microsystems, Inc. Menlo Park, California %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 06 Mar 1997 00:14:02 -0500 To: w3c-sgml-wg@w3.org From: Harvey Bingham Subject: Re: Kind of surprising commercial XML application (long) At 07:48 AM 3/5/97 -0800, Tim Bray wrote: >Check out > > http://www.ile.com/opentag/ > >I don't understand the application domain enough to really be fully >in tune with all the implications, but it's an interesting read. - Tim Thanks, Tim for the pointer. Executive Summary: The primary connection to this wg is their marketing hype, claiming they do XML. The novel idea for natural language processing is that text zones can be extracted from a word-processing proprietary format and tagged to the opentag DTD, manipulated (natural language translation of those text zones), and then restored to the places where the original text zones were, yielding the same formatting for a new document in the different natural language. Custom translators to and from the proprietary format are needed for the 25 elements of the OpenTag DTD. ---- 1. Analysis: OpenTag focuses on localization (natural langage processing, NLP) of text in documents in any proprietary formatting text processor. It uses its standard DTD that will support open data encoding methods during the localization process. It provides a 25-element DTD that assertedly preserves the significant clues useful for producing natural language translation of each text object. Presumably translation is easier using the opentag markup. When the translation is complete, the reverse process occurs: it substitutes the translated text objects back into the corresponding places in the original formatted document, so all the original formatting markup is reused. The SGML version is only the intermediary. It need not persist beyond the translation process. They assert "XML compliant (and therefore SGML compliant as well)". They aren't there yet. [See Eve's message as well.] The OpenTag DTD preserves a few styles that might provide aids to translation [but not font, face, pointsize information, that might convey hierarchy or captioning]. Presumably a human translator would have the original formatted document to work with that could convey this other information. A tagged instance has sequential numeric ids assigned to paragraphs in a document and again ordered sequential numeric ids to each inline textual object in each paragraph. As the content model includes tags for inlines in a paragraph, the mixed content #PCDATA parts would remain in the same order separated by injections of inlines. A generic x in-line code tag is available, that might be used to surround #PCDATA. It handles footnotes, index terms, and bibliographic references. It preserves column breaks and table cell breaks. They allow (character) codeset change within a document from that specified in an initial PI. Comparing different localizations for the same formatting language X of the same original would all share the ordered ids. Transformation to a different target formatting language Y, such as RTF, HTML, Wordperfect, etc. would not generally be possible, unless there were a richer way to assign corresponding style recognizers and generators. Some formatting languages such as MicroSoft Powerpoint scramble object order. There is no implicit left-to-right, top-down text progression as is true for western languages in most word-processing format languages. (Even in those, table cell line-wrapping can break that model.) I believe the opentag document instances will lose much information in the translation process of mapping everything onto their 25 generic elements, nine of which are EMPTY. The consequence is that they will not be able to generally go from X to different formatting language Y. 2. The DTD -- opentag.dtd The OpenTag DTD claims conformance with "XML, Extensible Markup Language, working draft 11-14-96". The assertion of compatiblity with XML is commendable, but overstated. Omissible tag indicators should not be present. Or, if they are, the omissible endtag on a content model is improper: is inconsistent with XML. All hierarchic structures are flattened into a sequence of paragraphs P. Self-exclusion exceptions occur, on b,i,u,d bold, italics, underline, doubleunderline) indicate a style attribute on something -- but why stop with those few? smallcaps, overbar, strikethrough, subscript, superscript, etc.] RCDATA is disallowed in XML. There is no element declaration for level, used in the ixd content model. Instead there is a lvl element, with pernicious mixed content, ((%paratxt;)*,so) that is illegal in XML. The PB tag semantics refer to an otherwise undefined definition group. 3. The OpenTag Format Specifications -- otspecs.htm This includes a markup reference to XML, character entities (either SGML &name;, or Unicode &#xxxx;), a file header, and a tag description table, providing some semantics. An initial PI file header describes version, type, encoding, locale, and original. This suggests document==file. There is no mention of external entities. No attributes are on the base document element, opentag. Almost universal is an id NUMBER attribute. Few other attributes exist. The element type distinguishes use: target or reference for the id value. The example for paragraph (which has a content model) "

" is inconsistent with SGML. It uses the XML empty tag variant "/>" in place of tagc, not now present in SGML. I am confused by the use of id as a numeric (not ID) attribute. It is appropriate for the textual definitions of footnotes, index terms, and (biographic) references -- FND, IXD and RFD, but also in their EMPTY points of reference in FN, IX, and RF. As the latter are actually references, in SGML I believe it would be better with a distinguishing attribute name, possibly "idr", rather than overload id. I see no reason why the "idr" need to be unique in the file. Several references to the same object should be allowed. [The end of the RFD semantics seems in error, referring to footnote definition, rather than reference definition.] The use of sequential integers starting from 1 at each

for each in-line makes any use of the id values during language processing awkward. Since each paragraph has its own sequence, presumably the paragraph ids, unique to the document, also a set of sequential numbers starting at 1 as qualifiers to disambiguate the ids of the in-line children. But since the inline id values are reused, they are not sufficientby themselves to locate any object, other than indirectly through its ancestors. The generic inline group can be arbitrarily moved in a P. That seems to means that all id values in that P need to be adjusted after such movement. [Any editing to add, reorder, or delete objects in a P has the same problem.] Perhaps this is ruled out in the localization NLP. Revisions across a set of localized versions of a document could use opentag versions to linearize the structure and provide some degree of common navigation to common places. There are no attributes that would indicate any revision control. >From this cursory look, I believe OpenTag still needs significant work. Regards/Harvey Bingham mailto:hbingham@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 00:33:58 -0500 To: Joe English , w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: Couldn't XML allow and ignore omitted tag minimization At 12:05 PM 3/4/97, Joe English wrote: >dgd@cs.bu.edu (David Durand) wrote: >> I am sympathetic to this, except for the SGML-imposed requirement that >> EMPTY tags must take minimization "- O" if they could be pure "noise" >> elements I wouldn't mind, but explaining that restriction in the context of >> "compatibility" is sure to be difficult. > >By my interpretation of the standard, this is not actually >required, only recommended. SGMLS agrees: it issues a warning >if it sees in the DTD but it does flag >the document as non-conforming. According to 7.3.1 and 11.2.2, >the parser doesn't even examine the tag omission parameters >for EMPTY elements or those with a non-#IMPLIED CONREF attribute. Right. And the recommendation is only that it be done for mnemonic purposes. (I.e., as a reminder to humans doing manual tag input.) The parser is guaranteed to ignore it. Furthermore, in the CONREF case, the recommendation is not even good advice. Because when the CONREF attribute is not specified (which presumably should happen sometimes, or the element type should have been EMPTY and the attribute REQUIRED), the omitted tag minimization parameter should be whatever is appropriate when the CONREF attribute is *not* specified. >(It would be nice to be able to turn this warning off in SGMLS/SP >though, especially for elements with CONREF attributes; I'd like >to be able to specify that the end-tag is always required if no >content reference attribute is supplied. But that has nothing >to do with XML...) Yet another reason why the perfect parser would have each warning able to be individually turned off. Gang-switching all warnings off just because you're deliberately going to violate one of the warning conditions and don't want to be flooded with messages isn't adequate. Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 22:10:40 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: hbingham@ACM.org CC: w3c-sgml-wg@w3.org Subject: Re: Kind of surprising commercial XML application (long) Wonderful analysis, Harvey. Thanks. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 22:29:44 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: opentag@ile.com cc: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Bogus XML conformance claim As the chairman of the committee developing XML, I'd like to thank you for your attempts at XML compliance. However, analysis shows that the claim to conformance with WD-xml-961114 as currently stated in opentag.dtd Draft version 3 is false (see below). Until you make the changes needed to bring OpenTag into compliance with the XML specification, I strongly suggest that you drop the claim, as it can only reflect badly on your expertise and credibility. I welcome your participation in the XML effort and hope that you will soon be able accurately to claim XML compliance for OpenTag. Sincerely, Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, | Best is he that inuents, Mountain View, California 94043 | the next he that followes Davenport Group::SGML Open::ANSI X3V1 | forth and eekes out a good ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB | inuention. ---------------------------------------------------------------------- Date: Wed, 05 Mar 1997 11:45:10 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: Kind of surprising commercial XML application In case anyone is curious, here are the ways in which the opentag.dtd isn't XML compliant (some of the ways are trivial, some not): - #PCDATA must come at the beginning of a content model (%paratxt;, u, ...) - #PCDATA must always use * occurrence indicator (u, ...) - #PCDATA can't be in a model with pernicious mixed content (lvl) - Exceptions not allowed (b, ...) - OMITTAG specifications not (yet :-) allowed - NUMBER declared value not allowed (p, ...) - Comments not (but this isn't in the spec version they used) Designing and implementing DTDs according to the XML constraints is a new discipline... Eve Date: Thu, 06 Mar 1997 00:14:02 -0500 To: w3c-sgml-wg@w3.org From: Harvey Bingham Subject: Re: Kind of surprising commercial XML application (long) Executive Summary: The primary connection to this wg is their marketing hype, claiming they do XML. The novel idea for natural language processing is that text zones can be extracted from a word-processing proprietary format and tagged to the opentag DTD, manipulated (natural language translation of those text zones), and then restored to the places where the original text zones were, yielding the same formatting for a new document in the different natural language. Custom translators to and from the proprietary format are needed for the 25 elements of the OpenTag DTD. ---- 1. Analysis: OpenTag focuses on localization (natural langage processing, NLP) of text in documents in any proprietary formatting text processor. It uses its standard DTD that will support open data encoding methods during the localization process. It provides a 25-element DTD that assertedly preserves the significant clues useful for producing natural language translation of each text object. Presumably translation is easier using the opentag markup. When the translation is complete, the reverse process occurs: it substitutes the translated text objects back into the corresponding places in the original formatted document, so all the original formatting markup is reused. The SGML version is only the intermediary. It need not persist beyond the translation process. They assert "XML compliant (and therefore SGML compliant as well)". They aren't there yet. [See Eve's message as well.] The OpenTag DTD preserves a few styles that might provide aids to translation [but not font, face, pointsize information, that might convey hierarchy or captioning]. Presumably a human translator would have the original formatted document to work with that could convey this other information. A tagged instance has sequential numeric ids assigned to paragraphs in a document and again ordered sequential numeric ids to each inline textual object in each paragraph. As the content model includes tags for inlines in a paragraph, the mixed content #PCDATA parts would remain in the same order separated by injections of inlines. A generic x in-line code tag is available, that might be used to surround #PCDATA. It handles footnotes, index terms, and bibliographic references. It preserves column breaks and table cell breaks. They allow (character) codeset change within a document from that specified in an initial PI. Comparing different localizations for the same formatting language X of the same original would all share the ordered ids. Transformation to a different target formatting language Y, such as RTF, HTML, Wordperfect, etc. would not generally be possible, unless there were a richer way to assign corresponding style recognizers and generators. Some formatting languages such as MicroSoft Powerpoint scramble object order. There is no implicit left-to-right, top-down text progression as is true for western languages in most word-processing format languages. (Even in those, table cell line-wrapping can break that model.) I believe the opentag document instances will lose much information in the translation process of mapping everything onto their 25 generic elements, nine of which are EMPTY. The consequence is that they will not be able to generally go from X to different formatting language Y. 2. The DTD -- opentag.dtd The OpenTag DTD claims conformance with "XML, Extensible Markup Language, working draft 11-14-96". The assertion of compatiblity with XML is commendable, but overstated. Omissible tag indicators should not be present. Or, if they are, the omissible endtag on a content model is improper: is inconsistent with XML. All hierarchic structures are flattened into a sequence of paragraphs P. Self-exclusion exceptions occur, on b,i,u,d bold, italics, underline, doubleunderline) indicate a style attribute on something -- but why stop with those few? smallcaps, overbar, strikethrough, subscript, superscript, etc.] RCDATA is disallowed in XML. There is no element declaration for level, used in the ixd content model. Instead there is a lvl element, with pernicious mixed content, ((%paratxt;)*,so) that is illegal in XML. The PB tag semantics refer to an otherwise undefined definition group. 3. The OpenTag Format Specifications -- otspecs.htm This includes a markup reference to XML, character entities (either SGML &name;, or Unicode &#xxxx;), a file header, and a tag description table, providing some semantics. An initial PI file header describes version, type, encoding, locale, and original. This suggests document==file. There is no mention of external entities. No attributes are on the base document element, opentag. Almost universal is an id NUMBER attribute. Few other attributes exist. The element type distinguishes use: target or reference for the id value. The example for paragraph (which has a content model) "

" is inconsistent with SGML. It uses the XML empty tag variant "/>" in place of tagc, not now present in SGML. I am confused by the use of id as a numeric (not ID) attribute. It is appropriate for the textual definitions of footnotes, index terms, and (biographic) references -- FND, IXD and RFD, but also in their EMPTY points of reference in FN, IX, and RF. As the latter are actually references, in SGML I believe it would be better with a distinguishing attribute name, possibly "idr", rather than overload id. I see no reason why the "idr" need to be unique in the file. Several references to the same object should be allowed. [The end of the RFD semantics seems in error, referring to footnote definition, rather than reference definition.] The use of sequential integers starting from 1 at each

for each in-line makes any use of the id values during language processing awkward. Since each paragraph has its own sequence, presumably the paragraph ids, unique to the document, also a set of sequential numbers starting at 1 as qualifiers to disambiguate the ids of the in-line children. But since the inline id values are reused, they are not sufficientby themselves to locate any object, other than indirectly through its ancestors. The generic inline group can be arbitrarily moved in a P. That seems to means that all id values in that P need to be adjusted after such movement. [Any editing to add, reorder, or delete objects in a P has the same problem.] Perhaps this is ruled out in the localization NLP. Revisions across a set of localized versions of a document could use opentag versions to linearize the structure and provide some degree of common navigation to common places. There are no attributes that would indicate any revision control. From this cursory look, I believe OpenTag still needs significant work. Regards/Harvey Bingham mailto:hbingham@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 5 Mar 1997 22:49:05 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Re: Couldn't XML allow and ignore omitted tag minimization (A second person has taken me to task offline for the statement quoted below, so I'd better acknowledge that I was overlooking legal SGML practice.) | >I am made uneasy by the thought that a legal DTD would then be stating | >specifically something that would not be true in XML, namely that | >certain omissions were allowed when, in fact, they would not be. | | SGML with OMITAG NO permits but does not require the omitted tag | minimization parameter. If it is present it is ignored. Do you | believe that in SGML you will "be stating specifically something | that would not be true" in SGML under these circumstances? This is | solely to prevent needing multiple copies of the same DTD. Why | should the same analysis and rationale not apply to XML. Yes, as I replied offline to someone else who made the same point, my quarrel turns out to be with the original design decision. I wouldn't have agreed with it then, either. If you push this rationale very far you end up with the position that *all* omission parameters are bogus, and that if you allow omission at all you might as well just mark everything possible "O O". I thank Eliot Kimber for this observation, which at first freaked me out but which I'm now beginning to see the logic of, though I still don't like it. To me it's a demonstration by reductio ad horrendum that you don't want to allow tag minimization. (By the way, I think that the people arguing in favor of Paul's original request have made a pretty good case for it.) Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 09:27:36 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: ERB decisions on the LINKTYPE proposal At 19:30 04.03.97 +0100, David Durand wrote: ... I won't to respond all David's arguments, because Murray Altheim did an excellent job of countering most of them. Let me just pick up on a few points he didn't cover: >If the Exoterica people claim that it's not well-defined enough to >implement, I take that seriously. So my assertion has some support. And I take even more seriously the fact that James Clark *has* implemented it. Even more so considering the arguments raised by those who think LINK has been rendered obsolete by DSSSL. (Now why would the guy who practically rewrote the DSSSL standard turn around and implement LINK, I wonder?) To be honest though, I don't think citing authorities is a very productive way of conducting a discussion. (Do you want me to start marshalling Charles, Eliot and others in my support?) I too have a lot of respect for the Omnimark people, but I don't consider people's arguments in a vaccuum. If anyone were to have a vested interest in *not* supporting standard mechanisms for generalised processing it would be vendors of an SGML processing language that is well on its way to becoming a de facto proprietary standard. (Not that I am accusing anyone of intellectual dishonesty; everyone's opinions are to some extent formed by their personal interests, as well as their experience and needs.) >I don't believe that LINK solve the attribute attachment problem because it >explicitly allows LINK attribute names to be the same as document attribute >names -- so it just doesn't address the problem unless you mis-implement it. > >... > >I note that you didn't address the separate namespace issue, which is the >real stumbling block in the current proposed application. I said I didn't feel qualified to comment on how much extra difficulty of implementation it would cause. I still don't, but I am grateful to Steve DeRose for admitting that this isn't the major issue. However, from a conceptual point of view, I think separate name spaces is a great strength, precisely because it solves the problem of name space collisions. Much cleaner than APPINFO "sda=sda" (or an implied APPINFO "xml-link=xml-link") and another reason why the LINK-based solution is preferable to multiple attlists. >What does an element with XML-link="xlink" and the LINK-attribute >XML-link="foobar" mean? It means that the document designer has included an element type which generally acts like an xlink, but that for a particular processing run (governed by a particular processing specification, or LPD) should be processed as if it were a foobar. More power, see? (Or else it means someone screwed up, of course. But you can't ever guarantee against that.) > Well, you came close to accusing him of fabricating the position in your >original post... the words were "I find this argument so unlikely that I >have it under suspicion of being vicarious." Maybe you meant something >else... I did indeed mean something completely different. (Is my English really that bad?) What I wrote was: >There remains the objection (brought to us second-hand by Tim) of >"several members" of the ERB who "find the syntax [of the technique], and the prospect of explaining it, repellent." > >I find this argument so unlikely that I have it under suspicion of being >vicarious... First of all, it was the *argument itself* I suspected of being vicarious. As far as I was concerned, Tim was merely reporting the argument in an objective manner. (I didn't know his own position at that point in time anyway.) Secondly, "vicarious" has nothing to do with fabricating positions. My dictionary defines it as "deputed, delegated; acting or done for another". My suspicion was that dislike of the syntax could not be the real underlying reason for objecting to LINK, and subsequent discussion has shown this to be the case (at least for Steve and Tim; it does appear that this was Jon's principal objection). >>* We do have a new construct which isn't in the November draft. However, it >> is just a one-production, simple wrapper around an existing construct. > >Michael responded to this already. I haven't seen any contributions from Michael on this topic. Did I miss something? Best regards, Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 09:24:38 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: ERB decisions on the LINKTYPE proposal At 14:27 04.03.97 +0100, Steven J. DeRose wrote: >>At 07:57 PM 03/03/97 +0100, Steve Pepper wrote: >>... >>The arguments against using LINK syntax seem to be falling into a number >>of distinct categories: >> >>... >>4) "LINK can't do the job anyway" >>... > >There are several others: > >LINK poses problems because you can't override the value on particular >instances; it's not just a default, like you can do with ATTLISTs. This is precisely the objection Martin Bryan raised. I put it under 4) and disposed of it in the message to which you replied. Please respond to that instead of repeating the objection. >Which reminds me since the question was asked: one specific design flaw in >LINK that I find fatal is that you can't address anything that isn't already >an element. For example, if you want to apply processing attributes that >indicate something is supposed to be set all in caps, or as a drop cap, you >can't do it *unless the something is already an element*, which in those >cases is unlikely ("set the first line of each section in bold"; "drop-cap >the first character of every chapter", and so on). Whoa, steady on there! No-one is suggesting using LINK for implementing XML style sheets! Elements are the only thing we *want* to address. We're talking about identifying the linking *elements*, right? >Link also uses a baroque style of overriding its settings: changes at event >boundaries, pretty much like troff. This leads to very subtle surprises when >you try to maintain the settings as contexts change or expand, because >LINK's set of distinguishable contexts is not organized quite like SGML's. I'm not quite sure what you mean here. Which "settings" are being "overridden" and when? In what way is LINK's set of distinguishable contexts organized differently than SGMLs? Are you referring to link set context sensitivity? If so, note that up to now I have not proposed #USELINK for XML purposes. (In fact it was on my list of possible 'draconian restrictions' on the subset of implicit link needed for our purposes.) >Also, complexity of implementation is not so much an issue as is a decade's >evidence that no one need bother. Link just hasn't proven itself useful >enough for almost anyone to bother building or using... I note that you don't believe complexity of implementation is the major issue. Good. However, ahistorical arguments like the one above cut no ice. (It's like Tim Gill of Quark saying that SGML just hasn't proven itself useful enough for more than a handful of people [after all, everything is relative] to bother using.) You need to look at the historical context. I believe that LINK was ahead of its time. During the first decade of SGML most people had their work cut out simply implementing the basics. We spent that time analysing information, converting legacy data, setting up authoring environments, figuring out how to print the damn stuff and taking the first tentative steps towards electronic publishing. Most of the processing we did was custom-built for a particular application. The amount of re-use and interchange was minimal compared to what it will be in the future. SGML had to achieve critical mass before generalised processing could become useful (or even feasible) on a large scale. In that situation, it isn't surprising that the concepts that underpin LINK weren't generally understood. Necessity isn't only the mother of invention, it is also the prerequisite for a general appreciation of the value of that invention. ICADD was one of the first applications where generalised processing really made sense; XML is another. The formalisation of the concept of SGML architectures is further proof that we have gained experience in this area. LINK fits so well into this picture, that I find it little short of miraculous that it could have been invented so long ago -- but far less surprising that it hasn't been used extensively up to now. I wasn't around during the last half of the eighties but I have the clear impression that there must have been many heated and rancorous discussions centered around LINK. Must have been -- because how else to account for the deep entrenchment of position, the pavlovian red-rag reactions and the apparent tendency for those entering the discussion at a later date to be much more open-minded? >Eschew redundancy. Embrace extensibility. Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 11:42:54 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Last word on LINKTYPE (ha, ha!) I have tried my best to keep this whole discussion as close as possible to specifically XML-related issues. I want to stress that I am *not* proposing any kind of general support for LINK (not even just implicit link, or even a restricted subset of it) for XML 1.0. All I am talking about at this stage is use of the syntax as a way of achieving the goal of associating XML-specific processing semantics with the document structure. As I said in my reply to Paul Prescod, I may have bent the stick a little too far with my use of the word "processing" (although I have in many cases tried to qualify it with expressions like "processing- related"). In particular, calling the stuff in the LPD a processing *specification* may be misleading. The specification of the processing is DSSSL's domain (unless it is built into the [XML] application itself). It is the *association* of the processing (specification) with the document structure that is LINK's domain. In other words, the LPD provides the link (or "bridges the gap") between the structure and the processing. Because the information being supplied (e.g. "my xref is an XML tlink") is very much oriented towards a particular form of processing, it should not be in the DTD. Nor should it be in the *document instance* (for reasons I think we all agree on). The fact that the LINKTYPE declaration is formally part of the document entity does not worry me unduly. (If I understood Joe English correctly, he saw it as the "fatal flaw".) The separation between the DTD, the LPD and the instance is so clear that I do not regard this as "mixing processing and markup". (And in fact you don't even have to put the LPD physically in the document if you use SP-based tools.) In any case, it beats me how anyone can claim that this is the case -- and then turn around and suggest putting fixed attributes in the DTD! Or is the DTD not part of the document? (Don't answer that: We all know it is.) In summary: LINK and DSSSL do not compete, they complement one another (which explains why James implemented both). David's final argument is that LINK is so underspecified that there is no guarantee of compatibility between two implementations: >At any rate, the result is not required to be _anything in particular_ -- >certainly not the annotation of the ESIS (or whatever the application sees) >with new attribute values not declared in the document. In other words >conforming LINK implementations according to 8879 are _not_ required to >look at, or even have access to, link attributes. This could create a >compatibility problem even between the 3 applications that have implemented >LINK. This just isn't true. Attribute information for the link attributes is very much part of ESIS (see for example page 590 in the handbook). It is certainly no less clearly defined than the rest of ESIS and it is very clearly defined in the grove. A parser that supports the LINK feature is *required* to inform an application about link attributes. (Of course, what the application then *does* with that information is up to the application -- as always in SGML.) -- And at this point, I think we have pretty much exhausted the arguments. I have no intention of repeating myself, so this looks like a good place to take time out. If and when new arguments turn up I will be back. At the latest, expect a return to the LINKTYPE proposal when the time comes to decide how to point at style sheets :-) Regards, Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 12:37:28 -0500 To: Steve Pepper , w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: Last word on LINKTYPE (ha, ha!) At 11:42 AM +0100 3/6/97, Steve Pepper wrote: >I have tried my best to keep this whole discussion as close as possible >to specifically XML-related issues. I want to stress that I am *not* >proposing any kind of general support for LINK (not even just implicit >link, or even a restricted subset of it) for XML 1.0. All I am talking >about at this stage is use of the syntax as a way of achieving the goal >of associating XML-specific processing semantics with the document >structure. Fine. Murray was, so I have had to answer that (even more disturbing) prospect. In answering your arguments, I have stuck to the core issues: attribute namespace. As far as processing semantics you declare your intention to advocate the use of LINK for stylesheets, so I guess that my arguemnts, contra your statements, are really not out of bounds. >In particular, calling the stuff in the LPD a processing *specification* >may be misleading. The specification of the processing is DSSSL's domain >(unless it is built into the [XML] application itself). It is the >*association* of the processing (specification) with the document >structure that is LINK's domain. Well, I for one, believe that no _mandatory_ association of processing specifications should be part of the _XML language_. Terry Allen and Len Bullard has presented good cases that in some situations XML software should be able to force such an association. I'm not in agreement with them about the scope with which these things should be applied, but that's not germane here. I do feel that instances that contain processing specifications are bad. This is in some sense a "religious" belief, but it is supported by a philosophy af document markup and document application design that is fundamental to the intended applications of SGML. >In other words, the LPD provides the link (or "bridges the gap") between >the structure and the processing. Because the information being supplied >(e.g. "my xref is an XML tlink") is very much oriented towards a >particular form of processing, it should not be in the DTD. Nor should >it be in the *document instance* (for reasons I think we all agree on). I am a simple man. The fact that the document subset (and LINK subset) appear in the same entity is what bothers me. The formal distinction that declares the document instance to be only part of that entity does not impress me -- ordinary folk will not make it. >The fact that the LINKTYPE declaration is formally part of the document >entity does not worry me unduly. (If I understood Joe English correctly, >he saw it as the "fatal flaw".) Well, I'm glad that you're easy in your mind, but the argument that new users of XML will see the distinction of Document instance from document entity so clearly seems optimistic... >The separation between the DTD, the LPD >and the instance is so clear that I do not regard this as "mixing >processing and markup". (And in fact you don't even have to put the >LPD physically in the document if you use SP-based tools.) yes, funny that SP should have chosen to be non-conformant in that way. Wihtout asking I would suspect that James is bothered by the same thing I am, to the extent that he's willing to ignore the standard in his implementation. >In any case, it beats me how anyone can claim that this is the case >-- and then turn around and suggest putting fixed attributes in the DTD! >Or is the DTD not part of the document? (Don't answer that: We all know >it is.) I agree, and I think that the need to put hypertext link info in documents imposes strict restrictions on our hypertext markup -- that it not include any rendering or processing aspects, but only pure connectivity and type information. You can read about 60K of spew on that topic between me an Len B. on the back issues of this list. I won't revisit that either. Hypertext linkage should be subject to the same forms of abstraction that document content is, and for the same reasons -- reuse, genericity, and management. >David's final argument is that LINK is so underspecified that there is >no guarantee of compatibility between two implementations: > >>At any rate, the result is not required to be _anything in particular_ -- >>certainly not the annotation of the ESIS (or whatever the application sees) >>with new attribute values not declared in the document. In other words >>conforming LINK implementations according to 8879 are _not_ required to >>look at, or even have access to, link attributes. This could create a >>compatibility problem even between the 3 applications that have implemented >>LINK. > >This just isn't true. Attribute information for the link attributes is >very much part of ESIS (see for example page 590 in the handbook). It >is certainly no less clearly defined than the rest of ESIS and it is >very clearly defined in the grove. A parser that supports the LINK feature >is *required* to inform an application about link attributes. (Of course, >what the application then *does* with that information is up to the >application -- as always in SGML.) Last I heard, MARK-IT used significant comments in LINK delcarations to invoke a scripting language. Maybe it does something different now? ESIS is non-normative text. It is the only place where you can find a description of what _might_ be done with link attributes, so it is useful. Is there any parser other than SP that actually processes LINK in this way? I'm sorry I forgot the ESIS hook. >And at this point, I think we have pretty much exhausted the arguments. >I have no intention of repeating myself, so this looks like a good place >to take time out. If and when new arguments turn up I will be back. At >the latest, expect a return to the LINKTYPE proposal when the time comes >to decide how to point at style sheets :-) I think I will stay out of that one. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Yves Savourel To: bosak , opentag Cc: "'elm@arbortext.com'" , "'hbingham@acm.org'" , w3c-sgml-wg Subject: RE: Bogus XML conformance claim Date: Thu, 06 Mar 97 11:20:00 MST Encoding: 234 TEXT Thanks for your note. We have been in touch with Tim Bray about XML and OpenTag and he kindly pointed out several mistakes. We are working on solving them. You have to understand that our expertise in that area is not perfect. But hopefull, with XML experts help, we will be able to improve it quickly. Thank you for having taken the time to analyse our DTD. Best regards Yves ---------- From: bosak[SMTP:bosak@atlantic-83.eng.sun.com] Sent: Wednesday, March 05, 1997 10:29 PM To: opentag Cc: bosak; w3c-sgml-wg Subject: Bogus XML conformance claim As the chairman of the committee developing XML, I'd like to thank you for your attempts at XML compliance. However, analysis shows that the claim to conformance with WD-xml-961114 as currently stated in opentag.dtd Draft version 3 is false (see below). Until you make the changes needed to bring OpenTag into compliance with the XML specification, I strongly suggest that you drop the claim, as it can only reflect badly on your expertise and credibility. I welcome your participation in the XML effort and hope that you will soon be able accurately to claim XML compliance for OpenTag. Sincerely, Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, | Best is he that inuents, Mountain View, California 94043 | the next he that followes Davenport Group::SGML Open::ANSI X3V1 | forth and eekes out a good ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB | inuention. ---------------------------------------------------------------------- Date: Wed, 05 Mar 1997 11:45:10 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: Kind of surprising commercial XML application In case anyone is curious, here are the ways in which the opentag.dtd isn't XML compliant (some of the ways are trivial, some not): - #PCDATA must come at the beginning of a content model (%paratxt;, u, ...) - #PCDATA must always use * occurrence indicator (u, ...) - #PCDATA can't be in a model with pernicious mixed content (lvl) - Exceptions not allowed (b, ...) - OMITTAG specifications not (yet :-) allowed - NUMBER declared value not allowed (p, ...) - Comments not (but this isn't in the spec version they used) Designing and implementing DTDs according to the XML constraints is a new discipline... Eve Date: Thu, 06 Mar 1997 00:14:02 -0500 To: w3c-sgml-wg@w3.org From: Harvey Bingham Subject: Re: Kind of surprising commercial XML application (long) Executive Summary: The primary connection to this wg is their marketing hype, claiming they do XML. The novel idea for natural language processing is that text zones can be extracted from a word-processing proprietary format and tagged to the opentag DTD, manipulated (natural language translation of those text zones), and then restored to the places where the original text zones were, yielding the same formatting for a new document in the different natural language. Custom translators to and from the proprietary format are needed for the 25 elements of the OpenTag DTD. ---- 1. Analysis: OpenTag focuses on localization (natural langage processing, NLP) of text in documents in any proprietary formatting text processor. It uses its standard DTD that will support open data encoding methods during the localization process. It provides a 25-element DTD that assertedly preserves the significant clues useful for producing natural language translation of each text object. Presumably translation is easier using the opentag markup. When the translation is complete, the reverse process occurs: it substitutes the translated text objects back into the corresponding places in the original formatted document, so all the original formatting markup is reused. The SGML version is only the intermediary. It need not persist beyond the translation process. They assert "XML compliant (and therefore SGML compliant as well)". They aren't there yet. [See Eve's message as well.] The OpenTag DTD preserves a few styles that might provide aids to translation [but not font, face, pointsize information, that might convey hierarchy or captioning]. Presumably a human translator would have the original formatted document to work with that could convey this other information. A tagged instance has sequential numeric ids assigned to paragraphs in a document and again ordered sequential numeric ids to each inline textual object in each paragraph. As the content model includes tags for inlines in a paragraph, the mixed content #PCDATA parts would remain in the same order separated by injections of inlines. A generic x in-line code tag is available, that might be used to surround #PCDATA. It handles footnotes, index terms, and bibliographic references. It preserves column breaks and table cell breaks. They allow (character) codeset change within a document from that specified in an initial PI. Comparing different localizations for the same formatting language X of the same original would all share the ordered ids. Transformation to a different target formatting language Y, such as RTF, HTML, Wordperfect, etc. would not generally be possible, unless there were a richer way to assign corresponding style recognizers and generators. Some formatting languages such as MicroSoft Powerpoint scramble object order. There is no implicit left-to-right, top-down text progression as is true for western languages in most word-processing format languages. (Even in those, table cell line-wrapping can break that model.) I believe the opentag document instances will lose much information in the translation process of mapping everything onto their 25 generic elements, nine of which are EMPTY. The consequence is that they will not be able to generally go from X to different formatting language Y. 2. The DTD -- opentag.dtd The OpenTag DTD claims conformance with "XML, Extensible Markup Language, working draft 11-14-96". The assertion of compatiblity with XML is commendable, but overstated. Omissible tag indicators should not be present. Or, if they are, the omissible endtag on a content model is improper: is inconsistent with XML. All hierarchic structures are flattened into a sequence of paragraphs P. Self-exclusion exceptions occur, on b,i,u,d bold, italics, underline, doubleunderline) indicate a style attribute on something -- but why stop with those few? smallcaps, overbar, strikethrough, subscript, superscript, etc.] RCDATA is disallowed in XML. There is no element declaration for level, used in the ixd content model. Instead there is a lvl element, with pernicious mixed content, ((%paratxt;)*,so) that is illegal in XML. The PB tag semantics refer to an otherwise undefined definition group. 3. The OpenTag Format Specifications -- otspecs.htm This includes a markup reference to XML, character entities (either SGML &name;, or Unicode &#xxxx;), a file header, and a tag description table, providing some semantics. An initial PI file header describes version, type, encoding, locale, and original. This suggests document==file. There is no mention of external entities. No attributes are on the base document element, opentag. Almost universal is an id NUMBER attribute. Few other attributes exist. The element type distinguishes use: target or reference for the id value. The example for paragraph (which has a content model) "

" is inconsistent with SGML. It uses the XML empty tag variant "/>" in place of tagc, not now present in SGML. I am confused by the use of id as a numeric (not ID) attribute. It is appropriate for the textual definitions of footnotes, index terms, and (biographic) references -- FND, IXD and RFD, but also in their EMPTY points of reference in FN, IX, and RF. As the latter are actually references, in SGML I believe it would be better with a distinguishing attribute name, possibly "idr", rather than overload id. I see no reason why the "idr" need to be unique in the file. Several references to the same object should be allowed. [The end of the RFD semantics seems in error, referring to footnote definition, rather than reference definition.] The use of sequential integers starting from 1 at each

for each in-line makes any use of the id values during language processing awkward. Since each paragraph has its own sequence, presumably the paragraph ids, unique to the document, also a set of sequential numbers starting at 1 as qualifiers to disambiguate the ids of the in-line children. But since the inline id values are reused, they are not sufficientby themselves to locate any object, other than indirectly through its ancestors. The generic inline group can be arbitrarily moved in a P. That seems to means that all id values in that P need to be adjusted after such movement. [Any editing to add, reorder, or delete objects in a P has the same problem.] Perhaps this is ruled out in the localization NLP. Revisions across a set of localized versions of a document could use opentag versions to linearize the structure and provide some degree of common navigation to common places. There are no attributes that would indicate any revision control. From this cursory look, I believe OpenTag still needs significant work. Regards/Harvey Bingham mailto:hbingham@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 13:09:19 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: ERB decisions on the LINKTYPE proposal Sumary. last I will say on this, my major point is that my primary objection to LINK in the XML context (that it doesn't solve our problem) has not yet been addressed. At 9:27 AM +0100 3/6/97, Steve Pepper wrote: >At 19:30 04.03.97 +0100, David Durand wrote: >>I don't believe that LINK solve the attribute attachment problem because it >>explicitly allows LINK attribute names to be the same as document attribute >>names -- so it just doesn't address the problem unless you mis-implement it. >> >>... >> >>I note that you didn't address the separate namespace issue, which is the >>real stumbling block in the current proposed application. > >I said I didn't feel qualified to comment on how much extra difficulty >of implementation it would cause. I still don't, but I am grateful to >Steve DeRose for admitting that this isn't the major issue. I didn't see that admission (and am surprised if he made it), but in any case, since I am claiming it is the major argument against LINK, I think you must concede the case if you can't respond to it. However, I will restate it in as concrete a form as I can manage, given that the basis for the argument (LINK itself) is so much more convoluted than it has to be. I ma pointing out a conceptual problem, not an implementation problem. It's one more hash table in an implementation -- but conceptually it's very difficult because we have chosen to use ELEMENT attributes to detect links. Any element can be a link if it has the right attributes, even without a DTD. We want the multiple attlists only so that people who want not to repeat a mass of specific attributes throughout their instance will have a way to deafault their values. This problem, is not solved by LINK as defined in 8879. We could steal the syntax, but would either have to change the meaning from that presecribed by 8879, or we would have to add a new notion of 2 kinds of attributes -- one specified by a PROCSPEC, and one specified on the element, and give rules for deciding which kind can make an element into a link. I think that this will make the standard more bloated, and more confusing. If we make LINK the only way to associate linking semantics with XML elements, we lose the ability to use XML-LINK attributes freely in the instance, and make the LPD a requirement for any document that uses hypertext links. This means that LPD-free instances could not use hyertext linking. A loss, in my view. If we base everything on _element_ attributes, people can type a lot of xml-link attributes, or use detached ATTLISTs if they want to save typing, or if their tool wants to save bytes. The HTML-in-XML DTD will of course include the attributes already, and not require any special work from the author. > >However, from a conceptual point of view, I think separate name spaces >is a great strength, precisely because it solves the problem of name >space collisions. Much cleaner than APPINFO "sda=sda" (or an implied >APPINFO "xml-link=xml-link") and another reason why the LINK-based solution >is preferable to multiple attlists. If you're trying to plug default values into a namespace, inability to create "collisions" is a problem, not a feature. >>What does an element with XML-link="xlink" and the LINK-attribute >>XML-link="foobar" mean? > >It means that the document designer has included an element type which >generally acts like an xlink, but that for a particular processing run >(governed by a particular processing specification, or LPD) should be >processed as if it were a foobar. More power, see? And how does a dumb browser know which to do? >(Or else it means someone screwed up, of course. But you can't ever >guarantee against that.) No, but there's little reason to throw a big bag of marbles into a roller-skating rink, either. That is, why create extra opportunities to screw things up, when you get no decisive benefit from it. >My suspicion was that dislike of the syntax could not be the real >underlying reason for objecting to LINK, and subsequent discussion has >shown this to be the case (at least for Steve and Tim; it does appear that >this was Jon's principal objection). Well, I hate the syntax too (though the restricted form is obviously much better), but given that the semantics are wrong, it's pointless to concentrate on syntax (where it is hard to make engineering arguments in any case). >>>* We do have a new construct which isn't in the November draft. However, it >>> is just a one-production, simple wrapper around an existing construct. >> >>Michael responded to this already. > >I haven't seen any contributions from Michael on this topic. Did I miss >something? Well, I can't find the message, so it must have been someone else. Whoever it was pointed out that it was not just 1 production but several productions and yet more terminal symbols, in a language whose spec is already a little longer than we wanted... >... > >I won't to respond all David's arguments, because Murray Altheim did an >excellent job of countering most of them. Let me just pick up on a few >points he didn't cover: > >>If the Exoterica people claim that it's not well-defined enough to >>implement, I take that seriously. So my assertion has some support. >To be honest though, I don't think citing authorities is a very productive >way of conducting a discussion. (Do you want me to start marshalling >Charles, Eliot and others in my support?) I too have a lot of respect >for the Omnimark people, but I don't consider people's arguments in a >vaccuum. If anyone were to have a vested interest in *not* supporting >standard mechanisms for generalised processing it would be vendors of an >SGML processing language that is well on its way to becoming a de facto >proprietary standard. (Not that I am accusing anyone of intellectual >dishonesty; everyone's opinions are to some extent formed by their >personal interests, as well as their experience and needs.) This motivation was not in effect at the time Exoterica took that decision. And I think that citing authorities like Lynne Price is not a feeble move. Her knowledge of the standard document, and commitment to SGML are beyond questioning, in my opinion, and I remember her telling me that she simply didn't believe the _standard's text_ provided sufficient information to create a sensible implementation. Lynne would neither extend or relax the standard one iota, so that I take her opinion quite seriously. But you don't have to if you don't want to. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 11:49:04 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: YvesS@hq.ile.com CC: elm@arbortext.com, hbingham@acm.org, w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: RE: Bogus XML conformance claim | Thanks for your note. | | We have been in touch with Tim Bray about XML and OpenTag and he | kindly pointed out several mistakes. We are working on solving them. I'm very pleased to hear that. ILE appears to be a useful approach to the problem of localization, and I'm glad to see XML being applied in this area. | You have to understand that our expertise in that area is not perfect. | But hopefull, with XML experts help, we will be able to improve it | quickly. As Eve pointed out, we're all very new at this. With mutual effort and criticism, we can prevent XML from turning into a meaningless label the way that HTML once did. | Thank you for having taken the time to analyse our DTD. Thank you for taking our analyses in the spirit in which they were given. I think you will find us more than willing to help in any serious attempt to implement this technology. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 21:04:28 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: XML marketing conference, San Diego Anyone going to the conference in San Diego next week? If so, is there any interest for a WG get-together? Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 6 Mar 1997 20:56:52 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: Last word on LINKTYPE (ha, ha!) I did say I'd said my last for the time being, but I have to clear up an error I made (I think): At 18:37 06.03.97 +0100, David Durand wrote: >At 11:42 AM +0100 3/6/97, Steve Pepper wrote: >>The separation between the DTD, the LPD >>and the instance is so clear that I do not regard this as "mixing >>processing and markup". (And in fact you don't even have to put the >>LPD physically in the document if you use SP-based tools.) > >yes, funny that SP should have chosen to be non-conformant in that way. >Wihtout asking I would suspect that James is bothered by the same thing I >am, to the extent that he's willing to ignore the standard in his >implementation. I'm not sure this is the case after all. I may have been half-remembering something else (that the "-A archname" option automatically activates any LPD of the same name). But it would be a nice feature to have -- and calling it "non-conformant" is a bit silly: All that would be happening would be the on-the-fly creation of a virtual document. Nothing in the standard that prohibits that. Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 06 Mar 1997 13:52:38 -0800 From: "Karl F. Best" To: Steve Pepper CC: w3c-sgml-wg@w3.org Subject: Re: XML marketing conference, San Diego Steve Pepper wrote: > > Anyone going to the conference in San Diego next week? > If so, is there any interest for a WG get-together? I'll be there. I think a get-togther would be appropriate. ====================================================================== Karl F. Best - Manager, Frame Developer Support Adobe Systems - San Jose, CA v. 408-536-6531 f. 408-536-6883 kbest@adobe.com ====================================================================== %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 06 Mar 1997 15:40:13 -0600 To: Steve Pepper , w3c-sgml-wg@w3.org From: "W. Eliot Kimber" Subject: Re: Last word on LINKTYPE (ha, ha!) At 08:56 PM 3/6/97 +0100, Steve Pepper wrote: >>>The separation between the DTD, the LPD >>>and the instance is so clear that I do not regard this as "mixing >>>processing and markup". (And in fact you don't even have to put the >>>LPD physically in the document if you use SP-based tools.) >> >>yes, funny that SP should have chosen to be non-conformant in that way. >>Wihtout asking I would suspect that James is bothered by the same thing I >>am, to the extent that he's willing to ignore the standard in his >>implementation. > >I'm not sure this is the case after all. I may have been half-remembering >something else (that the "-A archname" option automatically activates any >LPD of the same name). But it would be a nice feature to have -- and calling >it "non-conformant" is a bit silly: All that would be happening would >be the on-the-fly creation of a virtual document. Nothing in the standard >that prohibits that. With SP, you can concatenate files on the command line, which allows you to do: nsgmls mydoctype.dtd mylpd.lpd mydoc.sgm You can also have an external LPD subset, so you could do: ... Obviously, any entity manager could be designed so that you could "slip in" a LINKTYPE declaration without actually having in the document entity, although this is, of course, a hack. Cheers, E. --

W. Eliot Kimber, Senior Consulting SGML Engineer Highland Consulting, a division of ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 95202. 214.953.0004 www.isogen.com
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Mar 1997 10:06:45 +0000 To: dgd@cs.bu.edu (David Durand), Steve Pepper , w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: Last word on LINKTYPE (ha, ha!) At 12:37 6/3/97 -0500, David Durand wrote: >Last I heard, MARK-IT used significant comments in LINK delcarations to >invoke a scripting language. Maybe it does something different now? While MARK-IT provided a mechanism for attaching scripts to both IMPLICIT and SIMPLE links it also allows IMPLICIT links of the type proposed by Steve Pepper to be run in pure SGML mode. However, as it is SGML conformant, it will not allow you to use the barstadized form suggested by Steve for XML (which, incidentally, will never be approved by WG8 as an extension to SGML while I am on the committee as it is application specific!) ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 11:24:34 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: Last word on LINKTYPE (ha, ha!) Cc: mtbryan@sgml.u-net.com At 11:06 07.03.97 +0100, Martin Bryan wrote: >While MARK-IT provided a mechanism for attaching scripts to both IMPLICIT >and SIMPLE links it also allows IMPLICIT links of the type proposed by Steve >Pepper to be run in pure SGML mode. However, as it is SGML conformant, it >will not allow you to use the barstadized form suggested by Steve for XML >(which, incidentally, will never be approved by WG8 as an extension to SGML >while I am on the committee as it is application specific!) Martin! I thought you knew me better than to think I would propose an application specific extension to SGML! My thought was that it might serve to enhance the LINK feature generally if the syntax allowed some defaulting. Specifically (and this is off the top of my head, so please make allowance for that): [8879:1986] ]> [amended] ]> NOTES: [8879:1986] (omitted) [amended] - default (when no named #INITIAL link set) is that the implied initial link set consists of link rules which use the default values of all attributes declared in the LPD. Is there any reason why this wouldn't work and couldn't be useful? (Maybe best to answer i private email.) Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 10:32:40 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.c Homegrown locator language? At 12:33 PM -0800 3/4/97, Tim Bray wrote: >4.c The spec will describe some addressing types that we support. Should >we be open-ended and include a way to support other user-defined >locator languages? No. The fact that we are defining generalized markup means that users can define their own locator languages if they want to -- and have the same level of interoperability with the rest of the world (none, without prior arrangement). If they want a way to generalize things, they can use HyTime. For XML linking, no effective purpose is server by knowing that something is a locator, if there's no guarantee that it can be resolved. We should keep XML linking as a specific architecture, not a toolkit. XML is a toolkit, and allows for flexibile private arrangements, so lets keep links simple and only include features that we are wiling to require of xml linking implementors. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 10:36:41 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.c Homegrown locator language? At 12:33 PM -0800 3/4/97, Tim Bray wrote: >4.c The spec will describe some addressing types that we support. Should >we be open-ended and include a way to support other user-defined >locator languages? No, this generality doesn't offer very much, as authors can use any markup they want, and any interpretation they want is fine -- XML linking should concentrate on providing a base set of capabilities, and not explicitly address extensibility. This is not to say that we might not have some hooks to allow the standard to be extended, just that user-extension of XML linking is not allowed -- at least if you do that you are not doing XML linking, but something else. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 10:43:27 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.d Compulsory locator language(s)? At 12:33 PM -0800 3/4/97, Tim Bray wrote: >4.d The spec will describe some addressing types that we support. Should >we declare support for one or more locator languages to be compulsory? >Which? Yes. we are giving people link types, and anchor roles and explainers and N-ary links. That is all flexibility for content description. We should not offer the same flexibility for linking infrastructure (locator languages, URL formats, and the other stuff that people have to write code to resolve, and where we can't see a way that the extension could automatically work on a new client). I think IDref, and TEI locators give us what we want. I think Fragment IDs are the way they should be put in the attribute values, too. No separate address types. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 10:58:11 -0500 To: Tim Bray , w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.3 SGML addressing At 12:33 PM -0800 3/4/97, Tim Bray wrote: >Background: the draft spec supports SGML-style addressing, traditional >IDREF(S) and also by entity name. > >4.3.a Should we support this type of locator? We will impair the advantages of XML for SGML users a lot if we don't support SGML-style addressing. >4.3.b Should we support entity addressing by name? I think this idiom for inter-document links (ent=foo refid=bar-in-foo) is so common that we must support it. >4.3.c Should we support element addressing by ID attribute? Yes. >4.3.d Should we support a combination of these two? Yes. >4.3.e What syntax should we use? The Entity attribute should be one way to do BASE (or whatever). The declaration can cause the behavior to switch from URL-interpretation to entity reference interpretation. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 11:02:24 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.6 Query Language Locators? At 12:33 PM -0800 3/4/97, Tim Bray wrote: >4.6.a Should we support this? Not in general... if TEI locatoors are a query language, then we support this in the generic case. People can use Custom URLs for queries as they do today, or define their own markup for their application. Extendable query languages will not interoperate without prior agreement, so they should not be part of this spec. >4.6.b If so, should we specify any query languages? If we have them at all, we should specify a closed mandatory list of query languages required. we should not generalize so that XML linking users cannot expect that their links will be interpretable by any XML link conforming application. If they need more they can make up new tags/arch forms, or use HyTime. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 10:54:12 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.2 Location-source/Base address At 12:33 PM -0800 3/4/97, Tim Bray wrote: >4.2.a Should we formalize at all the concept of a base address? Probably. The URL standard underway does formalize the meaning of relative URLs, so that we could just steal that definition (but it won't help us for fragments, of course). It works in the obvious way, actually. >4.2.b If so, should we call it a location source or something else? Probably BASE, as the term seems to be well known. I know that the HTML definition was not too good, but changing the name will probably confuse people. >4.2.c Should we formalize the concept of the implied location source? It seems that this concept already underlies the notion of "relative URLs". I'm not convinced that we should include explicit location sources, even though they have a _lot_ of power and utility. The do provide one way to conceptualize inter-document IDREF (via ENTITY attributes) and the notion of BASE address. If we allowed _just_ those two forms, it might not be too pernicious. I think referred entities should be required to be well-formed for the results to be well-defined (It is possible that we could allow any XML entity, but then we would have to talk about "virtual" root nodes, for those entities not enclosed in a single tag. The complexityof explanation might be a net loss in that case. >4.2.d If so, should the values be DOCELEM and REFERRER, defaulting to >DOCELEM? I never cared for those values too much. We might do better to conceptualize this as an extension of BASE to handle entities values, rather than as a full LOCSRC. I'm thinking that the base attribute would be a URL if declared CDATA or undeclared, and an entity if declared ENTITY, and there would be no other case allowed. If not present, we get a default value of the URL used to fetch this (DOCUMENT or ENTITY??? open issue, but document is probably better...). -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Mar 1997 09:52:53 -0600 From: Len Bullard To: David Durand CC: w3c-sgml-wg@w3.org Subject: Re: 4.c Homegrown locator language? David Durand wrote: > > At 12:33 PM -0800 3/4/97, Tim Bray wrote: > >4.c The spec will describe some addressing types that we support. Should > >we be open-ended and include a way to support other user-defined > >locator languages? > > No. The fact that we are defining generalized markup means that users can > define their own locator languages if they want to -- and have the same > level of interoperability with the rest of the world (none, without prior > arrangement). If they want a way to generalize things, they can use HyTime. > > For XML linking, no effective purpose is server by knowing that something > is a locator, if there's no guarantee that it can be resolved. > > We should keep XML linking as a specific architecture, not a toolkit. XML > is a toolkit, and allows for flexibile private arrangements, so lets keep > links simple and only include features that we are wiling to require of xml > linking implementors. I agree with David particularly with regards to an XML 1.0 version. An easy to use but more powerful than current applications version is needed. I think it important to emphasize if not in the spec language, at least in the presentations that XML Linking is more like TEI and less like HyTime in this: XML Linking is an application. It is not a user-extensible meta-language standard in the way that XML syntax is. That is why some of us asked for separate documents and refer to XML as a suite. The user certainly can use XML syntax and create another similar or dissimilar link and location application. Nothing can prevent that nor should anything. XML Linking is a set of application conventions that a user community agrees to and agrees to implement. Its success will depend on who adopts it and uses it. Now can someone add their own extensions to the XML Linking applications: certainly. Who will use those extensions? That is up to the market. Will they pass a conformance suite test set? No. Could they be offered as improvements to XML 1.n? Certainly. That is the way it should work. Will this guarantee future interoperability? No, but nothing short of a big stick does that and even then, it doesn't work when someone can bear the pain. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 11:09:14 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 5.1 Extended Link Groups At 12:33 PM -0800 3/4/97, Tim Bray wrote: >5.1.a Shall we support a mechanism for a document to contain a list of >other documents that someone thinks ought to processed with it, in order >to find linking elements pointing into the first document, and in general >create a web of related documents? Yes. >5.1.b If so, shall we say anything normative about whether this must be >done? I think we should say that it should be done unless overridden by the user or unless it fails to fetch some documents (broken links). We should make a requirement that document sets not processed together should somehow indicate to the user that the display is "incomplete". In other words we can't ensure that applications do what they are asked, but ought to require that they inform the user if they are not so doing. >5.1.c Should we use an SGML element, a PI, or some other construct to hold >this list of documents? yes. It should be recursively defined, too. >5.1.d If we use an element, what should it be called? companion. I like the term companion document. >5.1.e If we use an SGML element, should we have subelements per referenced >doc or just a token-separated list of entity names in a single attribute? >In either case what should the subelement (if any) and attributes be >called? companion/companions -- depending on structure. we could use the same name for a PI if we use that method. I think elements of one form or another are nicer, however. PIs to extend XML are one thing, but XML link is, in some sense, the first XML application people will see so we should play nice... -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 11:22:29 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 5.2 Linking element corrals? At 12:33 PM -0800 3/4/97, Tim Bray wrote: >The premise is that since extended links are independent of their >resources, they can be difficult to find. One solution is to >corral them into one spot, either within a document or in a special >external document. > >5.2.a Should we provide an element to serve as a corral for extended >linking elements? No. Authors can define one if they need to do it. > >5.2.b If so, should we require its use? No. I don't believe that it has enough value to justify controlling the user's markup. Despite the feeling that it's hard to find elements, you still have to find the corral... I have not seen an argument that shows how corrals really make things significantly easier, so I don't believe that they do. >5.2.c If we allow but not require its use, should we require that if the >corral is used, there be no extended linking elements outside it? No. >5.2.e Should we specify LINKSET documents, i.e. external entities >existing only to contain extended link corrals. no. Even more restrictive than corrals. Emphatic no. This makes external links extremely difficult to control, especially when they are used within a document (eg. footnotes, commentary, local imagemaps)... >5.2.f If we specify LINKS and/or LINKSETS, should we discuss the temporal >effectivity and user-visibility of the links therein, in terms of the >period the document is "open"? We need to specify "minimal effectivity," so that users of a document are free to keep as many external links as they want open -- but an author shuld be guaranteed that once all companion documents are available, all the external links in those companions will be visible in the starting (displayed or current) document. In other words we want to enable authors to say what is _part of a document_ but we might as well let readers determine if they want to add links on their own (for bookmarks or commentaries, etc.). -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 11:40:05 -0500 To: Tim Bray , w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 7. Attribute remapping? At 12:33 PM -0800 3/4/97, Tim Bray wrote: >We have decided that we will allow the use of any old GI's on XML linking >elements, identifying by the use of reserved attribute names and values. >We will be specifying the use of some attributes to support XML linking. >Do we need to allow them to be remapped as well, so that when an >HTML doc says HREF= and a TEI doc says PTR=, they can mean the same >thing? Probably. I wish not though. > >If we don't do this, then either we call all locator attributes HREF= >or we take a terrible loss in selling this to the web-folk. True. And I dislike HREF enough that that is almost reason enough to add attribute remapping. Given that no common convention for the attribute names is currently in use in SGML, allowing attribute remapping would make dealing with old documents and DTDs much easier. This is why I think we probalby have to do it. >Eve suggested a mechanism for this in > > http://www.doctools.com/xml-link.html > >This involves pulling apart lists of things in attribute values. Yecch. Not so yecch like really. I'd be temtped to change the syntax she suggested to use an = or something so that the direction of remapping was clearer (and the organization into pairs more obxious). EG: xmlnames="ptr=href captions=labels" would mean that the PTR attribute role will be filled by an attribute called "href" and the captions role by one called "labels". Eve also had the pairs in the opposite order, but I find that the old=new is more analogous to attlist definitions. Of course, it's less analogous to assignment statements, so maybe we can't win. An arrow ":=" or "<-" or something would maybe make things clearer but it's too yucky... I'm not even sure about the "="... I think one attribute, or one PI, is all we can afford for the remapping. As I said before I think we should avoid PIs as far as possible for the linking, except maybe for the companion mechanism (where it's really instructions to the XML processor to handle a set of documents). >The obvious alternative is simply to have an arcform-like attribute >for every attribute we want to remap. Yecch also. Any other good ideas? afraid not. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 11:54:43 -0500 (EST) From: Sam Hunting To: David Durand cc: Tim Bray , w3c-sgml-wg@w3.org Subject: Re: 7. Attribute remapping? > xmlnames="ptr=href captions=labels" > would mean that the PTR attribute role will be filled by an attribute > called "href" and the captions role by one called "labels". Eve also had > the pairs in the opposite order, but I find that the old=new is more > analogous to attlist definitions. Of course, it's less analogous to > assignment statements, so maybe we can't win. An arrow ":=" or "<-" or > something would maybe make things clearer but it's too yucky... I'm not > even sure about the "="... I'm not sure I like teeny languages in CDATA ("old->new"). Why not just document what's going on in the attribute name, ("pairs.old-xml"?), then make the value a white-space delimited list of pairs? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Mar 1997 18:25:48 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: Last word on LINKTYPE (hum, hum!) At 11:24 7/3/97 +0100, Steve Pepper wrote: >Martin! I thought you knew me better than to think I would propose an >application specific extension to SGML! I do - I am aware that you have not thought out all the implications of the change you suggest:-) >My thought was that it might serve to enhance the LINK feature generally >if the syntax allowed some defaulting. Specifically (and this is off the >top of my head, so please make allowance for that): >[amended] > xml-link CDATA #fixed "xml-tlink"> > ]> > >NOTES: > > > - defaults to the active document type and implicit link You need to specifically state what DTD the link was designed for so that the parser can check that the LPD is not being applied to an DTD it was not designed to work with You need to say #IMPLIED so that the parser can check that the option to allow implied links has been allowed for in the SGML declaration > [8879:1986] The #INIITIAL makes the fact that this is the start point clear - you gain nothing by changing it to a default name such as xml-proc What the xref is meant to show is a puzzle - you have to assign attribute values to specific element names in the link spec. > (omitted) [amended] > > - default (when no named #INITIAL link set) is that the implied > initial link set consists of link rules which use the default > values of all attributes declared in the LPD. Yuk. This will just not work in the case of all SGML LPDs. How are we to distinguish when it is relevant from the majority of cases where it is not? >Is there any reason why this wouldn't work and couldn't be useful? >(Maybe best to answer i private email.) It may be useful for XML - it is less than useful as a general contraction of all SGML applications of LPDs. If it cannot be a general change to SGML XML is no longer SGML conformant, which is what we have all been fighting for so hard. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Mar 1997 19:01:52 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: BEHAVIOR Lines: 40 This is a somewhat general contribution to the behaviour of links which I hope the ERB can extract something useful from. I have just been at a conference in Germany on informatics in science organised by the Ministry and some general points may be interesting. Apart from myself two people were intending to use XML, one an innovative learned society publisher, and the other a creator of WWW indexes from metadata. In addition, another speaker from a well-known hypermedia projects emphasised the importance of publishing _collections of links_ as primary publications. (And I gave a plug for XML :-). The point I want to make is that XML opens up *new* opportunities and it is importance not to restrict these. In the case of links, I want to use these features in particular: - documents which consists solely of links. - links which point to several resources. - links as a means of adding structure to complex 'documents' My understanding of AUTO/REPLACE is that it is what is needed if the role of a link is as an invisible 'switch' linking a single input to several outputs. For example I might have a button which lights up a map and (separately) a timetable (through a double-ended pointer). If, however, I wanted to highlight several positions on the map and the corresponding entries in the timetable (which might appear as separate windows) I might need an intermediate set of links to expand this signal. (This may be a contrived example, my real requirement is in molecular applications). Even though XML is designed for use over the WWW, it should not be assumed that a link always points at a (graphical) display. Indeed, if it has to, I shall be disappointed as it has a very important role in helping to define the data structures of 'documents' (used in a very wide sense). Hope this makes sense P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Mar 1997 19:32:59 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: 4.4 URL processing Lines: 25 In message <3.0.32.19970305124250.009549a0@pop.intergate.bc.ca> Tim Bray writes: > At 12:33 PM 3/4/97 -0800, Tim Bray wrote: > >Very likely XML Link will use URLs (perhaps among things) for locators. > >Is this all we need to say? > >Do we need specific interpretation of '#' fragment handling for XML? > > Yes. And we need to get this right. I think that we should say that > if it's just a NAME after the #, this is an IDREF - if it's a '(', > this is the start of a TEI locator. If < wasn't such a problem > we could consider FSI syntax and so on too. -Tim I interpret this to mean that any use of the '#' target requires it to correspond to an ID and that HREF corresponds to an IDREF. This represents a departure from HTML, and while there is no requirement to follow those semantics, my primary concern is the potential confusion to users. [I raise this because when I developed CML I started with IDREF/ID and dropped in in favour of the HREF/NAME convention because I thought it was easier to 'sell' this to people who didn't know SGML.] P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 22:26:21 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: WG get-together in San Diego Several people have expressed a wish to get together at the XML Marketing Conference next week in San Diego. I am volunteering to be co-ordinator... I expect to be in the bar at the Marriott Mission Valley from about 9.30 pm on Sunday (my eyes propped open with matchsticks and looking like something out of the Cuban Revolution!). Drop by if you're around. Otherwise the best plan is to try and have lunch together on Monday and then take it from there. Keep an eye out for notices on the board or near the lunch restaurant. See you there! Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Mar 1997 22:21:08 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: 4.4 URL processing Lines: 25 In message <3.0.32.19970304121746.00964160@pop.intergate.bc.ca> Tim Bray writes: > Very likely XML Link will use URLs (perhaps among things) for locators. > > Is this all we need to say? I think that presenting references as URLs (rather than SGML ID/IDREFs) is the best (and probably only) way to get the webheads (i.e. me) on board. I'm wondering what the role of ID/IDREF now is? Is it: - left semantically free so that SGMLheads can use in in whatever way they are used to - acting as a synonym for a simple case of xlink? - doing something significant but different? (if so I'm not clear what that is). > > Do we need specific interpretation of '#' fragment handling for XML? If we are requiring the target to be an ID, it needs spelling out. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Mar 1997 22:03:27 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: 4.5 TEI Extended Pointer Locators? Lines: 55 In message <3.0.32.19970304121751.00964a20@pop.intergate.bc.ca> Tim Bray writes: > 4.5.a Should we support these? Yes. > > 4.5.b What portions of TEI extended > pointers should be dropped from this spec? None at all. I have very specific and important uses for all of these, especially TOKEN, SPACE and FOREIGN. These are particularly important for non-textual applications such as numeric data. TOKEN: I make use of constructs such as: 1.2 2.3 3.4 extremely frequently and so do most other people in technical fields. (The alternatives like: 1.22.33.4 waste space and are less human readable. I can't operate without subaddressing into this sort of construct. Admittedly the example above can be tackled with SPACE, but I am sure there are some that can't. [BTW. what are the default delimiters for tokens? can they be changed? And I am mystified by the example in A.1.1.13 (the 3rd, 4th 5th tokens in "This is _not_ a very good idea" are apparently: "not_", "a" "very" The _ acts as a delimiter if it leads a token but not if it trails it? (Any default use of _ as a delimiter will cause scientists a lot of grief, I suspect).] SPACE: We have many uses for multidimensional data. While large data sets may be best managed by NOTATIONs (e.g. NETCDF) there are many places where arrays are easily and cheaply passed and need subaddressing. FOREIGN: This is essential. My understanding is that I can use TEI navigation to locate (say) the fifth MOL with a child of BIB and then to apply my own method for searching that subtree (in this particular case a molecular search, using (say) Java classes). This will also be vital for numeric data - find all matrices and return those which are positive definite is a reasonable request. PATTERN. This isn't in the spec, but if it signifies applying a regexp to the #PCDATA content of the node I will argue strongly for it. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 16:03:24 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Upcoming Journal Publishers XML Tutorial and Math Round Table (EPSIG) [Forwarded by a WG member. No endorsement implied; just thought y'all might be interested... Jon] From: SGMLdk@aol.com Date: Wed, 5 Mar 1997 10:36:00 -0500 (EST) To: spence@sq.com, tfreeman@allenpress.com, bkasdorf@aa.impressions.com, marcia_walker@ipcjci.com, dave@penta.com, scot@penta.com, eowens@journals.uchicago.edu, predmon@coris.com, abigman@cadmus.com, dwaldt@tpp.com, phuber@wwilkins.texcel.no, juzzo@pong.ieee.org, lseab@cris.com, Kampmann@springer.de, rous@hq.acm.org, SDHenry@po.asm-intl.org, 100043.3201@compuserve.com, pharris@cni.org, Pierre.Attar.patt@berger-levrault.fr, Randall.Barry.rbar@loc.gov, EPNEWS@crnvma.cern.ch, mtbryan@sgml.u-net.com, buchinsm@magi.com, linda@interlog.com, ted_carpenter@staff.ichange.com, wcathro@nla.gov.au, peterc@silverplatter.com, dnc@ebt.com, johncook@acslink.net.au, Jacques.Ducloy@loria.fr, sgml@globalx.net, pirkko.eskola@vtt.fi, filliatreau@distb.mesr.fr, thomas.gordon@gmd.de, pbg@texcel.no, harmsze@phys.uva.nl, fharri@osa.org, 100621.2123@compuserve.com, ion@math.ams.org, SCHEUER@frcpn11.in2p3.fr, jeffrey@lemond.hks.com, ROB.deJEU@wkap.nl, scottj@aip.org, rakelly@aps.org, kircz@phys.uva.nl, ykh001@nuri.net, laloe@peterpan.ens.fr, cl@blutch.jouve.fr, pirkko.escola@vtt.fi, j.mancia@elsevier.com, smarland@rrddts.donnelley.com, bmicksch@riatax.com, chaz@aps.org, erlend.overby@usit.uio.no, P.L.H.Bergstrom@telub.se, markp@aps.org, erp@maxwell.ph.kcl.ac.uk, n.poppelier@elsevier.nl, dlr@math.ams.org, samarin@isocs.iso.ch, snavely%hook@beacon.com, soiffer@wri.com, Mark_Walter.SBEXPOS@elvis.sbexpos.com, ggruber@dlogics.com, prc%auto-graphics.comsb@stilo.demon.co.uk, bbellar@cchbspub.harvard.edu, as283@columbia.edu, fran@cadmus.com, jfleming@cadmus.com, michaeldgx@worldnet.att.net, Fotiaacr@aol.com, krawson@mindspring.com, prc@auto-graphics.com Subject: Upcoming Journal Publishers XML Tutorial and Math Round Table (EPSIG) Attached is an announcement from EPSIG. We are sponsoring a tutorial on the application of XML in Journal Publishing. The following day, journal publishers who have requirements to publish math are invited to a round table discussion to share requirements and provide input to vendors who are developing tools to support SGML Math. Input from this session will go back to the ISO 12083 meeting this May in Spain. If you have any questions, please contact me (Dianne Kennedy). Also please share this with any other publishers/vendors who may have an interest. XML The New Alternative for Journal Publishing on the Web In the years since SGML was introduced as an ISO Standard, journal publishers have attempted to use SGML as the foundation for publishing. We have lived through two standards development efforts (AAP Electronic Document Standard and ISO 12083) only to find that real use of SGML by journal publishers is suceeding in only a limited fashion. With emerging requirements by both publishers and those who use journals, it is clear that a ``standardized'' encoding which enables simultaneous delivery of journal information in multiple formats as well as facilitating the ability of users to quickly locate information in journals is critical. This tutorial explains the model for journal publishing, existing SGML journal publishing standards, and why implementing them is so difficult. It explains existing electronic publishing alternatives to SGML that just don't deliver what the readership requires and introduces XML--a new W3C standard which promises to provide solutions for both Web and traditional journal publishing. HTML, the current Web language, is just too simplistic to support ongoing Web publication of journals. Its parent language, SGML, has proven to be too complex. XML provides a middle ground for journal publishers being sophisticated enough to support full- function publishing on the Web without raising the technical and economic barriers one faces in attempting to use SGML. We invite the journal community to come to this tutorial to get a first-hand look at XML and the promise it holds for journal publishers. Tutorial Agenda ============================== 9:00-9:15 Introduction to the Tutorial 9:15-10:00 XML; A New Language for Web Publishing 10:00-10:30 Traditional Journal Publishing Models 10:30-10:45 Break 11:00-11:30 Emerging Requirements for Journals 11:30-12:00 Early Use of SGML; AAP Project 12:00-1:00 Lunch 1:00 - 1:30 Current SGML Standard; ISO 12083 1:30 - 2:00 Roadblocks to Using SGML 2:00- 2:30 Alternatives that Don't Deliver (PDF and HTML) 3:15-3:30 Break 3:30-4:00 The XML Alternative for Journals 4:00-5:00 An XML Version of ISO 12083 for Journal Publishing ========================================= Registration: ========== To Register, Contact EPSIG at the address below. Also look to the Web: http://www.mcs.net/~dken/xmljrnl.htm. Tutorial: $295 for EPSIG Members $350 for Non-Members Round Table: Free Admittance; All Invited! Please RSVP to EPSIG. ==================== About EPSIG =========== The Electronic Publishing Special Interest Group (EPSIG) is a collaboration between Graphic Communication Association and the Association of American Publishers (AAP). EPSIG is designed to serve as your source for information about ISO 12083 as well as related standards and industry implementation activities. For more information on EPSIG membership, EPSIG News Subscriptions, EPSIG publications and other EPSIG events, call 703-519-8184, fax 703-548-2867 or email; EPSIG@aol.com. EPSIG Math Requirements Round Table ==================================== In conjunction with this tutorial, a roundtable of journal publishers with specific math requirements will be held. Rather than focusing on the details of the ISO 12083 Math DTD fragment, the needs and concerns of journal publishers will be considered. Math definition has been particularly troublesome for the ISO 12083 working group and for publishers of journals that have an intensive math requirement. Vendor support for math has been held up because of conflicting requirements. This roundtable will provide a forum for journal publishers to state requirements for SGML math. A summary of this roundtable discussion will be presented at the upcoming ISO 12083 meeting in Barcelona. The Lecturer ============= Dianne Kennedy is an independent SGML consultant and founder of the SGML Resource Center. Ms. Kennedy has been an active participant in many industry SGML standards activities. Currently she serves as chairperson for the DTD Working Group of SAE J2008 for the automotive industry and is Deputy Conviener for ISO 12083 Standards work. She also has played a vital role as a consultant to the ATA 2100 Specification SGML working group and has served on a number of DoD CALS standards committees as well. Dianne Kennedy regularly presents ``SGML ToolTime Seminars''. Ms. Kennedy was in instructor for GCA SGML Tutorial Series from 1984 to 1991. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 7 Mar 97 21:52:20 EST To: w3c-sgml-wg@w3.org Subject: Re: Couldn't XML allow and ignore omitted tag minimization Sorry if this has been answered already -- I don't see it in my mailbox, but am behind... :-( Jon wrote about allowing - -, > I am made uneasy by the thought that a legal DTD would then be stating > specifically something that would not be true in XML, namely that > certain omissions were allowed when, in fact, they would not be. But > I'm willing at least to entertain the argument that this tradeoff > makes DTD maintenance a lot easier. I think this is a red herring, an argument based on a false assumption. Those people using SGML today will need conversion software for both DTD and instance. This might be something as simple as a perl script, or it might use OCLC's FRED, for example. Some people will use SGML internally, and translate to XML on the fly. New valid XML files wil be valid SGML files, when you use the right SGML declaration. In no case was a promise made that all existing XML files or DTDs could be used with XML, and we already know that most can't. So adding - - back makes life no easier. People can leave them out of SGML DTDs today and turn OMITTAG off and generate cleaner data anyway. Next we'll be asked to * accept "&" in model groups * accept mixed content with , and #PCDATA * accept inclusions and exclusions * add LINK (there's already been a proposal to add LINK to XML) * add CONCUR, OMITTAG, DATATAG... * add open-tag-entitie * ignore the keyword "SDATA" and so on, until an XML processor will have to include a full SGML parser simply for the benefit of less than 1,000 people on this list, and 10,000 people not on this list won't use XML. So no, there's no need for anything to do with OMITTAG in XML. And we need not to have things that are there for "SGML legacy conversion". Those who need to work with both systems will find "O O" among the least of their challenges. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Mar 1997 23:41:56 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: Couldn't XML allow and ignore omitted tag minimization From: John_Lavagnino@Brown.edu I'm inclined to agree with Lee's point--- that > Those who need to work with both systems will find > "O O" among the least of their challenges. For newly-written DTDs, if you need SGML/OMITTAG YES compatibility, there are pretty obvious tricks with parameter entities that you can use. For existing SGML DTDs, you're pretty fortunate if the omitted tag stuff is all that needs fixing; compared to the possible labor involved in dealing with inclusions, this is a piece of cake. The Perl-script-hacking approach can be applied to modifying the text of DTDs as well as that of XML instances; fixing the omitted tag stuff is amenable to that approach, but fixing content models is much less so. John Lavagnino %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 08 Mar 1997 00:30:40 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Couldn't XML allow and ignore omitted tag minimization A case may have been made for allowing the DTD omittag junk, but At 11:41 PM 3/7/97 -0500, John_Lavagnino@brown.edu wrote: >For newly-written DTDs, if you need SGML/OMITTAG YES compatibility, For new DTD's, does anyone? Ever? Why? -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 08 Mar 1997 22:10:00 +0000 (GMT) From: Peter Flynn Subject: Re: Upcoming Journal Publishers XML Tutorial and Math Round Table (EPSIG) To: w3c-sgml-wg@w3.org At 16:03 07/03/97 -0800, you wrote: >[Forwarded by a WG member. No endorsement implied; just thought y'all >might be interested... Jon] Unfortunately it omits a date and location. Do you have these? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 8 Mar 97 17:18:15 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Link draft: 5.5 TEI location reference type The first sentence/paragraph says: If the reference type is TEI, the HREF must be a TEI locator. Do we mean "TEI locator as defined by the TEI Guidelines" or "restricted TEI locator as defined by the XML subset." I assume the latter, since otherwise it makes no sense to talk about restrictions, but then I think we need to say that in the above quoted sentence. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 8 Mar 97 16:51:54 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Link draft: 3.2 extended link I have some questions about the May 5 XML Link draft, section 3.2, Extended link: 1. The content model for XML-LOCATOR is ANY. I would have expected it to be EMPTY. What is it supposed to mean to give the XML-LOCATOR element content? What are the expected processing implications? 2. the XML-XLINK element has an HRTYPE attribute. Being as XML-XLINK has no HREF attribute, what does its HRTYPE attribute mean/do? 3. LOCSRC and IMPLIED-LOCSRC are only on XML-XLINK, but I would have thought they both could vary per locator rather than per link. As written, it seems you can't have a different locsrc on different locators. Unless I'm missing something, this seems like an uncomformable restriction. 4. Both XML-XLINK and XML-LOCATOR have attributes of: HRTYPE TITLE BEHAVIOR SHOW ACTUATE What are the differences in processing expectations of each of these attributes depending on whether they are on the XML-XLINK element or the XML-LOCATOR element. If, in any case, the attribute of the same name has the same meaning on both elements, what is supposed to happen when both are specified and they aren't identical? Perhaps I'm missing a major paradigm here. I would have expected something more like the following given what I feel are link-related versus locator-related: ATTLIST XML-XLINK XML-LINK ROLE TITLE BEHAVIOR (maybe) ATTLIST XML-LOCATOR XML-LINK ROLE TITLE (maybe) HREF HRTYPE LOCSRC IMPLIED-LOCSRC BEHAVIOR SHOW ACTUATE I'm not violently opposed to having the attributes in both places if that helps cover some extra cases, but then it seems we have to discuss processing expectations some more or we could have lots of interoperability problems (e.g., one app uses the XLINK's SHOW attribute but another uses the LOCATOR's SHOW attribute). paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 8 Mar 97 17:10:39 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Link draft: 5.2 location source In the May 5 XML Link draft, section 5.2, location source: I don't understand "referrer". I don't know how to interpret "the non-link element that refers to the link element." I assume "link element" should read "linking element" (ref. section 1.3), but I didn't know the linking element was necessarily referred to by anything. Can someone please explain this to me? paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 8 Mar 97 17:26:27 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Upcoming Journal Publishers XML Tutorial and Math Round Table (EPSIG) I noticed that--amazing, isn't it! The referenced URL indicates that it is April 1, but I still never found a location. (I don't think this is an April Fool's Joke.) > Date: 08 Mar 1997 22:10:00 +0000 (GMT) > From: Peter Flynn > > At 16:03 07/03/97 -0800, you wrote: > >[Forwarded by a WG member. No endorsement implied; just thought y'all > >might be interested... Jon] > > Unfortunately it omits a date and location. Do you have these? > > ///Peter > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 08 Mar 1997 17:19:32 -0900 To: paul@arbortext.com (Paul Grosso), w3c-sgml-wg@w3.org From: "W. Eliot Kimber" Subject: Re: Link draft: 5.2 location source At 05:10 PM 3/8/97 CST, Paul Grosso wrote: >In the May 5 XML Link draft, section 5.2, location source: > >I don't understand "referrer". I don't know how to interpret >"the non-link element that refers to the link element." I assume >"link element" should read "linking element" (ref. section 1.3), >but I didn't know the linking element was necessarily referred to >by anything. Can someone please explain this to me? In HyTime, the "referrer" is the non-*location address* element that refers to a location address. The distinction is necessary because the location source for a location address element may either be the referrer or defined by the referrer. However, only the top rung of a location ladder can have a default location source, and since the top rung will be referred to by the rung below it (unless the ladder consists of exactly one location address), we can't talk about any element referring to the location address. Consider this HyTime (TC) example:
1 2 The treeloc addresses the second child of its location source, which is the referrer element (the Link), thus it addresses the element B. In this case there is exactly one step in the location path from the Link element to its ultimate target, so the element that refers directly to the treeloc is also the element that makes the initial reference to the location path the treeloc is in (because there is only one step in the path, the treeloc). If we interpose another step in the location path, we see the nomencature problem: foo 1 2 The link points to the name-space loc, which then addresses the treeloc, forming a two-step location path, with the treeloc at the end. The Link element doesn't refer directly to the treeloc but is still the treeloc's referrer for the purposes of determing the implied location source of the treeloc because the Link pointed to the location path of which the treeloc is a member. Intermediate location addresses can't be referrers because otherwise you'd never be able to form this example. Cheers, E. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 8 Mar 1997 17:22:30 -0800 From: Terry Allen To: eliot@isogen.com, paul@arbortext.com, w3c-sgml-wg@w3.org Subject: Re: Link draft: 5.2 location source Eliot writes: | Consider this HyTime (TC) example: | | | 1 2 | | The treeloc addresses the second child of its location source, which is the | referrer element (the Link), thus it addresses the element B. In this case | there is exactly one step in the location path from the Link element to its | ultimate target, so the element that refers directly to the treeloc is also | the element that makes the initial reference to the location path the | treeloc is in (because there is only one step in the path, the treeloc). Which is the location source for treeloc in the following? 1 2 Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 8 Mar 1997 21:10:38 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: Last word on LINKTYPE (ha, ha!) At 3:40 PM 3/6/97, W. Eliot Kimber wrote: >Obviously, any entity manager could be designed so that you could "slip in" >a LINKTYPE declaration without actually having in the document entity, >although this is, of course, a hack. Only a hack as you described it. But what SP does (I'm fairly sure--I haven't actually used SP, but I know James) is not to slip a LINKTYPE declaration into a pre-existing document entity; rather it creates the document entity out of more than one pre-existing file. Which is the job of the entity manager, and doesn't violate SGML principles or rules. Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Mar 97 19:13:31 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Upcoming Journal Publishers XML Tutorial and Math Round Table (EPSIG) > > Date: 08 Mar 1997 22:10:00 +0000 (GMT) > > From: Peter Flynn > > > > At 16:03 07/03/97 -0800, you wrote: > > >[Forwarded by a WG member. No endorsement implied; just thought y'all > > >might be interested... Jon] > > > > Unfortunately it omits a date and location. Do you have these? I sent private email and received the following terse response: ----- Begin Included Message ----- >From SGMLdk@aol.com Sun Mar 9 19:00:30 1997 From: SGMLdk@aol.com Date: Sun, 9 Mar 1997 16:47:28 -0500 (EST) To: paul@arbortext.com Subject: Re: Upcoming Journal Publishers XML Tutorial and Math Round Table (EPSIG) April 1 (tutorial / XML) April 2 Math RoundTable 99 Park Ave, 14 floor NY NY ----- End Included Message ----- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 14:18:34 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Attribute value normalization incompatibility XML spec (3.3.3) currently says: > 3. If the attribute is not of type CDATA, all strings of white space must be normalized > to single space characters. SGML also says that leading and trailing white space is removed. Is there any reason to be incompatible here? James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Mon, 10 Mar 97 10:20:20 GMT To: w3c-sgml-wg@w3.org Subject: Addressing spans As I read the draft, there's no way for a locator to address a span of elements, despite a number of statements to the effect that resouces need not be points. Have I missed something, or is there a gap here? I think spans are absolutely crucial for stand-off annotation, e.g. what I write now in our local normalised SGML as with an inclusion semantics, so this is processed as Now is . . . country ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 15:13:34 +0000 From: Lou Burnard To: W3C-SGML-WG@w3.org Subject: another vote for spans From: OXVAXD::LOU "Lou Burnard" 10-MAR-1997 15:10:43.51 To: MX%"Peter@ursus.demon.co.uk" CC: LOU Subj: Re: 4.5 TEI Extended Pointer Locators? While I don't share Peter's desire to include all the TEI location mechanisms in the XML spec (as already indicated, I think I would add only TOKEN and possibly PATTERN to the grove-based ones already proposed), I would like the ERB to reconsider its decision to disallow the spanning mechanism defined by echte TEI x-pointers. It seems to me that the ability to point/link/target not just "that blort" or "blort number 3" but also "everything from blort no 3 to blort number 12" is an extremely useful and intuitively simple requirement. The whole point of using extended pointers is to cater for the unexpected, unmarked up, and not necessarily hierarchically well-formed in a document, which this very simple mechanism gives you, at no extra cost, as well as the ability to point to entirely natural concepts like "the first six paragraphs of this book", "chapters 12 to 14", etc. I don't believe that it adds much to complexity of implementation -- you only have to be able to proceed sequentially through a document from one location to another -- and it certainly doesn't add much to the complexity of understanding. So how about it ERB? (I would however strongly support any proposal for a less confusing pair of attribute names than FROM and TO, if only I could think of them) Lou %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 15:14:02 +0000 From: Lou Burnard To: W3C-SGML-WG@w3.org Subject: clarification re. tokens From: OXVAXD::LOU "Lou Burnard" 10-MAR-1997 14:51:18.60 To: MX%"Peter@ursus.demon.co.uk" CC: LOU Subj: Re: 4.5 TEI Extended Pointer Locators? |Fnd I am mystified by the example in A.1.1.13 (the 3rd, 4th 5th tokens |in "This is _not_ a very good idea" are apparently: |"not_", "a" "very" |The _ acts as a delimiter if it leads a token but not if it trails it? |(Any default use of _ as a delimiter will cause scientists a lot of |grief, I suspect).] The rule is that the first SGML namecharacter found starts a new token, and the first non namecharacter terminates it, with the proviso that any character whose status as a namecharacter is not defined in the current SGML declaration is treated as a non-name-char (i.e. as white space). See TEI P3 p 419, from which the XML spec has been derived). This means that the underscore is, by default, regarded as white space, so the location specification TOKEN (3 5) starts with the "not" of "not_". The example is perhaps a little confusing because it requests a *span* of tokens (from the 3rd i.e. "not" to the 5th i.e. "very"), and a span, naturally enough, includes all the characters from the start of its beginning to the end of its end, including therefore one of the underscores, but not the other. Seemed a good idea at the time! Lou %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 12:48:02 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 3.1 b-h: BEHAVIOR At 1:47 PM -0600 3/5/97, Len Bullard wrote: >Christopher R. Maden wrote: >> I prefer to think of XML as the language for the database itself. XML >> is a markup language - that which is being marked up is data. An >> application could certainly use XML to mark up its specifications, but >> just because the same language can be used does not mean information >> should be stored in the same place. > >Ok, and understood. I consider that position a religious one. > >Markup of data vs markup of text that an interpreter treats >as instructions are still just markup. XML should neither prefer >not prevent either. Too many designers find it useful or >convenient to markup processes (e.g, action=) and include >behavioral specifications for it to be disregarded by the >WG for purely religious orientations. Separate church and *state*. And they can always mark that. Should we provide special support for non-reusable documents? I don't think so. people will do (what they believe) they have to do without our help. We know some things about good practice, so we should support that, while not encouraging bad practice. >> The data - textual content, metadata, and relationships between >> infoquanta - should be contained in the XML document. > >Yes. But relationships are either passive records or active >structures. They have a clickable interface or they don't. NO. My web mapper has no "clickable interface elements" that correcpond to links, but it does treat many things as "passive structures". This false dichotomy is what we need not encourage. Call it religion if you want. I think we are all aware that good design has aspects of art as well as engineering craft. Given the many concrete advantages however, I think it's much less religious an issue than you make out. >If the stylesheet is used to tell the system that an a hotspot, why bother with XML Link at all? When does the >division bell ring on that debate? As soon as the context >link is added, process is added to a document. What does this mean? You declare it's a link so you can do something _other_ than render it. If you just need to render you don't need a linking syntax at all, just a goto operation in your stylesheet. We can reinvent hypercard any time -- but we don't _need_ to. People can reinvent it on their own if they want to throw their data away in a few years. >> Suggested (or required) behavior should be stored separately. >If there were a technical reason for that other than someone >might prefer curly brackets over pointy brackets, it might >be a good point. But when I open an HTML file and see function >calls in attributes values, a script tag full of curly brackets, >etc., I think this religion is out of style, out of date, >and out of time. XML should be agnostic about that. REUSE REUSE REUSE. Not religion. >> I should be able to >> open the document in SoftQuad XenoMetaL Style Editor and turn off the >> d*mn flashing bullets in front of every item in the Luddite Manifesto. > >Yes, well, depending on where you fall on the "author intention vs >reader privilege" debates. If we don't have reader privilege we also abandon handicapped access. I go for reader privilege -- as if we could prevent it anyway. >> If the transclusion of those bullets is hardcoded in the XML source, I >> can't do that - unless I can override the suggested behavior in the >> stylesheet, and if that's true, why not just use the stylesheet >> always, since browsing will be sort of useless without it? > >Because there are times when to repurpose data, or simply to make it >smaller, no stylesheet will exist. Any tightly focused app such >as CML, MID, etc. may not offer many style options, and even these, >as with IADS, may be in a proprietary stylesheet format with a >point and click interface because the application designer or the >requirements >specify that only the document is portable, archivable, etc. And thus such data is (to the extent that it has such processing semantics) not reusable. People can create that with raw XML; I see no reason to encourage bad decisions in our linking spec. >For these cases, as in HTML, it is convenient to indicate the >behavior for active links. A static relationship link is >only a record of a relationship. An active link (e.g, a >hypertext link as common practice sees it) is a record and a >control interface (clickable). This is probably the piece >that keeps bothering everyone. While this can be achieved >by indirection, it isn't the only way and in many cases, >by empirical observation of existing systems, not always >the best way. Again, XML should be agnostic about that. By saying nothing, we are agnostic -- but we don't have to encourage such bad designs. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg <3.0.32.19970305124032.00978ab0@pop.intergate.bc.ca> Date: Mon, 10 Mar 1997 13:03:35 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.2 Location-source/Base address At 5:56 PM -0700 3/5/97, Dave Hollander wrote: >> At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >> >4.2.a Should we formalize at all the concept of a base address? >> >> Yes, it's generally useful for a variety of reasons, e.g. replication >> support, it's a real pity that HTML BASE is in general not better >> defined and understood. > >True. It is a useful concept to formally define. > >However, if we do, we need to establish what is the resolution >between discrepency between implied-resource-name (resource name used >to reach this resource) and the "base" value. If you specify a "Base" (locsc) you deep-six any other logic for determining the base. No problem. >While we are at it, should we also build in the ability to have the >document its prefered resource name? The one of many paths to that >resource that is prefered to be remembered? No. If people give something more than one name, they are responsible for making them all work. Otherwise we intorduce pointless complexity. > >>4.2.c Should we formalize the concept of the implied location source? > >Is this the same as: resource name used to reach this resource ? >If so, we do need the concept to express priority policy re expressed >location source. I don't see that we need anything other than relative URL rules for this -- either relative to the retrieval-source of the document, or whatever BASE was specified. This keeps it simple, and re-uses Web semantics where they make a lot of sense. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 13:13:27 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 4.c Homegrown locator language? At 9:52 AM -0600 3/7/97, Len Bullard wrote: >David Durand wrote: >> At 12:33 PM -0800 3/4/97, Tim Bray wrote: >> >4.c The spec will describe some addressing types that we support. Should >> >we be open-ended and include a way to support other user-defined >> >locator languages? >> >> No. The fact that we are defining generalized markup means that users can >> define their own locator languages if they want to -- and have the same >> level of interoperability with the rest of the world (none, without prior >> arrangement). If they want a way to generalize things, they can use HyTime. >> >> For XML linking, no effective purpose is server by knowing that something >> is a locator, if there's no guarantee that it can be resolved. >> >> We should keep XML linking as a specific architecture, not a toolkit. XML >> is a toolkit, and allows for flexibile private arrangements, so lets keep >> links simple and only include features that we are wiling to require of xml >> linking implementors. > >I agree with David particularly with regards to an XML 1.0 version. An >easy to >use but more powerful than current applications version is needed. I >think it >important to emphasize if not in the spec language, at least in the >presentations >that XML Linking is more like TEI and less like HyTime in this: XML >Linking >is an application. It is not a user-extensible meta-language standard >in the >way that XML syntax is. Listen to his words. It's got to mean something when Len and I are both in enthusiastic agreement! -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 12:56:05 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 5.2 Linking element corrals? At 12:53 PM -0800 3/5/97, Tim Bray wrote: >At 12:33 PM 3/4/97 -0800, Tim Bray wrote: >>The premise is that since extended links are independent of their >>resources, they can be difficult to find. One solution is to >>corral them into one spot, either within a document or in a special >>external document. >>5.2.b If so, should we require its use? > >No If use is not required, then implementors have to deal with external links in arbitrary contexts anyway, hence the corral gives no advantage. > >>5.2.c If we allow but not require its use, should we require that if the >>corral is used, there be no extended linking elements outside it? > >Yes. Otherwise worthless NO. -- since not using a corral allows the links anyway, using the corral shouldn't introduce funky dependencies! Hence, as I said before: Worthless! >Redundant... if you have an xlink corrall, then you can have a document >containing just an xlink corrall - so you got this in effect. And if you can have xlinks outside of corrals ever, then corrals are rendundant. > >>5.2.f If we specify LINKS and/or LINKSETS, should we discuss the temporal >>effectivity and user-visibility of the links therein, in terms of the >>period the document is "open"? > >No. I think it's hard to get this right; if we're clean on the semantics >of what it *means*, that should be enough. -T. This is right. We need to specify an effective set "required" by a document to respect author intent -- Any other rules are a matter of user-and application related choice. If we get the semantics clear, the rest will surely follow. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 12:15:29 -0500 To: Lou Burnard , W3C-SGML-WG@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: clarification re. tokens At 3:14 PM +0000 3/10/97, Lou Burnard wrote: >The rule is that the first SGML namecharacter found starts a new token, >and the >first non namecharacter terminates it, with the proviso that any character >whose status as a namecharacter is not defined in the current SGML declaration >is treated as a non-name-char (i.e. as white space). See TEI P3 p 419, from >which the XML spec has been derived). This rule (unnatural as it is) was chosen for compatiblity with HyTimes's TOKEN addressing mode -- I don't know its status nowadays, but I would be happier with "space-delimited groups" than any other form of token. But I'd rather leave it out, not becuase it isn't usefulk, but because it's hard to make any definition of "token" that will work across the many contexts where they may make sense -- scripts with their punctuation conventions, programming and scripting languages, and no doubt others. We're better off with REGEXPs I think... >This means that the underscore is, by >default, regarded as white space, so the location specification TOKEN (3 5) >starts with the "not" of "not_". The example is perhaps a little confusing >because it requests a *span* of tokens (from the 3rd i.e. "not" to the 5th >i.e. "very"), and a span, naturally enough, includes all the characters from >the start of its beginning to the end of its end, including therefore one of >the underscores, but not the other. Seemed a good idea at the time! It shows all the features -- so it's actually good that way. But the definition is weird enough that its effects are not necessarily clear from a casual reading. -- David > >Lou _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 16:26:03 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: 4.5 TEI Extended Pointer Locators? Lines: 24 In message <009B10ED.A43A6B80.1@vax.ox.ac.uk> Lou Burnard writes: > While I don't share Peter's desire to include all the TEI location mechanisms > in the XML spec (as already indicated, I think I would add only TOKEN and > possibly PATTERN to the grove-based ones already proposed), I would like the I am ignorant of the full glory of TEI (the phrase 'p.419' is slightly forbidding) but I wasn't really arguing for things I don't know about. TOKEN (possibly amended as in a separate message) and PATTERN will do me fine, though I will *have* to have something like FOREIGN and I would have thought many others would wish to search non-textual information. > ERB to reconsider its decision to disallow the spanning mechanism defined by > echte TEI x-pointers. This also seems like something we could use... P. > -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 16:07:50 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: 4.5 TEI Extended Pointer Locators? Lines: 57 [From a message from Lou Burnard. I'm not sure if this went to the WG, but if it didn't, Lou, I hope you don't mind my replyinh there.] In message <009B10EA.F5FEC08B.4@vax.ox.ac.uk> Lou Burnard writes: > |Fnd I am mystified by the example in A.1.1.13 (the 3rd, 4th 5th tokens > |in "This is _not_ a very good idea" are apparently: > |"not_", "a" "very" > |The _ acts as a delimiter if it leads a token but not if it trails it? > |(Any default use of _ as a delimiter will cause scientists a lot of > |grief, I suspect).] > > The rule is that the first SGML namecharacter found starts a new token, and the ^^^^ The rule is in TEI, not SGML I assume? Therefore we don't *have* to accept it precisely for XML...? > first non namecharacter terminates it, with the proviso that any character > whose status as a namecharacter is not defined in the current SGML declaration > is treated as a non-name-char (i.e. as white space). See TEI P3 p 419, from > which the XML spec has been derived). This means that the underscore is, by > default, regarded as white space, so the location specification TOKEN (3 5) I understand the logic! This is going to create great fun with numbers. Let's try something like: -.2 +1.3 0.13E-14 -2.3E+14 These are all (I think) valid IEE representations. If the rule is applied as stated then (I think) namechars include '-' but not '+'. Remarkably the first 3 numbers appear to survive, but the fourth gets its exponent deleted. In fact, given this rule, I cannot see how numbers can be transmitted in text (and I'm sure that there are even worse things we want to transmit! I would very much like to avoid having to use the construction: -.2+1.3, etc. This will drive scientists away quite rapidly. Many languages (including XML) have a concept of whitespace, so please can we qualify TOKEN with (say) DELIMITER="XML-S" or similar if we want it. > starts with the "not" of "not_". The example is perhaps a little confusing > because it requests a *span* of tokens (from the 3rd i.e. "not" to the 5th > i.e. "very"), and a span, naturally enough, includes all the characters from > the start of its beginning to the end of its end, including therefore one of > the underscores, but not the other. Seemed a good idea at the time! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It always does! The challenge is how can we use it for free format material which is not solely 'text'. I think we must address this. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Mar 1997 16:39:59 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Entity resolution Lines: 62 We have been having considerable problems on XML-DEV interpreting how and when entities are to be resolved, and there is sufficient ambiguity that it would be useful for the WG/ERB to see if this aspect of the XML draft could be clarified. I apologise for those WG/ERB members who will already have seen this on XML-DEV but I have been encouraged to bring this back. > > Peter Murray-Rust wrote: > > Entity substitution is very briefly defined in the draft. I don't know > > what it's like in 8879 (and I'm not going to find out!). > > I see the following problems: > > - it is *possible* (though I think unlikely) that not everyone on the > > ERB agrees as to what is meant to happen during substitution > > - parser implementers may: > > * find the spec not well-enough defined > > * interpret it in different ways > > - DTD implementers (i.e. those using PEs) may: > > * find the spec not well-enough defined > > * interpret it in 'incorrect' ways > > > > > > I have found 'programming' in SGML one of the most tedious and > > counter-intuitive things I have had to do. The primary problem has been > > entities, though RE hasn't helped. I had only two ways of proceeding: > > - if it failed with sgmls it was my fault > > - Joe English helped a great deal by answering 'simple' questions > > over e-mails. > > I finally ended up with a complex, hairy, and totally non-intuitive way > > (to non-SGML folk) set of DTDs and 'include' files. sgmls was the only > > way that I could tell whether it was 'right'. > > > > > > The only way that we can expect people to develop applications for XML > > using entities is: > > - be absolutely clear what we are doing > > - be as consistent as possible with past practice in SGML and > > provide guidance on conversion > > - have 100% accurate parsers > > - have very clear examples and torture tests > > - have tutorials My own experience comes from trying to 'convert HTML2.0 DTD to run under XML'. (My own DTDs use HTML2.0). [I appreciate that there is no algorithmic conversion and that certain constructs (e.g. inclusions) have no equivalent in XML]. HTML2.0 uses a significant number of PEs and PEReferences and some have to be called iteratively. My question therefore might be rephrasable as: 'does XML have the same power of entity substitution as SGML? If not, where not? Where it does, is it the intention of the ERB that it adopts the same strategy for entity substitution? In any case, can it please be summarised?' [Please accept this question from someone who learns by example, rather than trying to understand 8879. I'm afraid there are others like me...] P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Christopher R. Maden" Date: Mon, 10 Mar 1997 20:24:41 GMT To: w3c-sgml-wg@w3.org Subject: 5 March XML-link comments General: If the names of attributes on linking elements are fixed, they must be named xml-*. However, this introduces a problem - the href attribute's name is chosen for backwards compatibility; calling it xml-href defeats the purpose. There are two solutions that come to mind: a) Choose attribute names without regard to compatibility. Call them xml-*. Determine a method for attribute remapping. (Several proposals have been floated so far.) (I strongly prefer this to (b).) b) Choose attribute names called xml-*, and recommend error recovery behavior of looking for foo if xml-foo is not found. -=- Clause 3.1, Resource discussion typo: "thius" -> "this" -=- Clause 3.1, Label discussion: "associated with label" doesn't quite parse; perhaps "associated with a label"? -=- Clause 3.2: does "co-located" need defining? Its meaning can be divined pretty easily, but it is a new term and should probably be defined, IMO. -=- Clause 4.1, INCLUDE discussion: "for the purposes of display *or processing*, in the body of the resource" (emphasis added) sounds identical to the behavior of an entity reference. I don't think that's what was intended. It needs to be made explicit that this is for, e.g., rendering processing (like sizing the line to accomodate the graphic), and not for processing by the parser. If it *is* intended for processing by the parser, then I strongly urge that this be struck - providing two ways to do the same thing is a very bad idea. -=- Clause 4.1, REPLACE discussion: "the indicated resource should... replace the resource where the traversal started." Which resource? The definition of "resource" allows this to mean either the single in-line link, or the entire document entity. I've seen both interpretations stated as the only possible one on this list. -=- Clause 4.2, USER discussion: surely a Web spider doesn't need "an explicit external request" to follow a link. -=- Clause 5: The language on what happens if a link's target is also a link is very wishy-washy. Without a definitive statement of where the final destination is, different implementations will have different strategies, and I won't create any links with more than one level for fear of them breaking in FooBear's HappyTime XML Client. We must decide required behavior, and specify it. -=- Clause 5: I understand the use of the attribute name HREF for backwards-compatibility, but using that attribute for things other than URLs (like IDREFs) seems overloaded. -=- Clause 5.5: The first paragraph appears to require reading DSSSL and HyTime by its language. Perhaps it should be worded, "operate on groves (as those defined in DSSSL) ... grove plan (identical to that specified in HyTime)." Or something like that. -=- Clause 5.5: This specification must be self-contained. If TEI pointers are a supported part of the XML-link specification, then a description of the supported parts of them must be in the normative section of the document, not in an informative appendix. At the least, clause 5.5 must normatively reference Appendix A; at the moment, that appendix is free-standing. -=- Clause 6.2: Coralling xlinks in one part of a document seems reasonable. But why only at the beginning? I can see why one would want to do that to prevent information loss in case of interrupted transmissions, or so links can be rendered on-the-fly, but requiring that location seems unnecessarily restrictive for existing DTDs. Any tree-based parser should be able to find the xlink corral anywhere. -Chris -- Christopher R. Maden One Richmond Square DynaText SIT Technical Support Providence, RI 02906 USA Inso Corporation +1.401.421.9550 (voice) Electronic Publishing Solutions +1.401.521.2030 (facsimile) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Rivers-Moore, Daniel" To: "'W3C-SGML-WG@w3.org'" Subject: RE: another vote for spans Date: Tue, 11 Mar 1997 10:04:01 -0000 > >>>It seems to me that the ability to point/link/target not just "that blort" >>>or >>>"blort number 3" but also "everything from blort no 3 to blort number 12" >>>is an >>>extremely useful and intuitively simple requirement. The whole point of >>>using >>>extended pointers is to cater for the unexpected, unmarked up, and not >>>necessarily hierarchically well-formed in a document, which this very simple >>>mechanism gives you, at no extra cost, as well as the ability to point to >>>entirely natural concepts like "the first six paragraphs of this book", >>>"chapters 12 to 14", etc. I don't believe that it adds much to complexity >>>of >>>implementation -- you only have to be able to proceed sequentially through >>>a >>>document from one location to another -- and it certainly doesn't add much >>>to >>>the complexity of understanding. > >>>So how about it ERB? > >>>(I would however strongly support any proposal for a less confusing pair of >>>attribute names than FROM and TO, if only I could think of them) How about STARTFROM and ENDAT BTW, may I introduce myself. I am a newcomer to this mailing list, but hope to see some of you at WWW6, where I shall be attending Jon's workshop on the Monday. Daniel Rivers-Moore Fine Line Publishing Services Lotmead Business Village Swindon SN4 0UY UK phone : +44 (0) 1793 790802 fax : +44 (0) 1793 790812 e-mail : Daniel.Rivers-Moore@flps.co.uk web site : http://www.flps.co.uk > > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 11 Mar 1997 14:41:01 +0000 (GMT) From: Peter Flynn Subject: Re: 4.5 TEI Extended Pointer Locators? To: w3c-sgml-wg@w3.org > I am ignorant of the full glory of TEI (the phrase 'p.419' is slightly > forbidding) Try "Obtaining the TEI DTD' on p.1239 :-) ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Mar 1997 10:22:07 -0500 To: W3C-SGML-WG@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: another vote for spans At 3:13 PM +0000 3/10/97, Lou Burnard wrote: > .... I would like the >ERB to reconsider its decision to disallow the spanning mechanism defined by >echte TEI x-pointers. > >It seems to me that the ability to point/link/target not just "that blort" or >"blort number 3" but also "everything from blort no 3 to blort number 12" >is an >extremely useful and intuitively simple requirement. The whole point of using >extended pointers is to cater for the unexpected, unmarked up, and not >necessarily hierarchically well-formed in a document, which this very simple >mechanism gives you, at no extra cost, as well as the ability to point to >entirely natural concepts like "the first six paragraphs of this book", >"chapters 12 to 14", etc. I don't believe that it adds much to complexity of >implementation -- you only have to be able to proceed sequentially through a >document from one location to another -- and it certainly doesn't add much to >the complexity of understanding. > >So how about it ERB? I would also like to reinforce Lou's request. This was one of my first comments on the initial draft, and it didn't generate any stinging refutations. I think we need to be able to annotate resources that we can't write on (_one_ reasong xlinks are so nice) -- and that means that there may not be a convenient element to hang the notation on. And there may be situations where an author wants to provide optional fine-grained links without clogging the inline markup with a set of tags whose only purpose is to serve as an anchor. Finally, of course, I don't see that there's that much of a problem implementing such links -- it's a _very_ simple generalization of regular xlinks. >(I would however strongly support any proposal for a less confusing pair of >attribute names than FROM and TO, if only I could think of them) Yes we do. I thought start/end might be better, but it collides with linkend. and linkendstart and linkendend is confusing! -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Mar 1997 07:36:38 -0800 To: W3C-SGML-WG@w3.org From: Tim Bray Subject: Spans, and an RFI At 03:13 PM 10/03/97 +0000, Lou Burnard wrote: >I would like the >ERB to reconsider its decision to disallow the spanning mechanism defined by >echte TEI x-pointers. For the record, no such decisions have been made. In the initial draft, Steve pulled out a TEI subset that he thought was good, I reviewed it and it seemed sensible to me, and that's what's there. The ERB has yet to take up the question of what TEI subset to use. Request for information: what TEI xptr implementations are there? And what do they implement? I'm going to be *very* reluctant to vote for anything, no matter how cool & peachy-keen, that nobody is actually using. Finally, I take very seriously the comment (from whom I forget) that the current partial-references to the large & imposing TEI docs are out of place in XML-Link - we need a subset that we can describe in our kind of page budget in a standalone way. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Tue, 11 Mar 97 14:34:21 EST To: W3C-SGML-WG@w3.org Subject: Re: Spans, and an RFI > Request for information: what TEI xptr implementations are there? And > what do they implement? Panorama (built with Synex ViewPort) implements a subset of TEI pointers fairly close to the propsed subset for XML. We do spans, too, since otherwise you can't do user annotations with them. There are samples enclosed with Panorama Pro. > Finally, I take very seriously the comment (from whom I forget) that > the current partial-references to the large & imposing TEI docs are > out of place in XML-Link - we need a subset that we can describe > in our kind of page budget in a standalone way. - Tim Well, I don't know about imposing, but I agree with this. There is no difficulty in describing TEI pointers in this way, though -- again, see the Panorama manual, or maybe I could post the relevant excerpt. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Mar 1997 14:58:30 -0500 To: W3C-SGML-WG@w3.org From: Murray Maloney Subject: XML Press Release It is with great pleasure that I submit the following: ============================================================== SoftQuad and Other Web Technology Leaders Microsoft, Sun, NCSA and Dow Jones Interactive Publishing Hail XML as the Basis of a New Generation of Web-based Knowledge Publishing Applications. Tuesday, March 11, 1997 -- San Diego, California. Today, at the Graphic Communications Association's XML conference, SoftQuad, a leading provider of content publishing tools for corporate intranets and the Internet, announced its support of a broad industry initiative to entrench eXtensible Markup Language (XML) in Web-based Knowledge Publishing tools. XML, developed by online publishing experts from industry and academia under the auspices of a World Wide Web Consortium (W3C) working group, promises to become the next significant enabling technology for the Web. XML will provide Web publishers, information consumers, and knowledge workers with unprecedented power, flexibility and control over the creation of and access to internet and intranet content. The XML working group includes members from SoftQuad, Adobe, IBM, HP, Microsoft, Lockheed Martin, NCSA, Novell, Sun, Boston University, Oxford University, and the Universities of Illinois and Waterloo. eXtensible Markup Language Will Allow For New Features Inside Smarter Client Applications XML provides a standard way of adding custom markup to information-rich documents, so that complex documents can be rendered and published in any way. Today, HTML provides a very limited way of representing and publishing structured information. While HTML is easy to use, its inherent simplicity places serious constraints on the degree to which publishers and users can utilize business-critical documents and databases. XML provides the means to publish and receive any information, regardless of format or origin, in any way that they wish. "With XML and web-based Knowledge Publishing tools, Web users will have even greater power to create, manage and access dynamic, personalized and customized content on the Web and on corporate intranets," said Murray Maloney, SoftQuad Technical Director and a member of the W3C working group responsible for the XML specification. "And with XML, end users will be able to dynamically manipulate documents in the browser, creating a whole new paradigm for presenting highly targeted and dynamic web-based information." XML makes this possible by allowing information providers to encode data using a markup language that is designed to meet their business requirements. In effect, businesses will be able to distribute structured databases that consumers can manipulate at will. Dynamic processing on a Web browser will dramatically reduce the network delays that the current breed of server solutions have caused. "XML is poised to solve the problem of integrating structured information, such as that in SQL databases, into the fabric of Web pages," said John Ludwig, VP of Internet Client & Collaboration Division, Microsoft. "Knowledge consumers will now have immediate, personalized access to information that customizes itself on the fly to suit their specific needs." For example, a single mouse click might transform overall sales figures from a database into an annual report, or into a pie chart showing regional breakdown or a bar graph showing a breakdown of products sold. XML, together with dynamic HTML, CSS, Java and other Web technologies, make almost anything possible. Industry Leaders SoftQuad, Microsoft, NCSA, Sun, and Dow Jones Interactive Publishing Share Vision of Dynamic Content for the Web. "We're very excited about this new Web initiative," said David Gurney, Chief Executive Officer, SoftQuad International. "By implementing XML technology in SoftQuad's Knowledge Publishing tools, we broaden our ability to offer customers strong, integrated publishing solutions that can tap the corporate knowledge base in ways that no other solutions can, making corporate intranets richer, more active sources of information." "As a leader in the effort to bring the advantages of structured data to Web publishing, Sun applauds SoftQuad's commitment to XML-based product development," said Jon Bosak, SunSoft's Online Information Technology Architect and Chairman of the W3C working group responsible for the XML specification. "Standardized extensible markup makes possible a new generation of Web applications that use richly structured data to exchange information and drive Java programs. SoftQuad's initiative represents the first wave of what we expect to become a large and important body of high-level applications based on the XML model of data representation." "Microsoft is excited by SoftQuad's initiative in promoting the development of eXtensible Markup Language to enable dynamic content on the Web," said John Ludwig, VP of Internet Client & Collaboration Division, Microsoft. "XML is a powerful means to provide data awareness, giving users the ability to manipulate and input data efficiently, with minimal load on the server. The result will be faster, richer and more interactive information on the Web." "As developers of the NCSA Mosaic(tm) web browser, and long-time supportersof research on the World Wide Web, NCSA is very excited that SoftQuad hascommitted to providing support for the eXtensible Markup Language," said Larry Smarr, Director. "XML is a simple, truly extensible method for creating arbitrary structured markup, yielding an enormous potential for businesses and institutions to supply more sophisticated and usable structured content on the World Wide Web." "At The Wall Street Journal Interactive Edition, we've had to deal with a host of proprietary extensions to HTML in order to make use of new features in Web browsing and casting software," said Alan Karben, Manager, Multimedia, The Wall Street Journal Interactive Edition. "With the advent of XML I hope will come an acknowledgment in the industry that one doesn't have to shoehorn new tags into a quasi-HTML framework to create useful and novel Web client applications. What XML stands for, eXtensible Markup Language, can actually mean more for Internet users than new ways to make information look pretty. Maintaining the intelligence of documents all the way to the point of delivery allows for new features inside smarter client applications. And that's exciting news for Web publishers and surfers alike." About SoftQuad SoftQuad is the leading provider of multi-platform, standards-based Knowledge Publishing applications that enhance business processes. SoftQuad is recognized worldwide for its pioneering work in structured document publishing and, through its newly-acquired Alpha Software unit, structured databases. SoftQuad is a founding member and active participant in the World Wide Web Consortium, the Internet Engineering Task Force and Editorial Review Boards. Based in Toronto, Canada, SoftQuad International employs more than 200 people with additional sales offices across North America, and European operations based in London, with offices in Paris and Munich. Electronic access to SoftQuad's press materials can be accessed at http://www.softquad.com/press/ and through Newsdesk International at http://www.newsdesk.com or 1-800-636-6092. Forward-looking statements in this release are made pursuant to the safe harbor provisions of the Private Securities Litigation Reform Act of 1995. Investors are cautioned that all forward-looking statements involve risk and uncertainties, including without limitation risks of intellectual property rights and litigation, risks in technology development and commercialization, risks in product development and market acceptance of and demand for the Company's products, risks of downturns in economic conditions generally, and in the software application development tools and business intelligence tools markets specifically, risks associated with competition and competitive pricing pressures, risks associated with foreign sales and high customer concentration and other risks detailed in the Company's filings with the Securities and Exchange Commission. Murray Maloney Technical Director SoftQuad Inc. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 11 Mar 1997 22:22:43 +0000 (GMT) From: Peter Flynn Subject: Re: XML Press Release To: Murray Maloney Cc: W3C-SGML-WG@w3.org At 14:58 11/03/97 -0500, you wrote: >It is with great pleasure that I submit the following: > >============================================================== >SoftQuad and Other Web Technology Leaders Microsoft, >Sun, NCSA and Dow Jones Interactive Publishing >Hail XML as the Basis of a New Generation of Web-based >Knowledge Publishing Applications. Very nice. Is this text in the Web somewhere and should I point to it from the XML FAQ? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Mar 1997 16:32:06 -0600 (CST) From: Robin Cover To: w3c-sgml-wg@w3.org Subject: Re: XML Press Release Cc: murray@sq.com, robin@ACADCOMP.SIL.ORG Peter Flynn asked about the XML Press Release from SQ: Very nice. Is this text in the Web somewhere and should I point to it from the XML FAQ? ///Peter For now, see: http://www.sil.org/sgml/softQuadXML.html I HTML-ified the text and made a link from the SGML "What's New" Page. -robin ------------------------------------------------------------------------- Robin Cover Email: robin@acadcomp.sil.org 6634 Sarah Drive Dallas, TX 75236 USA >>> The SGML Web Page <<< Tel: +1 (972) 296-1783 (h) http://www.sil.org/sgml/sgml.html Tel: +1 (972) 708-7346 (w) FAX: +1 (972) 708-7380 ========================================================================= %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Mar 1997 16:23:55 -0600 From: Len Bullard To: Peter Flynn CC: Murray Maloney , W3C-SGML-WG@w3.org Subject: Re: XML Press Release Peter Flynn wrote: > > Very nice. Is this text in the Web somewhere and should I point to > it from the XML FAQ? Language FAQs should not point to press announcements from vendors. No disrespect, but that is the fastest way to get a rumor going that Softquad or any of the vendors listed as supporting XML have *unholy* influence, etc. Eschew hegemonies real or perceived. What we know, we know. What we do, we have to explain. Otherwise, Reagan would be in prison playing canasta with Norriega. :-) len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Mar 1997 16:25:31 -0600 From: Len Bullard To: Robin Cover CC: w3c-sgml-wg@w3.org, murray@sq.com Subject: Re: XML Press Release Robin Cover wrote: > > Peter Flynn asked about the XML Press Release from SQ: > > > Very nice. Is this text in the Web somewhere and should I point to > it from the XML FAQ? > > ///Peter > > > For now, see: > > http://www.sil.org/sgml/softQuadXML.html > > I HTML-ified the text and made a link from the SGML "What's New" > Page. > > -robin That's the right way to do it. Link the XML FAQ to the What's New page. Tidy, and one level of Politically Correct indirection. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Mar 1997 22:22:12 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: W3C-SGML-WG@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: XML Press Release As a follow-up to the SoftQuad press release, this interesting item >from the XML conference: Microsoft stated publicly that they have two programmers working full time on XML implementation. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Christopher R. Maden" Date: Wed, 12 Mar 1997 15:40:58 GMT To: w3c-sgml-wg@w3.org Subject: Stylesheet association There's been a fair bit of talk on xml-dev about how to associate a stylesheet with a document (James Clark and Terry Allen, at least, have been involved). It occurs to me that this is pretty simple with one addition to the linking spec. Right now, there are no predefined values for the role attribute of a locator. If the predefined value "xml-style" or "xml-stylesheet" is allowed, this indicates that the destination is a stylesheet. An xlink can be used to associate multiple possible stylesheets with a document. This method allows an XLG to associate stylesheets with read-only documents. In the simplest model, the root element of the document would be linked to one or more stylesheets. For more flexibility, other elements could also be linked; if this happened, the user agent could switch to the specified stylesheet for that element. I'm leery of that behavior, though, because it should either be required or forbidden, and requiring it seems too complex for now. Maybe in 2.0. -Chris P.S. I've seen good mentions of XML on the 'net from people totally uninvolved with the WG or even with xml-dev. On the Lynx Developers' list, someone said: I am just starting to find serious articles discussion the next generation markup language, XML, around in various public journals. I was wondering if anyone on this mailing list has begun thinking about the potential impacts this may have on lynx. And on the HTML Working Group of the W3C, someone said: I think you're after XML and proper SGML on the web. Join the queue! -- Christopher R. Maden One Richmond Square DynaText SIT Technical Support Providence, RI 02906 USA Inso Corporation +1.401.421.9550 (voice) Electronic Publishing Solutions +1.401.521.2030 (facsimile) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Mar 1997 09:02:42 -0800 From: Terry Allen To: crm@eps.inso.com, w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Chris Maden writes: | There's been a fair bit of talk on xml-dev about how to associate a | stylesheet with a document (James Clark and Terry Allen, at least, | have been involved). It occurs to me that this is pretty simple with | one addition to the linking spec. | | Right now, there are no predefined values for the role attribute of a | locator. If the predefined value "xml-style" or "xml-stylesheet" is | allowed, this indicates that the destination is a stylesheet. An | xlink can be used to associate multiple possible stylesheets with a | document. This method allows an XLG to associate stylesheets with | read-only documents. Works for me. This XLG would be in a document other than the read-only document. Extending this idea, this other document could also contain all the mappings between xmllink and the read-only document's GIs and attribute names (which means that the read-only document need not use the xmllink reserved names), and even a summary of all the GIs in the read-only document that are EMPTY. That would enable XML (or at least the read-only document) to do without the syntax, and potentially make many existing SGML documents valid XML documents. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Wed, 12 Mar 97 12:57:23 EST To: crm@eps.inso.com, tallen@sonic.net, w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Terry Allen wrote: > Chris Maden writes: [...] > | An xlink can be used to associate multiple possible stylesheets with a > | document. This method allows an XLG to associate stylesheets with > | read-only documents. > > Works for me. [...] this other document could also contain > [...] a summary of all the GIs in the read-only document that > are EMPTY. That would enable XML (or at least the read-only document) > to do without the syntax, and potentially make many existing > SGML documents valid XML documents. No -- that would mean that you could only parse XML documents if you could parse the xlinks in this external document, so the document would have to become part of the base XML spec, making that language more complex. This has all been discussed ad infinitum in the XML WG list, and the current draft XML syntax for EMPTY elements is a compromise with good reasons. I (reluctantly) refer you to the archive... The issue of existing SGML documents being valid XML is also much more complex than just changing to , and needs the use of a tool like James Clark's SPAM anyway -- which could easily add the / in empty elements' tags. Any more on this probably belongs on the XML list, or in private mail! Lee -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com/ | the barefoot programmer %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Mar 97 14:00:03 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Link draft: 5.2 location source After reading this a haf dozen times, I think I understand it, though I still don't see the utility of "referrer" (so a link can refer to a treeloc that can point back into the link itself?). But in any case, I submit that we need to do something to the XML-link spec to make this section clearer. (And I'm also still awaiting a respone to Terry's message on this.) > From: "W. Eliot Kimber" > > At 05:10 PM 3/8/97 CST, Paul Grosso wrote: > >In the May 5 XML Link draft, section 5.2, location source: > > > >I don't understand "referrer". I don't know how to interpret > >"the non-link element that refers to the link element." I assume > >"link element" should read "linking element" (ref. section 1.3), > >but I didn't know the linking element was necessarily referred to > >by anything. Can someone please explain this to me? > > In HyTime, the "referrer" is the non-*location address* element that refers > to a location address. The distinction is necessary because the location > source for a location address element may either be the referrer or defined > by the referrer. However, only the top rung of a location ladder can have > a default location source, and since the top rung will be referred to by > the rung below it (unless the ladder consists of exactly one location > address), we can't talk about any element referring to the location address. > > Consider this HyTime (TC) example: > > > 1 2 > > The treeloc addresses the second child of its location source, which is the > referrer element (the Link), thus it addresses the element B. In this case > there is exactly one step in the location path from the Link element to its > ultimate target, so the element that refers directly to the treeloc is also > the element that makes the initial reference to the location path the > treeloc is in (because there is only one step in the path, the treeloc). > > . . . > Date: Sat, 8 Mar 1997 17:22:30 -0800 > From: Terry Allen > > . . . > > Eliot writes: > | Consider this HyTime (TC) example: > | > | > | 1 2 > | > | The treeloc addresses the second child of its location source, which is the > | referrer element (the Link), thus it addresses the element B. In this case > | there is exactly one step in the location path from the Link element to its > | ultimate target, so the element that refers directly to the treeloc is also > | the element that makes the initial reference to the location path the > | treeloc is in (because there is only one step in the path, the treeloc). > > Which is the location source for treeloc in the following? > > > > 1 2 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Mar 97 13:42:52 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: XML interchange [was Re: Stylesheet association] Several of us were talking yesterday at the GCA XML conference about the fact that one of the biggest problems with SGML is still with what's supposed to be one of its key goals: interchange. It is still way too hard to hand off to someone all the various files associated with an SGML application in such a way that the recipient can easily reconstruct it. SDIF has existed for years, SGML Open's TR9401 made a simple stab at addressing this in its "Issue B: an interchange packaging scheme", and then the MIME-SGML work was another attempt to standardize this, but there appears to be no interoperably accepted solution. Some of us feel this is such an important issue that perhaps it should be the "fourth phase" of the XML effort. Notice that this issue goes way beyond associating a style sheet, and I think any XML effort to associate anything with anything will naturally get us into all these issues, so perhaps we should face them head on. > From: Terry Allen > > Chris Maden writes: > | There's been a fair bit of talk on xml-dev about how to associate a > | stylesheet with a document (James Clark and Terry Allen, at least, > | have been involved). It occurs to me that this is pretty simple with > | one addition to the linking spec. > | > | Right now, there are no predefined values for the role attribute of a > | locator. If the predefined value "xml-style" or "xml-stylesheet" is > | allowed, this indicates that the destination is a stylesheet. An > | xlink can be used to associate multiple possible stylesheets with a > | document. This method allows an XLG to associate stylesheets with > | read-only documents. > > Works for me. This XLG would be in a document other than the read-only > document. Extending this idea, this other document could also > contain all the mappings between xmllink and the read-only document's > GIs and attribute names (which means that the read-only document > need not use the xmllink reserved names), and even a summary of > all the GIs in the read-only document that are EMPTY. That would > enable XML (or at least the read-only document) to do without the > syntax, and potentially make many existing SGML documents > valid XML documents. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Mar 1997 16:47:46 -0600 From: Len Bullard To: Paul Grosso CC: w3c-sgml-wg@w3.org Subject: Re: XML interchange Paul Grosso wrote: > > Several of us were talking yesterday at the GCA XML conference > about the fact that one of the biggest problems with SGML is > still with what's supposed to be one of its key goals: interchange. With the caveat that it is actually easy to interchange an SGML document; it is hard to interchange all the other pieces needed by the application that processes it. It isn't hard to package it; it's hard to know what goes in the package. In an of itself, XML doesn't change anything except having *enticed* the SGML community to sit down and make agreements about this without CALS telling us we have to. > It is still way too hard to hand off to someone all the various files > associated with an SGML application in such a way that the recipient > can easily reconstruct it. SDIF has existed for years, SGML Open's > TR9401 made a simple stab at addressing this in its "Issue B: an > interchange packaging scheme", and then the MIME-SGML work was another > attempt to standardize this, but there appears to be no interoperably > accepted solution. Some of us feel this is such an important issue > that perhaps it should be the "fourth phase" of the XML effort. Keep the list alive. It has value waaaaay beyond this year. Make the agreements here. Even COM/OLE is only a contract; it is just backed up with running code. > Notice that this issue goes way beyond associating a style sheet, > and I think any XML effort to associate anything with anything will > naturally get us into all these issues, so perhaps we should face > them head on. Violent agreement here. We have lived through ten years of CALS and we all know how much of that time was spent defining 1840 which was really just a way to package a nine-track tape. If we insist on the separation of process and data, if we insist that style is not part of content, but we know that presentation and document management are the selling pieces, then for pity's sake, yes, let's do this up front and head on. We know it is needed. That said, an obvious but sometimes confused issue: document management, document production, and document navigation aren't the same things. I say this because in IETMs, this has not always been clear and when we start managing link sets and named relationships, it becomes more blurry. len bullard lockheed martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Mar 97 16:42:38 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: those predeclared entity refs Section 2.4 of the XML-lang draft has text that says that & and < must be represented using the strings "&" and "<" (sic wrt missing sentence ending punctuation) Section 4.2 discusses entity declarations in such a fashion that it does not rule out the possibility of declarations such as: I would think a user wishing to embed a "<" character into this XML document would be much better served by using &lessthan;, but per section 2.4, they *must* use < instead. I know we talked in the WG about whether these predeclared entity refs could be redeclared or not, but I can't find any such words in the draft spec (and I can't find any reference to a final decision on this point). What seems missing from the spec are some words that either say you cannot redefine the five special entities or words in 2.4 that say you can use different refs to get < and &. Personally, I'd prefer to be able to redeclare the predeclared entities, but I could live with not being able to do this is that's the decision that's been made. Then we need to say something like "the pre-declaration of those 5 entities effectively occur before any of the markup declarations are processed so that any attempted explicit declaration of them would be superceded by the pre-declaration and would therefore have no effect." What was the decision on this and am I right that the spec needs clarification in this area? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Wed, 12 Mar 97 18:50:32 EST To: w3c-sgml-wg@w3.org Subject: Re: XML interchange [was Re: Stylesheet association] Paul Grosso wrote: > It is still way too hard to hand off to someone all the various files > associated with an SGML application in such a way that the recipient > can easily reconstruct it. SDIF has existed for years, SGML Open's > TR9401 made a simple stab at addressing this in its "Issue B: an > interchange packaging scheme", and then the MIME-SGML work was another > attempt to standardize this, but there appears to be no interoperably > accepted solution. Some of us feel this is such an important issue > that perhaps it should be the "fourth phase" of the XML effort. Sorry for the long quote... I agree with this. One of the difficulties has always been defining the requirements. Mime-SGML (as I see it) derailed itself by having two proposals, one that required changes to mailers and gateways (politically difficult) and one that was less technically elegant. Having said that, HTML browsers have raised the water level, because of progressive concurrent rendering. Anyone who has used the Opera browser under windows [1] has seen how fast it is... it fetches up to 20 things concurrently, with up to 8 connections to any given server. An XML packing scheme probably ought to allow random-access fetching. Perhaps there will be other requirements for XML, that we have yet to discern. So yes, by all means let's work on this, and, as you say, let's leave it until after the current items are all dealt with., and preferably until we have some deployment experience, at least in the labs. Lee References: [1] http://opera.nta.no/ -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com/ | the barefoot programmer %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Mar 1997 17:54:36 -0800 From: Terry Allen To: crm@eps.inso.com, lee@sq.com, tallen@sonic.net, w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Lee writes: >No -- that would mean that you could only parse XML documents if you could parse the xlinks in this external document, so the document would have to become part of the base XML spec, making that language more complex. I don't understand this remark (and I did follow the WG's iscussion of EMPTY, and I do have a lot of sympathy for the result). An XML-compliant application will have to be able to parse xmllinks, won't it? Or are you envisioning applications that can parse XML but not xmllinks? Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html >From w3c-sgml-wg-request@w3.org Wed Mar 12 10:01:00 1997 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by sub.sonic.net (8.8.5/8.7.3) with SMTP id KAA09294 for ; Wed, 12 Mar 1997 10:00:53 -0800 Received: by www19.w3.org (8.6.12/8.6.12) id MAA01138; Wed, 12 Mar 1997 12:58:39 -0500 From: lee@sq.com Date: Wed, 12 Mar 97 12:57:23 EST To: crm@eps.inso.com, tallen@sonic.net, w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Status: R Terry Allen wrote: > Chris Maden writes: [...] > | An xlink can be used to associate multiple possible stylesheets with a > | document. This method allows an XLG to associate stylesheets with > | read-only documents. > > Works for me. [...] this other document could also contain > [...] a summary of all the GIs in the read-only document that > are EMPTY. That would enable XML (or at least the read-only document) > to do without the syntax, and potentially make many existing > SGML documents valid XML documents. No -- that would mean that you could only parse XML documents if you could parse the xlinks in this external document, so the document would have to become part of the base XML spec, making that language more complex. This has all been discussed ad infinitum in the XML WG list, and the current draft XML syntax for EMPTY elements is a compromise with good reasons. I (reluctantly) refer you to the archive... The issue of existing SGML documents being valid XML is also much more complex than just changing to , and needs the use of a tool like James Clark's SPAM anyway -- which could easily add the / in empty elements' tags. Any more on this probably belongs on the XML list, or in private mail! Lee -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com/ | the barefoot programmer %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Mar 1997 18:09:44 -0800 From: Terry Allen To: crm@eps.inso.com, lee@sq.com, tallen@sonic.net, w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Lee writes: >No -- that would mean that you could only parse XML documents if you could parse the xlinks in this external document, so the document would have to become part of the base XML spec, making that language more complex. I did follow the WG's discussion of EMPTY and I do have sympathy for the result. But the base XML spec was written without much consideration of how XML is to be served over the Internet, and as the rubber meets the road on the way to Santa Clara, we are seeing that additional framework is needed. The case of associating style sheets with read-only documents illustrates that it is not possible to cover all the bases by pointing out from a single XML instance to ancillary matter. The base XML spec will have (eventually) to be revised to deal with this problem. That revision will inevitably deal with a Second Part to XML instances; in the meantime implementors will be constructing solutions in the absence of a spec. Once a Second Part is admitted as necessary (and implemented) many now vexing problems will find easier solutions. is one of the worst warts on the present spec, inviting error and difficult to explain (" works fine in HTML, works fine in SGML, what's the problem?" "Conformance with SGML.") I urge the SGML ERB to devote some time *before the Santa Clara convention* to consideration of packaging and delivery. I think it will satisfy itself that XML won't get far without a Second Part, that robust XML applications will have to be able to deal with a Second Part, and that specifying the semantics, if not the syntax, of a Second Part will simplify rather than complicate the complete XML specification. Your mileage may vary. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Mar 1997 18:33:03 -0800 From: Terry Allen To: w3c-sgml-wg@w3.org Subject: Incorrect Reply to Lee ["Associating"] Please ignore the first of my two replies to Lee ("I don't understand ...") I did understand, and that reponse was sent by mistake, abetted by latency problems and fast typing. Best regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Wed, 12 Mar 97 22:48:43 EST To: w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Terry Allen wrote: >[...] Or are you envisioning applications that can parse XML > but not xmllinks? I am hoping that _most_ XML applications will parse XML but will have nothing to do with links or styles. Examples: * database export * spreadsheet save as XML * compiler intermediate file/parse tree * financial transactions * metadata records (XML version of MARC, if you will, or Dublin Core) * preferences files or anywhere else structured datea must be shared between applications. The revolution is beginning. If you're not for us, you will be soon. When the time comes, and you're up facing that wall, the black book will be empty. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 08:56:19 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: those predeclared entity refs Paul Grosso's question about the five predeclared character entities suddenly brought into focus something that has been bothering me since November but hadn't until that moment come to the front of consciousness. Back in November, we were just about to include nearly 200 predefined character entities to bring XML into alignment with HTML 4.0 when Anders Berglund pointed out that the entity names for Greek scientific characters were hopelessly mixed up with the names for the other Greek characters, and we cut back to the five that are needed to escape just those characters that have uses in markup. We rationalized this by saying that all the other characters could be referred to numerically if necessary, and that in a Unicode context any scheme that conferred special status on the couple of hundred characters that Europeans happened to find especially useful was suspect anyway. What I now realize is that the same logic applies to the remaining five as well. Assuming for a moment the most likely syntax for hex character references, we will have no less than three different ways of referring to the five syntactically meaningful characters in the absence of any user definitions: QUOTATION MARK " " " AMPERSAND & & & APOSTROPHE ' ' ' LESS-THAN SIGN < < < GREATER-THAN SIGN > > > We don't need three different ways to do this. I propose that we eliminate all problems relating to the predefined character entities by simply not having any. Here are the possible counterarguments that I can think of. Objection 1: People are used to using <, >, etc. Response: a. They are also used to using all the other ones predefined in HTML but not predefined in XML. b. They are used to using them without trailing semicolons under some circumstances; we don't allow that. Objection 2: The names quot, amp, apos, lt, and gt are significantly shorter than the corresponding numeric forms. Oops, no they're not. Forget that one. Objection 3: The names quot, amp, apos, lt, and gt are significantly easier to remember than the corresponding numeric forms. Response: Easier for people whose native language is other than English, i.e., most of humanity? I don't think so. In return for not predefining character entities we get the following benefits: 1. Language neutrality. 2. Cleaner specification. 3. Zero incursion into the user's name space for character entities. 4. Elimination of nitty objections to the names apos and quot (which we haven't talked about much but are out there). 5. Elimination of all other issues relating to predefined character entities (such as the one that Paul raised). Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 12:17:39 -0500 (EST) To: w3c-sgml-wg@w3.org (bosak@atlantic-83.Eng.Sun.COM) Subject: Re: those predeclared entity refs From: John_Lavagnino@Brown.edu I'd suggest following Jon's proposal to drop the five predeclared entity references, but also to try and work declarations of these (and perhaps others) into lots of sample XML files as they're made available, to condition the world into considering those a "standard" part of an XML DTD. In practice, that sort of thing is almost as good as having it as part of the language definition. It also provides an opportunity to puff this great XML feature that allows you to define new entities, rather than being confined to the HTML set. John Lavagnino %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: those predeclared entity refs To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Date: Thu, 13 Mar 1997 12:16:49 -0500 (EST) Cc: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com > Objection 3: > > The names quot, amp, apos, lt, and gt are significantly easier to > remember than the corresponding numeric forms. > > Response: > > Easier for people whose native language is other than English, > i.e., most of humanity? I don't think so. For those who know HTML, or almost any SGML DTD, they are. Besides, it is a false dichtomy: those more comfortable with numbers can use numbers. > In return for not predefining character entities we get the following > benefits: > > 1. Language neutrality. Overrated. What's the Japanese for " I heard this argument for the reason why OS/2 formatted floppies would report "SYSTEM ERROR: 32341" if they weren't bootable: if it isn't going to be a meaningful error message for everyone, it shouldn't be meaningful for anyone. I don't buy it. > 2. Cleaner specification. A little, but not, in my opinion worth the cost. > 3. Zero incursion into the user's name space for character entities. Who wants to override < and >? I think that anyone who does so is making a mistake, whether they are English speaking or not. It's like using "IF" as a variable name in languages that allow it: no matter what your native language you are just asking for confusions with the keyword IF and the convention that "IF" means "conditional" no matter what your native language is. Many programming languages invented by non-English speakers use the conventional keywords -- they are magic strings -- like "car" and "cdr" in Lisp. They were meaningful to a particular set of people at a particular time and it doesn't make sense to change them now. Calling them numbers would not have helped. > 4. Elimination of nitty objections to the names apos and quot (which > we haven't talked about much but are out there). I'm not as tied to those names as to <, & and to a lesser extent >, so if they really are contraversial, I would agree to dump them. > 5. Elimination of all other issues relating to predefined character > entities (such as the one that Paul raised). For the usability cost for those familiar with HTML and other DTDs, I would rather just solve the issues. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 09:30:43 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: those predeclared entity refs [Paul Prescod:] | > Objection 3: | > | > The names quot, amp, apos, lt, and gt are significantly easier to | > remember than the corresponding numeric forms. | > | > Response: | > | > Easier for people whose native language is other than English, | > i.e., most of humanity? I don't think so. | | For those who know HTML, or almost any SGML DTD, they are. Besides, it is a | false dichtomy: those more comfortable with numbers can use numbers. The number of people who are familiar with *anything* now is insignificant compared to the number of people who will be working with these languages five years from now. | > In return for not predefining character entities we get the following | > benefits: | > | > 1. Language neutrality. | | Overrated. What's the Japanese for " Apples and oranges. " Subject: Re: those predeclared entity refs To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Date: Thu, 13 Mar 1997 12:59:22 -0500 (EST) Cc: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com > The number of people who are familiar with *anything* now is > insignificant compared to the number of people who will be working > with these languages five years from now. If current trends continue, the majority of them will be English speakers, though not necessarily native English speakers. That isn't an argument for language bigotry, but for suggesting that it *may* still be more intuitive to most page authors five years from now than (seemingly random) numbers. Anyhow, five years from now is a LONG TIME. What do we know about five years >from now: do they still edit XML text by hand? Do they still use a few, standard DTDs, written in English? Do people write their own DTDs in their own languages but continue to use the < and > conventions because they are so universal? Did Unicode actually take off? Are programmers the only people who see "raw" XML code? > Apples and oranges. " m times per instance. Remember that XML is designed primarily for > delivery; the typical delivery scenario is one in which there is no > DTD at all. Okay then, what do "version" CDATA DOCTYPE RMD mean if I'm not an English speaker? Why are these funny double-tick mark ("") characters special? How do I know that they start and end a string? Once again, I'm not advocating that anyone be forced to use <, but that it be made easy for the majority of us now, and potentially in 5 years, who are either familiar with the convention or are English speakers (native or not). Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 13:14:57 -0500 (EST) From: Sam Hunting To: Paul Prescod cc: Jon Bosak , w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs > If current trends continue, the majority of them will be English speakers, > though not necessarily native English speakers. That isn't an argument > for language bigotry, but for suggesting that it *may* still be more intuitive > to most page authors five years from now than (seemingly random) numbers. If people should not be asked to pay ISO for an expensive standard, they surely should not have to buy a Unicode book to look up these numbers -- this to whoever suggested "simply flipping to the page of the Unicode book" to decipher the number. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: those predeclared entity refs To: John_Lavagnino@Brown.edu Date: Thu, 13 Mar 1997 17:44:19 -0500 (EST) Cc: w3c-sgml-wg@w3.org > And if you're going to > show XML documents to people and try to talk them into using the > scheme, then making it possible for them to grasp what's going on > without needing to read the documentation first is a strong persuasive > strategy. I want to emphasize John's point that short term concerns should take precedence on this issue. Five extra pre-defined and perhaps overridable entities won't hurt XML in 5 years. Maybe we'll look back critically at our Anglo-centrism, but I can live with that. I'll already be doing penance for the environment and the plight of the Ogoni. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Thu, 13 Mar 97 18:37:31 EST To: w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs Paul Prescod wrote > [...] Five extra pre-defined and perhaps overridable > entities won't hurt XML in 5 years. I could live with the idea of having only ampersand and lt defined. (I don't like amp particularly since for anyone who has done any physics or electronics, it obviously ought to represent an "A"). Perhaps we also need apostrophe and grave accent. Note that there is no single quote in ASCII, as ' is an apostrophe and ` is a grave accent. The typewriter doube quote (") makes the fifth, right? amp ampersand & lt left angle bracket < quot grave accent ` apos apostrophe ' dquot typewriter double quote " That makeds five; do we also need gt right angle brcket > or ket right bracket ] for quoting the end of a marked section? (]]>) The minimal set seems to be ampersand and left angle bracket. Can these already be quoted with their delimiter names, as in &#ERO; and so on? SGML allows that. I like that, as it makes clear why you are ding the quoting, although it's pretty hard to explain the strange names. I don't see a need for more than ampersand and lt, and I accept that some people will prefer the confusing "amp" name to "ampersand". So I propose a compromise: just two entities, amp and lt. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 16:30:00 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: those predeclared entity refs [Sam Hunting:] | If people should not be asked to pay ISO for an expensive standard, | they surely should not have to buy a Unicode book to look up these | numbers -- this to whoever suggested "simply flipping to the page of | the Unicode book" to decipher the number. Whom are you quoting? I can't recall anyone having made that statement. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 16:28:32 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: those predeclared entity refs [Paul Prescod:] | > The number of people who are familiar with *anything* now is | > insignificant compared to the number of people who will be working | > with these languages five years from now. | | If current trends continue, the majority of them will be English | speakers, though not necessarily native English speakers. Your estimate of the future proportion of non-English-speaking Internet users differs significantly from mine. | Anyhow, five years from now is a LONG TIME. What do we know about five | years from now: do they still edit XML text by hand? Yes. | Do they still use a few, standard DTDs, written in English? No. | Do people write their own DTDs in their own languages They invent tags in their own languages. Most of them don't know what a DTD is and don't care. | but continue to use the < and > conventions because they are so | universal? Depends on what we decide. | Did Unicode actually take off? If it didn't, we're toast. The XML character set is based on the assumption that Unicode takes off. | Are programmers the only people who see "raw" XML code? No. But with few exceptions they will be the only ones who need to put in a character entity by hand. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 17:52:13 -0800 (PST) From: altheim Subject: Re: those predeclared entity refs To: lee@sq.com Cc: w3c-sgml-wg@w3.org Lee writes: > The minimal set seems to be ampersand and left angle bracket. > Can these already be quoted with their delimiter names, as > in &#ERO; and so on? SGML allows that. I like that, as it makes > clear why you are ding the quoting, although it's pretty hard to > explain the strange names. I'm not sure quite what you mean by 'quoted.' I think the names seem strange in that it isn't the 'direct English' of 'amp' or 'lt'. If it were available as an option, I'd much prefer using character references in this form, since a. we are really only using them to escape special characters in SGML, so most if not all are declared in the reference delimiter set (Goldfarb, p. 360) b. if the reference delimiter is changed, (eg., '<' to 'foo') then the entity reference ('&#ERO') changes with it c. they are as 'language-neutral' as SGML, rather than specifically English acronyms d. they are well-defined (ie.,8879) But from what I can gather, they can't be used in a document instance. nsgmls returns an error such as "ERO" is not a function name so I'm gathering this option is not available. Too bad though. > I don't see a need for more than ampersand and lt, and I accept that > some people will prefer the confusing "amp" name to "ampersand". > > So I propose a compromise: just two entities, amp and lt. I'd certainly be happy with several such as you mention, but logically to me it seems better if we don't define any at all, insofar as they aren't formally declared in DTD-less documents unless a default ENTITIES document is invisibly included. And then, we're not compatible with SGML. Murray ........................................................................... Murray Altheim, SGML Grease Monkey Tools Development & Online Production Sun Microsystems, 2550 Garcia Ave., MS UMPK17-102, Menlo Park, CA 94043 USA "Give a monkey the tools and he'll build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Thu, 13 Mar 97 21:17:59 EST To: w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs Cc: v@sq.com h One thing this discussion seems to be missing is that ' and ' are not equivalent. Consider the following example: ">' > %boy; %Liam; ]> ginger curly hair, bare feet, broad smile - &Liam.name; This produces the following nsgmls output: (BOY -ginger curly hair, bare feet, broad smile - I am Liam. )BOY C Notice how the ' is interpreted as delimiting an entity value. Now, how do you change I am %boy-name;. to say I am Andrew's brother without using '? You can't include a " or a ', neither with &# nor directly, because they would end one or other parameter entity literal. This example may appear very obscure. I could give a larger example in which it would no longer be obscure, as can Eliot and Michael and Lou and others: IBMIDDOC, TEI, Davenport all use nested parameter entity deifintions. If you take out the nested definition, you can (with some SGML parsers) get one more level of nesting. Note that you can't do &#39; (like doing \\' in Unix shell scripts) because of the implicit Ee after $#38; -- or at least, I assume that's why it doesn't work. ">' > does what I want: (BOY -ginger curly hair, bare feet, broad smile - I'm Liam. )BOY C Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 13 Mar 1997 20:00:14 +0000 (GMT) From: Peter Flynn Subject: Re: those predeclared entity refs To: w3c-sgml-wg@w3.org At 16:42 12/03/97 -0600, Paul Grosso wrote: >Section 2.4 of the XML-lang draft has text that says that & and < > must be represented using the strings "&" and "<" > (sic wrt missing sentence ending punctuation) > >Section 4.2 discusses entity declarations in such a fashion that >it does not rule out the possibility of declarations such as: > > [...] >What was the decision on this and am I right that the spec needs >clarification in this area? Yes. I had a medical user last year wanting to define element sets for five classes of acute medical need, called aacute, bacute, ... eacute. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 13 Mar 1997 20:00:12 +0000 (GMT) From: Peter Flynn Subject: Re: XML interchange To: w3c-sgml-wg@w3.org At 16:47 12/03/97 -0600, Len Bullard wrote: >Paul Grosso wrote: >> >> Several of us were talking yesterday at the GCA XML conference >> about the fact that one of the biggest problems with SGML is >> still with what's supposed to be one of its key goals: interchange. > >With the caveat that it is actually easy to interchange an SGML >document; it is hard to interchange all the other pieces needed >by the application that processes it. It isn't hard to package it; >it's hard to know what goes in the package. Couldn't some parser author add an option to spit out a list of the filenames used in parsing an instance? Say nsgmls -Z produces teisgml.dec foo.sgml teifpi2.ent ... tei2.dtd teicore2.dtd ... isolat1.ent (complete paths where relevant) in a form you could pipe into tar or zip? Or a list of the FPIs instead/as well? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 19:55:07 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs Jon Bosak wrote: > | but continue to use the < and > conventions because they are so > | universal? > > Depends on what we decide. If < and & are so non-intuitive and hard to learn, people will replace them in their own language and no harm will have been done. They will be universal only in that the are universally supported by software. > | Did Unicode actually take off? > > If it didn't, we're toast. The XML character set is based on the > assumption that Unicode takes off. XML explicitly allows other encodings, as long as the characters you need exist somewhere in Unicode. Unicode doesn't need to take off for XML to succeed, though character entity handling would be pretty hit and miss if it doesn't. But that's no worse than the current situation with both HTML and SGML, and those seem to be successful. Better not to tie XML's success to the single issue of charcter entity handling. > | Are programmers the only people who see "raw" XML code? > > No. But with few exceptions they will be the only ones who need to > put in a character entity by hand. So if in five years only programmers put in character entities by hand, who cares what they are called underneath? Right now the Web is dominated by English, English speakers will dominate the software teams that decide whether to implement XML or not. We don't need to give Marc Andreeson reasons to ignore XML: "too hard < doesn't even do what you would expect it to." Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 15:37:48 -0500 (EST) To: w3c-sgml-wg@w3.org (bosak@atlantic-83.Eng.Sun.COM) Subject: Re: those predeclared entity refs From: John_Lavagnino@Brown.edu | | [John Lavagnino:] | | | I'd suggest following Jon's proposal to drop the five predeclared | | entity references, but also to try and work declarations of these (and | | perhaps others) into lots of sample XML files as they're made | | available, to condition the world into considering those a "standard" | | part of an XML DTD. In practice, that sort of thing is almost as good | | as having it as part of the language definition. | | [Jon Bosak:] | | Why bother? If "&" is a magic string (as Paul Prescod has pointed | out, and I agree with him), why urge it over the equally magic string | "&"? If I don't speak English, the second is as easy to remember | as the first, and it has the very significant advantage that I can | find out what it means my looking it up in the Unicode table. Well, then GIs are magic strings too. I'd go along with your line on this to the extent of saying that an example not in English certainly ought to use entity names that are appropriate for the language of the example. On Unicode numbers, I can only say that if I'm going to have to look at the encoding in this way, rather than having it obligingly hidden by an editor, I'd greatly prefer to see something like LATIN SMALL LETTER A WITH MACRON, or even ā, rather than &U-0101;. I think magic names with some family resemblance to a description of the character will be, for most people, easier to recognize or remember than the magic numbers of the Unicode scheme. And if you're going to show XML documents to people and try to talk them into using the scheme, then making it possible for them to grasp what's going on without needing to read the documentation first is a strong persuasive strategy. John Lavagnino %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 14:24:25 -0600 From: Len Bullard To: Peter Flynn CC: w3c-sgml-wg@w3.org Subject: Re: XML interchange Peter Flynn wrote: > > At 16:47 12/03/97 -0600, Len Bullard wrote: > >Paul Grosso wrote: > >> > >> Several of us were talking yesterday at the GCA XML conference > >> about the fact that one of the biggest problems with SGML is > >> still with what's supposed to be one of its key goals: interchange. > > > >With the caveat that it is actually easy to interchange an SGML > >document; it is hard to interchange all the other pieces needed > >by the application that processes it. It isn't hard to package it; > >it's hard to know what goes in the package. > > Couldn't some parser author add an option to spit out a list of > the filenames used in parsing an instance? Say nsgmls -Z produces > > teisgml.dec > foo.sgml > teifpi2.ent > ... > tei2.dtd > teicore2.dtd > ... > isolat1.ent > > (complete paths where relevant) in a form you could pipe into tar or zip? > Or a list of the FPIs instead/as well? Yes that is possible. That wasn't my point although it is an excellent suggestion. We could not say before what a stylesheet was. We could not guarantee what would be in a catalog. We could not get two experts to agree on what a hyperlink should have in it. (ok... the last bit is still a problem, but has boundaries now). The problem has not been a technical one but one in which there have been many competing and variant approaches to the stylesheets, the links, the catalogs, etc. We already have systems for SGML based on strongly typed links, automated stylesheets, well-formed content, etc. What we have never had before was agreements among ourselves that stayed in place long enough to establish common practice. XML is where the SGML community has been working these things out. Noisy, yes; productive, very much so. Certainly we have been an arbitrary lot at times, but the more compelling problem has been we have been driven by other strong forces. The remark by Paula Angerstein, "well, more charity work for DoD" always sticks in my mind. American SGML was hard driven by CALS for a long time. That was a very big bureaucracy. It resulted in some excellent work, but it tended toward standard DTDs and that wasn't enough. Further, it was driven by requirements that weren't always generalizable. The IETM standards are a good example. It was driven by overconcern for print and presentation, and sometimes, by a lack of concern for that. What is different here is that XML is happening because WE wish it to. Not customers, not the government, not academic requirements, not the Web, none of these: this WG is made up of committed SGML professionals: top dogs, creme de la creme. We are the ones who care, and we are doing this using a media that allows us to come together daily, hourly, sometimes minute to minute. Where it may be contentious, it is our contention. Where it may be successful, it is our success. Don't forget that. To paraphrase what the man says at the end of the X-Files episodes, "We made this." It isn't a revolution: it is an emergence. SGML has been like watching an elephant give birth: long pregnancy but a big baby. What Paul has suggested is very right. There is another piece of this that has to be done, so why we are under the house fixing the plumbing, let's go ahead and tighten up the pipes. Nice thing about internet lists; at the end of the week, no one goes home. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Mar 1997 21:49:05 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Microsoft bases two proposals on XML Web Collections: http://www.w3.org/pub/WWW/Submission/1997/2/Overview.html Channel Definition Format: http://www.w3.org/pub/WWW/Submission/1997/3/Overview.html http://www.microsoft.com/corpinfo/press/1997/Mar97/Cdfrpr.htm Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 08:47:03 -0500 To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: those predeclared entity refs Cc: bosak@atlantic-83.eng.sun.com At 9:30 AM 3/13/97, Jon Bosak wrote: > & occurs >m times per instance. Remember that XML is designed primarily for >delivery; the typical delivery scenario is one in which there is no >DTD at all. Much as I hate to admit it, this is the one reason why one might wish to prdefine some special-character entities rather than letting each DTD designer define them--you'd *have* to read the DTD. :-( Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 08:46:54 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: Stylesheet association At 6:09 PM 3/12/97, Terry Allen wrote: > >is one of the worst warts on the present spec, inviting error >and difficult to explain (" works fine in HTML, >works fine in SGML, what's the problem?" "Conformance with SGML.") Cheap shot? It's not conformance with SGML that's the problem. It's that with HTML we have, if not a fixed set of element types, at least a short-term-fixed set of element types declared EMPTY. Since those types are known ahead of time by name, that much of the "HTML DTD" is built into every HTML parser. It's the fact that XML wants to continue to permit EMPTY element types, doesn't want to pre-specify their names, and wants to parse without reference to a DTD that forces XML to differentiate between the tag for empty elements that don't use an end-tag and the start-tag of elements that do use end-tags. Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 10:05:08 -0500 To: lee@sq.com, w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: those predeclared entity refs At 6:37 PM 3/13/97, lee@sq.com wrote: >Perhaps we also need apostrophe and grave accent. Note that there >is no single quote in ASCII, as ' is an apostrophe and ` is a grave >accent. The typewriter doube quote (") makes the fifth, right? > >amp ampersand & >lt left angle bracket < >quot grave accent ` >apos apostrophe ' >dquot typewriter double quote " > >That makeds five; do we also need >gt right angle brcket > >or >ket right bracket ] Does Unicode or 10646 really define "<" and ">" as left and right angle brackets? In most of the character sets I've seen, they are less-than and greater-than signs. And those character sets that mention angle brackets treat them as different characters. (Not to mention that they are usually associated with different glyphs in any glyph-rich font.) Same question about "`". Really just a stand-alone accent? What authority says that the " entity is "`"? I always thought it was "'". For that matter, I know of systems whose character repertoires differentiate between apostrophe and single closing quote! and neither one is the "typwriter single quote" that "'" was at least originally meant to be. I assume you just made up "ket" as a name for "]"? Seems to me we don't even agree on what our "ASCII" character set really is. When you're writing a standard, you can't say "left angle bracket" when you mean "less than". You'll get different results. Besides clarifying just what characters we're talking about, there are some more important questions being glossed over in this discussion: o Do the implied entity definitions for &, <, and > (the current required set) take precedence over local ones? Currently they do. (And *currently* must, see next bullet.) o Is the user *required* to use these three to escape "&", "<", and ">", rather than any other entities he or she may have available, or even other mechanisms for escaping? As I read the Nov 96 spec, this is a requirement. I don't like it. BTW, the spec says that you are to escape "]]>" as "]]>". Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 09:26:13 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: Microsoft bases two proposals on XML Jon Bosak wrote: > > Web Collections: > http://www.w3.org/pub/WWW/Submission/1997/2/Overview.html > > Channel Definition Format: > http://www.w3.org/pub/WWW/Submission/1997/3/Overview.html > http://www.microsoft.com/corpinfo/press/1997/Mar97/Cdfrpr.htm > > Jon Nice spec. Complete with a DTD. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 08:28:51 -0800 From: Terry Allen To: davep@acm.org, w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Dave Peterson writes: | At 6:09 PM 3/12/97, Terry Allen wrote: | > | >is one of the worst warts on the present spec, inviting error | >and difficult to explain (" works fine in HTML, | >works fine in SGML, what's the problem?" "Conformance with SGML.") | | Cheap shot? It's not conformance with SGML that's the problem. | It's that with HTML we have, if not a fixed set of element types, | at least a short-term-fixed set of element types declared EMPTY. | Since those types are known ahead of time by name, that much of | the "HTML DTD" is built into every HTML parser. It's the fact | that XML wants to continue to permit EMPTY element types, doesn't | want to pre-specify their names, and wants to parse without reference | to a DTD that forces XML to differentiate between the tag for empty elements | that don't use an end-tag and the start-tag of elements that do use | end-tags. Not a cheap shot at all. My point is exactly that an XML instance without a style sheet, an applet that interprets the semantics of the GIs, a DTD, or some other document that collects that and similiar information is uninterpretable. As some other piece is required to interpret XML markup, the opportunity exists to insert a summary of EMPTY GIs there - an idea mooted last Fall in the context of PIs. I am more concerned about packaging and delivery in general than with ; I brought it up only to show that packaging and delivery have implications for aspects of XML that have already been decided - but could be reconsidered before everyone's feet are set in concrete. Now's the time. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 08:37:55 -0800 From: Terry Allen To: davep@acm.org, lee@sq.com, w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs Dave Peterson asks: | Does Unicode or 10646 really define "<" and ">" as left and right | angle brackets? In most of the character sets I've seen, they are | less-than and greater-than signs. And those character sets that | mention angle brackets treat them as different characters. (Not | to mention that they are usually associated with different glyphs | in any glyph-rich font.) Taking only <, Unicode has 003C Less-than sign 2039 Single left-pointing angle quotation mark = left pointing single guillemet [hyphenation sic] 2329 Left-pointing angle bracket = BRA 3008 Left angle bracket (in "CJK symbols and punctuation") [a case of failure to unify with 2329?] | Same question about "`". Really just a stand-alone accent? That involves Unicode's theory of combining characters; I'll leave the answer to Unicode specialists. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 10:29:56 -0600 From: Len Bullard To: Terry Allen CC: w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Terry Allen wrote: > > My point is exactly that an XML instance > without a style sheet, an applet that interprets the semantics of > the GIs, a DTD, or some other document that collects that and > similiar information is uninterpretable. I missed something here: uninterpretable by what or whom, summarized where, which packaging implications? Are you saying that because the stylesheet isn't used, that one can't know what the semantics are? That will be the case. If object encapsulation, virtual interfaces, etc. are used, you can't and that is exactly why some will prefer to do this. Inheriting the interface, not the implementation, and hiding the implementation is key to distributing objects without giving away code. I guess what I am saying is, some people think the way to maintain proprietary code is to encapsulate and deliver only exposed information. I think we shall see a lot of applications where XML is just initialization data and the stylesheets are irrelevant. > As some other piece is > required to interpret XML markup, the opportunity exists to insert > a summary of EMPTY GIs there - an idea mooted last Fall in the > context of PIs. I was just looking at the Microsoft proposals. They include a set of DTD fragments and tables to explain each. That has a number of empty tags. It was easy to read and understand. > I am more concerned about packaging and delivery in general than > with ; I brought it up only to show that packaging and > delivery have implications for aspects of XML that have already > been decided - but could be reconsidered before everyone's feet > are set in concrete. Now's the time. Ok. What implications? I must be missing the point of this in the mail avalanche. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 08:48:28 -0800 To: W3C-SGML-WG@w3.org From: Tim Bray Subject: Recent ERB work - miscellaneous More reports from the March 8 and 12 meetings. Attendence was confusing: every member of the ERB was in attendence in part, but there was a certain amount of checking in and out based on travel plans and interruptions; my notes record no dissenting votes to any of the following, but some member who missed a particular vote may choose to record a dissent: 1. The XML-LINK attribute will get a new declared value. So far, we have (LINK|XLINK), which inconveniently doesn't provide a this-ain't-no- steenking-link value to override a defaulted value from the subset. So we'll change it to (LINK|XLINK|FALSE). 2. We discussed the idea of having a way to provide a base address; the LOCATION-SOURCE and IMPLIED-LOCATION-SOURCE stuff in the initial draft. The ERB is powerfully in favor of giving entities a way to specify the canonical address by which they'd like to be referred to, bookmarked, relative address computed, etc. But we realize this is really not XML-LINK stuff, just a very convenient convenience feature for the XML language itself. So we provisionally decided (provisionally because this hasn't had WG exposure) to create a new per-entity Subject: Conference in San Diego Just a brief report on the conference in San Diego. There were 90 people so the meeting room (max 100) was pretty full. A solid contingent were SGML lifers and old vendor hacks. There were a pleasing number of Europeans: AIS, STEP, Steve Pepper, some folks from Volvo, some defense people from Britain. There were also some of the conference's intended audience - people who were looking at SGML and wondering about the business case. Also a few existing heavy SGML users, like for example Caterpillar, who are facing the web deployment issues. I led off with a half-day tour of XML; I had 72 slides that covered pretty well every paragraph of the spec (well, I didn't try to explain so-called nondeterministic grammars, nor will I, this side of the grave). I had no trouble getting through this in 2.5 hours. Some parts of the delivery were awkward and there is certainly room for improvement in the art & craft of teaching XML, but it's a start. Eve was there and took careful notes regarding inaccuracies and problems; when she gets those to me I'll revise the slides and put them up on a web site somewhere. Sitting prominently in the front row was Charles Goldfarb - the symbolic Dr. Goldfarb, one might say. I turned the stage over to Jon Bosak for the last 15 minutes; he gave a progress report on the state of the standard, and some cautionary notes about dangers that should be avoided in discussing XML's relationship to HTML and SGML. After lunch, and the usual welcoming noises from Norm Scharpf, Pam Gennusa, and myself, Jim Sterken, Arbortext supremo, give the opening keynote; basically an SGML vendor's take on the advent of XML. He was basically optimistic. He was worried, quite reasonably, about how we approach the great unexplored middle between the needs of Joe Homepage and those of the Boeing 777 document manager. He was also concerned about pricing pressure. Afternoon break, then Bruce Sharpe of SoftQuad (VP Development and Peter's brother) talked at length about XML, HTML and Web publishing from the (currently fashionable) viewpoint of "knowledge management". The arguments for XML in this context (like, HTML is dumb, y'know) are pretty straightforward and I won't reproduce them. Bruce was able (not till the next day) to present the SQ press release that has been discussed here. Jean Paoli followed Bruce, giving all of Microsoft's excellent reasons for liking XML - first and foremost was that the Web is too slow and the best way to fix that is to cut down on server roundtrips, and the best way to do that is to load smarter documents down and let client code do smart things with them. They've already got a nice setup in the forthcoming IE ship to do this with tabular data, and XML lets text in the door. For his Q&A, Jean invited Adam Bosworth up; Adam is Jean's boss, a general manager on the Microsoft IE team, and as former parent of Access and Quattro Pro, a force to reckon with. Adam fielded two questions, the first about the yawning gap between the home-page author and the professional publisher - he also acknowledged that it was tough to see where to go; pointing out that Microsoft probably isn't interested in addressing any market where they can't move a million units. Second, he was asked, given that many people think it would be desirable for Internet Explorer to do direct XML support, what did they need to hear from us in order to make this happen? His answer: reassurance that if Microsoft did this, that people would use it, thus giving Microsoft an advantage in the struggle for market share. He wondered how many people in the room would think this a good idea; every hand went up amid a round of applause. He also praised XML's simplicity and exhorted us not to compromise this. My take? They'll do it, sooner or later. Marketing issues aside, XML neatly solves several technical problems that are in the way of bleeding-edge Web development. This ended Monday's speeches. We adjourned to the world's first-ever XML trade show, excellent hors-d'oeuvre and free drinks in a covered tennis court. Arbortext was showing off Adept, reading & writing XML - they had a tough time making an interesting demo out of loading and saving SGML files, then exposing tags to show the ones, but I was impressed. Two companies were showing SGML-savvy document management, Texcel's Information Manager and Chrystal's Astoria. Both look good to me - unfortunately I didn't get around to asking for their take on XML. AIS was showing a way-cool XML Internet Explorer plug-in built with Balise - it isn't a product and I can't imagine it will be given Microsoft's likely moves, but it was a nice demo for Balise. Inso was showing DynaWeb, and while they weren't saying anything publicly, given that the Dyna-* products have been doing XML under the covers for years, it would be surprising if they didn't jump in XML's direction soon. Tuesday morning opened with case studies. Jared Sorenson of Novell (attention future conference chairthingies - Jared is a *good* speaker) telling the Novell story. ROI to the max, we're talking millions per year in Novell's case. Especially interesting to me was the continuing opposition to SGML at Novell, in the old days from the WYSIWYG'ers, now from the HTML-rules folks. Todd Freter (a former member of that Novell team, as is Jon Bosak) then discussed the current work at Sun on AnswerBook - preaching somewhat to the choir, but once again full of good solid SGML arguments for those who need them. Eric Skinner of Omnimark went last, showing how Omnimark uses SGML and microdocuments to automate the devilishly complex task of installing the Omnimark product. Tuesday's second session was the integration heavies. First was SGML veteran Eric Severson, now a technology integrator with IBM Global Solutions. He gave us a really good tour of the basic SGML business case - richer data creates more evenues for competition between information providers; competition is good. Peter Lamb, Andersen Consulting's world-wide #1 on document technologies, gave a skeptical but enlightening address - pointing out that the stock market is still very dubious about SGML companies, then moving through a series of Andersen predictions about the shape of publishing technologies in the short and medium term. His strongest point was that if SGML and XML are to prevail, they will have to do so on the basis of a sound business case, not because of any intrinsic technology elegance. Norm Scharpf asked Peter a really good question - in the printing industry at least, the state of EDI is pretty poor - these systems are a major pain to set up, and seem to require all sorts of special bilateral arrangements. Peter agreed that this seems like a favorable arena for technologies like XML. After lunch we explored the publishing dimension. First up was Wes Hair of Inso (formerly EBT) - a company that knows whereof it speaks on electronic publishing. Wes gave a solid walk-through on the case for doing things right, i.e. with SGML. Second was Liora Alschuler, standing in for Seybold's Mark Walter - she took a look at publishing from the writer's view, declaiming that the authoring systems for SGML just have to be a lot better than they are if most SGML is ever to be the product of authors rather than of conversion software. Finally she (controversially) predicted that downstream, there will be room for both HTML and one of SGML and XML, but perhaps not for both SGML and XML. I don't agree, but that's what conferences are for. The final session was the most entertaining. Dr. Robert McHenry, editor-in-chief of the Encyclopaedia Brittanica, gave an address entitled "Copernicus" which I shall refrain from trying to summarize, except to say that it toured through the history of science, mainframe reference publishing systems, being on the inside of a paradigm shift, had really handsome graphics, and ended with kind words for XML. He pretty clearly won the conference applause meter sweepstakes. The closing keynote was Charles Goldfarb, who opened with a vary precise explanation of the relationship of SGML to HTML (an application) and XML (a profile), with useful charts, which I fully intend to steal and re-use heavily. The body of his talk was concerned with the process of selling SGML and XML - which starts that pointing out that communication is impossible without rendering information, that rendering demands the use of style, and that style is by definition volatile and evanescent - but the underlying information is probably deserving of a longer-lived treatment. As always, his slides had the best graphics of the conference. I'd like to close by repeating my final remarks, which were a hearty thank-you to the speakers, who exhibited nearly insane courage in agreeing (in January) to come speak at a conference for which we had no way of predicting the attendence, on the subject of a technology which did not really exist yet. What will the next big XML conference look like? Beats me. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 09:01:47 -0800 From: Terry Allen To: w3c-sgml-wg@w3.org Subject: FYI: URN status >From owner-urn-ietf@Bunyip.Com Fri Mar 14 08:39:55 1997 Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by sub.sonic.net (8.8.5/8.7.3) with ESMTP id IAA05773 for ; Fri, 14 Mar 1997 08:39:54 -0800 Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA26720 for urn-ietf-out; Fri, 14 Mar 1997 10:51:19 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA26712 for ; Fri, 14 Mar 1997 10:51:17 -0500 (EST) Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07676 (mail destined for urn-ietf@services.bunyip.com); Fri, 14 Mar 97 10:51:15 -0500 Received: from ietf.ietf.org by ietf.org id aa05016; 14 Mar 97 9:59 EST To: IETF-Announce: ; Cc: urn-ietf@Bunyip.Com From: The IESG Subject: [URN] Last Call: URN Syntax to Proposed Standard Date: Fri, 14 Mar 1997 09:59:09 -0500 Errors-To: owner-urn-ietf@Bunyip.Com Status: R The IESG has received a request from the Uniform Resource Names Working Group to consider "URN Syntax" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 28, 1997 Files can be obtained via ftp://ds.internic.net/internet-drafts/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 08:48:26 -0800 To: W3C-SGML-WG@w3.org From: Tim Bray Subject: Recent ERB Work on URL addressing This report is on the last couple of ERB meetings, on March 8 and 12th. The majority of the time was spent on the issues (the discussion items numbered 4.*). One issue is central: can we afford to assert that all XML locators are URLs? The advantages are huge: - no need for separate locator-language machinery - web conformance. On the WWW, locators are URLS, and that's that - existing understanding and machinery There is one substantial downside: pure XML IDREFs cannot in this framework be XML Links; a URL consisting only of a Name is interpreted in URL-talk as a relative URL - you'd have to put a leading '#' in order to get IDREF behavior. You could rely on the declaration - if its declared IDREF, then you know - but this probably requires DTD processing in order to recognize links, and adds complexity; neither are good. Another issue arises, unavoidably. When a URL points into an XML doc, what does the part after the '#' mean? We have to define this. And if we are going to assert that we want to have all our pointers be URLs, then we have to explain how to squeeze TEI Xpointers into these things. This leads to the #1 problem that makes the ERB unhappy about the pure-URL idea: internationalization. We have gone to great lengths to allow the use of any sane Unicode encoding in data and markup - and yet the rules as to what can be in a URL are very restrictive; URL-encoded UTF-8 is going to be massively non-human readable. On the other hand, it may be the case that browsers de facto do the right thing with the part after the '#' - for sure this doesn't get sent out over the network, so why can't it be internationalized. So maybe we could just assert that the URL-encoding is not required after the '#'. We have some action items to check out what the specs say, what people think they mean, and what the de facto behavior of popular browsers is. Summary: the ERB is leaning *very* strongly to asserting that all locators are to be URLs - and will almost certainly go this way, if we aren't thereby throwing away our nice clean international interoperability. Input welcome. - Tim Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 09:13:30 -0800 From: Terry Allen To: w3c-sgml-wg@w3.org Subject: Re Stylesheet association Len Bullard wrote: | > My point is exactly that an XML instance | > without a style sheet, an applet that interprets the semantics of | > the GIs, a DTD, or some other document that collects that and | > similiar information is uninterpretable. | | I missed something here: uninterpretable by what or whom, | summarized where, which packaging implications? Are you saying | that because the stylesheet isn't used, that one can't know | what the semantics are? That will be the case. If Yes. I'm not thinking about simply constructing a grove, but actually being able to use it (or even know what to do with it). | object encapsulation, virtual interfaces, etc. are used, | you can't and that is exactly why some will prefer to do | this. Inheriting the interface, not the implementation, | and hiding the implementation is key to distributing | objects without giving away code. I guess what I am So far as I understand what you're saying, such an arrangement would rely on the user already possessing some sofware that encapsulates the semantics of the XML. Is that right? If so, that software already has the information about what tags are EMPTY. | saying is, some people think the way to maintain | proprietary code is to encapsulate and deliver only | exposed information. I think we shall see a lot | of applications where XML is just initialization | data and the stylesheets are irrelevant. [ ... ] | > I am more concerned about packaging and delivery in general than | > with ; I brought it up only to show that packaging and | > delivery have implications for aspects of XML that have already | > been decided - but could be reconsidered before everyone's feet | > are set in concrete. Now's the time. | | Ok. What implications? I must be missing the point of this | in the mail avalanche. It has been argued that XML instances must stand on their own, hence the need for reserved attribute names; but when I look at how XML will have to be packaged and delivered in all but the simplest cases, it seems to me that there is always going to be something else, be it a catalog, a style sheet, etc. So design decisions made on the basis that XML instances must stand on their own may have been ill considered. Now one can argue that the simple case must be accomodated, and that complexity is unwanted, hence complex cases must use the syntax invented for the simple cases (which is where we're at today). If that point of view survives a serious consideration of packaging and delivery, okay; but let's consider. [To throw another log on the fire: if XML is delivered as MIME type "XML-version-number", or whatever the magic string will be, is there any need for a PI that says the same thing (XMLDecl, production 29)? What's the need?] case, Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 11:35:40 -0700 To: w3c-sgml-wg@w3.org From: mag@ncsa.uiuc.edu (Tom Magliery) Subject: XML article in EC.COM There's a short article in the February 1997 issue of ec.com ("The Magazine for Electronic Commerce Management") about XML. It doesn't say anything that readers of this forum don't know, but it pretty much has its facts straight, and it's a little bit of evidence that the media/public awareness is growing. mag -- .---o Tom Magliery, Research Programmer .---o `-O-. NCSA, 605 E. Springfield (217) 333-3198 `-O-. o---' Champaign, IL 61820 O- mag@ncsa.uiuc.edu o---' %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 12:43:32 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: Re Stylesheet association At 9:13 AM -0800 3/14/97, Terry Allen wrote: >Yes. I'm not thinking about simply constructing a grove, but >actually being able to use it (or even know what to do with it). The "simple case" (as you refer to it below) will never go away. Web crawlers, text indexers, web mappers, generic XML databases, and the like will need to be able to pull in lage quantities of XML text, and my often care _only_ about the syntacxtic structure of the XML -- leaving the semantics out, or leaving them to another module. For those cases, self-delimiting syntax, without required semantic knowledge, is essential. SOme applications will simply say "stuff your package: give me the document" and for those applications, packaging is irrelevant to XML syntax. So there is nothing to reconsider. > >So far as I understand what you're saying, such an arrangement >would rely on the user already possessing some sofware that >encapsulates the semantics of the XML. Is that right? If so, >that software already has the information about what tags are >EMPTY. Not if we don't care about the semantics of the XML! >| > I am more concerned about packaging and delivery in general than >| > with ; I brought it up only to show that packaging and >| > delivery have implications for aspects of XML that have already >| > been decided - but could be reconsidered before everyone's feet >| > are set in concrete. Now's the time. I agree that packaging and delivery are critical -- but I am not convinced that they (should) have implications for the syntax. >| >| Ok. What implications? I must be missing the point of this >| in the mail avalanche. > >It has been argued that XML instances must stand on their own, >hence the need for reserved attribute names; but when I look >at how XML will have to be packaged and delivered in all but >the simplest cases, it seems to me that there is always going >to be something else, be it a catalog, a style sheet, etc. >So design decisions made on the basis that XML instances must >stand on their own may have been ill considered. No, carefully considered. There are applications that don't care about semantics in the senses that you mean... >Now one can argue that the simple case must be accomodated, >and that complexity is unwanted, hence complex cases must use >the syntax invented for the simple cases (which is where we're >at today). If that point of view survives a serious consideration >of packaging and delivery, okay; but let's consider. I find the dependence between empty element declarations and DTDs inconvenient even in regular SGML -- Looking at a document in an unfamiliar DTD is a minefiled until one has internalized the element definitions -- so I don't even regard the EMPTY suntax of XML as a "notorious wart" but rather an "examplary improvement". > >[To throw another log on the fire: if XML is delivered as >MIME type "XML-version-number", or whatever the magic string >will be, is there any need for a PI that says the same thing >(XMLDecl, production 29)? What's the need?] Well, I would still argue strongly that the PI and the HTTP header should be exactly equaivalent (as to syntax and semantics) and thus optional when HTTP is in use. However, I lost that battle. And I do accept the argument for in-document meta-data, since XML documents may move by other channels, we need meta-information in the document as well as in the HTTP channel. This does point out that the HTTP header should just be text/XML or application/xml (MIME experts can decide between these -- I once thought I understood it, but I don't think I really do). The version number is _not_ needed since it will be in the document. -- David _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: Re Stylesheet association To: dgd@cs.bu.edu (David Durand) Date: Fri, 14 Mar 1997 13:07:57 -0500 (EST) Cc: w3c-sgml-wg@w3.org > I find the dependence between empty element declarations and DTDs > inconvenient even in regular SGML -- Looking at a document in an unfamiliar > DTD is a minefiled until one has internalized the element definitions -- so > I don't even regard the EMPTY suntax of XML as a "notorious wart" but > rather an "examplary improvement". I agree strongly. I also feel that it is better to require less metadata to get a simple XML document up and running, rather than more. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 12:44:07 -0600 From: Len Bullard To: Tim Bray CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB work - miscellaneous Tim Bray wrote: > > 5. On the subject of Extended Link Groups, the ERB is unanimous that > we must have some way of providing this function - of pointing to > other documents that contain links into a current one. However, there > is another standardization effort underway in the W3C called Web > Collections that may well be, in parallel, cooking up a solution to > this same problem. Furthermore, the rumor mill says that the idea of > using XML for Web Collections is in play. We have an action item to > check this out - if we can outsource this job to existing web machinery, > it would clearly be a good thing. Is this the work sitting behind a passworded web site and available only to dues-paying members of the W3C? If so, how does that fit into a spec being developed by this Working Group which includes consortium and non-consortium members? len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 12:50:54 -0600 From: Len Bullard To: Tim Bray CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB Work on URL addressing Tim Bray wrote: > > This report is on the last couple of ERB meetings, on March 8 and 12th. > > The majority of the time was spent on the issues (the discussion items > numbered 4.*). One issue is central: can we afford to assert that all > XML locators are URLs? The advantages are huge: > - no need for separate locator-language machinery > - web conformance. On the WWW, locators are URLS, and that's that > - existing understanding and machinery > > There is one substantial downside: pure XML IDREFs cannot in this > framework be XML Links; a URL consisting only of a Name is interpreted > in URL-talk as a relative URL - you'd have to put a leading '#' in order > to get IDREF behavior. You could rely on the declaration - if its > declared IDREF, then you know - but this probably requires DTD processing > in order to recognize links, and adds complexity; neither are good. > > Another issue arises, unavoidably. When a URL points into an XML > doc, what does the part after the '#' mean? We have to define this. > And if we are going to assert that we want to have all our pointers > be URLs, then we have to explain how to squeeze TEI Xpointers into > these things. > > This leads to the #1 problem that makes the ERB unhappy about the > pure-URL idea: internationalization. We have gone to great lengths > to allow the use of any sane Unicode encoding in data and markup - > and yet the rules as to what can be in a URL are very restrictive; > URL-encoded UTF-8 is going to be massively non-human readable. On > the other hand, it may be the case that browsers de facto do the > right thing with the part after the '#' - for sure this doesn't get > sent out over the network, so why can't it be internationalized. So > maybe we could just assert that the URL-encoding is not required > after the '#'. We have some action items to check out what the specs > say, what people think they mean, and what the de facto behavior of > popular browsers is. > > Summary: the ERB is leaning *very* strongly to asserting that all > locators are to be URLs - and will almost certainly go this way, if > we aren't thereby throwing away our nice clean international > interoperability. Input welcome. - Tim If the Web architecture cannot support clean internationalization, then making all locators URLs is only an option for the first release. My guess is, this is a hole that can be exploited in the competition between the two commercial vendors of web browsers and should, therefore, be left open in some way to take advantage of the one who is able to devise a *beyond URL* solution. If IDREFs can't be links, we are invalidating a lot of existing work in SGML as well in order to accomodate a weak addressing system. It looks like URLs need some work. You should make it clear that URLs are a first version limitation only and that XML developers should be working on a stronger, more flexible, and more international solution. If they can't do this within the URL framework, then it should be replaced. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 14:08:16 -0500 (EST) From: Sam Hunting To: Len Bullard cc: Tim Bray , W3C-SGML-WG@w3.org Subject: Re: Recent ERB work - miscellaneous > > other documents that contain links into a current one. However, there > > is another standardization effort underway in the W3C called Web > > Collections that may well be, in parallel, cooking up a solution to > > this same problem. Furthermore, the rumor mill says that the idea of > > using XML for Web Collections is in play. We have an action item to > > check this out - if we can outsource this job to existing web machinery, > > it would clearly be a good thing. > > Is this the work sitting behind a passworded web site and available > only to dues-paying members of the W3C? If so, how does that fit > into a spec being developed by this Working Group which includes > consortium and non-consortium members? Well, I when I go to look at "http://www.w3.org/pub/WWW/Submission/1997/2/Overview.html", the site certainly behves like it's passworded and not available to non-consortium members. On the other hand, the abstract that I can read says: "The submission may be distributed publicly free of any fee." So... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 11:14:42 -0800 To: W3C-SGML-WG@w3.org From: Tim Bray Subject: Re: Recent ERB work - miscellaneous Cc: W3C-SGML-WG@w3.org Len wrote: >> Is this the work sitting behind a passworded web site and available >> only to dues-paying members of the W3C? If so, how does that fit >> into a spec being developed by this Working Group which includes >> consortium and non-consortium members? Good point. Microsoft has to be a bit careful, because this is a *formal* proposal from that corporation to an industry consortium of which they're a member - they have to play by the rules, which I think say that proposals are initially available only to members. On the other hand, I think that MS would agree that it would be a good thing to make this available to us - I'll ask around. On the other hand, we just create XML, we cannot, nor should we want to, control what people do with it. The playwright has no normative influence over the director. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 11:31:19 -0800 From: Terry Allen To: tbray@textuality.com, W3C-SGML-WG@w3.org Subject: Re: Recent ERB work - miscellaneous Tim Bray: | Len wrote: | >> Is this the work sitting behind a passworded web site and available | >> only to dues-paying members of the W3C? If so, how does that fit | >> into a spec being developed by this Working Group which includes | >> consortium and non-consortium members? | | Good point. Microsoft has to be a bit careful, because this is a | *formal* proposal from that corporation to an industry consortium | of which they're a member - they have to play by the rules, which | I think say that proposals are initially available only to members. Web Collections is supposed to be part of the IETF WEBDAV spec, too. Discussion is ongoing on that list about the document (which Yaron Goland says he's going to revise to meet criticisms). There must be a public copy somewhere. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 13:16:27 -0600 From: Len Bullard To: Tim Bray CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB work - miscellaneous Tim Bray wrote: > > On the other hand, we just create XML, we cannot, nor should we > want to, control what people do with it. The playwright has no > normative influence over the director. Yes, but the playwright sits in on rehearsals and is consulted for changes in the script. Union rules. We can't adopt or count on what we can't see. If those are the consortium rules, we are definitely building this under the wrong aegis. Hitching a ride is one thing; walking behind the horse without watching where one steps is another. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 13:51:01 -0600 From: Len Bullard To: Terry Allen CC: w3c-sgml-wg@w3.org Subject: Re: Re Stylesheet association Terry Allen wrote: > >len wrote > > | object encapsulation, virtual interfaces, etc. are used, > | you can't and that is exactly why some will prefer to do > | this. Inheriting the interface, not the implementation, > | and hiding the implementation is key to distributing > | objects without giving away code. I guess what I am > > So far as I understand what you're saying, such an arrangement > would rely on the user already possessing some sofware that > encapsulates the semantics of the XML. Is that right? If so, > that software already has the information about what tags are > EMPTY. Depending on the level to which they hardwire the app, yes. Would you rather send an encapsulated object down the wire, an application --, (what an instance plus processing specification, plus any embedded thingies, plus PIs which hide the DTD under smokin' syntax are), or just a data file of hierarchies of value-pairs? > | saying is, some people think the way to maintain > | proprietary code is to encapsulate and deliver only > | exposed information. I think we shall see a lot > | of applications where XML is just initialization > | data and the stylesheets are irrelevant. This is the key. It is the key to what Eve is suggesting about PIs, about the question Tim passes from the conference about "selling a million units", "competitive advantage", semantics vs data, etc. etc. etc. Push aside the syntax arguments for awhile. Forget URLs. Forget stylesheets. Why would one want to use XML and StylesheetX if all they have to do is deliver an object to the user and the object is automatically usable? It is complete, it is ready for action, it's interface is already contractually obligated. Why? If I want to add an object to an Active-X system, right now, I just have to keep up with COM. As long as the IUnknown and queryInterface pointer magic is done right, it will work. Every time. If apply containment and aggregation correctly, I even get a pretty efficient system. If I keep in-process, out-of-process, and remote process interfaces (stubs, etc.) straight, this all even works across a network transparently except for speed. Why bother with XML, HTML, SGML, or DSSSL? Keeping up with a complicated packaging scheme, stylesheets, collections, catalogs, and the other nine yards looks pretty daunting to someone who only has to submit to COM/OLE to get what they want? Right? This isn't just arbitrariness on my part. These are questions being asked very seriously in some quarters off this list, and they must be answered. I can cite the SGML legacy, I can cite the lifecycle advantages (even where seriously compromised by well-formed approaches), but to make the case for a complete XML System in a world in which the proliferation of objects is fast and accelerating, we have to answer with something that is an irrefutable advantage. I can cite one or two, but I am interested in what the list thinks. I'm not looking to stoke the fires of paranoia, but I think there is a business case and it can't be made unless the technical details are understood just a little, and the technical tradeoffs are understood a lot. Furthermore, unless one accepts and embraces the competitive position the adopter accrues, it isn't a very strong case. With SGML/XML, the adopter can lay out a company that only knows how to do ONE DTD like filleted fish: one slice/newDTD at a time. But to do it, they have to dump the stylesheets and catalogs for most applications. Ask yourselves: when does it make good sense to have a stylesheet? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 15:01:21 -0500 To: Tim Bray From: "Eve L. Maler" Subject: Re: Recent ERB Work on URL addressing Cc: W3C-SGML-WG@w3.org At 08:48 AM 3/14/97 -0800, Tim Bray wrote: >This report is on the last couple of ERB meetings, on March 8 and 12th. > >The majority of the time was spent on the issues (the discussion items >numbered 4.*). One issue is central: can we afford to assert that all >XML locators are URLs? The advantages are huge: > - no need for separate locator-language machinery > - web conformance. On the WWW, locators are URLS, and that's that > - existing understanding and machinery > >There is one substantial downside: pure XML IDREFs cannot in this >framework be XML Links; a URL consisting only of a Name is interpreted >in URL-talk as a relative URL - you'd have to put a leading '#' in order >to get IDREF behavior. You could rely on the declaration - if its >declared IDREF, then you know - but this probably requires DTD processing >in order to recognize links, and adds complexity; neither are good. Explicit link recognition needs "DTD processing" anyway, whether the ATTLIST machinery is in the external or the internal subset. (The latter is more trivial to retrieve, but no easier to process.) Given than IDREF[S] and ENTITY[IES] are usually only interesting in the cases where the relevant ATTLIST is read, I'd prefer that we sanction these as links in XML by allowing them to have the XML-LINK="LINK" on them and to dictate the "template" (that is, arch form) requirements for these attributes. If you supply just an IDREF[S] value, then it's a fragment identifier relative to the current document. If you supply an ENTITY[IES] value, then it's just an indirect way of pointing to a URL (which is what entities have to resolve to anyway, right?). The tricky part would be doing the entity-plus-ID in separate attribute values, which is a really common thing to want to do. If you supply an IDREF[S] that's intended as a fragment identifier relative to the entity, you'll get a validation error if the entity isn't the current document (though you may not care about validation errors). Perhaps, when ENTITY[IES] is supplied, the regular locator attribute value can be interpreted as the fragment identifier relative to the entity, and too bad if you don't combine them properly. FWIW, here's a concrete proposal, with a few comments/questions: o LOCATOR here is the all-powerful locator attribute. The locators that have special declared values are named after the declared values. o Does "ANY" allow the element to be declared "EMPTY"? I think we should allow this! How can we get the template/AF to indicate it? o What I mean is to allow *either* IDREF or IDREFS, and *either* ENTITY or ENTITIES. How do you do this in a template/AF? o If the element and attribute names become canonical, then perhaps DTD processing *isn't* needed in the cases where the name matches up with the declared value. Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 13:53:01 -0600 From: Len Bullard To: Terry Allen CC: tbray@textuality.com, W3C-SGML-WG@w3.org Subject: Re: Recent ERB work - miscellaneous Terry Allen wrote: > > Web Collections is supposed to be part of the IETF WEBDAV spec, too. > Discussion is ongoing on that list about the document (which Yaron > Goland says he's going to revise to meet criticisms). There must be > a public copy somewhere. Until that is located or arrangements are made, for the rest of us could someone summarize what this is and how it is advantageous to XML apps? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 15:23:14 -0500 To: Tim Bray From: "Eve L. Maler" Subject: Re: Recent ERB work - miscellaneous Cc: W3C-SGML-WG@w3.org At 08:48 AM 3/14/97 -0800, Tim Bray wrote: >More reports from the March 8 and 12 meetings. Attendence was confusing: >every member of the ERB was in attendence in part, but there was a >certain amount of checking in and out based on travel plans and >interruptions; my notes record no dissenting votes to any of >the following, but some member who missed a particular vote may >choose to record a dissent: > ... >2. We discussed the idea of having a way to provide a base address; >the LOCATION-SOURCE and IMPLIED-LOCATION-SOURCE stuff in the initial >draft. The ERB is powerfully in favor of giving entities a way to >specify the canonical address by which they'd like to be referred to, >bookmarked, relative address computed, etc. But we realize this is >really not XML-LINK stuff, just a very convenient convenience feature >for the XML language itself. So we provisionally decided (provisionally >because this hasn't had WG exposure) to create a new per-entity >at this time, muster support for the IMPLIED-LOCATION-SOURCE stuff. ... We thought that it would be handy to be able to provide multiple base locations, which you'd be able to do if you repeated the PI. My preference, which you all must be tired of hearing about at this point :-), would be syntax like this (a fake GI along with the attribute structure): . . . Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Matthew Fuchs" Date: Fri, 14 Mar 1997 14:18:18 -0800 "Re: Re Stylesheet association" (Mar 14, 1:51pm) To: cbullard@hiwaay.net, Terry Allen , w3c-sgml-wg@w3.org Subject: Re: Re Stylesheet association On Mar 14, 1:51pm, Len Bullard wrote: > Subject: Re: Re Stylesheet association > Terry Allen wrote: > > > >len wrote > > > > | object encapsulation, virtual interfaces, etc. are used, > > | you can't and that is exactly why some will prefer to do > > | this. Inheriting the interface, not the implementation, > > | and hiding the implementation is key to distributing > > | objects without giving away code. I guess what I am > > > > So far as I understand what you're saying, such an arrangement > > would rely on the user already possessing some sofware that > > encapsulates the semantics of the XML. Is that right? If so, > > that software already has the information about what tags are > > EMPTY. > > Depending on the level to which they hardwire the app, yes. > > Would you rather send an encapsulated object down the wire, > an application --, (what an instance plus processing specification, > plus any embedded thingies, plus PIs which hide the DTD under > smokin' syntax are), or just a data file of hierarchies of > value-pairs? > Depends entirely on the circumstances. Sometimes you need to send an object because you are trying to convey behavior which doesn't exist at the client side. Sometimes you send "data" because you are trying to convey information. It is very much a question of semantics, because (unlike an XML document) objects _are_ semantics - they provide a particular "interpretation" to strings in the language specified by their interface (incidentally, Alan Kay has told me this was very explicit in the earliest versions of Smalltalk). In their cdf specs, Microsoft adopted XML because it makes no sense to send objects - how the information is to be used is a client concern (and don't you think they'd use COM if they could?). There will also be cases where the server has already sent info to personalize the client, so all it is sending is information to previously downloaded objects. > > | saying is, some people think the way to maintain > > | proprietary code is to encapsulate and deliver only > > | exposed information. I think we shall see a lot > > | of applications where XML is just initialization > > | data and the stylesheets are irrelevant. > This will certainly be the case. Here, XML is just a convenient data structure. But my favorite examples are where information may be handled in ways the server knows nothing about. I think object interfaces, since they are naturally going to revolve around behavior will always be limited - they can't anticipate all they ways they will be used. > This is the key. It is the key to what Eve is suggesting > about PIs, about the question Tim passes from the > conference about "selling a million units", "competitive > advantage", semantics vs data, etc. etc. etc. > Semantics vs. data is real important. > Push aside the syntax arguments for awhile. Forget > URLs. Forget stylesheets. Why would one want to > use XML and StylesheetX if all they have to do is > deliver an object to the user and the object is > automatically usable? It is complete, it is ready > for action, it's interface is already contractually > obligated. Why? > And it is totally limited by the vision and economies of scale (one can only program so much functionality) of its creator. XML data will be much less limited and far more easily integrated into _other people's_ applications (and even my own). > If I want to add an object to an Active-X system, > right now, I just have to keep up with COM. As > long as the IUnknown and queryInterface pointer > magic is done right, it will work. Every time. > If apply containment and aggregation correctly, > I even get a pretty efficient system. If I > keep in-process, out-of-process, and remote > process interfaces (stubs, etc.) straight, this > all even works across a network transparently > except for speed. Why bother with XML, HTML, > SGML, or DSSSL? > > Keeping up with a complicated packaging > scheme, stylesheets, collections, catalogs, > and the other nine yards looks pretty daunting > to someone who only has to submit to COM/OLE > to get what they want? Right? > Isn't this a case of intuitive really meaning what you're used to (although your basic point still holds)? However, I've got to agree that the SGML community has built a complex array of standards and terminology parallel to what the rest of the world is doing. It may be better, it may be worse, but it's still pretty daunting. At the same time, I think we've been a little overly nervous about sending DTD information. I suspect that people are thinking of Docbook or HTML DTDs, but many applications will have DTDs that are just a few lines long. I mention this because well-formedness will not always be sufficient for the client - it needs to know that at least a part of the document is valid, or that the part of the DTD it is interested in conforms to the one it knows. Matthew Fuchs %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 17:08:20 -0600 From: Len Bullard To: Matthew Fuchs CC: Terry Allen , w3c-sgml-wg@w3.org Subject: Re: Stylesheet association Matthew Fuchs wrote: > > > Would you rather send an encapsulated object down the wire, > > an application --, (what an instance plus processing specification, > > plus any embedded thingies, plus PIs which hide the DTD under > > smokin' syntax are), or just a data file of hierarchies of > > value-pairs? > > > > Depends entirely on the circumstances. Sometimes you need to send an object > because you are trying to convey behavior which doesn't exist at the client > side. Sometimes you send "data" because you are trying to convey information. Right. In some cases, all you are sending is the information needed to initialize objects, things that already have class distinctions. The property values can be validated as long as the types are known or determinable by DTD or "hey, I'm a Doc of this type". I note the CDF example includes the doctype. > It is very much a question of semantics, because (unlike an XML document) > objects _are_ semantics - they provide a particular "interpretation" to strings > in the language specified by their interface (incidentally, Alan Kay has told > me this was very explicit in the earliest versions of Smalltalk). I think it is still explicit. > In their cdf specs, Microsoft adopted XML because it makes no sense to send > objects - how the information is to be used is a client concern (and don't you > think they'd use COM if they could?). I think they do. I think they use XML because they need an analogus fat packet to formatec. They don't send the object; we have the object if we are using a CDF client. That's the point. That's also why XML is valuable beyond practice. If one competitor can only use One DTD and refuses to use others, the easy way to corral them, shear them, then blood them is to put out a lot of little DTDs with the code. Make it easy by the DTD and the editor to enter information, and force the other guy to cope. NEVER use the stylesheet because that exposes the code. The DTD is cheap to write; the code is expensive. ALWAYS hide the implementation. Use the *standard approach* like a skillful filleting knife. The ironic thing is by claiming HTML was a standard, its supporters handed them the knife. XML makes it into stainless steel; it stays sharp. > There will also be cases where the > server has already sent info to personalize the client, so all it is sending is > information to previously downloaded objects. Downloading is not the issue. How they got the objects isn't important; only that they have them and can read the initialization data: eg, the well-formed instance Plus whatever else it needs. PIs/DTDs add more initialization data or data for the object to munch on. Packaging and marshalling start to look a lot alike. > > > | saying is, some people think the way to maintain > > > | proprietary code is to encapsulate and deliver only > > > | exposed information. I think we shall see a lot > > > | of applications where XML is just initialization > > > | data and the stylesheets are irrelevant. > > > > This will certainly be the case. Here, XML is just a convenient data > structure. Not convenient; strategically deadly. Now that they can extend, extend fast while the other guy is still trying to convince everyone else not to do it. The fight is won or lost in the first six months. It uses the same colonization approach and exploits the other guys lack of vision. > But my favorite examples are where information may be handled in > ways the server knows nothing about. I think object interfaces, since they are > naturally going to revolve around behavior will always be limited - they can't > anticipate all they ways they will be used. Ah, but how often will that be the case especially for well-formed instances? IOW, when do we not know semantics in advance? If we don't is it cheaper to send the objects/semantics, then begin sending the data to munch as needed? Or, in short, how often would I want to send a stylesheet, and why would I want a stylesheet if I can send an object? > > This is the key. It is the key to what Eve is suggesting > > about PIs, about the question Tim passes from the > > conference about "selling a million units", "competitive > > advantage", semantics vs data, etc. etc. etc. > > > > Semantics vs. data is real important. Duh. It's data AND semantics with a separation made for convenience of transport, particularly, trying to get the size of the rat the snake is swallowing down... or network packets. > > Push aside the syntax arguments for awhile. Forget > > URLs. Forget stylesheets. Why would one want to > > use XML and StylesheetX if all they have to do is > > deliver an object to the user and the object is > > automatically usable? It is complete, it is ready > > for action, it's interface is already contractually > > obligated. Why? > > > > And it is totally limited by the vision and economies of scale (one can only > program so much functionality) of its creator. XML data will be much less > limited and far more easily integrated into _other people's_ applications (and > even my own). No. A COM object can increase its functionality at any time using dynamic marshalling. The creator only has to rename the interface, and the receiver's system can install it and use it without the client even knowing that is done. COM handles versioning. A data format can only accomodate so much reuse. There is a sliding scale between two poles. But at least, it can be adjusted. There is a choice. > > If I want to add an object to an Active-X system, > > right now, I just have to keep up with COM. As > > long as the IUnknown and queryInterface pointer > > magic is done right, it will work. Every time. > > If apply containment and aggregation correctly, > > I even get a pretty efficient system. If I > > keep in-process, out-of-process, and remote > > process interfaces (stubs, etc.) straight, this > > all even works across a network transparently > > except for speed. Why bother with XML, HTML, > > SGML, or DSSSL? > > > > Keeping up with a complicated packaging > > scheme, stylesheets, collections, catalogs, > > and the other nine yards looks pretty daunting > > to someone who only has to submit to COM/OLE > > to get what they want? Right? > > > > Isn't this a case of intuitive really meaning what you're used to (although > your basic point still holds)? No. This isn't intuition at all. It is an economy of interaction, or communication. If I send you (client) an object ready to go, why would you want to do the assembly yourself? Why not just query for the interface and let me (server) do my work. > However, I've got to agree that the SGML community has built a complex array of > standards and terminology parallel to what the rest of the world is doing. It > may be better, it may be worse, but it's still pretty daunting. Sure. Well, what I am getting at is the plea "keep this simple". We have sort of, but we may by adding lots of PIs, stylesheets, catalogs, etc. be about to repeat the old madness because that is what we understand. There may be cases where the old madness is warranted, but we better be very clear about what those cases are or the business case for XML is nil or at least, exactly the same case as SGML. XML becomes "a rolling con". We didn't make things better; we shuffled all the pieces, fixed empty tags and end tags, and agreed on how we want to do strongly typed links. That's a lot for SGML, but may not be a valid business approach when one can buy into COM/OLE and skip a lot of this. We can say we've reached "critical mass" but that's not just silly, that's laughable. > At the same time, I think we've been a little overly nervous about sending DTD > information. Yep. Given everything else we have to package, that is trivial. >I suspect that people are thinking of Docbook or HTML DTDs, but > many applications will have DTDs that are just a few lines long. Yep. A lot of us championing DTDlessNess are the same people who championed some of the most overbuilt DTDs ever seen. IOW, a neatly circular and self-fulfilling prophecy. > I mention > this because well-formedness will not always be sufficient for the client - it > needs to know that at least a part of the document is valid, or that the part > of the DTD it is interested in conforms to the one it knows. Yes. Then there is the question that if we are adding lots of PIs, templates whatever to get around the DTD, why not just send the DTD? At least that is well-understood if not well-formed practice. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 15:19:05 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Microsoft bases two proposals on XML | Web Collections: | http://www.w3.org/pub/WWW/Submission/1997/2/Overview.html | | Channel Definition Format: | http://www.w3.org/pub/WWW/Submission/1997/3/Overview.html | http://www.microsoft.com/corpinfo/press/1997/Mar97/Cdfrpr.htm In response to several inquiries: This is all that is publicly visible. The rest is internal W3C-only at this time. The Web collections proposal (the part that you can't see if you're not a W3C member) goes into some detail about XML, though it is not mentioned in the overview. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 23:38:11 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: W3C-SGML-WG@w3.org Subject: Re: Recent ERB work - miscellaneous Lines: 34 In message <3.0.32.19970313215024.0096fac0@pop.intergate.bc.ca> Tim Bray writes: [...] > > 3. We took up the questions of what subset of TEI Xpointers we're > going to need. We developed consensus that: > - the subset in the initial spec is reasonable, except that > - even though SPAN is really useful, we are nervous that as far as we > know, the world has only one implementation, namely Panorama; are > there others?, and > - sub-element addressing (TOKEN, character counting, patterns) are just > not stable enough, particularly in the case of some Asian languages, > to be worthwhile including in XML-Link release 1.0. > > 4. We decided that we were not going to specify support for any query > language, built-in or FOREIGN, in XML-Link 1.0, beyond TEI Xpointers, > which are in fact a query language. Support in some way for SDQL remains > firmly on the agenda, but not in this release. TOKEN and FOREIGN seemed the obvious ways to solve some of my problems. I'm happy to accept the ERB's conclusion, but will require some method of searching through a node once it has been reached by a TEI pointer. Is this completely application-specific, or is there a way (FOREIGN not being allowed) to apply (say) a Java method to the node contents? It could be worthwhile to converge towards a standard syntax, because this will be a common requirement and general XML applications/browsers will need to recognise it. (It may be that the solution is best discussed elsewhere, but I'd like to feel comfortable :-) P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 23:26:53 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs Lines: 24 In message <9703140217.AA28707@sqrex.sq.com> lee@sq.com writes: [...hairy nested entity example deleted...] > > This example may appear very obscure. I could give a larger example > in which it would no longer be obscure, as can Eliot and Michael > and Lou and others: IBMIDDOC, TEI, Davenport all use nested parameter > entity deifintions. This concerns me because the implementers on xml-dev have been struggling with the precise management of entities. I suspect that without further guidance, they might come up with different implementations of nested entities (and other similar problems). I'd like the WG/ERB to try to come up with some way of expressing their views in the XML-spec - my feeling is that either it has to be much simpler than SGML or else exactly track what SGML requires (or at least how SGMLS interprets it). People will naturally look to SGML if they can't get it from the XML spec. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 22:49:43 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs Lines: 28 > At 6:37 PM 3/13/97, lee@sq.com wrote: > >Perhaps we also need apostrophe and grave accent. Note that there > >is no single quote in ASCII, as ' is an apostrophe and ` is a grave > >accent. The typewriter doube quote (") makes the fifth, right? > > > >amp ampersand & > >lt left angle bracket < > >quot grave accent ` > >apos apostrophe ' > >dquot typewriter double quote " > > > >That makeds five; do we also need > >gt right angle brcket > > >or > >ket right bracket ] I have a nasty feeling that physicists use 'bra' for '<' and 'ket' for '>' and I suspect this could cause serious confusion in at least part of the community. [...] P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 14 Mar 97 20:42:51 EST To: w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs davep@acm.org (Dave Peterson) wrote: > lee@sq.com wrote: > >Perhaps we also need apostrophe and grave accent. Note that there > >is no single quote in ASCII, as ' is an apostrophe and ` is a grave > >accent. The typewriter doube quote (") makes the fifth, right? > > > >amp ampersand & > >lt left angle bracket < > >quot grave accent ` > >apos apostrophe ' > >dquot typewriter double quote " > > > >That makeds five; do we also need > >gt right angle brcket > > >or > >ket right bracket ] > > Does Unicode or 10646 really define "<" and ">" as left and right > angle brackets? No -- I was writing from home, sorry. They are GREATER THAN and LESS THAN. > Same question about "`". Really just a stand-alone accent? UNICODE has ' (0027) as APOSTROPHE-QUOT and ` (0060) as SPACING GRAVE > What authority says that the " entity is "`"? My faulty memory. Actually different SGML sources give " to be ' or ", which doesn't help (e.g. Joan Smith, an authority but not authoritative) gives quot as " and since the standard didn't give pictures, nor the handbook, that's how I've always used it. > I know of systems whose character > repertoires differentiate between apostrophe and single closing quote! Yes, that's resonable. In display work the single quote is often rendered more heavily. > and neither one is the "typwriter single quote" that "'" was at > least originally meant to be. Well, ASCII has it as an apostrophe, I believe. > I assume you just made up "ket" as a name for "]"? No, it's a common computer science name: bra and ket, [ and ]. > o Do the implied entity definitions for &, <, and > (the > current required set) take precedence over local ones? Currently > they do. (And *currently* must, see next bullet.) > > o Is the user *required* to use these three to escape "&", "<", > and ">", rather than any other entities he or she may have > available, or even other mechanisms for escaping? As I read > the Nov 96 spec, this is a requirement. I don't like it. > > BTW, the spec says that you are to escape "]]>" as "]]>". Someone else gave the 5 names. The spec isn't up to date, so I didn't check against it, sorry. If the names are part of the language they must begin with XML-. If you can override them, they should not begin with XML-. If you override them and do not have a DTD, you're OK to the same extent you are with any other entity. I don't see how you can forbid other entities to have replacement values of & or < or " --- and that would be the effect of your second bullet point --- so that must surely be an error in reading? Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 14 Mar 97 21:51:16 EST To: W3C-SGML-WG@w3.org Subject: Re: Recent ERB Work on URL addressing Quoth Tim: > This leads to the #1 problem that makes the ERB unhappy about the > pure-URL idea: internationalization. [...] This is an issue for URLs in general. When the HTML/HTTP/URI groups agree on somethhing, we can follow it in a future XML. > URL-encoded UTF-8 is going to be massively non-human readable. On > the other hand, it may be the case that browsers de facto do the > right thing with the part after the '#' - for sure this doesn't get > sent out over the network, so why can't it be internationalized. The browser is responsible for URL-encoding strings passed over HTTP as part of GET requests. Some old and broken HTML browsers did't URL-encode things they found in HTML, or tha the user entered. I note that Netsape 4 does do automatic URL enoding, and I think 3 does also. MSIE quotes spaces but allows 8-bit characters to pass through, but turns \ into / everywhere (!) It would be a good idea to mention in the XML link spec that URLS must be url-encoded by software that uses them in contexts that require such encoding, and that they may be expected to undo/revese such encodings before displaying the results to users. > Summary: the ERB is leaning *very* strongly to asserting that all > locators are to be URLs - and will almost certainly go this way, if > we aren't thereby throwing away our nice clean international > interoperability. Good! Note that this way XML will be no less international than the WWW... where there are strong incentives for i18n. Perhaps someone (Misha? You there?) could comment on RFC 2070 and that working group's discussion on URLs. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Mar 1997 23:31:11 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: those predeclared entity refs From: John_Lavagnino@Brown.edu Peter Murray-Rust: | > At 6:37 PM 3/13/97, lee@sq.com wrote: ... | > >That makeds five; do we also need | > >gt right angle brcket > | > >or | > >ket right bracket ] | | I have a nasty feeling that physicists use 'bra' for '<' and 'ket' for '>' | and I suspect this could cause serious confusion in at least part of | the community. Back when my field was physics and not literature, "bra" and "ket" did not refer to bare < and > but to larger entities like . The short explanation is that these are vectors. The vertical bar was essential, and generally the letter too so that you knew what variable you were talking about; < and > on their own would not be distinguishable from less-than and greater-than signs. So I don't think using "bra" and "ket" to refer to other single symbols would be an enormous problem, because for physicists they don't meaningfully refer to single characters anyway. (I also had the impression that this notation is no longer much used, but that could be subject to a lot of local variation.) The second edition of the OED will give you a reasonable picture of the origin and use of this notation. John Lavagnino %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 15 Mar 1997 15:40:25 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Conditional sections XML currently defines conditional sections like this: [57] conditionalSect := '' [58] CSKey := PEReference | 'INCLUDE' | 'IGNORE' [59] csdata := internalsubset This is not compatible with SGML because in SGML ignored marked sections are only scanned for nested . So for example, in XML (as I understand [59]), the marked section in *--> ]]> will be terminated by the second ]]> whereas in SGML it will be terminated by the first. Unfortunately the SGML way makes it harder for DTD-less parsers to find the end of the DTD subset. Since I can do *--> ]]> I can't tell in SGML where the subset ends without at least processing parameter entity declarations. James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 15 Mar 1997 15:46:07 +0000 (GMT) From: Peter Flynn Subject: Re: Stylesheet association To: w3c-sgml-wg@w3.org >| > >| >is one of the worst warts on the present spec, One thing which was abundantly unclear in the spec until Mike S-McQ pointed it out to me last weekend is that even valid instances must use format, even if the element is defined EMPTY in the DTD. I has mistakenly assumed that DTDfull instances didn't need this, because the DTD said which elements were EMPTY and which weren't, and that
would be required only in DTDless cases. I've changed the FAQ to reflect this, 0.5 out next week including math in response to several queries as to whether XML could "handle" it (some misapprehensions still being created :-) ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 15 Mar 1997 15:57:38 +0000 (GMT) From: Peter Flynn Subject: Re: Conference in San Diego To: w3c-sgml-wg@w3.org >best way to fix that is to cut down on server roundtrips, and the best >way to do that is to load smarter documents down and let client code ^^^^^^^^^^^^^^^^^ USP. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 15 Mar 1997 23:04:43 +0000 To: altheim , lee@sq.com From: Martin Bryan Subject: Re: those predeclared entity refs Cc: w3c-sgml-wg@w3.org At 17:52 13/3/97 -0800, altheim wrote: > b. if the reference delimiter is changed, (eg., '<' to 'foo') then > the entity reference ('&#ERO') changes with it >But from what I can gather, they can't be used in a document instance. >nsgmls returns an error such as > > "ERO" is not a function name You could always define a set that gave you entity names such as &ERO; &MDO; &MDC; &LIT; &LITA; ... As cap names ware less likely than lowercase ones in user declared sets these should be fairly safe from name clashes with user-defined sets, and should stand out as keywords because they are in caps. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 15 Mar 1997 23:04:40 +0000 To: "Rivers-Moore, Daniel" , "'W3C-SGML-WG@w3.org'" From: Martin Bryan Subject: RE: another vote for spans At 10:04 11/3/97 -0000, >How about STARTFROM and ENDAT STARTS and ENDS would be even simpler. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg