From: lee@sq.com Date: Sat, 1 Feb 97 01:30:54 EST To: U35395@UICVM.UIC.EDU, w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) > Indirection and hand-waving of the type recommended by Lee and Dave > are a recipe for inconsistent and incompatible implementations. I'm not sure that I am recommending hand waving. Many other languages do something similar in this sort of cases -- C comments were specified as follows [1]: The characters /* introduce a comment, which terminates with the characters */. Comments do not nest. Comments in C are white space (Lexical Conventions, para 1). > a surprising number of > intelligent people with an interest in parsing and grammars can *fail* > to formalize them correctly when working from a natural-language > description, and trying to express them without recourse to scanning > modes. Some problems are very difficult to express with regular expressions. I still don't have one that will match correctly, for example (I'm using x instead of * because it's easier to test). > I think having full regular expressions defining comments, etc., is in > fact useful to implementors. I think you are right if the expressions are simple enough. Expressions this complex are unlikely to work the same way in enough tools, although I suppose that giving expressions for lex, perl 4, perl 5, jacc and sed would be sufficient in practice, at least for now. (perl 4 and 5 have slightly different rules about nested brackets, and also about whitespace in expressions, but that's not for this list!) Most perl 5 scripts will work fine with For example, try perl -w -p -e 's//COM/g;' This is because the perl *? operator is not greedy, so the first occurrence of *--> satisfies the following literal, and is not eaten by the ".*". Hence, hello will produce COMhelloCOM correctly. But not everyone is using perl 5 :-) Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 1 Feb 97 01:43:55 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: XML catalog draft I find myself agreeing completely with James. On Paul's notes: > 1. It was a goal to allow the catalog to map public identifiers into > URNs. (Do we want to open up the defn of sysids in XML to include > URNs, or does the defn of URL already include URNs?) The solution to this seems to me to use URI everywhere instead of URL or URN, and allow any system identifier (whether in a CATALOG or an instance) to be a URI. > 2. It was a goal to allow XML catalogs to be used with SGML/XML > repositories (aka databases). For example, it was felt important > to allow an entry such as: > PUBLIC "corporate legal boilerplate C312" "get_bplate('C312')" > where the rhs is some database call (whether expressed in FSI syntax > as in this example or not). This I believe is bogus. You could just as well use PUBLIC "[...] C312" "get_bplate;id=C312" and be legal -- this is a partial URL that does the same thing. > 3. It was a goal (albeit a less important one) to allow catalogs to > have FSIs on the rhs. We have already agreed not to require XML systems to support FSIs. They are too complex. > 4. Though URLs remain the most obvious thing for a sysid to be, it > might make sense to allow the market to decide what sysids will > work. This is one place where it might be best to suggest that > URLs give maximum interoperability, but to allow other things > to develop. After all, any decent XML tool that finds a sysid > that isn't a URL is going to try its best to figure it out anyway, > so how is restricting it in the XML spec going to help? I don't see the logic here at all. You don't maximise interoperability by allowing non-standardised strings. The market is not capable of standardising -- if it was, we wouldn't be here, and WG8 could disband. > [...] I'm quite sure that no one in our subgroup > would feel it inappropriate for the ERB or WG to decide to restrict the > rhs of catalog entries to URLs, especially if the concerns I list above > are considered and either addressed or deemed beyond the scope of XML. I think in this light that I hope the ERB does this... I should add that with the reservations I've stated, and also with James' reservation about requiring catalog support at all, I think this is a sensible and helpful proposal. I want to make sure that it does not forbid a system that uses a remote lookup in a database instead of a catalog (for example). We need to be 200% clear on what happens if both system and public ID are given: * is catalog consulted? * what happens if the catalog lookup gives a different result than the system identifier? For Panorama, the system identifier on the DOCTYPE line usually wins in that case. But it actually depends on the user's preferences. Author/Editor ignores the PUBLIC identifier if there is a SYSTEM one. We also need to say what happens when catalog is not found. We also need to say exactly where to find the catalog file. Does a processing instruction in the document header point to it, for example? What if the XML document is generated as the result of a cgi query, so that there is no "current directory" of the document...? What if we don't have a "base URL" for the XML document? I know the proposal doesn't answer these questions. It needs to. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:39:26 +0000 To: w3c-sgml-wg@www10.w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? >1.c: Should we exclude relationships such as containment and >succession from this spec? > >1.d Should we specify a way for a document to provide a summary of >the linkage machinery it uses? > I think a summary in some easily found spot is highly desirable. Presumbly XML docs might be *large*. It will be a bind to have to wait for all 10MB to arrive before partial rendering with links visible. Also, a threaded implementation might make use of a linkage summary to do behind the scenes link work whilst simultaneously doing the rendering. Sean digitome@iol.ie %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:39:29 +0000 To: w3c-sgml-wg@www10.w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: Production 21 (and others) >On Thu, 30 Jan 1997 22:32:49 -0500 Dave Peterson said: >>At 4:30 PM 1/30/97, lee@sq.com wrote: >> >>>Folks, please stop this. >>>It won't help implementors. >>>It won't help users. >>> ... >>Quite. There is no rule engraved in stone that every aspect and >>restriction of the language must be captured in the productions. That >>which can without terrible complication should (8879 probably erred the >>other way) but there is no point in evolving more and more complicated >>productions except as an academic exercise. I too vote to kill this >>track. > >OK, I'll drop it. Before I do, I will just register my continued >opinion that the syntax of XML should be wholly explicit, where >mechanisms as simple as regular expressions suffice to describe it. I totally agree. Credibility amongst implementors is at stake. If comments are complex enough in regexp to warrant a BNF grammar instead then I say lets give'em a BNF. Sean digitome@iol.ie %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:39:22 +0000 To: w3c-sgml-wg@www10.w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: 1.5: Discuss link characteristics? >>From section 1.5 Types of link types > >1.5.a Shall we have a discussion of the characteristics links can > can have, including relationship, topology, locator language, > formatting, and behavior? > I think we need to somehow formalise what the various link types are supposed to do when "actioned". Otherwise, how can two implementations be compared are adjudicated correct or incorrect? I think a lot of dense prose explaining what they should do might be obviated by an implementation neutral expression of the dynamic semantics in something like Scheme (using groves presumably). Sean digitome@iol.ie %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:39:19 +0000 To: w3c-sgml-wg@www10.w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: 1.a: Use Elements? >Should links be expressed as SGML elements? > Yes. I think the benefits in simplicity far outweigh the name-space pollution it entails. I cannot think of a single markup scheme that does not have name-space pollution. I do not know a single potential implementor who whould be bothered with a "Reserved Element Names" page in the spec. Admission of Guilt: I am an extremist (admitting defeat) on this point! I would apply the same reasoning to remove other special syntactic constructs such as content models, PI's, Marked Sections, Catalogs etc. Sean Mc Grath digitome@iol.ie %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:29:15 +0000 To: Tim Bray , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: 1.4 d: Address terminology At 11:09 31/1/97 -0800, Tim Bray wrote: >1.4.d: What do we call the locator/adddress? > If we restrict ourselves to pointing to SGML elements only, then if locator and address are not good enough (which I believe they are) how about grove-point-identifier or grove-identification-point (which could be shortened to grip!)? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:29:11 +0000 To: Tim Bray , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: 1.a: Use Elements? At 11:08 31/1/97 -0800, Tim Bray wrote: >Should links be expressed as SGML elements? > Yes ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:29:08 +0000 To: Tim Bray , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? >1.c: Should we exclude relationships such as containment and >succession from this spec? No - We need concept like PARENT, CHILD, HERE and ROOT to make querying into documents that do not have any IDs or otherwised named anchor (or whatever they are called) points. > >1.d Should we specify a way for a document to provide a summary of >the linkage machinery it uses? If we can have a way of identifying the notation used for link definition, with ideally that notation pointing to the address of a Java class that can be used to implement the relevant notation, then we might be able make it possible for blind browsers to process newly invented notations. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:29:05 +0000 To: Tim Bray , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: 1.4 a-c: Basic Terminology >1.4.a What do we call the container used to hold the bits that > point at other things? (in current discussion: link) >1.4.b What do we call the bits that point at other things? (in current > discussion: pointer) >1.4.c What do we call the things that are pointed at? (in current > discussion: terminus) The thing that points at other things is an envelope (i.e. SGML container) that includes as one of its many properties the current address(es) of the object(s) to be located. One links a set of these addressed envelopes together and adds some material about why they have been linked to make them useful. The addressed envelopes are not butts, ends or rope knots.... They are address containers that can be used to locate objects over long periods of time. If we cannot recognize them as locators then we need to recognize the fact that what is important about them is that they include the current address of something that we will need to be able to locate, probably at another location, at some later date. They are a form of indexable address book entry. (Which is why they need to have IDs so that they can be easily reused!) If we cannot recognize them as an address of a location for some, to me illogical, reason then we must come up with some wording that indicates the role of the element that is better than end or butt. Perhaps we should call them 'chains to the post-points of information-homes' to show we are different, but to me 'links to the addresses of SGML containers' is the most logical way of describing them. NB: The last part of this will need to change when we realise that we absolutely need to address things at a lower level than SGML containers, but that argument seems to have been lost for this month! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:29:20 +0000 To: Tim Bray , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? (repost) At 11:50 31/1/97 -0800, Tim Bray wrote: >[Oops - cut & paste error, screwed this up first time around.] > >1.c Should we define a link processor and specify any actions > required of it? No - except for 1 default mechanism, which should exactly map an HTML . >1.d Should we specify a way for a document to provide a summary of > the linkage machinery it uses? Yes ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:29:17 +0000 To: Tim Bray , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: 1.5: Discuss link characteristics? At 11:09 31/1/97 -0800, Tim Bray wrote: >>From section 1.5 Types of link types > >1.5.a Shall we have a discussion of the characteristics links can > can have, including relationship, topology, locator language, > formatting, and behavior? > XML should not define the characteristics of links - this must be application specific. What XML could usefully do is provide a way of finding information about relationships, topology, locator language/notation, formatting and behaviour by providing suitable addresses for obtaining relevant information. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:00:21 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@www10.w3.org Subject: Re: XML catalog draft Lines: 46 I'd like to congratulate the CATALOG WG on an excellent document and one I wholeheartedly support. (Recursive) catalogs are important in my approach and I have had to implement them in a previous incarnation of CML (tcl/tk version). I did this from the sgmls man pages which are wonderfully precise (but understandably did not address the syntax of FPIs). CML is already 3 DTDs (TecML - generic, HTML2.0, and MOL). I have tried to design TecML as a 'core' DTD onto which specialist DTDs can be added (see http://www.venus.co.uk/omf/cml/doc/dtd for the mechanism). This uses a catalog to identify the various component DTDs to create a single DTD at parse time. CML is also capable of resolving a link within a document (hopefully to be an XML-LINK shortly) to a document using another (XML-based) DTD so long as this can be resolved via the catalog. (At that stage the additional Java classes are downloaded, but this is outside the topic). I particularly appreciate the WG's specification for FPI's since I regard them (in principle) as more stable than URLs. However, in using FPI's from documents on the WWW there appears to be variability in the 'FPI' for the 'same' object. In HTML 2.0 DTD, for example, the FPIs "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML" "-//IETF//DTD HTML 2.0//EN" and the string "ISO 12083:1993" occur. I have also seen "ISO 8879:1986" used in other documents at the start of the ENTITIES FPI. My impression, therefore, was that there is not enough _actual_ consistency in the literals used in FPIs, and that without this a catalog may have to hold a number of FPIs pointing to a single SGML document. For example, I can find several FPIs for HTML 2.0 (even without version numbers) - a catalog will have to hold them all. (BTW I think we should promote the idea that HTML documents can profitably be constructed as valid XML dcouments - in fact much of the HTML I see on the WWW is valid XML - assuming that the FPI in the DOCTYPE can be resolved!). This may be out of scope, but if the XML spec makes any reference to the syntax of FPIs, it will be valuable to give a definitive statement and some examples of good practice. P. Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 01 Feb 1997 11:49:46 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@www10.w3.org Subject: Re: text/xml volunteers needed Lines: 64 In message <199702010419.UAA28885@boethius.eng.sun.com> bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: > The ERB decided not long after the November XML rollout that it was > time to register the text/xml MIME type. Since then, I've been Jon, This is very dear to my heart - I can't volunteer (see below). [...] Henry Rzepa and I spent > 1 year proposing the value of a new top-level mime type (chemical/*) - in the end it faded into nowhere. It raised strong feelings (some supportive) but my .sig for a MIME type application may not be the best start at present. [In _practice_ the whole of our community now use chemical/* and so CML will be transmitted as the (ugly and IANA-incorrect) chemical/x-cml.] One suggestion made was that we should use text/sgml for CML, which though _technically_ correct is useless _in practice_. This is a problem which is going to reoccur as we develop non-textual applications. If I send someone a molecule/integrated_circuit/etc. and they read it in a current 'SGML browser' it won't do them much good at present. IFF the browser recognised the DTD _and_ had access for routing the whole problem to an appropriate system, fine - but that is asking a lot. A second possibility is application/xml. This would tell the client that a text/sgml processing system was inappropriate for the contents of the message. Indeed the first priority (assuming that there were no MIME subsubtypes) would be to process the DOCTYPE and retrieve the DTD. Then the system would almost certainly have to retrieve the processing software for that application. With CML/XML this would be something like: client receives application/xml document client fires up non-textual XML processor (e.g. a parser + generic TOC tool) client reads DOCTYPE client resolves FPI (or URL) in doctype. client retrieves DTD and parses the document (including validation). client asks for processing software (stylesheets and/or Java), presumably from server or gets indirection from server. client downloads software and processes document. If document contains XML-LINKS to an application/xml document (possibly with a different DTD) it (may) repeat the whole sequence of operations for the linked document. (You will also see why I consider it important for XML-LINK to give as much information as possible about the type of the object before actually reading it. MIME types seem the best way. ) > > Here's your chance to cover yourself with glory and become one of It is probably premature to submit application/xml at the same time (see the complexity of the above) but I think it would be a useful placeholder. (And, in general, if people are developing XML applications which don't fit into text/ , image/ , audio/ then they should either be considered for application/xml or ... :-). I cannot remember where the official process has got to on subsubtypes, but we could surely benefit from (say) application/xml.cml or similar P. -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 1 Feb 1997 10:46:42 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org cc: bosak@atlantic-83.eng.sun.com Subject: New members; archives updated Having been duly certified to me to be SGML experts, the following persons have been added to the W3C SGML Working Group: Murata Makoto, Fuji Xerox murata@apsdc.ksp.fujixerox.co.jp Todd Freter, Sun todd.freter@sun.com David Slocombe, Structured Information dns@vex.net Sarah Slocombe, Apropos Toy and Tool sarah@attd.com Peter Murray-Rust, Nottingham U. peter@ursus.demon.co.uk Liora Alschuler, The Word Electric liora@the-word-electric.com Peter Rauleder, Daimler-Benz rauleder@dbag.stg.daimlerbenz.com I have put the WG mail for the second half of January on sunsite.unc.edu in files named 9701a and 9701b: ftp://sunsite.unc.edu/pub/sun-info/standards/xml/wg/9701b.zip ftp://sunsite.unc.edu/pub/sun-info/standards/xml/wg/9701b.gz You can also use HTTP to retrieve these. As usual, I cannot guarantee that I received everything sent to the list, but these files contain everything that I did receive. The W3C archive for this group is publicly visible, so you are free to share these files with anyone who might be interested in our transactions. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 1 Feb 1997 10:57:37 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Current SGML ERB/WG roster I've just updated the roster of current ERB/WG members. For general information, the list is given below. Jon ======================================================================== W3C SGML ERB AND SGML WG ROSTER (Last updated: 1997.02.01) W3C Contact: Dan Connolly connolly@w3.org SGML ERB (ex officio members of the WG): Chair: Jon Bosak, Sun jon.bosak@sun.com Technical Lead: James Clark jjc@jclark.com Tim Bray, Textuality tbray@textuality.com Steve DeRose, EBT sjd@ebt.com Dave Hollander, HP dmh@hpsgml.fc.hp.com Eliot Kimber, Passage Systems drmacro@drmacro.com Tom Magliery, NCSA mag@ncsa.uiuc.edu Eve Maler, ArborText elm@arbortext.com Jean Paoli, Microsoft jeanpa@microsoft.com Peter Sharpe, SoftQuad peter@sqwest.bc.ca C. M. Sperberg-McQueen, U. of Ill. U35395@UICVM.UIC.EDU WG members who are not on the ERB: David Abrahamson, Trin. Coll., Dublin david.abrahamson@cs.tcd.ie Sharon Adler, EBT sca@ebt.com Terry Allen, Fujitsu Software tallen@fsc.fujitsu.com Liora Alschuler, The Word Electric liora@the-word-electric.com Paula Angerstein, Texcel paula@texcel.no Murray Altheim, Spyglass murray@spyglass.com Todd Bauman, U. of Maryland bbauma1@cs.umbc.edu Barbara Beeton, Amer. Math. Soc. bnb@math.ams.org Anders Berglund, EBT alb@ebt.com Karl Best, Adobe kbest@adobe.com Michel Biezunski, High Text michel@hightext.com Harvey Bingham, SGML consultant hbingham@acm.org David Birnbaum, U. Pittsburgh djbpitt+@pitt.edu Tom Borgman, Interleaf tborgman@tomb.hq.ileaf.com Elaine Brennan, SGML Consultant elaine@netcom.com Steve Brown, InfoObjects sbrown@cortland.com Martin Bryan, SGML Centre mtbryan@sgml.u-net.com Mark Buckley, Microsoft mbuckley@microsoft.com Len Bullard, Lockheed-Martin cbullard@HiWAAY.net Lou Burnard, Oxford University lou@vax.ox.ac.uk François Chahuneau, AIS fcha@berger-levrault.fr Kurt Conrad, Sagebrush Group conrad@cbvcp.com Paul Cope, auto-graphics prc@auto-graphics.com Keith Corbett, Harlequin kmc@harlequin.com Martin Cottreau, Andyne martinc@andyne.com Robin Cover, SIL robin@acadcomp.sil.org Lori DeFurio, Adobe ldefurio@adobe.com Derek Denny-Brown, CRI ddb@criinc.com Dave Durand, Boston University dgd@cs.bu.edu Carol Ellerbeck, INSO Carol_Ellerbeck@inso.com Joe English, CR Laboratories jenglish@crl.com Ralph Ferris, Fujitsu OSSI ralph@ossi.com Peter Flynn, University College, Cork pflynn@curia.ucc.ie Lee Fogal, Digital Equipment fogal@zk3.dec.com Todd Freter, Sun todd.freter@sun.com Matthew Fuchs, Disney Imagineering matt@wdi.disney.com Charles Goldfarb, Info. Management charles@sgmlsource.com Tony Graham, Mulberry tgraham@mulberrytech.com Paul Grosso, ArborText paul@arbortext.com Eduardo Gutentag, Sun eduardo@eng.sun.com Hasse Haitto, Synex haitto@synex.se Catherine Hamon, Hightext hamon@hightext.com Ken Holman, Microstar gkholman@microstar.com John Iobst, Newspaper Assoc. of America iobsj@naa.org Rick Jelliffe, Allette Systems ricko@allette.com.au Alan Karben, Wall Street Journal karben@interactive.wsj.com Pär Karlsson, Ericsson etxpkar@stdoca.ericsson.se Debbie Lapeyre, Mulberry Technologies dlapeyre@mulberrytech.com John Lavagnino, Martin Hensel/Brown U. john_lavagnino@brown.edu Bill Lindsey, BDM Technologies blindsey@BDMTech.com Per Åke Ling, Ericsson etxperl@stdoca.ericsson.se Megan MacMillan, BDM Technologies megan@bdmtech.com Sean Mc Grath, Digitome digitome@iol.ie Mary McRae, Xyvision mmcrae@xyvision.com Christopher Maden, EBT crm@ebt.com Murata Makoto, Fuji Xerox murata@apsdc.ksp.fujixerox.co.jp Murray Maloney, SoftQuad murray@sq.com Satwinder Mangat, Novell smangat@novell.com James Mason, ORNL masonjd@ornl.gov Norbert Mikula, U. Klagenfurt e_nmiku@utila.ifi.uni-klu.ac.at Alex Milowski, Copernican Solutions alex@copsol.com Ed Mooney, Sun emooney@east.sun.com Gregory Murphy, CETH Princeton/Rutgers gjmurphy@cethsun.Princeton.EDU Peter Murray-Rust, Nottingham U. peter@ursus.demon.co.uk Steve Newcomb, TechnoTeacher srn@techno.com Gavin Nicol, EBT gtn@ebt.com Joakim Östman, Citec jos@citec.fi Nancy Paisner, Borland npaisner@oec.com Gary Palmer, ActiveSystems gpalmer@sonetis.com Steve Pepper, Falch pepper@falch.no Dave Peterson, SGMLWorks! davep@acm.org Martin Pike, Stilo mp@stilo.demon.co.uk Paul Prescod, U. of Waterloo papresco@calum.csclub.uwaterloo.ca Lynne Price, SGML consultant lprice@ix.netcom.com Roger Price, U. Mass. Lowell rprice@cs.uml.edu Liam Quin, SoftQuad lee@sq.com Peter Rauleder, Daimler-Benz rauleder@dbag.stg.daimlerbenz.com Arjun Ray, Q2-II aray@q2.net David Slocombe, Structured Information dns@vex.net Sarah Slocombe, Apropos Toy and Tool sarah@attd.com Bill Smith, Sun bill.smith@sun.com Thomas Stadler, STEP ths@step.de Bob Stayton, SCO bobs@sco.com Robert Streich, Schlumberger streich@slb.com Jeff Suttor, Sun jeff.suttor@sun.com James Tauber, U. of Western Australia jtauber@jtauber.com Wayne Taylor, Novell wtaylor@novell.com Henry Thompson, U. of Edinburgh ht@cogsci.ed.ac.uk Sarah G.E. Tourville, SAGRELTO sagrelto@mindspring.com Pim van der Eijk, SGML consultant pvde@nedernet.nl Norm Walsh, O'Reilly norm@ora.com Sam Wilmott, OmniMark s.wilmott@omnimark.com Chris Wilson, Microsoft cwilso@microsoft.com Wayne Wohler, IBM wohler@vnet.ibm.com Lauren Wood, SoftQuad lauren@sqwest.bc.ca Russ Young, Folio ryoung@folio.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 1 Feb 1997 11:13:48 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org cc: bosak@atlantic-83.eng.sun.com Subject: XML and DSSSL at WWW6 In addition to more formal presentations that will be given at the World Wide Web Conference in April (technical papers have been submitted, and this activity is a part of the W3C track), I'm thinking that it might be a good idea to take advantage of the new half-day workshop format (see http://www6conf.slac.stanford.edu/workshops) to hold working sessions on XML and DSSSL. The idea would be to hold a half-day workshop on XML Monday morning, April 7, and a half-day workshop on DSSSL that afternoon. This would tie in nicely with reports on XML and DSSSL during Developer's Day (Friday, April 11). This idea may conflict with plans that other people might already have made, but I didn't realize until this morning that the half-day format was an option. The deadline for filing workshop proposals is this Monday, February 3, so I have to act quickly to reserve these spots. Please contact me off the list if you happen to know of any potential collisions. What I need to know from the WG is, who can commit to attending either or both of these workshops? The conference is being held in Santa Clara, California; please see http://www6conf.slac.stanford.edu/ for conference information, and get back to me BY PRIVATE MAIL (don't clutter the list with this) if you feel confident that you will be able to participate in one or both of the workshops. I would like to know by Monday if possible so that I can word the proposals appropriately. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 1 Feb 1997 11:24:24 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Discussions foreground and background Please note in considering the slew of questions that have just been dumped into the WG that some things have to be addressed right away and some things don't. The XML catalog proposal is the continuation of a debate that has been going on since September; this needs your careful consideration, but it's not something that has to be decided right away. The numbered questions that Tim Bray posted, however, will be considered by the ERB on Wednesday, so if you have anything at all to say on these subjects, you'd better say it now. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 1 Feb 97 16:35:27 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: text/xml volunteers needed Peter@ursus.demon.co.uk (Peter Murray-Rust) wrote: > One suggestion made was that we should use text/sgml for CML, which though > _technically_ correct is useless _in practice_. This is a problem which > is going to reoccur as we develop non-textual applications. If I send > someone a molecule/integrated_circuit/etc. and they read it in a current > 'SGML browser' it won't > do them much good at present. IFF the browser recognised the DTD _and_ > had access for routing the whole problem to an appropriate system, fine - > but that is asking a lot. The distinction between text/ and application/ is two-fold; (1) if people can, in the worst case, make sense of the document by looking at the source, it should be text/* (2) text/* documents are subject to newline substitution, so that CR or LF is translated to CR LF for transmission as MIME requires. They are also (strictly speaking) subject to a 72 octet line limit, when they are transmitted as text. This is why NAMELEN is set to (I think) 70 in RFC 1866, for example. (3) application/* documents are sent as binary images -- i.e. no transformations are performed on the stream -- and the expectation is that without the correct viewer, you can do nothing. For CML, the best thing would be to use content negotiation, and send the document as text/cml if you have a cml viewer, and text/sgml if you have no CML viewer but do have an SGML viewer, and perhaps text/html or text/plain otherwise... For XML, the MIME type should be text/xml. Note that most current HTTP servers may go wrong with text Unicode files, performing incorrect CR LF substitution. However, as more HTML documents use Unicode, this will quickly get fixed. With regard to your other mesage (Peter), note also that very few (if any) existing HTML documents are valid XML documents, as they (1) lack the processing instruction at the start, and more importantly (2) are not well-formed, because they use the "wrong" syntax for EMPTY elements (
instead of
) and use OMITTAG. They also use SHORTTAG, but this is YES in the XML SGML declaration in order to allow use of NET, and hence is sort of half allowed ;-), although forbidden by the XML specification prose. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 1 Feb 1997 16:58:01 -0500 To: lee@sq.com, w3c-sgml-wg@www10.w3.org From: davep@acm.org (Dave Peterson) Subject: Re: text/xml volunteers needed At 4:35 PM 2/1/97, lee@sq.com wrote: >With regard to your other mesage (Peter), note also that very few >(if any) existing HTML documents are valid XML documents, as they > (1) lack the processing instruction at the start, and more importantly > (2) are not well-formed, because they use the "wrong" syntax for EMPTY > elements (
instead of
) and use OMITTAG. > >They also use SHORTTAG, but this is YES in the XML SGML declaration in >order to allow use of NET, and hence is sort of half allowed ;-), although >forbidden by the XML specification prose. If "forbidden by the XML specification prose", then using SHORTTAG other than for the NET trickery is forbidden in XML, not "sort of half allowed". In any case, as soon as the TC is adopted, XML will cease treating the "CPTAGC" as a NET, and presumably will specify SHORTTAG NO. Don't expect *any* XML system to tolerate other SHORTTAG stuff. Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 1 Feb 97 22:05:27 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: text/xml volunteers needed [SHORTTAG] > >They also use SHORTTAG, but this is YES in the XML SGML declaration in > >order to allow use of NET, and hence is sort of half allowed ;-), although > >forbidden by the XML specification prose. > > If "forbidden by the XML specification prose", then using SHORTTAG other > than for the NET trickery is forbidden in XML, not "sort of half allowed". > > In any case, as soon as the TC is adopted, XML will cease treating the > "CPTAGC" as a NET, and presumably will specify SHORTTAG NO. > > Don't expect *any* XML system to tolerate other SHORTTAG stuff. I expect that all currently existing SGML systems that support XML at all will tolerate all SHORTTAG stuff, as well as incorrect use of the NET syntax. This has been discussed before, and I meant nothing more than this by "half allowed". I'm sorry I wasn't clear. The context was one of pragmatic validation, where it is relevant. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:12:55 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4 a-c: Basic Terminology At 11:09 AM 1/31/97, Tim Bray wrote: >Note: On this item, the ERB is leaning towards using the terms link, with the >obvious meeting, pointer for the pointy bits that point at things, and for >the >third term, what the current spec calls anchor, the ERB is contemplating >link end, end, and terminus. > >For the time being, and in order that Jon can read this without getting >headaches, the spec has been adjusted to use link, pointer, and terminus. > >1.4.a What do we call the container used to hold the bits that > point at other things? (in current discussion: link) >1.4.b What do we call the bits that point at other things? (in current > discussion: pointer) >1.4.c What do we call the things that are pointed at? (in current > discussion: terminus) I can deal with "terminus" or "link end". End is too generic for clarity, I think. And I think we need to separate address from pointer for reasons already posted. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:12 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4 e: ordinality of directionality At 11:09 AM 1/31/97, Tim Bray wrote: >1.4.e Should we get into talking about bi/multi directional links? Yes, but let's not wax philosophical on the issue. It's a clear place where XML can get a lot of power, so we do need the capability. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:29 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4 a-c: Basic Terminology At 4:26 PM 1/31/97, Murray Altheim wrote: > 1.4.d What do we call the things that point at other things as well as > are pointed at? > >This follows from my other message regarding links (nee HTML Anchors) that >contained both NAME and HREF attributes. I think we can stick to terminus and pointer. It might be worth a qualifying phrase to point out that a pointer _might_ also be a terminus. I don't think we will need to refer to a pointer that is also a terminus often enough that we need to make up more terms. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:20 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.5: Discuss link characteristics? At 11:09 AM 1/31/97, Tim Bray wrote: >>From section 1.5 Types of link types > >1.5.a Shall we have a discussion of the characteristics links can > can have, including relationship, topology, locator language, > formatting, and behavior? Given the variety of linking models out there, I think we will have to, if we want to be easily understood. It should be as minimal as we can manage, and I think should be part of the introduction, so as to make absolutely clear the separation between why the spec exists and its normative features. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:02 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.b: Excluded relationships At 11:08 AM 1/31/97, Tim Bray wrote: >Should we exclude relationships such as containment and >succession from this spec? We need not (and I would not) specify how to use links to represent these, but should not banish these notions from the format of addresses. The point is that in XML, these are better represented by XML features, than links. On the other hand, I'm not averse to showing (as an example, not normative text) how XML can help you to better manage HTML-style links. I am also assuming that transclusion rendering semantics are _not_ an instance of containment, as can be seen from the fact that meta-properties like authorship do not propogate over transcusion boundaries. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:12:41 -0500 To: digitome@iol.ie (Digitome Ltd.), w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.a: Use Elements? At 6:39 AM 2/1/97, Digitome Ltd. wrote: >>Should links be expressed as SGML elements? There is a critical ambiguity in this question, which I point out in the next post, but your interpretation is clear, so I can answer it first. >Yes. > >I think the benefits in simplicity far outweigh the name-space pollution >it entails. I cannot think of a single markup scheme that does not have >name-space pollution. I do not know a single potential implementor >who whould be bothered with a "Reserved Element Names" page in the spec. I think the problem with reserved names is not for implementors -- they only need to type in a table of reserved words -- but for users, who can get unpredictable results if they don't know (or forget) that a keyword they don't use is reserved. Especially when users can define their own syntax, namespace pollution is a user problem. Now PL/I solved this by letting people override syntactic keywords. So if I defined a variable called "do" then the "do"-loop (equivalent to "for" loops) was simply syntactically unavailable. This seems also bad, though there's an argument for it. Finally, if we pick really nice names we are inconveniencing people by removing sensible names for document objects form their namespace, but if we pick ugly names, then we are inconveniencing the users of the linking features. Furthermore, if we reserve element names, even XML users who don't use XHL will have to worry about processors misinterpreting XHL-conflicting element names, unless we have a special turn-on signal for XHL -- and if we _do_ have that, we might as well let people remap the names while they're signalling the document's XHL-link-nature. In summary, I don't think the arguments for element names save you very much. >Admission of Guilt: I am an extremist (admitting defeat) on this point! Too soon, I think. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:09 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4.g: define/discuss Traversal? At 11:09 AM 1/31/97, Tim Bray wrote: >1.4.g Should we define/discuss traversal? I think the term traversal implies a specific processing model too precisely; I want to use links to write my footnotes, but have them rendered inline. Calling this traversal is consistent but confusing. Similarly for drawing a map based on a set of links (where we might not even have to fetch the documents). I think the linking markup should talk about processing, and the link processing spec needs to define a variety of kinds of traversal. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:07 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4 f: terms for links colocated with their ends At 11:09 AM 1/31/97, Tim Bray wrote: >1.4.f Should we define terms for links that are colocated with their > ends, and if so, should we use in-line and out-of-line? I like the terms, but if we decide to generalize things so that a pointer's address can specify that the link is one of its own termini, we may not need the distinction for the sake of the spec. It might be worth introducing these terms as names for the idioms, even if we do perform this generalization. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:18 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.1.a Formatting Issues Out of Scope? At 11:09 AM 1/31/97, Tim Bray wrote: >1.1.a are formatting issues (aside from perhaps a metadata slot) >outside of scope? Yes, with a qualification: It is outside of the _markup definition_ scope. We _must_ make decisions on a base set of formatting primitives for link processing, but that can wait until we have defined _what_ they will have available to process. We can delay making Len happy, but we I think we have to. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:23 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.3, Notation: SGML? Reference Concrete? At 11:09 AM 1/31/97, Tim Bray wrote: >1.3.a Should we assume that saying links are expressed using SGML elements >and attributes, and describing them in SGML terms, is a satisfactorily >complete syntax spec, thus avoiding a requirement for any BNF? We don't need BNF, I agree, but we should use some variant of the "architecture" approach. >1.3.b If links are SGML elements, should require XML-style reference >concrete syntax + quoted attribute values? I.e. assert that >all links would fit into XML docs? YES! YES! No _more_ syntax is required, so no more should be forthcoming! -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:27 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Subject headings -- and multiple CCs At 12:21 PM 1/31/97, Jon Bosak wrote: >Just a friendly reminder: >Also, you will substantially decrease the level of irritation among >many members of the WG if you will take a few seconds to make sure >that your reply is not redundantly copied to individuals but is posted >only to the list server. The following unauthorized re-posting is a very coherent explanation of why we _should_ change the mailing list software. (address removed to save the author from misdirected followups). (Don Blaheta) Ok, diatribe time. A number of mailing lists perform "reply-to munging" on all messages they process. This makes responses go back to the list by default. There are numerous advantages and disadvantages to this sort of thing. The problem with a lack of munging is, as BRG says, that replies directly to the list require a user to either type in the list name explicitly, or else to do some sort of group-reply, which also includes the sender, which means that after a thread gets started, every participant gets duplicate copies. Yuck. Reply-to munging solves this problem nicely, because a regular reply will be sent to the list. However, it makes it difficult to send replies to the original sender, as is occasionally appropriate. It makes it especially difficult if the sender has a bad mailing system and used the Reply-to field to specify their return address. An additional difficulty with either system is that people will forget to send it to the right address. On a munged list, this means that they will accidentally send a private message to the list, and on a non-munged list, this means that they will accidentally send a public message to just one person. In my experience, the former is far less common (less than once a month, usually), while the latter is not only common, but also highly annoying since the message does not reach most of its target audience. However, to throw another wrench into the problem, a fairly recently-devloped mailer called Mutt has come about, and it has a command "list-reply", which replies directly to the list even if it wasn't munged. Because this feature exists on a single mailer, people now say that there is no reason to use munging at all, ever, although so many people still use elm and pine that all the problems of a non-munged list are still just as bad as they ever were. So basically, it's just a judgement call. I say that most lists (discussion lists, at least) should munge their reply-to fields, including conlang and auxlang, but I thought y'all should be informed. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:31 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4 a-c: Basic Terminology At 6:29 AM 2/1/97, Martin Bryan wrote: >NB: The last part of this will need to change when we realise that we >absolutely need to address things at a lower level than SGML containers, but >that argument seems to have been lost for this month! No, No. That's one of the things that _will_ change between draft and final draft. Throwing out span termini is a terrible idea, that makes it impossible for XML linking to deal with non-XML data. A prescription for misery, I think. We _must_ have sub-element addressing. If this was not pushed hard before the draft, it was because few people seriously advocated leaving it out, I thought. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:12:50 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.a: Use Elements? -- critical ambiguity in question! At 11:08 AM 1/31/97, Tim Bray wrote: >Should links be expressed as SGML elements? This could mean one of 2 very different things: 1. Should the syntax of links somehow involve the use of elements as opposed to entities, PIs or other SGML (or ad-hoc) features? Answer(for me): YES. 2. Should the syntax of links involve fixed element name definitions? Answer(for me): Definitely not! As this has been a significant part of the last month's discussion, I will wait to see how the discussion goes, before frobbing the issue again. I vote that we add a new XML declaration (that looks like a PI) to declare AF roles for elements, including a setting that simply maps all AFs to their element names. Or that we use architectural forms, the Internal subset, and separate attribute declaration to solve the problem in an SGML-like way. So: Should be enough, or: or: ]> -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:12:53 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4 d: Address terminology -- Another possible ambiguity. At 11:09 AM 1/31/97, Tim Bray wrote: >1.4.d: What do we call the locator/adddress? I think we need to distinguish between a "pointer" (an element or attribute related to a link, that designates a particular terminus) and the "address" (string component of a pointer that indicates a particular terminus). Eg. a pointer might be the HREF attribute of an A element. an address would be a URL. I think pointer is good for what I say above (and compatible with the working terminology, which I like quite well). I think having the term address will ease the addressing discussion and keep it orthogonal to attribute/element wars, and the like. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:16 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? At 11:09 AM 1/31/97, Tim Bray wrote: >1.c: Should we exclude relationships such as containment and >succession from this spec? How is this different from 1.b? Otherwise, what I said. >1.d Should we specify a way for a document to provide a summary of >the linkage machinery it uses? Yes, as users need to be able to choose their options. I think that we should _not_ have explicit leeway for implementors to vary implementations within XML Linking. They can extend, but such extensions should be _clearly outside_ the scope of the standard... There's nothing to stop people from implementing new features, just as anyone can put new tags into HTML, but they should not be able to claim that their new feature is "part" of XML linking, unless it is universally mandated. This is essentially the hypertext extension of the "no options" policy goal. In particular we have to bite the buillet and decide what address formats are legal and not, what link facilities are legal or not. Extensions _will_ duke it out in the marketplace, but we need a well-defined, interoperable base of functionality. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:25 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? (repost) At 11:50 AM 1/31/97, Tim Bray wrote: >[Oops - cut & paste error, screwed this up first time around.] Now I understand! >1.c Should we define a link processor and specify any actions > required of it? As a separate document, or possibly as a part of the processing spec ("style sheet") language. We should separate the descriptive and procedural aspects, but for linking, people _expect_ and _require_ at least a minimal set of procedures -- and unlike text formatting are much more naive about the possibilities. >1.d Should we specify a way for a document to provide a summary of > the linkage machinery it uses? Already answered this. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 2 Feb 1997 15:13:33 -0500 To: Martin Bryan , Tim Bray , w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? At 6:29 AM 2/1/97, Martin Bryan wrote: >>1.c: Should we exclude relationships such as containment and >>succession from this spec? > >No - We need concept like PARENT, CHILD, HERE and ROOT to make querying into >documents that do not have any IDs or otherwised named anchor (or whatever >they are called) points. An interesting point. This would allow XML linking to externally attach markup to non-XML data. While I like the idea, and have specified such markup in projects that I'e worked on, I'm not sure that XML can't live without it. I agree that it would be good if we had it though.... >>1.d Should we specify a way for a document to provide a summary of >>the linkage machinery it uses? > >If we can have a way of identifying the notation used for link definition, >with ideally that notation pointing to the address of a Java class that can >be used to implement the relevant notation, then we might be able make it >possible for blind browsers to process newly invented notations. And _impossible_ for blind users to use those notations, because they invoke a bunch of AWT crap-code that can't be interpreted (turing complete, don't you know), and whose execution is pointless. This is one of many reasons that executable specifications must be applied _after_ a declaration of type (And to effectively require the type declaration, we need to make it part of attaching the processing spec, since most people don't look far enough ahead to see that other renderings may be appropriate. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 02 Feb 1997 18:01:58 -0500 To: Tim Bray From: "Eve L. Maler" Subject: Re: 1.4 a-c: Basic Terminology Cc: w3c-sgml-wg@www10.w3.org At 11:09 AM 1/31/97 -0800, Tim Bray wrote: >1.4.a What do we call the container used to hold the bits that > point at other things? (in current discussion: link) I've been stewing on this a lot. "Link" has the same problem that "marry" does: two people can be married (linked), but a clergymember or justice of the peace might also marry (link) them. This ambiguity is driving me nuts. I've found an alternative that I can live with and doesn't require clever adjectives: link (for in-line links) and association (for out-of-line links). Then, a "link" becomes a relationship between termini that's expressed in an element at one of the termini, and an "association" becomes a relationship between termini that's expressed in an element at some neutral, non-terminus location. >1.4.b What do we call the bits that point at other things? (in current > discussion: pointer) I agree that it's a good idea to distinguish pointer and address. E.g., if we end up allowing spans, and it takes two attributes ("startspan" and "endspan") to do spans, I assume that each one contains an address; do the two attributes together constitute the pointer? >1.4.c What do we call the things that are pointed at? (in current > discussion: terminus) Sure! (I think I came up with this one.) Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 2 Feb 97 18:28:05 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: 1.4 a-c: Basic Terminology > We _must_ have sub-element addressing. I think it would be a very useful and sensible feature. It's a major thing that most HTML browsers can't do today, but more importantly it's very useful for annotations, marking reviewer's changes, and for marking remote search results, all things you want to do over the Internet. If SDQL is used, you get the possible benefit of being able to apply styles to "pseudo-elements" as well. It would make no sense for the style sheet language and the hypertext language to use different sorts of locator/finding-things-in-documents languages. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 2 Feb 97 18:31:28 EST To: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: 1.a: Use Elements? -- critical ambiguity in question! David Durand said: > I vote that we add a new XML declaration (that looks like a PI) to > declare AF roles for elements, including a setting that simply maps all AFs > to their element names. I like this approach too. > > Should be enough, or: > > This might better be I don't see any need for XHL as an abbreviation. > Or that we use architectural forms, the Internal > subset, and separate attribute declaration to solve the problem in an > SGML-like way. > > [ > > ]> This doesn't work if the element called LINK already has other attributes declared in the DTD. If SGL is changed to allow multiple AttList declarations for a given element, it would be well worth considering, though. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 02 Feb 1997 20:08:36 -0500 To: lee@sq.com From: "Eve L. Maler" Subject: Re: 1.a: Use Elements? -- critical ambiguity in question! Cc: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org At 06:31 PM 2/2/97 EST, lee@sq.com wrote: >David Durand said: > >> I vote that we add a new XML declaration (that looks like a PI) to >> declare AF roles for elements, including a setting that simply maps all AFs >> to their element names. > >I like this approach too. >> >> Should be enough, or: >> >> >This might better be > > >I don't see any need for XHL as an abbreviation. > >> Or that we use architectural forms, the Internal >> subset, and separate attribute declaration to solve the problem in an >> SGML-like way. >> >> > [ >> >> ]> > >This doesn't work if the element called LINK already has >other attributes declared in the DTD. If SGL is changed to >allow multiple AttList declarations for a given element, it >would be well worth considering, though. > >Lee I've been doing some link doodling, and have come up with some architectural forms for in-line and out-of-line links. In the course of that stuff, I got to thinking that the most useful PI would be one that simulates the effect of multiple ATTLISTs, even if we don't quite have multiple ATTLISTs yet. The following conforms to my own in-line link AF (so please excuse any disconnects with the draft spec); it shows the mapping of the DocBook element PrimaryIE, which has an IDREFs attribute for linking from the index to locations within the text, to the in-line link form: (It's assumed that the original IDREFs attribute on PrimaryIE, called "linkends", was already declared in the "real" ATTLIST.) If we use AFs, we'll need a capability for attribute design that's more sophisticated than we can get by trying to duplicate ATTLIST functionality in a PI of another form. And presumably the existing parsers would already know how to handle it. Plus, it's already designed -- no waiting! Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 2 Feb 97 21:28:52 EST To: elm@arbortext.com, lee@sq.com Subject: Re: 1.a: Use Elements? -- critical ambiguity in question! Cc: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Eve, your idea is an interesting one: > xml (linkto) "linkto" > xmlnames CDATA #FIXED "linkends ptr" > scheme (intid) "intid" > ?> but I think I see a problem with it -- XML documents would use these extra attributes, but they would not be declared to the SGML parser, and the result would not be valid SGML. Now, at one point, a partial DTD wasn't allowed -- it had to be all or nothing. If that's still the case, the rules on undeclared entities are inconsistent. But if it isn't the case, I think we must either (1) apply pressure for multiple Attlists, and help draw up a draft amendment if necessary; (2) until then, stick to markup that is clearly different. or even Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@www10.w3.org Subject: Re: 1.a: Use Elements? -- critical ambiguity in question! <9702030228.AA04183@sqrex.sq.com> Date: Sun, 02 Feb 1997 21:46:37 -0500 From: Eve Maler >Eve, your idea is an interesting one: >> > xml (linkto) "linkto" >> xmlnames CDATA #FIXED "linkends ptr" >> scheme (intid) "intid" >> ?> > >but I think I see a problem with it -- XML documents would use these >extra attributes, but they would not be declared to the SGML parser, >and the result would not be valid SGML. > >Now, at one point, a partial DTD wasn't allowed -- it had to be all >or nothing. If that's still the case, the rules on undeclared entities >are inconsistent. But if it isn't the case, I think we must either >(1) apply pressure for multiple Attlists, and help draw up a draft > amendment if necessary; > >(2) until then, stick to markup that is clearly different. > > > > > or even > > >Lee I see your point. Does this mean that without multiple ATTLISTs, there's no point in our even defining architectures? Then again, if we only allowed #FIXED attributes (and possible the other "fixed" token value method that I used above) in the ATTLIST PI, and specified that these attributes not appear in the instance, SGML wouldn't have a problem with it. Yuck...too many if's. I think I just talked myself out of it. Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 03 Feb 1997 14:15:49 +0000 (GMT) From: Peter Flynn Subject: Re: Sample Question To: w3c-sgml-wg@www10.w3.org Len Bullard writes: > >

Your IP address is write(request.ip) > > write( > > Last time your were " + client.oldname + "."]]) > > Yep. Now, what is the short sweet clear language that tells > the executive why he must require his programmers or IS specialists > to switch to this when what they have looks a lot like this > and is working? What do we say when he says, "But my browser > vendor says this is 'stupid', slows down the system, and they > will never support it"? How do we convince him that it is > worth the extra money and considerable risk to move off of > working platforms onto other platforms just to get closed > tags, obscure syntax, and fatter files? The short answer is that they should never be seeing it, as any half-way decent compliant XML editor would be set up to know that 's contents must be shielded, and put in the CDATA marked section automagically. In reality :-) you're quites correct: the browser vendors will simply not support syntax that costs them money to program around for no obvious benefit apart from the warm fuzzy glow of knowing they conform to 8879, regardless of how much easier it might make things in the middle or long term. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 97 09:33:31 CST From: Michael Sperberg-McQueen Subject: Re: 1.a: Use Elements? -- critical ambiguity in question! To: W3C SGML Working Group David's, Eve's, and Lee's sketches of possible markup for declaring use of XHL architectural forms looked interesting to me, but I confess I didn't understand any of them very well. Would you be willing to provide simple prose glosses for those of us in the back of the class, saying what information a processor is to glean from Something along the lines of 'This indicates that the element BLORT in the document corresponds to the architectural form FARBLE as specified in the XHL draft, and the AF's attributes FOO, BAR, FU, and MANCHU appear in the document as PHEW, HAR, WHO, and ATCHOO; it also signals that the intended action is to EMBED the object pointed at.' I realize that you probably omitted the gloss on the grounds that the meaning was intuitively obvious. So here's a reality check: it wasn't, at least to me, at least not in full. If I'm the only one on the list who didn't grasp it all, feel free to send your glosses only to me, or to ignore this request. C. M. Sperberg-McQueen %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Feb 97 10:03:40 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@www10.w3.org Subject: Re: XML catalog draft > From: lee@sq.com > Date: Sat, 1 Feb 97 01:43:55 EST > > I want to make sure that it does not forbid a system that uses a remote > lookup in a database instead of a catalog (for example). The catalog proposal says: If an entity has a public identifier, an XML processor may retrieve the content of the entity using any mapping of public identifier to system identifier that it wishes; in the interest of document portability, this specification describes a particular mapping that is recommended but not required. Further on, it says: When an XML processor encounters an external entity defined by a public identifier, the processor may, but need not, determine the associated system identifier required for the tasks described in section 4.3 of this specification from a supplemental XML catalog. Do you still feel additional or modified wording is needed so that this proposal "does not forbid a system that uses a remote lookup in a database instead of a catalog (for example)"? > > We need to be 200% clear on what happens if both system and public ID > are given: > * is catalog consulted? > * what happens if the catalog lookup gives a different result than > the system identifier? For Panorama, the system identifier on > the DOCTYPE line usually wins in that case. But it actually > depends on the user's preferences. Author/Editor ignores > the PUBLIC identifier if there is a SYSTEM one. While the SGML Open TR9401 does require an implementation to allow a user to choose either to "prefer SYSTEM" or "prefer PUBLIC", the current XML catalog proposal was simplified so that PUBLIC is always preferred. If there is a PUBLIC id (whether or not there is also a SYSTEM id) and a catalog is being used, the catalog is consulted. If using the PUBLIC id results in finding the external entity, any SYSTEM id included in the original ExternalID is ignored. All this was meant to be addressed in the current XML proposal by the following wording: If an entity has a public identifier, an XML processor may retrieve the content of the entity using any mapping of public identifier to system identifier that it wishes;. . . Regardless of the resolution process attempted, if the XML processor cannot successfully use or resolve the public identifer, and a system identifier follows the public identifier, the XML processor shall behave as if the system identifier was the only identifier supplied. If the XML processor cannot successfully use or resolve the public identifier, and a system identifier does not follow the public identifier, the XML processor shall behave as if a system identifier could not be resolved. Perhaps preceding the current first sentence of the second above quoted paragraph with a new initial sentence as follows would help: If an ExternalID has a public identifier, the XML processor shall first attempt to retrieve the contents of the entity by using or resolving the public identifier. > > We also need to say what happens when catalog is not found. > > We also need to say exactly where to find the catalog file. > Does a processing instruction in the document header point to it, > for example? What if the XML document is generated as the result of > a cgi query, so that there is no "current directory" of the document...? > What if we don't have a "base URL" for the XML document? Our subgroup mentioned this point, and we decided this was not necessarily part of adding public identifiers to XML. PaulP offered to write up some suggestions in this area as a separate task so as to avoid confounding public IDs and catalogs with questions of how to "package" XML applications that might include document instance files, external XML entities, graphics, style sheets, catalogs, etc. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 10:01:27 -0600 From: Len Bullard To: Peter Flynn CC: w3c-sgml-wg@www10.w3.org Subject: Re: Sample Question Peter Flynn wrote: > The short answer is that they should never be seeing it, as any > half-way decent compliant XML editor would be set up to know that > 's contents must be shielded, and put in the CDATA marked > section automagically. Right. Which makes me wonder why they need the tags there. I'm still reading the LiveWire document. Perhaps all will be revealed. > In reality :-) you're quites correct: the browser vendors will simply > not support syntax that costs them money to program around for no > obvious benefit apart from the warm fuzzy glow of knowing they conform > to 8879, regardless of how much easier it might make things in the > middle or long term. So it becomes a marketing wedge. XML evangelists have to extol the virtues of having control of the markup even where the need to provide a processing specification exists. We have to make these vitues crystal clear. Use of HTML and server-side HTML will continue. However, once understood, it is possible that the customer base will demand XML applications be supported and if the browser vendors do not, they lose market position the same way Microsoft did temporarily by ignoring the WWW for a little too long. This comes down to running code. Do not underestimate the power of the media to screw this up when prompted by their favorite browser vendor. I hope SGML Open is preparing a blizzard of materials. I also hope the upcoming conference is not premature. Don't blow it with technoSpeak. The attendees do not need to understand delimeters: they need to see how many more things are possible if XML is applied. If we can't make that presentation, this is a dirigible in an age of jet transport, or will be perceived that way. The trick is to get across the notion that XML has the jet engines. Ok. Off list with this one now. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 16:13:07 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@www10.w3.org Subject: Syntax of PIs Lines: 38 (please excuse an ignorant question) I am confused about the syntax of PIs (or at least markup which begins with the '' and sometimes only with a '>' For example here is some recent correspondence from several WG members > > > > > [...] > > xml (linkto) "linkto" > xmlnames CDATA #FIXED "linkends ptr" > scheme (intid) "intid" > ?> > > > > > > In the draft (2.5) <9 Processing instructions> it seems clear that '?>' is required but in 2.8 <12 ...> it gives whereas in 2.9 <13 ...> and 3.5 <25...> a closing '?>' is required. Peter -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 10:21:04 -0600 From: Len Bullard To: w3c-sgml-wg@www10.w3.org Subject: Initial draft of XML-Link spec now availab It's a happy day here. :-) For the most part, I agree with Durand. The naming issues are a matter of taste. I can't find any terms that aren't overloaded, so whatever. I don't generally like the use of Latin. It's dead. >From "section 0": Naming >0.1 What should the title of the spec be? XML Linking and Location Specification >0.2 What should the generic term or acronym we use to reference whatever > it is the spec describes? XML - Part Deux Don't introduce new acronyms if you can avoid it. Too many people can't figure out why SMGL is wrong. >Should links be expressed as SGML elements? If this means the specification has a set of element type definitions that are the range of the set of all XML Links, no. If this means a link is XML is specified by the application designers as an element type, maybe. If this means, XML provides a set of abstract types or classes or architectural forms from which an application designer can derive a set of element types, or another architecture for link types, yes. >1.c: Should we exclude relationships such as containment and >succession from this spec? Maybe. The concept of tree relationships as used in TEI is quite good. Previous and Next confused me originally until I read Lou's paper. Like most of the world, I thought these were file/frame load semantics as On The Buttons. >1.d Should we specify a way for a document to provide a summary of >the linkage machinery it uses? No. This is an application design decision. An informative annex may include a recommended way to do this. On the other hand, this depends on how the XML specification is treated. As "a set of recommendations", there is no normative text. As a standard, such separation is needed. Should this ever move to ISO, it is probable such a separation would be performed. OTH, if by this, a CATALOG is meant, then I favor that as a separate specification. It's utility is undeniable. >1.1.a are formatting issues (aside from perhaps a metadata slot) >outside of scope? Yes. But defining all linking to be formatting is a red herring anyway. A link to an executable (done every day) is not a call to a rendering engine. >1.3.a Should we assume that saying links are expressed using SGML elements >and attributes, and describing them in SGML terms, is a satisfactorily >complete syntax spec, thus avoiding a requirement for any BNF? If writing it as BNF is clearer, do that. I am satisfied with SGML. If you do BNF, do both. >1.3.b If links are SGML elements, should require XML-style reference >concrete syntax + quoted attribute values? I.e. assert that >all links would fit into XML docs? If a link does not fit into an XML document, what good is it? However, an application designer declares what fits into an XML application. I probably don't understand that question. >For the time being, and in order that Jon can read this without getting >headaches, the spec has been adjusted to use link, pointer, and terminus. Send Jon a bottle of aspirin and some antacid to the rest of us. >1.4.a What do we call the container used to hold the bits that > point at other things? (in current discussion: link) link >1.4.b What do we call the bits that point at other things? (in current > discussion: pointer) Pointer is OK. I believe it will be confusing too. This seems to fall under the "more meta than thou" dilemma. >1.4.c What do we call the things that are pointed at? (in current > discussion: terminus) Latin is dead. Requiescat in pacem. Target is easier to use. Confusion with HTML is not a problem. But, I don't really care. >1.4.d: What do we call the locator/adddress? Locator >1.4.f Should we define terms for links that are colocated with their > ends, and if so, should we use in-line and out-of-line? clink and ilink. Why use anything else when you can use a standard? >1.4.e Should we get into talking about bi/multi directional links? Yes. I like n-way links. No protests from the Swingonics Task Force. >1.4.g Should we define/discuss traversal? Only if you can make it simpler than the discussion in ISO 10744. This one deserves graphics. Will a discussion of traversal include state management, IOW, is is affected by the candidate BEHAVIOR attribute? The problem here is that if discussed, you must be very explicit about how the concept of traversal is used: lots of examples. >From section 1.5 Types of link types >1.5.a Shall we have a discussion of the characteristics links can > can have, including relationship, topology, locator language, > formatting, and behavior? This comes back to the concept of architecture and letting a link inherit from multiple architectures. If as in HyTime, XML Linking ONLY defines the minimum/basic architecture which all XML applications share, no. If yes, would this force a breakout of subtypes beneath XML and complicate MIME typing? If a XML application equals a notation, and that notation can be declared to the XML processor invisibly to MIME, then, the handling of XML applications is a separate problem and XML Link does not require all of the above because they can be added by the application designer. This really depends on how much portability (data declared) and interoperability (predictable behavior in the sense of a virtual method/message) you want. You can have portable data easily using the syntax. Interoperation is behavior by definition and this cannot be shared unless you have a communication protocol which includes the values you want to include in a message. To me, this falls inside the application domain. In other words, is a link a data object or a data structure? >1.c Should we define a link processor and specify any actions > required of it? See above. It is the most effective way to get interoperability. OTH, this looks like application design. We may want to consider this in terms of a reference implementation. >During the ERB meeting, my esteemed Co-editor pointed out that a word >that is synonym for both "target" and "end" is... "butt". So instead of >termini, we could have butts. Multi-butt links. Butt modes. Butt >syntax. I like this. -Tim I guess if you put all the links in the header you would then have buttheads. I like that too. Heh Heh Heh. Len Bullard Lockheed Martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 03 Feb 1997 15:09:00 +0000 (GMT) From: Peter Flynn Subject: Re: Production 21 (and others) To: w3c-sgml-wg@www10.w3.org Sean McGrath writes: [REs] > I totally agree. Credibility amongst implementors is at stake. > If comments are complex enough in regexp to warrant a BNF grammar > instead then I say lets give'em a BNF. More than that: one FAQ from CS SGML-non-initiates (read: implementors) is always "Where's the BNF? "Why do we have to use this weird syntax?" ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Feb 1997 12:01:47 -0500 To: W3C SGML Working Group From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.a: (David's Archform declaration gloss) At 9:33 AM 2/3/97, Michael Sperberg-McQueen wrote: > > This indicates that the Link XHL architectural form is the only one in use in this document, and that it applies to the element types and . The DTD must declare the required attributes for that form, and the processor _may_ validate the attribute specifications against the XHL definition. An architectural form would specify: 1. A set of attributes that should be present, and whether they are optional or required (optional attributes need not be declared, as long as not used). 2. A content model to which every instance must corespond (and against which the processor may validate the element's content model, for compatibility). The processor _should_ (must?) apply appropriate link semantics to those elements in context. Of course, if you don't have a DTD, the attributes are still there in the instance. This method of doing archforms does not require #FIXED attributes to signal an element with an archform, or indeed any architecture-signalling attributes at all. We might prefer to continue imposing such a requirement for compatibility with SGML practice, or we could simply allow it, on the principle that anyone who needs the compatibility could ensure it themselves. The other suggestion: would activate all XHL architectural forms for this document, and would apply them to elements with the same names (e.g. the "link" form, if it exists, would apply to the element type). In this example, I changed the confusing keyword "on" to "all" for greater clarity that a shole set of declarations is actually being made. I just realized that this should be: so that when XHL 2.0 adds 500 element types, we don't create name conflicts in existing documents. I thought we might make "all" the default, but then we would not have an XHL version number -- unless we make XHL and XML version numbers track exactly... -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Christopher R. Maden" Date: Mon, 3 Feb 1997 15:54:38 GMT To: w3c-sgml-wg@www10.w3.org Subject: Re: XML catalog draft I think there are a few ambiguities in the specification. Overall, I found it very clear. 1) The resolution process for a public identifier is that all PUBLIC entries be searched in order, then all DELEGATE entries. It appears from the description of when to use DELEGATE that PUBLIC entries are searched only from the first catalog entry entity, then DELEGATE entries from that entity, then PUBLIC entries from the second catalog entry entity, and so on. However, that wasn't completely explicit, and seems out of keeping with the concept of the catalog as a logical construct. 2) Does the DELEGATE process recurse? I know that in the header notes it indicates that this is left to implementations, but it should be explicit in the specification. 3) The DELEGATE description says that other parts of the entity are not available, as opposed to SGML Open TR9401... This is confusing, as no other reference to TR9401 nor to other modes of lookup have been made. Mention at the beginning of the lookup process description that only the public identifier is available for referencing, and don't mention it again. References to TR9401 should be restricted to an SGML Geek appendix. The ambiguity here contributed to my confusion on point 2). 4) The behavior of CATALOG is not completely clear - is it like an #include instruction? That is, is the referenced catalog entry entity inserted in its entirety into the catalog at the point of the CATALOG reference, or is it appended to the current logical catalog? This has implications on point 1) - is the inserted catalog then part of the current catalog entry entity for purposes of the PUBLIC/DELEGATE cycle, or should things after the CATALOG entry be searched before searching members of the referenced catalog entry entity? -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: Mon, 03 Feb 1997 20:37:48 +0100 From: "Norbert H. MIKULA" To: w3c-sgml-wg@w3.org Subject: NXP Update (V 0.9) released I have just put an updated release of my XML parser in Java to my pages at : http://edu.uni-klu.ac.at/~nmikula/NXP/ The new version should fix most of the old problems and contains ( prototype ) validation. Please test and give feed-back..... -- Best regards, Norbert H. Mikula ===================================================== = SGML, DSSSL, Intra- & Internet, AI, Java ===================================================== = mailto:nmikula@edu.uni-klu.ac.at = http://www.edu.uni-klu.ac.at/~nmikula ===================================================== %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Feb 1997 15:11:52 -0400 To: w3c-sgml-wg@w3.org From: murray@spyglass.com (Murray Altheim) Subject: Re: 1.4 a-c: Basic Terminology Joe English writes: >[ * * * Warning: HyTime spoken below; feel free to skip * * * ] [...] Well, I must admit that did me no good at all. *urp* >In this case, the A element can be, in the current >terminology, one of: > > + : a link and a terminus (of that same link) > + : a (potential) terminus (of some other link) > + : both of the above. > > >Here the pointer -- the thing which points at something else -- >is the HREF attribute, and there does not appear to be a way for >this to be pointed at. I'm mystified. The HREF *attribute* is the pointer? I thought adding the HREF attribute to the A element made the A _element_ point at the location indicated in HREF. I don't understand the HREF attribute to be the pointer, as it's not part of the document content; rather it is markup. I was under the impression that the anchor's text _content_ (the 'hypertext') became the pointer -- one doesn't point at markup, one points at content (which may be delimited by markup). IOW, the text becomes hypertext by being marked up with start and end tag delimiters that indicate what the text content is meant to point at. If an HTML anchor start tag contains both a NAME and HREF attribute, the text content becomes both the potential target of another anchor (via NAME), as well as pointing to whatever URL is indicated in the HREF of the start tag. go to bottom [...] go to top This certainly works in HTML. Please show me where I'm mistaken about this possible occurrence in XML without resorting to HyTime terminology. It seems strange to me that this should be "impossible" in XML. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 13:47:05 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: [Fwd: Re: Use of ";" in relative URLs: procedural issue?] FYI: John C Klensin wrote: > > At 07:26 97.02.03 -0800, Larry Masinter wrote: > >There is a proposal to change the definition of relative URL > >processing from that previously defined in RFC 1808 and > >draft-fielding-url-syntax around processing of relative URLs that > >... > >This is quite attractive, and is important for some schemes. No one > >seems to implement this currently, though, so introducing it at this > >point seems like we would at least have to start over at "Proposed > >Standard", and should only do so if the consensus of the community is > >that this is the right thing to do. > > Larry, > > This is just a personal opinion, but, to me, this is a good idea that falls > into the general category of "probably have to do it (or something like it) > sooner or later -- doing it now, however painful, is likely to be less > painful than doing it a few years hence". > > regards, > john %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Feb 97 13:01:23 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > From: "Christopher R. Maden" > > 1) The resolution process for a public identifier is that all PUBLIC > entries be searched in order, then all DELEGATE entries. It > appears from the description of when to use DELEGATE that PUBLIC > entries are searched only from the first catalog entry entity, then > DELEGATE entries from that entity, then PUBLIC entries from the > second catalog entry entity, and so on. However, that wasn't > completely explicit, and seems out of keeping with the concept of > the catalog as a logical construct. Your explication of the algorithm as described in the proposal is in agreement with the proposal. The proposal says: If there are no PUBLIC entries in a given catalog entry entity that result in an exact match with the interpreted value of the public identifier of the ExternalID, then all DELEGATE catalog entries in that catalog entry entity are considered. . . . If there are no PUBLIC or DELEGATE matches for the interpreted value of the public identifier of this ExternalID in the current catalog entry entity, match processing continues with the next catalog entry entity in the catalog list (if any). Perhaps you could suggest more explicit wording for the editors of the XML spec to consider. I'm not sure how this process is out of keeping with the catalog as a logical construct. Note this idea of completely processing one catalog entry file/entity before going to the trouble to access and process the next catalog entry file/entity is basically the same algorithm as described in TR9401 and seems to be the obvious thing you'd want to do over the internet. > > 2) Does the DELEGATE process recurse? I know that in the header notes > it indicates that this is left to implementations, but it should be > explicit in the specification. Yes, it "recurses." No, you misread the header note which seems quite clear to me. The header note doesn't say that whether or not the DELEGATE process is recursive is left to implementations, it says: How to avoid undesirable recursion is left as an implementation issue. The proposal says: The catalog lookup process for this public identifier continues with this new (replacement) catalog. . . . This newly defined catalog is then processed in much the same manner as if it had been the originally specified catalog. . . Perhaps you could suggest more explicit wording for the editors of the XML spec to consider. Personally, I do not think using the word "recursive" is going to improve the readability, clarity, or general acceptability of the spec. > > 3) The DELEGATE description says that other parts of the entity are > not available, as opposed to SGML Open TR9401... This is > confusing, as no other reference to TR9401 nor to other modes of > lookup have been made. Mention at the beginning of the lookup > process description that only the public identifier is available > for referencing, and don't mention it again. References to TR9401 > should be restricted to an SGML Geek appendix. The ambiguity here > contributed to my confusion on point 2). Yes, I too did find the mention of TR9401 unfortunate, and I would think suggestions for avoiding this might well be welcome by the editors. The problem this reference is attempting to address is as follows. In an XML catalog as proposed, the only two "lookup" entry types are PUBLIC and DELEGATE. If a given catalog entry entity has no PUBLIC match for the public id, matches for one or more DELEGATE entries are attempted. If there are any such matches, the newly "delegated to" catalog is then processed, one entity at a time, each first for PUBLIC matches then DELEGATE matches. However, an XML catalog does allow "extensions" (catOtherEntry), and the most obvious XML extensions will be valid TR9401 entries. So even avoiding an explicit mention of TR9401, the question is how an XML processor should consider catOtherEntry extensions in a "delegated to" catalog or not. The proposal addresses this by saying that the only info about the ExternalID available to a "delegated to" catalog is the PublicID. What this means is that entries such as ENTITY "foo" "bar.xml" DOCTYPE "html" "html.dtd" SYSTEM "fred.sgm" "http://www.acme.com/fred/fred.htm" . . . [any extension requiring a match on anything but public ID] (seen as catOtherEntry extensions to an XML processor) would be unmatchable in a "delegated to" catalog, but not unmatchable in an "un-delegated to" catalog. Note that extensions such as SGMLDECL "blerf.dcl" OVERRIDE "YES" . . . [any extension requiring no match or matching on public ID] would, per the current proposal, still be processable in a "delegated to" catalog. The rationale for "shedding" all other info about the ExternalID in a "delegated to" catalog is that the process of delegation is one in which you've already decided, in effect, that you're trying to resolve the public id, so it makes sense to continue the resolution process using just that public id. Furthermore, a "delegated to" catalog is very likely to be on another system, so it is questionable to try to resolve something based on its entity name (and system id) namespace. > > 4) The behavior of CATALOG is not completely clear - is it like an > #include instruction? That is, is the referenced catalog entry > entity inserted in its entirety into the catalog at the point of > the CATALOG reference, or is it appended to the current logical > catalog? This has implications on point 1) - is the inserted > catalog then part of the current catalog entry entity for purposes > of the PUBLIC/DELEGATE cycle, or should things after the CATALOG > entry be searched before searching members of the referenced > catalog entry entity? No, the referenced catalog entry entity is neither inserted in its entirety into the catalog at the point of the CATALOG reference, nor is it appended to the current logical catalog. As the proposal indicates: The CATALOG entry can be used to insert new catalog entry entities into the current list of catalog entry entities. The right hand side of a CATALOG entry is used to locate another catalog entry entity that is read after the current catalog entry entity if the current catalog entry entity does not provide a match for the public identifier. Multiple CATALOG entries are allowed, and the referenced catalog entry entities will be inserted into the current catalog list in order. If the idea of inserting a new catalog entry entity into the list of catalog entry entities (what the first quoted sentence says) is not clear enough, the next quoted sentence restates the intent by saying explicitly that the referenced catalog entry entity is read after the current catalog entry entity. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Mon, 3 Feb 97 16:40:18 EST To: w3c-sgml-wg@w3.org Subject: Re: 1.a: Use Elements? -- critical ambiguity in question! > From www10.w3.org!w3c-sgml-wg-request Mon Feb 3 16:32:29 1997 > Resent-Date: Mon, 3 Feb 1997 10:46:30 -0500 > Resent-Message-Id: <199702031546.KAA23572@www19.w3.org> > Date: Mon, 03 Feb 97 09:33:31 CST > From: Michael Sperberg-McQueen > Organization: ACH/ACL/ALLC Text Encoding Initiative Michael wrote: > I realize that you probably omitted the gloss on the grounds that the > meaning was intuitively obvious. Actually I omitted it on the grounds that I wasn't trying to make a formal proposal. By I meant no more than to suggest the use of a processing instruction to say that the HREF of the A element contains a URI (URL or URN) and should thus have some sort of linking behaviour. I added the example as a reminder that URI-valued attributes can be used in multiple ways -- HTML's IMG uses it to embed an image. Whether to embed is probably better specified through a style sheet, but that's a separate discussion. I would suggest a separate ProcInst for each element or attribute affected, for the sake of the Barefooted Perl Hacker if nothing else! Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 03 Feb 1997 21:48:27 +0000 (GMT) From: Peter Flynn Subject: Re: Sample Question 1997 11:52:00 -0600) To: w3c-sgml-wg@w3.org > In general, HTML files will need to be filtered to become XML > files. The transformation is simple, and has been discussed at > length on this list. I think this was before I put my head round the door. Did anyone do a script (perl, sed, ...)? and has anyone a pointer to a rough date? and I'll go trawl the logs. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 17:22:41 -0500 To: Michael Sperberg-McQueen From: "Eve L. Maler" Subject: Re: 1.a: Use Elements? -- critical ambiguity in question! Cc: W3C SGML Working Group At 09:33 AM 2/3/97 CST, Michael Sperberg-McQueen wrote: >David's, Eve's, and Lee's sketches of possible markup for declaring use >of XHL architectural forms looked interesting to me, but I confess I >didn't understand any of them very well. Would you be willing to >provide simple prose glosses for those of us in the back of the class, >saying what information a processor is to glean from ... > xml (linkto) "linkto" > xmlnames CDATA #FIXED "linkends ptr" > scheme (intid) "intid" > ?> This indicates that the element PrimaryIE in the document corresponds to the architectural form LINKTO in the XHL draft (I made up LINKTO; the current draft calls it ALINK), and the AF's attribute PTR (I made that up too; the draft calls it HREF) appears in the document as LINKENDS. The AF's attribute SCHEME (HRTYPE in the draft) is set permanently to INTID (my previously suggested hrtype for SGML IDs in the current document). No particular linking behavior or formatting is specified. So you see, I was cheating by making up my own markup names... Sorry! (I do like my names better.) Does this help? Eve ... >Something along the lines of 'This indicates that the element >BLORT in the document corresponds to the architectural form FARBLE >as specified in the XHL draft, and the AF's attributes FOO, BAR, >FU, and MANCHU appear in the document as PHEW, HAR, WHO, and >ATCHOO; it also signals that the intended action is to EMBED >the object pointed at.' > >I realize that you probably omitted the gloss on the grounds that the >meaning was intuitively obvious. So here's a reality check: it >wasn't, at least to me, at least not in full. If I'm the only one >on the list who didn't grasp it all, feel free to send your glosses >only to me, or to ignore this request. > >C. M. Sperberg-McQueen %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:19:13 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? (repost) At 11:50 AM 31/01/97 -0800, Tim Bray wrote: >[Oops - cut & paste error, screwed this up first time around.] > >1.c Should we define a link processor and specify any actions > required of it? >1.d Should we specify a way for a document to provide a summary of > the linkage machinery it uses? 1.c I am sympathetic to Durand's position on this one; I'd like to be as pure as possible about specifying simply a way to point at things. On the other hand, Len's point that the market will demand some behavior specification has weight. For the moment, I will argue for *no* processor specification; simply markup syntax, and the minimum of that. 1.d On the other hand, having written 1.d, it was obvious to me that this is a hole in the spec. It is of obvious utility for there a way for a document to signal what it's got. I think that (a) this should be in a PI and (b) it should be required to come before the first element. Having said that, we can defer the argument over its syntax and contents until we've hammered out what things XHL will do that might require signalling. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:19:10 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Section 0: Naming It dawned on me that since I co-drafted the spec, I ought to have the courtesy to put in a pitch for the status quo on all these section 1 items. At 11:08 AM 31/01/97 -0800, Tim Bray wrote: >0.1 What should the title of the spec be? >0.2 What should the generic term or acronym we use to reference whatever > it is the spec describes? (a) I don't think that XML-Link is euphonious or memorable, and (b) XML is not exactly a name to conjure with (yet), and (c) It is *important* that what we build operate with, and be advised as operating with, SGML and HTML. Thus I would favor the current title, "Extended Hyper Linkage" and the acronym XHL; the theory is that it sounds enough like XML that we can spin the XML+XHL story when that is what the people want, and is nonetheless distinct, which would avoid giving the impression that you can't use it in SGML or HTML. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:19:12 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.a: Use Elements? At 11:08 AM 31/01/97 -0800, Tim Bray wrote: >Should links be expressed as SGML elements? People are over-reacting to this. The discussion as to whether we should link up via AF's and so on should really be put off until the #2.* items come up; we've got substantive enough issues to deal with now. The reason the question was asked is, the spec says that links are SGML elements; the ERB feels the WG ought to be asked for comments on every issue of substance, and even though this one seems like a no-brainer to me, perhaps there are other ways to do it that we missed. Of *course* links should be expressed as SGML elements. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:34:12 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.1.a Formatting Issues Out of Scope? At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >1.1.a are formatting issues (aside from perhaps a metadata slot) >outside of scope? Absolutely. This is a slippery slope going nowhere. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:34:22 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.5: Discuss link characteristics? At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >>From section 1.5 Types of link types > >1.5.a Shall we have a discussion of the characteristics links can > can have, including relationship, topology, locator language, > formatting, and behavior? Yes - I think this will be very useful to the readers, both those new to the discipline, and those carrying the baggage of some other hyperlinking scheme. I think this holds independent of what we decide to do about all these things, and even if we decide to say nothing about some of them. I.e. if we do someting controversial like say nothing about behavior, we owe it to the readers to warn them in advance that this is going to be the case, i.e. that we didn't just leave it out by accident. Also, I love the title "Types of Hyperlink Types" (Steve's contribution). - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:34:18 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.4 e: ordinality of directionality At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >1.4.e Should we get into talking about bi/multi directional links? I think it *is* worth talking about this in the terminology section, but I think we should probably switch from bi- to multi-. Means what it says, which is good. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:34:15 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.4 a-c: Basic Terminology At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >1.4.a What do we call the container used to hold the bits that > point at other things? (in current discussion: link) >1.4.b What do we call the bits that point at other things? (in current > discussion: pointer) >1.4.c What do we call the things that are pointed at? (in current > discussion: terminus) Sign me up for link, pointer, and terminus. Motivation: a link is what people expect, fewer suprises are better. Pointer: I could be swayed on this one, but it's nicely mnemonic, a single word, and not already used by any of the existing hypertext tribes. Terminus: I like this one a lot, same reasons as pointer, plus both the denotation and connotations are good. -Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:34:13 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.3, Notation: SGML? Reference Concrete? At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >1.3.a Should we assume that saying links are expressed using SGML elements >and attributes, and describing them in SGML terms, is a satisfactorily >complete syntax spec, thus avoiding a requirement for any BNF? Absolutely; it's more compact and the BNF would be big and hairy and duplicate XML. >1.3.b If links are SGML elements, should require XML-style reference >concrete syntax + quoted attribute values? I.e. assert that >all links would fit into XML docs? I want this to be usable with real SGML. So I think we should *not* restrict them to XML-style syntax, but insert a usage note saying it won't work with XML unless you follow XML rules. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:34:16 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.4 d: Address terminology At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >1.4.d: What do we call the locator/adddress? We have to be careful here. For example, these could be URN's or FPI's, which are not addresses but names. At the moment locator seems like the best compromise; whatever it is, you undeniably use it to locate the terminus. -Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:34:19 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.4 f: terms for links colocated with their ends At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >1.4.f Should we define terms for links that are colocated with their > ends, and if so, should we use in-line and out-of-line? Yes and yes; it's a key intellectual underpinning, and whereas there is a case for clink and ilink, they are less mnemonic. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 15:34:20 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.4.g: define/discuss Traversal? At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >1.4.g Should we define/discuss traversal? I'm beginning to think we should leave this out. In the spec, we wrote "traverse" means "use". If we believe this, why don't we just say "use"? Unless we are going to be forced to specify some behaviors; in which case a specific term like traversal is probably called for. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 03 Feb 1997 17:41:32 -0600 From: len bullard To: w3c-sgml-wg@w3.org Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? (repost) Tim Bray wrote: > > At 11:50 AM 31/01/97 -0800, Tim Bray wrote: > >1.c Should we define a link processor and specify any actions > > required of it? > >1.d Should we specify a way for a document to provide a summary of > > the linkage machinery it uses? > > 1.c > I am sympathetic to Durand's position on this one; I'd like to be as > pure as possible about specifying simply a way to point at things. On the > other hand, Len's point that the market will demand some behavior > specification has weight. The situation that troubles me is not what they demand, but that they may put one in anyway and then the horse is dammnably difficult to get back into our barn. We keep getting caught on the problems of making information portable while keeping systems interoperable, so maybe we just have to say, XML does not do interoperability except insofar as two communicators agree to use the same processor specification. If an XML designer chooses to hand off property values inside the XML instance which are then interpretable as behavioral flags, so be it. Any XML processor that can handle it does. One that doesn't can't. Finis. That is the situation with SGML/HTML now. >For the moment, I will argue for *no* > processor specification; simply markup syntax, and the minimum of that. I'm sympathetic too. Does this mean no "get" or "post"? No action=? If this appears contrary, bear with me. I simply want to cook every potential red herring at this fishfry now before the next events in the public begin. > 1.d > On the other hand, having written 1.d, it was obvious to me that this is > a hole in the spec. It is of obvious utility for there a way for a document > to signal what it's got. I think that (a) this should be in a PI and > (b) it should be required to come before the first element. Having > said that, we can defer the argument over its syntax and contents until > we've hammered out what things XHL will do that might require signalling. I'm only worried that we get a very long list of PIs. It is the lesser evil I guess. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 3 Feb 1997 17:40:38 -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: Section 0: Naming | It dawned on me that since I co-drafted the spec, I ought to have the | courtesy to put in a pitch for the status quo on all these section 1 | items. And I should, pro forma, repeat my disagreement. | At 11:08 AM 31/01/97 -0800, Tim Bray wrote: | >0.1 What should the title of the spec be? | >0.2 What should the generic term or acronym we use to reference whatever | > it is the spec describes? | | (a) I don't think that XML-Link is euphonious or memorable, and | (b) XML is not exactly a name to conjure with (yet), and | (c) It is *important* that what we build operate with, and be advised as | operating with, SGML and HTML. I think that we should emphasize the association between components of a suite of specifications. I also personally find "XHL" a really unpleasant acronym (I can't say why, I just don't like it). Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 00:03:42 -0500 To: From: Harvey Bingham Subject: Re: 1.4 c: Basic Terminology At 11:09 1997/01/31 -0800, you wrote: > >1.4.c What do we call the things that are pointed at? (in current > discussion: terminus) I hope we do plan to allow more than one terminus? [1.4 e:] If so, we need a plural form. I propose termini (ter'-mi-ni) [not (ter-mi'-ni)], rather than terminuses (ter'-mi-nus-es), or even (term'-i-nus-es) [not (ter-min'-us-es)] I wonder what current algorithmic hyphenators do least violence? I don't want to be ter(ribly) negative here. Regards/Harvey %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 11:03:12 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Revised text for Section 5 of XHL --=====================_855054192==_ The attached document contains a rewrite of Section 5 of the XML Links specification that seeks to: a) clarify the existing text b) suggest two additional attributes for -XML-XLD c) show how linksets can be nested --=====================_855054192==_ Suggested update to Part 5 of XML specification

5. Extended Link Groups

5.1 Identifying Extended Link groups

XHL describes the syntax of link elements embedded in documents. Many applications may wish to process not only the links to external documents embedded in that document, but also links from other documents which point into the document currently being displayed. It may, for example, be desirable to highlight the located parts of such external links to make the fact that other documents have commented on the displayed document apparent.

Where it is important to know which other documents qualify the current document, the Extended Link Group (XLG) element may be used to reference documents that form an interlinked document group. Each referenced document, which must have been declared as an external text entity in the document's DTD, is identified using the DOC attribute of an Extended Link Document (XLD) element, which is a child element of the XLG.

XLG and XLD elements can be recognized by the presence of an XHL- attribute with a value of either XLG or XLD on the relevant element, through the use of two XML reserved element types, -XML-XLG and -XML-XLD, or through other external mechanisms.

The declaration for the XML form of the XLG and XLD elements is:

<!ELEMENT -XML-XLG (-XML-XLD+)>
<!ELEMENT -XML-XLD EMPTY>
<!ATTLIST -XML-XLG
XHL- CDATA #FIXED "XLG"
>
<!ATTLIST -XML-XLD
XHL- CDATA #FIXED "XLD"
DOC ENTITY #REQUIRED
PRESENCE (REQUIRED|OPTIONAL) "OPTIONAL"
SHOW (MLINKS|ALINKS|BOTH) #IMPLIED
>

The PRESENCE attribute can be used to indicated which entities must be available to the client prior to display of the form. Where the XLD entry is changed from the default PRESENCE=OPTIONAL to the alternative PRESENCE=REQUIRED the entity must be retrievable from the specified source, or the source associated with the local XML catalog, before the referencing document can be displayed.

The SHOW attribute can be used to indicate whether all references from document should be displayed, or only those that represent multi-headed links, or in-line links. By default the system will imply which values should be defined, but users can override the default by specifying that element whose XHL type is MLINK or ALINK should be displayed. Where both options are required the SHOW=BOTH option can be used.

Question: Should a finer granularity be allowed so that, for instance, elements of a specific HRTYPE or GI can be associated with different rules?

The -XML-XLG element should always be an immediate descendent of the base document element that forms the root of the document tree. It should be entered before any elements containing displayable text.

Question: Is it valid to have more than one -XML-XLG element in a document?

5.2 LINKS and LINKSET Elements

To help software to find MLINK type links efficiently, two special elements have been defined, -XHL-LINKS and -XHL-LINKSET. These elements are always immediate descendents of the base document element that forms the root of the document tree. They should be entered before any elements containing displayable text.

The -XHL-LINKS element can be used to identify multilinks which need to be known to the software, and available to the user, at all times while the current document is being displayed. Whilst most links will need to be identified during loading, whether defined at the start of the document or within its contents, links requiring the identification of elements via TEI locators, and other forms of query, will particularly benefit from being defined as part of a separate -XHL-LINKS element at the start of the document rather than at the point of reference.

Where a set of MLINK definitions is to be shared by an extended link group the -XHL-LINKSET element should be used as the container for the link specifications. This tells the application that the links are to remain valid while any document identified by a -XML-XLD element associated with the current document is valid.

To promote the sharing of links sets, an XML document can consist of just -XML-XLG, -XML-XLD and -XML-LINKSET elements. Where such a document is referenced in an -XML-XLD element in another document, all its linked documents and its links are considered to form part of the link group being defined. If one of the documents indentified by a -XML-XLD in the link definition document is itself an XML document that contains a -XML-LINKSET, the referenced linkset is appended to the local linkset.

The declaration for the XML form of the -XML-LINK and -XML-LINKSET elements is:

<!ELEMENT -XML-LINKS (MLINK+)>
<!ELEMENT -XML-LINKSET (MLINK+)>
<!ATTLIST -XML-LINK
XHL- CDATA #FIXED "LINKS" >
<!ATTLIST -XML-LINKSET
XHL- CDATA #FIXED "LINKSET" >
--=====================_855054192==_ ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ --=====================_855054192==_-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 04 Feb 1997 11:44:02 +0000 (GMT) From: Peter Flynn Subject: Re: 1.4 c: Basic Terminology To: w3c-sgml-wg@w3.org Harvey Bingham writes: > I hope we do plan to allow more than one terminus? [1.4 e:] > If so, we need a plural form. Despite my fondness for Latin, I think terminus has been anglicized for long enough to have acquired an -es plural. Problem is, terminuses sounds terrible and termini is a lot easier to say. Is there really no other word? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 08:42:51 -0500 (EST) From: Gregory Murphy To: w3c-sgml-wg@w3.org Subject: Re: 1.4 c: Basic Terminology On 4 Feb 1997, Peter Flynn wrote: > Harvey Bingham writes: > > Despite my fondness for Latin, I think terminus has been anglicized > for long enough to have acquired an -es plural. Problem is, terminuses > sounds terrible and termini is a lot easier to say. Is there really > no other word? I can't find a single instance of "terminuses" in the OED 2, but "termini" abound, including a reference dated 1975. Seems to be pretty solidly common usage. I for one can't read/hear the plural without lapsing into nostalgia for Rome and its seedy but grandiose train station. - Gregory Murphy %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 10:41:02 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? (repost) Jon Bosak wrote: > > [Len Bullard:] > > | We keep getting caught on the problems of making information portable > | while keeping systems interoperable, so maybe we just have to say, XML > | does not do interoperability except insofar as two communicators agree > | to use the same processor specification. > > I don't think this works. A key reason that HTML is successful is > because it provides a basic set of common understandings. Without a > basic set of common understandings, communication is impossible. Hmmm... yes, Jon. Contracts are about enforceable agreements. No argument there. The basic understandings are HTML and the URL approach. We can't assume the former. What understandings will we assume? It is because they extend HTML without agreements (violate the contract) and use the market to work out the differences that they have interoperation problems now. So far, we can only assume portability based on syntax. HTML includes ACTION="post" | "get". Can we use XML hyperlinking to build controls with predictable behaviors unless we agree on the behaviors? We can agree on indirection although they may still elect not to do that with all of the implied compromises to portability. How do we agree on what we indirect to? As soon as controls are interlaced with data, we have this conflict of interest. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 13:16:19 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4 c: Basic Terminology At 6:44 AM 2/4/97, Peter Flynn wrote: >Harvey Bingham writes: >> I hope we do plan to allow more than one terminus? [1.4 e:] >> If so, we need a plural form. > >Despite my fondness for Latin, I think terminus has been anglicized >for long enough to have acquired an -es plural. Problem is, terminuses >sounds terrible and termini is a lot easier to say. Is there really >no other word? If we use termini, then we can leave it to vulgarians to get it wrong, if they wish. I've never heard terminuses, and, like a purple cow, I never hope to hear it. I think terminus is a good word... If it was good enough for the Romans, it's good enough for me! -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 13:16:26 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? (repost) At 10:41 AM 2/4/97, Len Bullard wrote: >The basic understandings are HTML and the URL approach. We can't >assume the former. What understandings will we assume? It is >because they extend HTML without agreements (violate the contract) and >use the market >to work out the differences that they have interoperation problems >now. So far, we can only assume portability based on syntax. We cannot guarantee arbitrary interoperability without losing the power of XML (making your own description language). But that makes it incumbent on us to clearly draw a line about what our linking primitives _do_ and _don't do_. If we say use indirection, then we are providing a powerful well-structured way to do things such that people who don't do it cannot claim to be compatible with our linking, or they have created a buggy implementation. Just as Netscape-style HTML was "bad" HTML to an original Mosaic user. If we also provide a separate, but powerful execution spec to complement our linking, I hope that people will not make such agreements, but we cannot prevent that. However, it doesn't stop us from specifying a machanism that _will interoperate_. We can't control people, but we can define the terms for a social agreement (Extended Hyperlinking). Whether the baby will live or die afterwards is something we cannot tell. >HTML includes ACTION="post" | "get". Can we use XML hyperlinking >to build controls with predictable behaviors unless we agree on the >behaviors? We can agree on indirection although they may still >elect not to do that with all of the implied compromises to >portability. How do we agree on what we indirect to? As soon as >controls are interlaced with data, we have this conflict of interest. I think we should not put ACTION= into the our linking spec, though we might be able to define a processing spec that will let people implement it if that's what they need. Just because HTML has muddied the waters, we don't have to drink mud. We can let the glass settle out into two nice clear layers of drinkable content water, and muddy execution specs. Another reason to separate execution specs from linking and document markup is that linking and markup have (in various forms) centuries of analytic and practical work underlying them, while computer display has a very short, incredibly variegated history, with few "tried and true" solutions. If you disbelieve me on the history of hyperlinking, check out a Talmud, annotated bible, or scholarly critical edition, to pick 3 well-worn examples. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 13:16:22 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: 1.4.g: define/discuss Traversal? At 8:17 AM 2/4/97, Jon Bosak wrote: >I'm the token minimalist on this subject, but in the case of >"traverse" I think we should take advantage of the existence of a term >that precisely describes what we mean and isn't already grossly >overloaded. > >Jon I disagree, because traverse exactly implies _less_ than I want to do with links. I don't consider it helpful to use the word traversal for the rendering of footnotes, or the creation of local link maps without fetching documents, or the associationg of glosses with original texts in multi-lingual documents. Traversal implies that there's only one thing to do with a link -- GOTO, and that's a very limiting view. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 13:16:13 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Section 0: Naming At 3:19 PM 2/3/97, Tim Bray wrote: >It dawned on me that since I co-drafted the spec, I ought to have the >courtesy to put in a pitch for the status quo on all these section 1 >items. > >At 11:08 AM 31/01/97 -0800, Tim Bray wrote: >>0.1 What should the title of the spec be? >>0.2 What should the generic term or acronym we use to reference whatever >> it is the spec describes? > >(a) I don't think that XML-Link is euphonious or memorable, and >(b) XML is not exactly a name to conjure with (yet), and >(c) It is *important* that what we build operate with, and be advised as > operating with, SGML and HTML. > >Thus I would favor the current title, "Extended Hyper Linkage" and the >acronym XHL; the theory is that it sounds enough like XML that we can >spin the XML+XHL story when that is what the people want, and is nonetheless >distinct, which would avoid giving the impression that you can't use it >in SGML or HTML. - Tim Well, this argument seems very good to me, but I didn't pick it up in my readind. _I_ at least finished the spec with no thought that it was intended for use with SGML or HTML. Now that I double check, I see that the draft actually says SGML where I _read_ XML. (I think I may have thought that it was an editing error). I think that an explicit list including at least XML and SGML would help to highlight the intended universal applicability, especially to densoids like myself. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 11:11:36 -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: 1.c-d: Define a Link Processor and Communicate With It? (repost) [Len Bullard:] | Can we use XML hyperlinking to build controls with predictable | behaviors unless we agree on the behaviors? No, but specifying behaviors directly isn't the only way to handle this. The fundamental agreement needed to make communication happen isn't an agreement about how things act but about what they mean. So to me the logical way to establish communication is to agree on a set of shared meanings and then agree on a mechanism for associating behaviors with those meanings. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 20:21:24 +0000 To: w3c-sgml-wg@w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: Section 0: Naming I think we should look for some marketing spin in the naming. I am not a marketing type and am distinctly unqualified to offer an opinion but that never stopped me before:-) I suggest we call it "Hyper-X" being the short name for "Hyper-XML" being the short name for "Hypertext enhanced eXtensible Markup Language" Sean Mc Grath digitome@iol.ie Sean Mc Grath digitome@iol.ie Digitome Electronic Publishing Developers of IDM - Next Generation SGML Transformation Technology http://www.screen.ie/digitome %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Tue, 4 Feb 97 14:44:37 EST To: w3c-sgml-wg@w3.org Subject: Re: 1.4 c: Basic Terminology > I think terminus is a good word... I have no particular problem with railway analogies -- the terminus is the main station where the traincomes in, and has to go out backwards. The plural may be either termini or terminuses -- both are accepted, at least in British English [1]. The word also has some other, less familiar meanings. Well, maybe people in America are less familiar with the obvious railway meaning? Would "airport" be a better name instead? Lee [1] Longman, dict. of the Eng. lang., 1991 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 13:56:33 -0600 From: Len Bullard To: "David G. Durand" CC: w3c-sgml-wg@w3.org Subject: Re: 1.c-d: Define a Link Processor and Communicate With It? (repost) Part of the record, but those who have pressing work, hit delete. >David G. Durand wrote: > > We cannot guarantee arbitrary interoperability without losing the power of > XML (making your own description language). But that makes it incumbent on > us to clearly draw a line about what our linking primitives _do_ and _don't > do_. Yes. I think that is what I was saying to Jon. Interoperability isn't guaranteed by XML. To do that, we would have to do something similar to the MID or hardwire some linktypes with axiomatically defined behaviors. > If we say use indirection, then we are providing a powerful well-structured > way to do things such that people who don't do it cannot claim to be > compatible with our linking, or they have created a buggy implementation. > Just as Netscape-style HTML was "bad" HTML to an original Mosaic user. Ok. Won't that eliminate a fairly large number of applications? Netscape was bad HTML, soon became good HTML, then MS introduces Other HTML, and so it goes. This is SGML application development as we know it in practically every SGML application. Even the Federal government couldn't put the teeth in to prevent it in IETMs. However, we know what the pathologies are... err... we know which fish keep coming up again and again. We have the low-bottom dwelling catfish , we have the fast barracuda
If we also provide a separate, but powerful execution spec to complement > our linking, I hope that people will not make such agreements, but we > cannot prevent that. However, it doesn't stop us from specifying a > machanism that _will interoperate_. Within narrow limits, perhaps we can. This depends on the requirements. We knew what the objections to the gosubs, gotos, spawns, in MID were. That is why they were optional. But to meet the requirements which focused on interoperability, we couldn't think of a way that was easier to explain, simpler to user, and met the requirement. It wasn't a theory issue. The design was meant to make GUI behaviors as interoperable as possible. All I can say is the language works. Because you and I have covered this ground over and over again, perhaps people understand that there isn't a universal hypertext theory that will apply, or satisfy all cases. It remains to be very specific about the cases XML will satisfy. Again, we debate until the ERB decides, and we move on. Making the business case is a different thread. Yes, I am being contrary. No, I won't stop. Yes, it is easy to ignore this. No, it won't go away. Before we ask them to buy products, we have to be more clear than we have ever been about what XML makes possible and impossible. > We can't control people, but we can define the terms for a social agreement > (Extended Hyperlinking). Whether the baby will live or die afterwards is > something we cannot tell. This is where we differ David. My job is to be able to say that very precisely. It isn't an exercise. The agreements my customers make have implications that rattle up and down the carrier decks and through the halls of every major weapon systems vendor on the planet. I know that is "dramatic"; it is also, true. I'm not tagging manuscripts from Rome. I almost wish I were. In truth, I am much more of a purist than it appears here because I have also done a lot of conversion and I know what a PIA variants are. I also know we have strung large communities along for sometime with our proposals, and now they believe the Web applications are the answer to their problems. Now, XML is offered to solve those problems but with totally different software. It's a good idea, but a hard sale. > >HTML includes ACTION="post" | "get". Can we use XML hyperlinking > >to build controls with predictable behaviors unless we agree on the > >behaviors? We can agree on indirection although they may still > >elect not to do that with all of the implied compromises to > >portability. How do we agree on what we indirect to? As soon as > >controls are interlaced with data, we have this conflict of interest. > > I think we should not put ACTION= into the our linking spec, though we > might be able to define a processing spec that will let people implement it > if that's what they need. Ok. We are at an impasse on that. > Just because HTML has muddied the waters, we don't have to drink mud. We > can let the glass settle out into two nice clear layers of drinkable > content water, and muddy execution specs. There isn't the time. We have been trying to do that for a decade and so far, most of the DTDs I know of have the pathologies I mention in one form or another. We are not Italian aristocracy who can lock ourselves up in a castle and wait while the plague rages outside our walls. We are lowly software peddlars. To sell our glasses of water, they must buy both kinds and drink. Where there is thirst, they drink with or without the water filter. > Another reason to separate > execution specs from linking and document markup is that linking and markup > have (in various forms) centuries of analytic and practical work underlying > them, while computer display has a very short, incredibly variegated > history, with few "tried and true" solutions. Integrated Open Hypermedia: Bibliographic model. It did not produce a design for a digital computer. Poor Alan Turing, and Hopper, and Von Neumann, and so on did. I can't sit here and say the Book Metaphor is imperfect, or that it doesn't work. I can say that where we have developed hypermedia on the digital computer, lots of different solutions have been tried and do work. Each has tradeoffs. We are debating the tradeoffs. Where we go Beyond The Book Metaphor, as I said some years ago, we are on new ground taking risks, making mistakes, and sometimes falling off the monkey tree. We are learning. > If you disbelieve me on the history of hyperlinking, check out a Talmud, > annotated bible, or scholarly critical edition, to pick 3 well-worn > examples. I do not disbelieve you. I debate you until the bell rings. I enjoy it. As Charles said to you and Steve in Orlando some years ago while I was laying on the floor getting flu, "you're good." But for today, we must help Tim and Steve finish the draft. I've said my piece. It has been considered. Time to move on. I have to get back to designing a landscape for Europa. :-) len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 12:32: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: 1.4 c: Basic Terminology [David Durand:] | If we use termini, then we can leave it to vulgarians to get it wrong, if | they wish. I've never heard terminuses, and, like a purple cow, I never | hope to hear it. Same here. I didn't know that "terminuses" existed until someone found it in a dictionary. | I think terminus is a good word... | | If it was good enough for the Romans, it's good enough for me! Agreed. None of the alternatives is as good. (Except "butt". Once I stopped laughing, I realized that I actually liked it.) Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 15:27:01 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: Section 0: Naming I like Hyper-XML -- a lot! -- as the short name, and Hypertext Enabled XML as the long name. In fact, for the short version, HyperXML spelled solid, without the hyphen, looks even better. Eve At 08:21 PM 2/4/97 +0000, Digitome Ltd. wrote: >I think we should look for some marketing spin in the naming. I am >not a marketing type and am distinctly unqualified to offer an opinion but >that never stopped me before:-) > >I suggest we call it "Hyper-X" being the short name for "Hyper-XML" being >the short name for "Hypertext enhanced eXtensible Markup Language" > >Sean Mc Grath >digitome@iol.ie > > >Sean Mc Grath >digitome@iol.ie >Digitome Electronic Publishing >Developers of IDM - Next Generation SGML Transformation Technology >http://www.screen.ie/digitome > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 14:22:10 -0600 From: Len Bullard To: "Eve L. Maler" CC: w3c-sgml-wg@w3.org Subject: Re: Section 0: Naming Eve L. Maler wrote: > > I like Hyper-XML -- a lot! -- as the short name, and Hypertext Enabled XML > as the long name. In fact, for the short version, HyperXML spelled solid, > without the hyphen, looks even better. > > Eve > > At 08:21 PM 2/4/97 +0000, Digitome Ltd. wrote: > >I think we should look for some marketing spin in the naming. I am > >not a marketing type and am distinctly unqualified to offer an opinion but > >that never stopped me before:-) > > > >I suggest we call it "Hyper-X" being the short name for "Hyper-XML" being > >the short name for "Hypertext enhanced eXtensible Markup Language" > > > >Sean Mc Grath > >digitome@iol.ie I like it too. Nice, Sean. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 13:07:20 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Section 0: Naming At 03:27 PM 2/4/97 -0500, Eve L. Maler wrote: >I like Hyper-XML -- a lot! -- as the short name, and Hypertext Enabled XML >as the long name. In fact, for the short version, HyperXML spelled solid, >without the hyphen, looks even better. HyperXML is nice. I didn't like Sean's Hyper-X, because that collides with Hyper-G. I take it that nobody else considers it important to advertise the fact that this technology is *not* limited to XML applications? - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 15:25:55 -0600 From: Len Bullard To: Tim Bray CC: w3c-sgml-wg@w3.org Subject: Re: Section 0: Naming Tim Bray wrote: > > At 03:27 PM 2/4/97 -0500, Eve L. Maler wrote: > >I like Hyper-XML -- a lot! -- as the short name, and Hypertext Enabled XML > >as the long name. In fact, for the short version, HyperXML spelled solid, > >without the hyphen, looks even better. > > HyperXML is nice. I didn't like Sean's Hyper-X, because that collides > with Hyper-G. Yes. I predcit they will quickly call it HyperX in practice, but that's not important. > I take it that nobody else considers it important to advertise the fact > that this technology is *not* limited to XML applications? - Tim Is this something like the HyTime claim that it is not limited to SGML? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 13:49:38 -0800 (PST) From: Todd Freter Subject: Re: Section 0: Naming To: Len Bullard cc: "Eve L. Maler" , w3c-sgml-wg@w3.org Len Bullard wrote: > Eve L. Maler wrote: > > > > I like Hyper-XML -- a lot! -- as the short name, and Hypertext Enabled XML > > as the long name. In fact, for the short version, HyperXML spelled solid, > > without the hyphen, looks even better. > > > > Eve > > > > At 08:21 PM 2/4/97 +0000, Digitome Ltd. wrote: > > >I think we should look for some marketing spin in the naming. I am > > >not a marketing type and am distinctly unqualified to offer an opinion but > > >that never stopped me before:-) > > > > > >I suggest we call it "Hyper-X" being the short name for "Hyper-XML" being > > >the short name for "Hypertext enhanced eXtensible Markup Language" > > > > > >Sean Mc Grath > > >digitome@iol.ie > > I like it too. Nice, Sean. > > len > Is there any chance of confusing Hyper-X or Hyper-XML with Hyper-G, now known as HyperWave, the web server and web authoring software from the Technical University in Graz? I believe that they are in the process of commercializing this software. It certainly has its followers. -Todd. ======== Todd Freter Sun Microsystems, Inc. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: David Durand Date: Tue, 4 Feb 1997 16:53:54 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: Section 0: Naming > I take it that nobody else considers it important to advertise the fact > that this technology is *not* limited to XML applications? - Tim Is this something like the HyTime claim that it is not limited to SGML? It is rather more plausible, I think, as the mapping of XML architectural forms to SGML architectural forms is pretty obvious. But Hyper-XML is a good name. I'd leave the prose pointing out that the architectural forms will work with SGML, but not let that affect the choice of name. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 17:10:52 -0400 To: w3c-sgml-wg@w3.org From: murray@spyglass.com (Murray Altheim) Subject: Re: Section 0: Naming >Eve L. Maler wrote: >> >> I like Hyper-XML -- a lot! -- as the short name, and Hypertext Enabled XML >> as the long name. In fact, for the short version, HyperXML spelled solid, >> without the hyphen, looks even better. If the majority of XML applications are targeted at delivery over the Internet, then this sounds kinda redundant. Call me a troll, but I still like Jon's idea of a suite of specs around the "XML-" prefix. At least this way the public can immediately see the relationships between the parts, and XML remains the primary focus. >> At 08:21 PM 2/4/97 +0000, Digitome Ltd. wrote: >> >I think we should look for some marketing spin in the naming. I am >> >not a marketing type and am distinctly unqualified to offer an opinion but >> >that never stopped me before:-) >> > >> >I suggest we call it "Hyper-X" being the short name for "Hyper-XML" being >> >the short name for "Hypertext enhanced eXtensible Markup Language" >> > >> >Sean Mc Grath >> >digitome@iol.ie > >I like it too. Nice, Sean. Well, part of product marketing is checking out the existing trademarks, although I've always thought 'do diligence' a silly term. Note that Hyper-X is already in use, although I wouldn't want to guess who owns the trademark: a) "Hyper-X, Hypertextual Consciousness" by Mark Amerika (!). b) "Hyper-X for SCO UnixWare 2" -Novell c) NASA Langley's "Hyper-X High Speed Research Vehicle Production" d) "Hyper-X -- the department of Alt-X concerned with hypertext/hypermedia" e) Quarterdeck's [defunct?] "X11 Server Software for the PC" and many more... whew. Tim Bray writes: >I take it that nobody else considers it important to advertise the fact >that this technology is *not* limited to XML applications? - Tim That may be true and even a pleasant side effect, but hardly necessary to consider for the task at hand, which is to provide hypertext links for XML. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 17:16:36 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: 1.4 c: Basic Terminology From: John_Lavagnino@Brown.edu The name "terminus" for one of the "things that are pointed at" seems OK to me. But I'll make another suggestion, based on the feeling that terminology like "terminus", "target", "end", and "link end" is too termin-centric; it's taking the link element's point of view, that the important feature of these "things that are pointed at" is the fact that they're being pointed at. That's certainly true from the link-machinery point of view, but not in terms of what the document is trying to do. I'd suggest "selection" as a possible alternative, because it focuses more on the picking-out-and-relating function than the arrival-here or pointer-points-here or address-maps-to-this functions. It is blander, but one problem with end-oriented terms is that they're too specific: linking may not be end-oriented. Suppose what you want to do is display two texts in parallel: are you really thinking in terms of "traversal" or of "going" from one text to the other? The viability of "terminus" lies in the fact that you can sort of think that way about any linking; but it's also not the mot juste because what you're really trying to do with a link may be more complicated than, or just different from, what the railway metaphor implies. "Selection" also has some familiarity from its use in the jargon of some current computer systems. This is an advantage in that the usual sense does not conflict with what we want it to mean in (Hyper-)?(X[HM]L-)?(Link)?: in particular, a selection does not have to map exactly to the full content of one or more SGML elements, and indeed it needn't be text at all. But there could be some possibility of confusion as well, of course (for example, in the way you often can't have more than one selection active or even defined at a time). The problem I've described with "terminus" is a problem with "pointer" as well; but that feels more acceptable to me because it's more of a behind-the-scenes thing. For example, as a document author, you can think about linking some termini without having to work out how they're pointed at or addressed within the document's innards; that's the part that a program could do for you (in response to your clicks or pointing at the screen or whatever). When document authors talk about this stuff, I expect they will often talk about links and termini, and not much about pointers and addresses. (And even the stuff about links will be in a more abstract sense than what we've got in the draft: it's probably more focused on a "link relationship" than on a particular link element.) I expect they will also have reason to often point out to neophytes that "terminus" has a more subtle meaning than "endpoint as in the place where an HTML link takes you". John Lavagnino Women Writers Project, Brown University %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 17:24:29 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: Section 0: Naming From: John_Lavagnino@Brown.edu It seems desirable to me that the names of all our pieces should carry a strong implication that XML is REALLY (the SGML subset) + (the linking stuff) + (the style stuff), and that anyone who says "I support XML" but who's only done the SGML subset should be widely regarded as a schmuck. So I like Hyper-XML, or XML-Link, but am a tad worried about the possibility that this might be seen as an add-on that you don't really have to support (or could even replace with your own specs). Maybe these worries would be adequately addressed simply by cross-references between the final specs (the XML spec saying "You better do the stuff in the Hyper-XML spec, too", and so on). The applicability of Hyper-XML to SGML can be adequately addressed by a statement to that effect in the draft, I should think. As for HTML, they're going to have to change it to be able to use Hyper-XML, so perhaps the appropriate language is "You HTML people should incorporate all this if you know what's good for you". John Lavagnino Women Writers Project, Brown University %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 17:53:14 -0500 To: murray@spyglass.com (Murray Altheim) From: "Eve L. Maler" Subject: Re: Section 0: Naming Cc: w3c-sgml-wg@w3.org At 05:10 PM 2/4/97 -0400, Murray Altheim wrote: >If the majority of XML applications are targeted at delivery over the >Internet, then this sounds kinda redundant. Call me a troll, but I still >like Jon's idea of a suite of specs around the "XML-" prefix. At least this >way the public can immediately see the relationships between the parts, and >XML remains the primary focus. ... >Well, part of product marketing is checking out the existing trademarks, >although I've always thought 'do diligence' a silly term. Note that Hyper-X >is already in use, although I wouldn't want to guess who owns the >trademark: > > a) "Hyper-X, Hypertextual Consciousness" by Mark Amerika (!). > b) "Hyper-X for SCO UnixWare 2" -Novell > c) NASA Langley's "Hyper-X High Speed Research Vehicle Production" > d) "Hyper-X -- the department of Alt-X concerned with hypertext/hypermedia" > e) Quarterdeck's [defunct?] "X11 Server Software for the PC" >and many more... Given your reasons and the marketing focus, maybe we should switch around the XML and the hyper, and then call it XML-Hype for short. :-) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 04 Feb 1997 23:45:13 +0000 (GMT) From: Peter Flynn Subject: Re: Section 0: Naming (elm@arbortext.com) To: w3c-sgml-wg@w3.org Sean McGrath writes I suggest we call it "Hyper-X" being the short name for "Hyper-XML" being the short name for "Hypertext enhanced eXtensible Markup Language" Eve adds I like Hyper-XML -- a lot! -- as the short name, and Hypertext Enabled XML as the long name. In fact, for the short version, HyperXML spelled solid, without the hyphen, looks even better. Two colleagues here -- unaware of anything called XML as yet -- overheard me discussing Eve's list of DTD no-nos with someone and interrupted to ask if I had tried Tinaderm (a cream for Eczema; go on, say it aloud with a short middle "e" :-) Might Hyper-X be thought to have something to do with Hyper-G? But I like the thrust of this name. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 04 Feb 1997 18:19:33 -0600 From: len bullard To: Todd Freter CC: "Eve L. Maler" , w3c-sgml-wg@w3.org Subject: Re: Section 0: Naming Todd Freter wrote: > Is there any chance of confusing Hyper-X or Hyper-XML with Hyper-G, now known > as HyperWave, the web server and web authoring software from the Technical > University in Graz? I believe that they are in the process of commercializing > this software. It certainly has its followers. There is that chance, but it is not a worry IMO. They could confuse it with HyperCard and other products. How many folks think Sun makes a brand of coffee? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 13:06:01 -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: Section 0: Naming [Eve Maler:] | I like Hyper-XML -- a lot! -- as the short name, and Hypertext Enabled | XML as the long name. In fact, for the short version, HyperXML | spelled solid, without the hyphen, looks even better. But Hyper-XML implies a complete language spec, and Hypertext Enabled XML says that directly. We're not working right now on a spec of the complete language, just the module that addresses linking. The name has to be a name for that module, not a name for the whole thing. You could call this "Hypertext enabling syntax for XML". But I'd rather just call it XML-link. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 08:21: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: 1.c-d: Define a Link Processor and Communicate With It? (repost) [Len Bullard:] | We keep getting caught on the problems of making information portable | while keeping systems interoperable, so maybe we just have to say, XML | does not do interoperability except insofar as two communicators agree | to use the same processor specification. I don't think this works. A key reason that HTML is successful is because it provides a basic set of common understandings. Without a basic set of common understandings, communication is impossible. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 08:17:18 -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: 1.4.g: define/discuss Traversal? | I'm beginning to think we should leave this out. In the spec, we | wrote "traverse" means "use". If we believe this, why don't we just | say "use"? Unless we are going to be forced to specify some | behaviors; in which case a specific term like traversal is probably | called for. - Tim I'm the token minimalist on this subject, but in the case of "traverse" I think we should take advantage of the existence of a term that precisely describes what we mean and isn't already grossly overloaded. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 4 Feb 1997 11:11:22 -0400 To: w3c-sgml-wg@w3.org From: murray@spyglass.com (Murray Altheim) Subject: Re: Section 0: Naming bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: >| It dawned on me that since I co-drafted the spec, I ought to have the >| courtesy to put in a pitch for the status quo on all these section 1 >| items. > >And I should, pro forma, repeat my disagreement. > >| At 11:08 AM 31/01/97 -0800, Tim Bray wrote: >| >0.1 What should the title of the spec be? >| >0.2 What should the generic term or acronym we use to reference whatever >| > it is the spec describes? >| >| (a) I don't think that XML-Link is euphonious or memorable, and >| (b) XML is not exactly a name to conjure with (yet), and >| (c) It is *important* that what we build operate with, and be advised as >| operating with, SGML and HTML. > >I think that we should emphasize the association between components of >a suite of specifications. I also personally find "XHL" a really >unpleasant acronym (I can't say why, I just don't like it). Possibly because it sounds like "exhale", something heard in a doctor's office. We should do everything we can to reduce complexity, including absolute minimization of acronyms and other obscure codes where a simple word or phrase would suffice. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Tue, 4 Feb 97 22:27:46 EST To: w3c-sgml-wg@w3.org Subject: Re: Section 0: Naming -- not limited to XML? Quoth Tim: > I take it that nobody else considers it important to advertise the fact > that this technology is *not* limited to XML applications? - Tim I think that it is important _not_ to say too openly that it can be used with anything else, except possibly SGML. What's the point of using XML if you can get the same benefits with HTML/PDF/FTP? Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Feb 1997 07:00:03 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 1.4 c: Basic Terminology At 08:42 4/2/97 -0500, Gregory Murphy wrote: >> Harvey Bingham writes: >> >> Despite my fondness for Latin, I think terminus has been anglicized >> for long enough to have acquired an -es plural. Problem is, terminuses >> sounds terrible and termini is a lot easier to say. Is there really >> no other word? > > > I can't find a single instance of "terminuses" in the OED 2, but >"termini" abound, including a reference dated 1975. Seems to be pretty >solidly common usage. > > I for one can't read/hear the plural without lapsing into nostalgia >for Rome and its seedy but grandiose train station. > So instead of 'links to the addresses of SGML containers' we are going to have 'links to the locators of termini' or, heaven forbid, 'links to the ends/butts of terminuses'. Where have I heard this type of phrase applied to taxi-drivers? Ever seen 19th century travellers phrase books? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Feb 1997 11:03:29 +0000 To: John_Lavagnino@Brown.edu, w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 1.4 c: Basic Terminology At 17:16 4/2/97 -0500, John_Lavagnino@Brown.edu wrote: > When document authors talk >about this stuff, I expect they will often talk about links and >termini, and not much about pointers and addresses. The problem is that what is needed to get a link to a terminus is its address/locator. Pointers are what contains the address that the link uses to get to the terminus. Without these terms you cannot completely describe the mechanism. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Wed, 5 Feb 97 11:20:11 EST To: w3c-sgml-wg@w3.org Subject: Re: 1.4 c: Basic Terminology > From w3.org!w3c-sgml-wg-request Wed Feb 5 06:34:43 1997 > Resent-Date: Wed, 5 Feb 1997 06:07:30 -0500 > Resent-Message-Id: <199702051107.GAA28556@www19.w3.org> > X-Sender: mtbryan-sgml@mail.u-net.com > Pointers are what contains the address that the link uses to get to the > terminus. Without these terms you cannot completely describe the mechanism. So an XML-LINK pointer is what HTML calles a Reference, I think. E.g. HREF = Hypertext Reference. And pointers don't point to anything, but contain addresses that point to things. And the things pointed to are railway stations. OK... I think HTML has clearer terminology here, at least to me. An anchor contains (has) a reference to a resource. That resource is "a point in cyberspace" and otherwise opaque. It's also easy to understand. I'm not asking for XML to be simpler than HTML, but I *am* asking for it to be described as simply. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 05 Feb 1997 15:31:20 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: elm alternate linking proposal Cc: elm@arbortext.com I've been working on an alternate proposal for the basic parts of the linking spec, and it seems time to share it. (Thanks to those folks who took the first peek!) Because this proposal grew out of an attempt to pick *really good* names for the markup, I've used my alternate names throughout. However, I've related them back to the current Bray/De Rose proposal whenever possible, so as to avoid giving Jon a headache. You can find it at: http://www.doctools.com/xml-link.html You can send your comments to the WG list or to me. (Oh ghod, what am I getting myself into?...) Thanks-- Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 06 Feb 1997 16:26:57 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: elm alternate linking proposal At 03:31 PM 2/5/97 -0500, Eve L. Maler wrote: >I've been working on an alternate proposal... There is nothing in Eve's proposal (hereinafter ELP) with which I can bring myself to disagree violently. I *think* that the design choices in ELP can all be decided on within the question/voting framework I published last week; but it is certainly a good idea for Eve to have trotted out the whole ELP framework so that we can get the context for the positions she will doubtless be endorsing. A couple of detailed design comments: - In general I support less-is-more. But I doubt that we're going to be able to get away with doing *nothing* on the issues of explainers, terminus-roles, and behavior/formatting metadata. It is absolutely dead certain that people are going to put this stuff in their links; at the very least we should probably give them a standard place to put it. On the other hand, I'm starting to be convinced that locsrc is more trouble than it's worth. - I'm not sure we want to embrace the whole power of archforms to the extent of allowing attribute name overrides; not that another level of indirection isn't always a good idea, it just makes it a bit harder to explain. I think in XML, we have gotten good mileage out of nuking everything that was in the slightest hard to explain. It's *so* easy to explain, "once you've figured out that this thing is an MLINK, then here are the attributes and here's what they mean." Also the tokenized attribute saying "consider this attribute to be that attribute" feels kind of klunky to me. - A design principle I realized I had used implicitly without writing it down was: you should be able to extract all the linking information with just an XML processor and nothing else. This is why in the initial draft proposal, there is no case in which you have to tokenize an attribute string. This is just an invitation to problems in the i18n arena; and furthermore, I've always thought that the base principle of SGML was that you should take things that are supposed to be separate, and separate them with markup. This explains my discomfort with the ELP "xmlnames" attribute mechanism. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 06 Feb 1997 19:55:21 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: Re: Section 0: Naming Hi. I am new to the WG and have taken advantage of the recent pause-to-consider-a-new-proposal to catch up with recent threads, going back to about 1/21. I feel like I just walked out of a double feature of Patton and The Longest Day -- sort of like a veteran spectator, tired of combat, but loving the show. But this is definately The Good War. I would like to contribute to the discussion of naming and terminology since these lie closest to my own expertise and since, like many of you, I will have the task of explaining these terms once they are released. This post contains both General Comments on the approach to naming and a summary of Specific Comments that link to the numbered discussion items. For thread continuity, I will also post opinions addressing specific issues with the appropriate headers. *** ====== *** General Comments I have tried to listen to the language used most often to describe the concepts, not in formal terms, but in the narrative of the WG, and where possible, to put these in place of terms that, like Jon, sent me reaching for an analgesic. I suggest that a reliance on adjectives is quite proper here because judicious use of modifiers conveys relationships between terms that is obscured by undue originality in naming parts of what should appear as a unified specification. Whereas a car is just car whether it is a broken car, a new car, or a chauffeur-driven car, all the tiny bits that make up that thing-that-I-click-on in my browser require a unifying set of terms if the user is ever to understand why what appears as one thing (and one action) can't just be called by one name. (I am expanding a point made by Jon, Murray, and others on the need for a clear, cohesive identity for these concepts -- some call it marketing.) *** ====== *** Specific Comments 0. Naming I have to side with XML Link or XML Linking (is a hyphen necessary?). The XML-Hyper-X suggestions expand to something like: hypertext enhanced extensible markup language. This is not only a mouthful but reads like a superset of XML, (if you want the whole shebang you've got to have this stuff which is the *enhanced* XML) where I believe we want to convey that the linking spec is a module of the larger concept which is XML. XML Linking keeps the proper relationship between XML and the XML linking spec (I don't think the hyphen is necessary.) 1.4.a-c here's where the adjectives come in: link --> link element pointer --> link pointer terminus --> link end Using two words in place of one may seems uneconomical, but is a concise method of describing the relationship between the specific concept (pointer, end, terminus, thing) and the overall concept (link, to link, to be a link, to have a link, to make a link...). It addresses Eve's quandry: Did the parson marry the young girl? (AND the young boy!?) We know a "link element" is an element, not an action. We all think we know what we mean by "link" (which is good) and it can retain that intuited meaning and continue to act as both a noun *and* a verb if we keep it as the big concept word and attach the little pieces to it in well defined ways. 1.4.d (link) address I'm still not sure what is meant even though I've got addresses and locators coming out of both eyes; I'll address this in comments on 1.4.d 1.4.e n-directional seems to capture bi- multi- and uni-, if a single modifier will suffice. It seems to offers opportunity of association in a democratic fashion. 1.4.f I have real problems with in-line and out-of-line. Although the WG seems to have come to peace with this, I am going to argue against it. Coming in from the outside, these don't work. See separate post. *** ====== *** I realize that this addresses last week's topics not the new proposal that Eve has put on the table that uses yet again a new set of terms. While the naming may be very well thought out in her scheme (and knowing her care and respect for language, I expect that it is), I couldn't really wrap my little writer's mind around it. When it comes up for general discussion, I will try to apply the same principles used here and root around for room for improvement. Until it is broken down and torn apart for discussion a bit, I'm afraid I just can't adddress it. Regards, Liora ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 11:50:16 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Re: XML catalog draft >Date: Thu, 30 Jan 97 10:57:43 CST >From: paul@arbortext.com (Paul Grosso) >Subject: Re: XML Catalog draft proposal > >> From: James Clark >> >> >1. In the XML WD1.0, a system identifier is a URL. However, the >> > current catalog draft chooses not to put this restriction on >> > the "right hand side" of a catalog entry, though a URL continues >> > to be the most obvious thing to use there. ... >Allow me to explain some of the concerns we discussed on this issue. >It may be that the ERB will see a way to address these concerns. > >1. It was a goal to allow the catalog to map public identifiers into > URNs. (Do we want to open up the defn of sysids in XML to include > URNs, or does the defn of URL already include URNs?) > >2. It was a goal to allow XML catalogs to be used with SGML/XML > repositories (aka databases). For example, it was felt important > to allow an entry such as: > PUBLIC "corporate legal boilerplate C312" "get_bplate('C312')" > where the rhs is some database call (whether expressed in FSI syntax > as in this example or not). > >3. It was a goal (albeit a less important one) to allow catalogs to > have FSIs on the rhs. > >4. Though URLs remain the most obvious thing for a sysid to be, it > might make sense to allow the market to decide what sysids will > work. This is one place where it might be best to suggest that > URLs give maximum interoperability, but to allow other things > to develop. After all, any decent XML tool that finds a sysid > that isn't a URL is going to try its best to figure it out anyway, > so how is restricting it in the XML spec going to help? Your points 2 to 4 apply equally to system identifiers and were considered when deciding whether to restrict system identifiers to URLs. They don't provide any justification for treating the RHS of a catalog entry differently from a system identifier. As for 1, I don't think the issue of how URNs are going to fit into the XML framework has been decided. Adding SGML public identifiers and catalogs to XML complicates this significantly. Before we add public identifiers to XML, I think we need to have a clear picture of how URLs, URNs, FPIs, non-formal public identifiers, system identifiers and catalogs all fit together. I'm still unclear. James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 11:49:41 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Re: 1.4 f: terms for links colocated with their ends At 11:09 31/01/97 -0800, Tim Bray wrote: >1.4.f Should we define terms for links that are colocated with their > ends, Yes. > and if so, should we use in-line and out-of-line? No. I find "out-of-line" much less suggestive of the nature of the link that the existing HyTime term "independent". I think using the term "in-line" is going to be confusing when we get to the style stage, since the term "in-line" is used very heavily in formatting (at least in DSSSL). I am not very keen on the term "contextual" either. Since the "in-line" links are the kind of links that most people are currently used to, may be they could be called something like "simple", "normal" or "basic". James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 06:58:58 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: XML catalog draft >[69] ExternalID := 'PUBLIC' S PublicID ( S SystemID )? | > 'SYSTEM' (S SystemID)? >[70] SystemLiteral := '"' [^"]* '"' | "'" [^']* "'" >[70a] PublicID := RestrictedLiteral >[70b] SystemID := SystemLiteral >[70c] RestrictedLiteral := > '"' RestrictedLiteralChars '"' | "'" RestrictedLiteralChars "'" >[70d] RestrictedLiteralChars := (Letter | Digit | S | SpecialChars)* >[70e] SpecialChars := ['()+,-./:=?] >[71] [[unchanged]] Why is # not included in SpecialChars? (It might be nice to use the URL fragment identifier as part of a public ID in some cases, even though this might lead to incompatiblities with SGML name rules, which were done before URLs became popular.) ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 09:38:13 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: elm alternate linking proposal Comments by Martin and replies by me... >X-Sender: eve@village.doctools.com >Date: Thu, 06 Feb 1997 10:29:59 -0500 >To: Martin Bryan >From: "Eve L. Maler" >Subject: Re: elm alternate linking proposal >Cc: "Eve L. Maler" ... >At 10:47 AM 2/6/97 +0000, Martin Bryan wrote: >>Eve >> >>I like linkto and associate - these are good names, but I hate termini, for >>the reasons your write-up makes obvious - it just does not read smoothly. > >I actually agree that terminus is a bad name for an element. I originally >called it "loc" (while keeping terminus for the prose description), but >didn't want to confuse people even further. > >>Why is xmlnames set to #FIXED ""? This means users can never change it - yet >>you would want to allow xmlnames="ptr href" for HTML users. (It may be >>advisable to use #FIXED in the final DTD, but not in the architectural form >>definition.) > >I (thought I) was copying the HyTime AFs I found on the Web. I guess in >the AF itself it should just be CDATA "". > >>Your -xml=tlink definition does not make sense. I would make it >> >>> xhl- CDATA #FIXED "-xml-tlink" >> xml CDATA #FIXED "linkto" >> xmlnames CDATA #FIXED "ptr href scheme hrtype" >> href CDATA #REQUIRED >> hrtype CDATA #IMPLIED > >The tlink version is just to show what my proposal would look like, using >the markup names in Tim's and Steve's proposal; I wasn't trying to map one >to the other, just show where they are conceptually similar. > >> Your A example is wrong because the HREF is always required. It should be: >> >> >>> xml CDATA #FIXED "linkto" >> xmlnames CDATA #FIXED "ptr href" >> scheme CDATA #FIXED "url" >> href CDATA #REQUIRED >> name CDATA #IMPLIED > >When A is used *as a linking mechanism*, the HREF is required. But if you >look at the DTD, HREF is optional, because NAME might be supplied instead! >This is a fact of life with the HTML DTD (and with DocBook and many others). > >>Here we find another problem. Scheme means something different for someone >>from the WWW arena. Scheme is the name of the HTTP/FTP/... part of the URL >>so to say scheme=url rather than scheme=HTTP will present a name conflict to >>them. > >I'm happy to use another name besides scheme. I just thought HRTYPE was >unnecessarily cryptic. If you've got suggestions, fire away! > >>I suggest we steer clear of roles in place of type because this will cause >>confusion with those used to anchrole in HyTime. The XML type attribute is >>not the same as an anchrole. > >That's fine with me too. > >>Re:Titles, explainers, or descriptions >> >>> I didn't provide any title/explainer/description attribute because: >>> This information is related to behavior. >>> It is "content" and may need markup inside it (which design >>decision the AF should not >>> dictate). >> >>This is why the explainer should just be an IDREF to the element that >>contains the content, and why you need a separate attribute to define the >>notation of the behaviour. Both are necessary, both must be separate. >>Without these two items you just will not get interoperability. > >I don't agree that the explainer should be an IDREF. This dictates a >particular mehod of associating the link stuff and the explanation stuff, >and for many users, association by element containment (or by attribute >value) is much preferable. > > Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 09:41:47 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: Re: 1.4 e: ordinality of directionality At 11:09 AM 1/31/97 -0800, you wrote: >1.4.e Should we get into talking about bi/multi directional links? > > 1.4.e I suggest using the term n-directional since it includes the possibility of uni-directional, bi-directional, and multi-directional linking. ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 09:41:45 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: Re: 1.4 a-c: Basic Terminology >At 11:09 AM 31/01/97 -0800, Tim Bray wrote: >>1.4.a What do we call the container used to hold the bits that >> point at other things? (in current discussion: link) >>1.4.b What do we call the bits that point at other things? (in current >> discussion: pointer) >>1.4.c What do we call the things that are pointed at? (in current >> discussion: terminus) > >Sign me up for link, pointer, and terminus. Motivation: a link is >what people expect, fewer suprises are better. Pointer: I could >be swayed on this one, but it's nicely mnemonic, a single word, and >not already used by any of the existing hypertext tribes. Terminus: >I like this one a lot, same reasons as pointer, plus both the denotation >and connotations are good. -Tim > 1.4.a link --> link element We think we know what we mean by link, but it is in fact defined by context -- "I link this link". So, it's fine to call a link a link when the context is clear, but formally, I suggest we use "link element" when we define a link element and let users shorten this to "link" when the context is unambiguous. This way, we will provide a point of reference when there is confusion and there will be confusion because HTML'rs will not understand right away why they need all these terms if "this" (whatever this is) is actually "the" link. The solitary term "link" should be reserved for the overall concept of a link and the separate components of a link should be given equal weight and a clear interrelationship by naming them as separate parts of the link. I believe that inserting "element" into the formal definition also makes it easier to explain how this is just a certain way of using good old SGML/XML elements. 1.4.b pointer --> link pointer Again, users can shorten this when the context and application is clear. Initially, and in formal definitions, I think two words are worth the extra keystrokes because it sets up a clear relationship between the thing that points and all encompassing concept which is a hypertext link. 1.4.c terminus --> link end In all the fine distinctions made over this point, the basic definition used was always that this is a link end. So call it a link end. "End" solo is vague, but again, in lengthy expositions and where the context is clear and if we really succeed in propagating XML, the "link" part will drop off of its own accord where appropriate. I guess I feel about these concatenated terms the way a processor might feel about end tags: extra markup, but boy does it make my job easier. See also my general remarks in 0. Naming Liora ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 09:41:48 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: Re: 1.4 f: terms for links colocated with their ends At 11:49 AM 2/7/97 +0700, James Clark wrote: >At 11:09 31/01/97 -0800, Tim Bray wrote: >>1.4.f Should we define terms for links that are colocated with their >> ends, >> and if so, should we use in-line and out-of-line? > >No. I find "out-of-line" much less suggestive of the nature of the link >that the existing HyTime term "independent". > >I think using the term "in-line" is going to be confusing when we get to the >style stage, since the term "in-line" is used very heavily in formatting (at >least in DSSSL). I am not very keen on the term "contextual" either. Since >the "in-line" links are the kind of links that most people are currently >used to, may be they could be called something like "simple", "normal" or >"basic". > >James I also had much trouble with these terms. I believe that what is called here "in-line" and in HyTime "contextual" are links that share a number of characteristics: 1. located at the (start) link end 2. uni-directional 3. hardwired Choosing 1. -- co-location -- as the basis for naming is confusing for the reason James cites and also obscures the other characteristics which identify this type of link. I can't think of a single name that will evoke all three characteristics and I agree that "simple", "normal" or "basic", which require definition, are an improvement on "in-line". "Out-of-line" sounds like scolding and emphasizes the location of the link look-up table, which is much less relevant than the fact that there is a look-up of some sort. "Simple" and "independent" are somewhat descriptive and are explainable. Is there a reason why we can't just call these "direct" and "indirect" links? This also keys on just one of the three characteristics of this type of link, but if 1. a direct link is always located at its start link end 2. a direct link is always uni-directional 3. a direct link is by definition hardwired then, I think we should call it a direct link because unlike co-lation or uni-directionality, it does imply the other two characteristics. There may be some very obvious reasons that "direct" and "indirect" are non-starters, but they sure would speak well to both technical and non-technical audiences. Liora ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 11:10:48 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: 1.4 h: Explainer? 1.4.h Does "explainer" make anyone else uncomfortable? I added this question, at risk of bringing up something on which there is already concensus, because I can find no reason not to call a caption a "caption". This is a link caption so call it a "link caption" or if there are reasons not to use caption, then some of the other common words already used to describe what it does: "link title" or "link subtitle" "Explainer" is in the dictionary, but it sounds weird. ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 10:55:59 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: Re: 1.4 d: Address terminology At 11:09 AM 1/31/97 -0800, you wrote: >1.4.d: What do we call the locator/adddress? > > Following on the use of two words to denote association and avoid ambiguity, and, to avoid introducing extraneous, linguistically-unrelated terms, I would call this the "pointer address" or "pointer value". Of course, it could also be the "point". If there is a reason that it must be one word or that it must be a form of locat*, I vote for "location" over "locator". ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 11:28:18 -0500 To: Liora Alschuler From: masonjd@ornl.gov (James David Mason) Subject: Re: 1.4 h: Explainer? Cc: w3c-sgml-wg@w3.org At 11:10 AM 2/7/97 -0500, Liora Alschuler wrote: >1.4.h Does "explainer" make anyone else uncomfortable? > >This is a link caption so call it a "link caption" or if there are reasons >not to use caption, then some of the other common words already used to >describe what it does: "link title" or "link subtitle" > >"Explainer" is in the dictionary, but it sounds weird. I'll second that. Dr. James D. Mason Lockheed Martin Energy Systems Information Management Services SGML Systems Development 1060 Commerce Park, M.S. 6480 Oak Ridge, TN 37831-6480 U.S.A. Telephone: +1 423 574-6973 Facsimile: +1 423 574-0004 Network: masonjd@ornl.gov http://www.ornl.gov/sgml/wg8/wg8home.htm %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 10:29:25 -0600 From: Len Bullard To: Liora Alschuler CC: w3c-sgml-wg@w3.org Subject: Re: 1.4 h: Explainer? Liora Alschuler wrote: > > 1.4.h Does "explainer" make anyone else uncomfortable? Yes. Sounds like Howard Cosell. > I added this question, at risk of bringing up something on which there is > already concensus, because I can find no reason not to call a caption a > "caption". > This is a link caption so call it a "link caption" or if there are reasons > not to use caption, then some of the other common words already used to > describe what it does: "link title" or "link subtitle" VRML uses Description. Caption is better than explainer. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 1997 08:24:08 -0800 (PST) From: Terry Allen To: jjc@jclark.com, w3c-sgml-wg@w3.org Subject: Re: XML catalog draft James writes: >As for 1, I don't think the issue of how URNs are going to fit into the XML framework has been decided. Adding SGML public identifiers and catalogs to XML complicates this significantly. Before we add public identifiers to XML, I think we need to have a clear picture of how URLs, URNs, FPIs, non-formal public identifiers, system identifiers and catalogs all fit together. I'm still unclear. Just a note: I had argued for URNs as PIs, on the inarticulate assumptions that only FPIs would be used as PIs and that PIs would always be resolved as URNs. Paul has taken a different approach (more articulately). Currently, I think that an SGML Open catalogue could be expressed as a set of ilinks, and that doing so would reduce the number of syntaxes required for implementation (this is a different issue >from FPIs and URNs and PIs). Either way, some means of associating catalogues or ilinksets with documents is required. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 7 Feb 97 12:27:57 EST To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Terry wrote: > Just a note: I had argued for URNs as PIs, on the inarticulate > assumptions that only FPIs would be used as PIs and that PIs would > always be resolved as URNs. Paul has taken a different approach > (more articulately). I think that it would be better to specify that URNs be used (which I would support) than FPIs (which I do not support), as there is still no resolution mechanism that will scale up to millions of FPIs even proposed, let alone working, as far as I can see. ISO can mandate the use of things that don't exist and might never work, but that doesn't mean we can, and if you need a W3C Recommendation and/or an RFC, that won't cut any ice. (why do people need to cut ice? it comes in cubes) > Currently, I think that an SGML Open catalogue could be expressed > as a set of ilinks, and that doing so would reduce the number of > syntaxes required for implementation (this is a different issue > from FPIs and URNs and PIs). Yes, I agree. It is very sad that SGML OPEN used a non-SGML syntax because it was easier to implement and get people to agree on and to have a common working inplementation than an SGML file. > Either way, some means of associating > catalogues or ilinksets with documents is required. Clearly -- otherwise we haven't solved the problem, but only made it more complicated. A way of getting from instance to catalog is needed. I will say right now that we spent a lot of effort on this topic for SoftQuad Panorama, and didn't get it right in the 1st release. It's still not perfect, but we have backward compatibility issues. Let's do it right for XML. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 1997 12:16:59 -0500 (EST) To: w3c-sgml-wg@w3.org Feb 1997 10:29:25 -0600) Subject: Re: 1.4 h: Explainer? From: John_Lavagnino@Brown.edu "Explainer" sounds fine to me. Both "caption" and "description" seem to imply a function in too narrow a way: this thing is not necessarily going to be displayed as some sort of caption (to me this sounds like it has to go right under a big arrow), and a "description" makes it sound more like some kind of documentation rather than part of a function or interface. John Lavagnino Women Writers Project, Brown University %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 97 11:01:00 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > From: Martin Bryan > > >[69] ExternalID := 'PUBLIC' S PublicID ( S SystemID )? | > > 'SYSTEM' (S SystemID)? > >[70] SystemLiteral := '"' [^"]* '"' | "'" [^']* "'" > >[70a] PublicID := RestrictedLiteral > >[70b] SystemID := SystemLiteral > >[70c] RestrictedLiteral := > > '"' RestrictedLiteralChars '"' | "'" RestrictedLiteralChars "'" > >[70d] RestrictedLiteralChars := (Letter | Digit | S | SpecialChars)* > >[70e] SpecialChars := ['()+,-./:=?] > >[71] [[unchanged]] > > Why is # not included in SpecialChars? RestrictedLiteralChars is a synonym for 8879's "minimum data character" (production 78). SpecialChars is a synonym for 8879's "Special" character class which 8879 defines to be the characters shown for SpecialChars above and which does not include the # character. In other words, if we allowed # in SpecialChars, an XML PublicID would not be a value 8879 minimum literal and hence not a valid 8879 public id. > (It might be nice to use the URL > fragment identifier as part of a public ID in some cases, even though this > might lead to incompatiblities with SGML name rules, which were done before > URLs became popular.) It seems to me that a URL makes more sense as a system identifier than a public identifier. You could use a public identifier and map it into a URL via the catalog, but I wouldn't say something with a URL fragment identifier needs to be able to be a public ID. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 09:09:30 -0600 From: Len Bullard To: Liora Alschuler CC: w3c-sgml-wg@w3.org Subject: Re: 1.4 f: terms for links colocated with their ends Liora Alschuler wrote: > > At 11:49 AM 2/7/97 +0700, James Clark wrote: > >At 11:09 31/01/97 -0800, Tim Bray wrote: > >>1.4.f Should we define terms for links that are colocated with their > >> ends, > >> and if so, should we use in-line and out-of-line? > > > >No. I find "out-of-line" much less suggestive of the nature of the link > >that the existing HyTime term "independent". Yes. > > > >I think using the term "in-line" is going to be confusing when we get to the > >style stage, since the term "in-line" is used very heavily in formatting (at > >least in DSSSL). I am not very keen on the term "contextual" either. Since > >the "in-line" links are the kind of links that most people are currently > >used to, may be they could be called something like "simple", "normal" or > >"basic". > > > >James > > I also had much trouble with these terms. > I believe that what is called here "in-line" and in HyTime "contextual" are > links that share a number of characteristics: > 1. located at the (start) link end > 2. uni-directional > 3. hardwired > > Choosing 1. -- co-location -- as the basis for naming is confusing for the > reason James cites and also obscures the other characteristics which > identify this type of link. I can't think of a single name that will evoke > all three characteristics and I agree that "simple", "normal" or "basic", > which require definition, are an improvement on "in-line". > > "Out-of-line" sounds like scolding and emphasizes the location of the link > look-up table, which is much less relevant than the fact that there is a > look-up of some sort. There can be a lookup in either case. > > "Simple" and "independent" are somewhat descriptive and are explainable. Yes. Basic may be better. Simple makes people think it isn't powerful. > Is there a reason why we can't just call these "direct" and "indirect" links? Yes. A clink can point to a location ladder. Direct and indirect are not actually descriptive of functionality. Inline and out-of-line are just descriptive of storage location. Neither has much descriptive power. Context and independent don't have very much, but they are in current use and used correctly. They are also standard. The XML specification is just a set of recommendations that COULD be standardized. It will be simpler to achieve this later process if standard terms are used. Durand argues against 'de novo' terms, but for a pre-standard practice, all terms are de novo. Better to use the standard. > This also keys on just one of the three characteristics of this type of > link, but if > > 1. a direct link is always located at its start link end > 2. a direct link is always uni-directional > 3. a direct link is by definition hardwired Define "hardwired". Is the being generated by a server side script "hardwired"? > then, I think we should call it a direct link because unlike co-lation or > uni-directionality, it does imply the other two characteristics. > > There may be some very obvious reasons that "direct" and "indirect" are > non-starters, but they sure would speak well to both technical and > non-technical audiences. Call them George if you like. The average user tries them once, and then uses that "experience" to identify functionality. Stick with the standard terms already in use in the larger SGML community. What is being suggested now is guaranteed to perpetuate confusion and even more factionalization. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 18:20:12 +0000 To: cbullard@hiwaay.net, Liora Alschuler From: Martin Bryan Subject: Re: 1.4 h: Explainer? Cc: w3c-sgml-wg@w3.org At 10:29 7/2/97 -0600, Len Bullard wrote: >VRML uses Description. Caption is better than explainer. This sounds much better ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 12:25:36 -0600 From: Len Bullard To: John_Lavagnino@brown.edu CC: w3c-sgml-wg@w3.org Subject: Re: 1.4 h: Explainer? John_Lavagnino@brown.edu wrote: > > "Explainer" sounds fine to me. Both "caption" and "description" seem > to imply a function in too narrow a way: this thing is not necessarily > going to be displayed as some sort of caption (to me this sounds like > it has to go right under a big arrow), But that is a common usage of it. > and a "description" makes it > sound more like some kind of documentation rather than part of a > function or interface. which is the most common usage of it. This points out the problems of the name game: o Implies the functionality o Is in concert with common practice o Satisfies an abstract set of rules for naming I think there will be no argument or choice that satisfies all conditions in all cases. This is why I think it preferable to use HyTime names where possible. In this coin toss, the coin should be weighted to the side of the standard. That is easy to explain(er)/describe/capture. Len Bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: XML catalog draft To: lee@sq.com Date: Fri, 7 Feb 1997 14:21:46 -0500 (EST) Cc: w3c-sgml-wg@w3.org > I think that it would be better to specify that URNs be used (which I > would support) than FPIs (which I do not support), as there is still no > resolution mechanism that will scale up to millions of FPIs even > proposed, let alone working, as far as I can see. ISO can mandate the > use of things that don't exist and might never work, but that doesn't > mean we can, and if you need a W3C Recommendation and/or an RFC, that > won't cut any ice. (why do people need to cut ice? it comes in cubes) The proposal leaves the resolution mechanism up to the application as it should. Therefore we do not need to argue FPIs vs. URNs. Furthermore, when URN resolution mechanisms become available, FPI resolution mechanisms will also become available (global resolution mechanisms, I mean), because the representation of an FPI as a URN and the set of all FPIs as a URN namespace is straightforward. There is no dichtomy, nor any competition between them. > > Either way, some means of associating > > catalogues or ilinksets with documents is required. > Clearly -- otherwise we haven't solved the problem, but only made it > more complicated. A way of getting from instance to catalog is needed. I don't agree here. Catalogs are useful without a transmission mechanism. If I send you a file with I have a feeling that your software will resolve it correctly. On the other hand! I think that a mechanism for associating catalogs with instances is useful, and important. I raised this in the catalog group, and we agreed that it was outside of our mandate and did not bother to discuss it further. Some of us felt that it was something that the ERB should add when they integrate the catalog proposal with the XML spec. I planned to recommend a mechanism to the ERB independent from the catalog group, but could not decide between the Socat-way, with a file named "catalog" which is very convenient, but tromps on the user's filename space, (perhaps less if the file was named xml-cat) or with a processing instruction, which is syntactically ugly and a little inconvenient to add to each document. Comments welcome. > I will say right now that we spent a lot of effort on this topic for > SoftQuad Panorama, and didn't get it right in the 1st release. > > It's still not perfect, but we have backward compatibility issues. > Let's do it right for XML. What is "right"? Your experience with this issue will be useful to us. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 16:27:49 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: Re: 1.4 h: Explainer? At 06:20 PM 2/7/97 +0000, you wrote: >At 10:29 7/2/97 -0600, Len Bullard wrote: > >>VRML uses Description. Caption is better than explainer. > >This sounds much better >---- >Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK >Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ In that case, I like "link description" even better than "link caption" -- congruent with SOMETHING ELSE and real, clear English. CAption could imply a certain position in a layout. Liora ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 7 Feb 97 17:23:17 EST To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft [this is a long article because of the notes at the end on how Panorama actually fetches SGML OPEN CATALOG files, and some (by no means all) of the issues involved. Lee ] Paul Prescod wrote: > The proposal leaves the resolution mechanism up to the application as it > should. No it shouldn't. I want something that works. In the same way. Everywhere. That is what we all need. There is no point saying the market will produce lots of competing mechanisms and the best one will win. They will all lose. [...] > > > Either way, some means of associating > > > catalogues or ilinksets with documents is required. > > Clearly -- otherwise we haven't solved the problem, but only made it > > more complicated. A way of getting from instance to catalog is needed. > > I don't agree here. Catalogs are useful without a transmission mechanism. I didn't say they weren't. Nor did Terry. > If I send you a file with > I have a feeling that your software will resolve it correctly. Wrong. And what if I put up on the Web an XML file using PUBLIC "-//Liam Quin//DTD b359//EN" which the draft allows. How are you going to resolve = find = use the DTD? If you say that's not specified, please start again. > On the other hand! I think that a mechanism for associating catalogs with > instances is useful, and important. Which is what I said in my article, and all I said. > I raised this in the catalog group, and > we agreed that it was outside of our mandate and did not bother to discuss it > further. Some of us felt that it was something that the ERB should > add when they integrate the catalog proposal with the XML spec. Then I hope the ERB sends you all back to the drawing board. What is the catalog _for_? It is for turning a PUBLIC ID into a SYSTEM ID. That is _all_ it is for. You now have to solve the problem of finding the CATALOG in the first place, or you have not solved the required problem. If I say, I'd like a brandy but I don't have one, telling me, "you can get brandy by pouring it out of a brandy bottle" doesn't help me very much; it only frustrates me, because if I had a brandy bottle, I wouldn't have said I didn't have any brandy. If I say, I'd like a SYSTEM ID, telling me I can get one in a CATALOG file that I don't have is similar, except I need a SYSTEM ID to get the CATALOG, whereas I need money to get the brandy (usually -- anyone willing to swap brandy for PUBLIC identifiers??) > I planned to recommend a mechanism to the ERB independent from the catalog > group, but could not decide between the Socat-way, with a file named > "catalog" which is very convenient, but tromps on the user's filename > space, If SGML users are keeping files around called catalog.soc that are not SGML OPEN catalogs, that's their problem. > (perhaps less if the file was named xml-cat) or with a processing > instruction, which is syntactically ugly and a little inconvenient to > add to each document. There are no files on the web -- a URL is not a filename. Now, they usually map into filenames, but given the following URL to an XML file, how do I get to the catalog? http://some.where.com/cgi-bin/documentation/bk12/ch3;level=novice hint: cgi-bin/documentation is a program, a CGI interface to a document management system doing dynamic fragmentation of SGML/XML; I cannot store CATALOG files in the database... (since they are not SGML) let's say. This is a real, common example (but with a fake URL here!) > > I will say right now that we spent a lot of effort on this topic for > > SoftQuad Panorama, and didn't get it right in the 1st release. > > > > It's still not perfect, but we have backward compatibility issues. > > Let's do it right for XML. > > What is "right"? Your experience with this issue will be useful to us. (1) allow links from the doc to the DTD directly (no catalog) even if there is a PUBLIC ID (Pano does this -- you'll see why in a sec) (2) allow a way of identifying a "base" URL of the current document, so that relative paths can work in links & sys-ids. Allow this to be prepended to the file with no other processing (it would come before the header in this case, I expect) so that it can be done by a non-XML-aware proxy server or very simple CGI script. Panorama 2 uses a processing instruction for this -- we didn't have it for Panorama 1, and this was a big problem, as you couldn't get bookmarks and annotations working from GET-style search queries without it. (3) use the same mechanism to link style sheets to instances as you use to link documents to instances. Panorama uses a separate file, "entityrc", but I now wish that the information had all beein in one place, e.g. "catalog". If you use public identifiers to link to style sheets, you will need to be able to give both a PUBLIC and a SYSTEM for the DTD as in (1), but you will need the SYSTEM identifier to override the PUBLIC one in the case where you don't actually have a catalog file. (4) remember that you can't do file system probes. The original CATALOG spec said that the filename for catalog was case insensitive. Originally, because of its Windows heritage (despite the first version ("darc") being on Unix!), Panorama looked for CATALOG on the remote server. But more than half of all web servers are running Unix today, and the path parts of URLS are case sensitive. We got so many support calls about this that today Panorama looks first for "catalog" and then for "CATALOG", but the failed probe does cause an obscure (to the user) error message on many systems. We never implemented the TR requirement of supporting Catalog, cAtalog, and so forth, as each one would take a separate HTTP transaction... This has been fixed (the TR was changed, as I recall), but it is best if you never have to look and see if a URL works or not. Sometimes, a URL probe might actually cost money -- e.g.if you're paying for documents -- or might require a password, or might simply fail silently with a zero-length "document" being returned, or a document being returned saying "the URL you requested was not found; please check your spelling..."!!! (5) allow an instance to indicate that no CATALOG exists, and to give all the information in some other way. Same for style sheet linkage, whether using CATALOG or ENTITYRC (I hope not) or something else. This need follows from a combination of the need to support database queries and the inadvisability of trying to do something like file system probes. (6) you need to be able to associate multiple style sheets with each instance (e.g. for printing), and possibly other things, such as Java programs, active table of contents definitions, metadata, collection information, location on navigational maps, and so forth. Public identifiers can be used as part of this, as can processing instructions. However you do it, it's essential that the same files can be viewed locally with no web server and locally or remotely using a web server, as otherwise it's imossible to test them without putting them on a web server. The best way to do this is to treat all system identifiers as partial URLs, relative to the file containing them. This means that if you open /users/liam/docs/barefoot/ankle1.xml and it refers to SYSTEM "walking.dtd" then an XML application ought tolook for /users/liam/docs/barefoot/walking.dtd but if exactly the same unchanged bytestream had been downloaded as http://www.sq.com/people/liam/ankle1.xml (this is a fake URL) then the same XML application should resolve "walking.dtd" as http:://www.sq.com/people/liam/walking.dtd and if it had been ftp://.... then the same procedure should be used. You have to consider what to do with a URL such as: http://...../ankle1.xml;version=3 and SYSTEM "walking.dtd;version=2" where presumably we should look for http://...../walking.dtd;version=2 and not try to apply both sets of MIME parameters. (the ; is a preferred alternative to using & in queries, too) Sorry, I have probably written too much already. All of these issues need to be solved, or you won't end up with interchangeable SGML on the Web. I know. I've been there. I don't want to force the same solutions we used on people necessarily, but the same issues do need to be addressed. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 1997 18:30:28 -0400 To: w3c-sgml-wg@w3.org From: murray@spyglass.com (Murray Altheim) Subject: Re: XML catalog draft lee@sq.com writes: >> I raised this in the catalog group, and >> we agreed that it was outside of our mandate and did not bother to discuss it >> further. Some of us felt that it was something that the ERB should >> add when they integrate the catalog proposal with the XML spec. > >Then I hope the ERB sends you all back to the drawing board. >What is the catalog _for_? It is for turning a PUBLIC ID into a SYSTEM ID. >That is _all_ it is for. You now have to solve the problem of finding >the CATALOG in the first place, or you have not solved the required >problem. I really have no problem at all with your accurate statement of the need for a resolution mechanism. But I must ask the question 'What is XML _for_?' in the same way you do, as we aren't trying to solve all the world's problems here, simply come up with a simplified subset of SGML called XML. There are a lot of thorny problems that XML may force to a head, but within the XML specification(s) I don't believe it appropriate to try to force resolution of this issue or of entity resolution in general. I do agree that the market will solve this (hopefully soon), as the need is obviously there. And it may be an XML application that points the way. This isn't a matter of passing the buck; it's simply outside the mandate for XML. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 18:03:53 -0600 From: len bullard To: Murray Altheim CC: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Murray Altheim wrote: > > I do agree that the market will solve this (hopefully soon), as the need is > obviously there. And it may be an XML application that points the way. This > isn't a matter of passing the buck; it's simply outside the mandate for > XML. True. But it isn't outside a mandate for a consortium reference implementation. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 1997 16:49: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: Re: 1.4 h: Explainer? [Liora Alschuler:] | This is a link caption so call it a "link caption" or if there are | reasons not to use caption, then some of the other common words | already used to describe what it does: "link title" or "link subtitle" I don't like "explainer" either (there seems to be a consensus building on the dislike, anyway), but "caption" is too presentationally specific; you wouldn't want to call this a caption if it were an item in a menu list, for example. I would suggest "label" (that is, more formally, "link label"). Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 1997 16:51: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: 1.4 f: terms for links colocated with their ends [Liora Alschuler:] | Is there a reason why we can't just call these "direct" and "indirect" | links? I agree with Liora. These work very well intuitively and are about as apropos as anything else that's been suggested. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 7 Feb 97 19:43:01 EST To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft murray@spyglass.com (Murray Altheim) wrote: [...] > I really have no problem at all with your accurate statement of the need > for a resolution mechanism. But I must ask the question 'What is XML > _for_?' in the same way you do, as we aren't trying to solve all the > world's problems here, simply come up with a simplified subset of SGML > called XML. See the list activity page, http://www.w3.org/pub/WWW/MarkUp/SGML/Activity. We're trying to make a subset of SGML that's especially suitable for use on the Internet. Yes, entity resolution _is_ needed, and yes, I do believe it's in scope. The market won't solve it. Individual companies will solve it in incompatible ways. > This isn't a matter of passing the buck; it's simply outside the mandate for > XML. I believe it is firmly within our mandate. What good is SGML on the Internet if the spec doesn't say how you use it on the Internet?? Jon, you there? What do you think? I don't care if non-Internet uses of XML don't have to include any way of doing http (for example) -- I do care if two http-based XML systems can't share the same files because they have incompatible rules for looking up FPIs and mapping to SYSTEM IDs. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 1997 16:58:13 -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: 1.4 a-c: Basic Terminology I agree completely with Liora on everything she says about this point. (Not surprising, since I am strongly motivated by the same desire to make everything as easy as possible to explain.) Formally: link element link pointer link end Informally: link pointer end I can live with terminus, but I *know* that everyone will call these things "link ends". Why not use the term that people are going to use anyway? Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 19:22:01 -0600 From: len bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: 1.4 f: terms for links colocated with their ends Jon Bosak wrote: > > [Liora Alschuler:] > > | Is there a reason why we can't just call these "direct" and "indirect" > | links? > > I agree with Liora. These work very well intuitively and are about as > apropos as anything else that's been suggested. They are functional labels and do not indicate function. So, no, not intuitive. Why not use independent link and context link? They are standard and a large segment of the SGML community recognizes them? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 1997 17:18:06 -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 catalog draft [Liam Quin:] | I think that it would be better to specify that URNs be used (which I | would support) than FPIs (which I do not support), as there is still | no resolution mechanism that will scale up to millions of FPIs even | proposed, let alone working, as far as I can see. With all due respect for the URN effort, I'm not convinced that it's very far along toward implementation, either. And I'm beginning to suspect that we could, in fact, come up with a believable resolution mechanism for millions of FPIs. This is just a sketch, but consider: Given DELEGATE, a catalog-based mechanism works for a reasonably large number of FPIs on something the size of a corporate network. The problem comes when something links to an FPI that's not in the space defined by local catalogs. Let's suppose that "-//FOOCORP::FOOAUTH//DOCUMENT sometitle ver1.01//EN" fails to find resolution at the local level. Postulate the existence of a server (probably mirrored, but let's stay above that level of detail for the nonce) funded by every organization that wishes to use this mechanism. Let's call this server xmlid.net. That server does not have a listing for every FPI; all it has is one (and only one) entry for every publisher that has joined the cooperative. So on that server there is a single lookup table cached in RAM, one line of which consists of FOOCORP::FOOAUTH on one side and foodocs.foo.com on the other. Add to the abilities assumed for the XML client under the XML catalog proposal the following: it can query xmlid.net with the string FOOCORP::FOOAUTH and get back foodocs.foo.com; it can then query foodocs.foo.com for its corporate catalog; and it can add that corporate catalog to its own for long enough to resolve the query (or fail, but that's entirely FooCorp's responsibility). This isn't enough to build a resolution mechanism, but it's enough to think that building one might be possible. Is there anything basically wrong with the idea? Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 7 Feb 97 21:39:19 EST To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: 1.4 f: terms for links colocated with their ends > | Is there a reason why we can't just call these "direct" and "indirect" > | links? > > I agree with Liora. These work very well intuitively and are about as > apropos as anything else that's been suggested. They are good terms, but not the right ones (sorry). An indirect link ought to be the case where I have a link (a thingie) that points to another link, and that link is the real link that is used. E.g. Link called Priscilla: I am a link betweeen word 3 of paragraph 1 of chapter 2 in document 301 and all of footnote 27 in document 906 Link Called Ignatius: I am an indirect link. When you use me, you are really supposed to use Priscilla instead. That means that if you are going uphill, you get to word 3 of paragraph 1 of chapter 2 in document 301 and if you are coming back downhill, you get to all of footnote 27 in document 906 The TEI Pointers support such indirection, for example, although without explicit use of the names Priscilla and Ignatius :-) As I understand the proposal, there are three things conflabulated: (1) Internal or External: whether the link is contained within the document that uses it; Example: a HyTime "ilink" can be internal or external, but a "clink" (as far as I know) must be internal. An HTML must be internal -- it must be contained in the document that's at one end of the link. (2) With an implicit end document: whether the link is between this document and others, or between two arbitrary documents not necessarily including this document; Example: in HTML establishes a link between the current document and another one; one end of the link is implied by putting the in a particular document, and HTML software (such as Mosaic or Lynx) inferrs this. (3) participating or detached: whether one end of the link is where the link occurs or whether the link's markup itself is not part of the link. Example: The HTML construct xxx surrounds a region of a document (xxx) that's one end of a link, so the markup participates in the link. Of course, has to be in the document that's at one end of the link, and hence is also Internal. A HyTime "clink" is contained in the document that's one end of the link, so it's Internal, but the clink markup can go anywhere in the document, and is detached; you establish the position within the this-end-document using an ID/IDREF link to point to the clink, a subject of much confusion amongst HyTime learners. (HyTime doesn't describe it like this -- I am concerned here with giving an example of a detatched link, not with describing HyTime correctly) An annotation held in a separate file might be an exmple of a link that's External. If the actual annotation is placed inside the markup of that External link, the markup is Participating in the link -- i.e. the link is itself one of its own end points. If all the annotations in that separate file refer to the same document, perhaps as determined by a header in the annotation file, then the annotation links in tht file needn't name the other document each time; in that case, our annotation has an Implicit End Document. Not all combinations are useful: a unary external participating link with an implicit endpoint is a binary link waiting to happen :-) Having sorted out the concepts (I hope), perhaps we can find terms for them that we like, and preferably that don't use analogies like harpoons (pointy bits on the ends of ropes) or railway stations (terminuses -- although checking the dictionary I see that in English a terminus can also be a milestone as well as a railway station or a town or city containing one, in English it can't be the end of a link) or airports. I've got lots of analogies. Full of them. I can tell you why an External Unary Link is like an odd sock in an otherwise empty sock drawer if you like :-) For now, I have Internal if it's contained in a document it refers to; Participating if it's one of its own end points. With an Implicit End if one end point (or more) is deduced from the context in which the link occurs. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 7 Feb 97 21:59:53 EST To: w3c-sgml-wg@w3.org Subject: Re: 1.4 f: terms for links colocated with their ends Len said: > Why not use independent link and context link? They are > standard and a large segment of the SGML community recognizes them? As long as they are not shortened to ilink and clink that's not too bad, but there is no point in confusing 1000000 people because a community of under 100 people who understand HyTime well would prefer those terms with which they are the most comfortable :-) I have just posted to suggest splitting the various concepts out and having 3 names -- internal/external, implicit end, and participating. An ilink can be internal or external, is not participating (since it is not itself one of the link ends) and does not have an implicit end, since all the ends are given in the linl. A clink is internal, and has an implicit end document which is the one that contains it. It is not participating because it is not one of its own link ends. An HTML is internal, participates in the link, and has an implicit end document (this one). So I am saying call them all links, and give them attributes that describe them in more detail when more detail is needed. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 7 Feb 97 21:52:49 EST To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft I'd said: > | I think that it would be better to specify that URNs be used (which I > | would support) than FPIs (which I do not support), as there is still > | no resolution mechanism that will scale up to millions of FPIs even > | proposed, let alone working, as far as I can see. Jon replied: > With all due respect for the URN effort, I'm not convinced that it's > very far along toward implementation, either. And I'm beginning to > suspect that we could, in fact, come up with a believable resolution > mechanism for millions of FPIs. I'm sorry, I wasn't very clear what I wanted when it came to FPIs that could be treated as URNs. I would rather say you can use any URN you like, since they all have the necessary properties of perstance and uniqueness and being cool that we need than restrict XML to one particular kind of identifier that might or might not become a URN in the not too distant future. If you allow any URN, then if FPIs start to have a URN resolution mechanism, you can use FPIs, and if they don't, but sock weaving patterns are used instead, you can use a sock weaving pattern and get the same result. Translation of existing SGML FPIs into sock weaving patterns may be hard, I admit. But you don't have to do that, because if FPIs are not made resolvable, are not URNs, then in the URN world they are no bettwe than system identifiers, as we have no reliable universal eternal omnipresent inescapable resolution for them (!). So in that case you have to use system identifiers, and whether you put them in a CATALOG or in your instance and look them up in a catalog they are still system identifiers. So when you do the other transformations on your SGML to make it into valid XML -- e.g. changing the syntax of EMPTY elements to use , adding the procinst at the header, normalising OMITTAG and SHORTTAG usages, removing CONREF elements, normalising SHORTREF and so forth, you can add Change FPIs into either sock weaving patterns or SYSTEM IDs, as approriate. If you do this on the fly at runtime in a server (presumably with a cache for acceptable performnce), then if FPIs ever became usable, you could use them. Your sketch might or might not be workable. I'm not sure, because (1) it would have to compete more or less in price with the other URN schemes for the user; (2) it would need to deal with the case where a firm goes out of business and no longer pays for its FPIs to be kept in the catalogue (URNs have this to deal with too, of course) (3) it's less glamorous than sock weaving patterns, which could look really cool on your screen -- although I am not sure how many different socks you can weave with fixed length weaving patterns :-( But even if it is, why make the restriction? I think that it makes us _rely_ on an FPI resolution scheme, whereas allowing URNs would enable us to _use_ an FPI resolution scheme if one came along, but any other URN mechanism would also work, Perhaps the best thing to do is wait six months on this issue, and see which URN schemes are being deployed successfully. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 7 Feb 1997 19:29:39 -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 catalog draft [Murray Altheim:] | I really have no problem at all with your accurate statement of the | need for a resolution mechanism. But I must ask the question 'What is | XML _for_?' in the same way you do, as we aren't trying to solve all | the world's problems here, simply come up with a simplified subset of | SGML called XML. No, we're not trying to "simply come up with a simplified subset of SGML called XML". According to our activity statement:

The W3C has created an Editorial Review Board and Working Group to build a set of standards to make it easy and straightforward to use SGML on the Web: easy to define document types, easy to author and manage SGML-defined documents, and easy to transmit and share them across the Web.

The goal of the W3C SGML activity is to enable generic SGML to be served, received, and processed on the Web. As in the case of HTML, the implementation of SGML on the Web will require attention not just to structure and content, but also to the standardization of linking and display functions.

Requirements

Web servers and clients conforming to the relevant standards must be able to exchange generic SGML documents in a transparent manner. In particular:

  • Web servers with generic SGML content must be able prepare data for transmission. This typically includes the generation of a context wrapper with each SGML fragment together with pointers to an associated DTD and one or more stylesheets.
  • Clients that process generic SGML must be able to unpackage the fragment, parse it in context according to the DTD, render it (if a rendering application) in accordance with the stylesheet, and correctly interpret hypertext semantics (links, etc.) associated with various SGML elements.
There's more going on here than just subsetting SGML. You have to be able to get documents across the Web and they have to be able to do what they're expected to do when they get there. It's still an open question whether this group should be trying to establish or recommend a resolution mechanism, but the question is relevant and will eventually have to be dealt with. Personally, I find that I am much more inclined to try to establish a mechanism than I was a few months ago. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 07 Feb 1997 22:10:15 -0600 From: len bullard To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: 1.4 f: terms for links colocated with their ends lee@sq.com wrote: > > Len said: > > Why not use independent link and context link? They are > > standard and a large segment of the SGML community recognizes them? > > As long as they are not shortened to ilink and clink that's not too bad, > but there is no point in confusing 1000000 people because a community > of under 100 people who understand HyTime well would prefer those terms > with which they are the most comfortable :-) Well, I dare say it is a bigger community, but in either case, it is standard, descriptive, and most of the suggestions so far wander off in the weeds for some reason. I say use the standard and be done with it. Why not? This one will be really hard to explain away later. Anyway, great fun, but this is a loss. Have at. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 08 Feb 1997 11:39:58 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Is XML-Link Rocket Science? Lines: 128 I have been following the discussion of XML-link but as I am not an expert in hypermedia, have not contributed. I have a fundamental concern about the outcome, which I believe is being addressed implicitly but I'd like that confirmed :-). I am assuming that the 10 articles of faith for XML also apply to XML-link - if this is not true, please delete this message :-). I pick: 1. XML shall be straightforwardly usable over the Internet 2. XML shall support a wide variety of applications 4. ****It shall be easy to write programs which process XML documents**** 5. XML documents should be human-legible and reasonably clear 9. XML documents shall be easy to create. Let me suggest a spectrum of people who may potentially develop XML applications and who may create documents (** without using turnkey systems **). At one end are the rocket scientists (RS) - and I fully support the need for XML to be able to support RS. At the other end are webhackers like myself (WH). My concern at present is that XML-link will *only* be usable by RS. I believe that this isn't the intention, but I'm worried that it might turn out that way without the WG realising. My ideal would be to have a solution that had a spectrum of potential applications ranging from WH to RS, and this could be an evolutionary path for WHs, rather than all-or-nothing Let me draw analogies with the following: SGML, HTML, HyTime and DSSSL, and give my position in each. (Remember also that in the scientific/technical community there are a huge number of WH's , mainly self-taught, but capable of creating very valuable applications and information resources. There are very few RS and this is recognised as a serious problem - I sit on a funding body which is trying to bring computer scientists and biologists together). SGML. SGML (pre-XML) started as RS. There was no simple way in for WH's. It relied on the assumption that either you bought a (very expensive) customised system for a particular job, or that you had a specifically-funded academic project (like TEI). To write an SGML parser was RS. (The only reason that I am part of this WG today was that sgmls was developed and I'd like to go on record for my gratitude to James Clark for this. IMO it was a crucial step in bringing SGML to the ordinary person). The next stage , NSGLMS and SP, is even more rocket science. I have looked at the source and can't understand what it does :-), but I'm absolutely sure that it's addressing key issues.) However, even so, full-SGML remains out of reach of most WH's. HTML. The *basis* of HTML (hypermedia and SGML) is also RS, but it was immediately available as a creative tool for the WH as well. To a first approximation WH could ignore SGML - I didn't read the DTDs until 2 years later - and hypertext theory (you just put in HREFs where it seemed sensible). The result is all around us, a vast explosion of creative activity and information interchange, with a complete neglect of formal validity. I see XML as (at least in part) addressing this tradition and bringing it gently to a more formal position. HyTime. HyTime is RS. I tried to get to grips with it, but as far as I could see it required a large investment in time and money and probably a specialised person before I could even tell whether it was worthwhile. Even if it was, none of my colleagues would take it up because there was no easy path. I also looked at Hyper-G (and my colleagues are running it as a server) but it was not trivial. The only other hypermedia system that I am acquainted with is Microcosm. A feature of both Hyper-G and Microcosm is that you have to have special browsers and I assume that will be true for HyTime applications as well. DSSSL. This is RS. I downloaded the spec a few months ago, and after a few minutes discarded it. No-one in our community has heard of Scheme and no-one would know where to get it/implement it, etc. quite apart from learning it. OTOH DSSSL is clearly _a_ right way to manage things but is available to about 0.001% of the WWW community. In a single sentence, I'm very worried that the XML-Link spec will have the same psychological effect on someone as DSSSL did on me. (And I knew a fair amount about structured documents when I first read DSSSL - my community doesn't know what a structured document _is_ :-). [NOTE. I've since read the spec again. It makes a bit more sense. And I'm delighted to see that Alex Milowski has made Kawa (a Java-based Scheme/DSSSL tool) available. Nonetheless it will take at least a week for me to understand how to use it.] XML spans the spectrum between WH and RS perfectly. A WH can hack a _useful_ WF document from a very simple set of rules. Many people can write a WF-parser from scratch (I've done this myself in an amateurish way). However, it is RS to write a validating parser for XML (as evidenced by the fact that there aren't any written yet :-). A validating parser is required before an XML editor can be constructed (though document creation tools do not necessarily require RS). Areas such as entity management and catalogs can be omitted by the WH at the start of their exploration of XML. Question: Do you have to be a Rocket Scientist to create XML-link applications, and to create documents which use XML-Link? If yes, then you will lose the WH community (including myself :-) immediately. The outcome will be that XML-link is only used by commercial publishers (in the most general sense of the term) to create hypermedia systems for which the customers are passive consumers. A partial solution will be to create the tools which are required for the various parts of the process, but if they cost significant amounts of money, or are difficult to learn and use, again we are disenfranchised. My own requirements for XML-Link are: 0. It must be done rigorously. (I am sure that this will happen :-) 1. I should be able to understand the document. (I am not sure of this). 2. It must not be an all-or-nothing solution (i.e. either you are a HyTime expert or you can't use XML-link). (I am not sure of this). 3. If 2., then it should provide useful constructs for solutions 'halfway between HTML and RS'. In this case I am hoping that the experts 'know what I need' even though I cannt formulate that need :-) Some of this may be an educational and presentational problem. Personally I (and many other WH's) learn by doing; i.e. they try it out and see what happens. Very few HTML authors read formal specs. I am also delighted to see the various freely avaliable tools that are already available to help, but there is nothing, as yet, in the XML-Link area. (For example, is a 'link processor' something that is problem-independent and can be produced as a software tool, or does it have to be written for each application?) I appreciate that this is a very challenging task, but I think it will have to be undertaken before XML-Link takes off P. -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 08 Feb 1997 11:06:25 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Lines: 76 In message <199702080118.RAA04259@boethius.eng.sun.com> bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: [... suggestion for XML catalogs ...] I support the _idea_ of this proposal, because it gives an impetus to creating a managed namespace. Sometimes such namespaces can be cheap to create and it simply needs some-body to make a proposal which is sufficiently convincing, and suffiently simple to implement that everyone sees the value and adopts it. (IMO MIME has some of these features though it also has design flaws.) At present the most obvious namespace management available to everyone is DNS. (For example, in 'Java in a Nutshell', p 19, O'Reilly show how it can be used to provide a unique namespace for any Java package, e.g: COM.ora.writers.david.widgets.Barchart; (The first two components are the domain name in reverse order). I am not familiar with the URN process in detail - am I right in assuming that it based on DNS? > Let's suppose that "-//FOOCORP::FOOAUTH//DOCUMENT sometitle > ver1.01//EN" fails to find resolution at the local level. Postulate > the existence of a server (probably mirrored, but let's stay above > that level of detail for the nonce) funded by every organization that > wishes to use this mechanism. Let's call this server xmlid.net. That > server does not have a listing for every FPI; all it has is one (and > only one) entry for every publisher that has joined the cooperative. ^^^^^^^^^ Jon, could you expand on this word, please? If it means 'Those large corporations whose business is publishing information and who are prepared to pay for a maintained site (xmlid.net) to be set up'. If this is the case then it will lead either to a fragmentation of the community, or to a proliferation of 'xmlid.net's (e.g. 'xmlid.net.ac.uk', 'xmlid.bio.net') > So on that server there is a single lookup table cached in RAM, one > line of which consists of FOOCORP::FOOAUTH on one side and > foodocs.foo.com on the other. This server is going to have to be funded somehow, with a registration process and removal of dead entries. Will it, in itself, be able to scale to respond to demand or will there be a DNS-like system of servers? > > Add to the abilities assumed for the XML client under the XML catalog > proposal the following: it can query xmlid.net with the string > FOOCORP::FOOAUTH and get back foodocs.foo.com; it can then query > foodocs.foo.com for its corporate catalog; and it can add that > corporate catalog to its own for long enough to resolve the query (or > fail, but that's entirely FooCorp's responsibility). > > This isn't enough to build a resolution mechanism, but it's enough to > think that building one might be possible. Is there anything > basically wrong with the idea? It seems to involve a mapping of organisations onto domain names. For example SUN:: would map onto sun.com (right?). Is SUN:: the only component of SUN or are there also SUNSOFT, SUN_MICROSYSTEMS, etc. It seems to me that it is necessary to have a feel for the stability of organisation names before you can get an idea of the work involved. If domain names are a useful approach, what about the use of something like: http://www.sun.com/xmlcatalog/ This says, in effect, if your site (or server) has implemented XML then this is reserved request for the XML catalog that relates to XML information on that site/server. It's unlikely to clash with existing namespace (apart from people who used XML for something else :-). Webmasters could easily implement it, and it should be fairly straightforward to update the local catalog. P. -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 8 Feb 1997 16:59:29 -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: Is XML-Link Rocket Science? As my fellow ERB members are acutely aware, I am highly sympathetic to the thrust of Peter's remarks about the need to make what we're doing understandable to the slowest members of the class. Me, for example. The good news is that it seems to be happening. I finally got out from under an important internal commitment at Sun long enough to sit down this morning and read through the revised link spec. I was delighted to find it 80 percent understandable on the first reading. I didn't even need analgesics or antacids to get through it. Reading Eve's simplification proposal was tougher going because it's about the architectural form approach, and that's most of the 20 percent that I'm not understanding in the official proposal. But as the canary in this particular mineshaft, I can tell you that we are making real progress here. I'm not sure that it's realistic to expect the mlinks ever to be easy to understand right off the bat, because what they are expressing are relational structures that are difficult to fathom regardless of the syntax. If mlinks are to do their job, it will always be possible to create structures that only a rocket scientist will understand. But in the area of the tlinks I feel confident that we will be able to produce something not much harder to understand than the HTML
link, and we ought to be able to create an mlink syntax that ordinary people can use to express simple associations. Implementing mlinks is another matter, but that's something that will probably have to be left to the rocket scientists anyway. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 08 Feb 1997 20:52:44 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft lee@sq.com wrote: > > [this is a long article because of the notes at the end on how Panorama > actually fetches SGML OPEN CATALOG files, and some (by no means all) > of the issues involved. > Lee > ] > > Paul Prescod wrote: > > The proposal leaves the resolution mechanism up to the application as it > > should. > > No it shouldn't. > I want something that works. In the same way. Everywhere. > That is what we all need. > > There is no point saying the market will produce lots of competing > mechanisms and the best one will win. They will all lose. I think history disagrees. SGML didn't choose a single resolution mechanism for either public or system identifiers. Because of the first choice, we can still reasonably discuss how to use URN resolvers as Public Identifier resolvers without going back and changing the SGML spec. Leaving that as a system option was a Good Idea and we are benefitting from it now. Similarly, SGML did not specify a special syntax for system identifiers or a resolution mechanism for them. Thanks to that "omission" we can now use URLs in XML. Once again, that was a Good Decision. Now it would not have hurt anything if SGML had *suggested* a resolution mechanism for each of them, as long as there was an "out" that would allow XML to be created and to ignore posix file names and FPI catalogs (or whatever else SGML would have standardized). Progress has not stopped. Things still change. I think it would be a huge mistake to exclusively require a single mechanism that "works in the same way everwhere", for always. In fact, I think it would be an impediment to development *right now*. When I use XML on my intranet, I should be able to use whatever mechanism I want to find the catalog, and I should be able to skip the catalog altogether if I feel like it. Suggesting a resolution mechanism would be fine, even a good idea, in my opinion. Exclusively mandating one would be a big mistake. > I don't care if non-Internet uses of XML don't have to include any way > of doing http (for example) -- I do care if two http-based XML systems > can't share the same files because they have incompatible rules for looking > up FPIs and mapping to SYSTEM IDs. At this point, it is worth bringing in some history. XML 1.0 November Draft not only did not have a specification for catalogs, it explicitly prohibitted public identifier lookup by not allowing any place for public identifiers in the ssyntax. As far as I was and am, concerned, the provision of that syntax is *sufficient* for a high quality, useful standard. If vendors implement public identifiers in incompatible ways, then you can always use system identifiers on the Web, and public identifiers on your internal systems. You can even have your httpd map public identifiers to system identifiers. If the web market demands public identifiers, they can go through the same process the SGML community did, to standardize them: *as long as the XML syntax allows it*. Which it didn't before. That is really all I wanted fixed. I've made the analogy before that public identifiers are addressing processing instructions. Every parser must read them, but they need not use them in the same way. If you want 100% reliability, then you can either standardize explicitly (as people sometimes standardize processing instructions, within a department, organization, or across the whole SGML community), or you can avoid them (and use system identifiers) or use them internally and map to system identifiers externally (using httpd, or Perl or whatever). To argue that a feature is useless if everyone cannot use it in the same way is to argue that processing instructions or formal system identifiers or new URL schemes or alternate text encodings or even DTDs... are useless. Sometimes you put hooks into a spec for *private use* and hope that enough people will find it useful in private to try to standardize it publically. If we want to standardize it publically now, we can, but we should not try to force our solution on everybody, because this is, in my opinion, one of the points in the spec that we should explicitly leave open to experimentation. To sum up: I think it would be nice and useful if we could send catalogs over the web in a reliable way, as Panorama does. But I think it is crucial that I be allowed to use them on my computer, or in my organization in the way I want to, without violating the XML specification. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 08 Feb 1997 21:08:15 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Peter Murray-Rust wrote: > I am not familiar with the URN process in detail - am I right in assuming > that it based on DNS? As I understand it, there is no URN process: " Last, this document intentionally does not address the problem of name resolution, other than to recommend that for each naming authority a name translation mechanism exist. Naming authorities assign names, while resolvers or location services of some sort assist or provide URN to URL mapping. There may be one or many such services for the resources named by a particular naming authority. It may also be the case that there are generic ones providing service for many resources of differing naming authorities. Some may be authoritative and others not. Some may be highly reliable or highly available or highly responsive to updates or highly focussed by other criteria such as subject matter. Of course, it is also possible that some naming authorities will also act as resolvers for the resources they have named. This document supports and encourages third party and distributed services in this area, and therefore intentionally makes no statements about requirements of URNs or naming authorities on resolvers." http://sunsite.auc.dk/RFC/rfc/rfc1737.html Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 08 Feb 1997 20:23:57 -0600 From: len bullard To: w3c-sgml-wg@w3.org Subject: Reference Implementation (Was: Re: XML catalog draft) Paul Prescod wrote: > > To sum up: I think it would be nice and useful if we could send catalogs over the > web in a reliable way, as Panorama does. But I think it is crucial that I be > allowed to use them on my computer, or in my organization in the way I want > to, without violating the XML specification. Yes. But Lee has a very valid point: proof. There is a middle way. No implementations of XML exist. HTML/HTTP got a leg up by the presence of libWWW. Sure, not too many browser vendors would use libWWW now, but it did show how it could be done, and that it could be done. While the specification should not be a blueprint for implementation, a reference implementation can be. This is the course I think the consortium members should consider. Further, the work should begin now BEFORE there are several implementations claiming hegemony by colonization. This has become a very hot topic in VRML now, and unfortunately, as VRML is in the 2.0 stage, it is harder to establish a common practice. There are also very difficult problems with the 3D animation and rendering features that will delay acceptance of any proposed reference implementation submitted by a vendor. If we have learned nothing else, surely we now understand the persuasiveness of "running code". It tests 1.0. Those tests point the way to 2.0. And so it goes. Len Bullard Lockheed Martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 08 Feb 1997 20:15:08 -0600 From: len bullard To: w3c-sgml-wg@w3.org Subject: Re: Is XML-Link Rocket Science? Jon Bosak wrote: > > I'm not sure that it's realistic to expect the mlinks ever to be easy > to understand right off the bat, because what they are expressing are > relational structures that are difficult to fathom regardless of the > syntax. If mlinks are to do their job, it will always be possible to > create structures that only a rocket scientist will understand. But > in the area of the tlinks I feel confident that we will be able to > produce something not much harder to understand than the HTML > link, and we ought to be able to create an mlink syntax that ordinary > people can use to express simple associations. I second Jon on this issue. Again, from watching the VRML experience, it was very rough sledding to master the complexities of 3D animation given only the specification. I have been a reviewer for the annotated 2.0 version and was already proficient with the 1.0 version. It was still tough. However, as soon (and even before) the actual specification was published, books were hitting the shelves that made it possible to master by example. So, I think while XML will be straightforward for those who are SGML literate and understand hypermedia, for many, these concepts will require hands-on experience. We can work as hard as we can to make it clear in the spec, but the spec should err on the side of being unambiguous particularly for implementors. The *average user* (whoever that is) will master XML through the tools. > Implementing mlinks is > another matter, but that's something that will probably have to be > left to the rocket scientists anyway. I live in a town full of them. Don't hold your breath. ;-) len > Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 8 Feb 97 21:36:29 EST To: papresco@calum.csclub.uwaterloo.ca, w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Paul Prescod wrote: > [...] SGML didn't choose a single resolution mechanism > for either public or system identifiers. Because of the first choice, we can > still reasonably discuss how to use URN resolvers as Public Identifier > resolvers without going back and changing the SGML spec. Leaving that as a > system option was a Good Idea and we are benefitting from it now. We are working on XML because how to use SGML over the Web is neither simple nor well defined. > Similarly, SGML did not specify a special syntax for system identifiers or > a resolution mechanism for them. Thanks to that "omission" we can now use URLs > in XML. Once again, that was a Good Decision. That "omission" has been corrected, and SGML now has FSIs, because of problems with SGML systems not being sufficiently interoperable in practice. > Suggesting a resolution mechanism would be fine, even a good idea, > in my opinion. Exclusively mandating one would be a big mistake. I think that again we are at cross-purposes. I am not proposing mandating a single resolution mechanism. I am saying tht the proposal has to work, in the sense that its proponents have to show how you can deliver XML on the web (our Purpose) using it. >> I don't care if non-Internet uses of XML don't have to include any way >> of doing http (for example) -- I do care if two http-based XML systems >> can't share the same files because they have incompatible rules for looking >> up FPIs and mapping to SYSTEM IDs. > > At this point, it is worth bringing in some history. XML 1.0 November Draft > not only did not have a specification for catalogs, it explicitly prohibitted > public identifier lookup by not allowing any place for public identifiers > in the syntax. As you know, I am aware of that. I poopsed the introduction of FPIs then, and I still think they are making things far more complex than they need to be or ought to be. But if we have to have them, they had better work. > If vendors implement public identifiers in incompatible ways, > then you can always use system identifiers > on the Web, and public identifiers on your internal systems. We are not here to standardise what people do on their own internal systems -- we are here to standardise interchange. > If the web market demands public identifiers, they can go through the > same process the SGML community did, to standardize them: *as long as > the XML syntax allows it*. Which it didn't before. That is really all > I wanted fixed. It would be better to extend the syntax later, in XML 2, if that were true. > To sum up: I think it would be nice and useful if we could send > catalogs over the web in a reliable way, as Panorama does. But I > think it is crucial that I be allowed to use them on my computer, or > in my organization in the way I want to, without violating the XML > specification. What you do on your own computer is up to you. It is only the interchange that we must standardise. If we have PUBLIC identifiers in files, and catalogs in some standard way, but no way to interchange catalogs, and no way to get a catalog given an XML file, we have failed to specify enough details to get interchange of XML files working over the web. And that's what we're here for, so that's what we have to do. If you want, you can allow for RCDATA marked sections and starttag entities in your XML spec, in case we want them later (we might), but I don't think that's very sensible. Yes, there's a legacy problem, you can say -- if I can have a PUBLIC identifier in an XML file that is ignored by all standard conforming applications, then I can have my own private non-XML system using them and that gives me a nice feeling. (is that a fair summary?) But when XML 2 comes along (say) and PUBLIC identifiers are now required to be sock weaving patterns, you're still hosed. And if someone else's implementation tries to look up PUBLIC IDs before SYSTEM IDs, and produces an error message on failure, your files are not interoperable. By not specifying how PUBLIC IDs work, that's the sort of problem we'll have. Paul, I'm sorry -- it's clear that you are trying to achieve something that I do not understand, and in which I at present see no merit at all, but only many problems. Perhaps you should give us some clear, concrete examples of how PUBLIC helps interchange XML documents over the web, or how there is no circumstance, now or future, in which it can hinder such interchange, and what other gain is made. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 06:54:36 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: XML catalog draft Paul Grosso wrote: >> Why is # not included in SpecialChars? > >RestrictedLiteralChars is a synonym for 8879's "minimum data character" >(production 78). SpecialChars is a synonym for 8879's "Special" character >class which 8879 defines to be the characters shown for SpecialChars above >and which does not include the # character. > >In other words, if we allowed # in SpecialChars, an XML PublicID would >not be a value 8879 minimum literal and hence not a valid 8879 public id. I knew this, but the question I wanted to raise is whether there is a real need to restrict XML public IDs to the same rules as SGML ones. I'm not convinced there is, despite my strong allegience to SGML. My reasons are stated below. >> (It might be nice to use the URL >> fragment identifier as part of a public ID in some cases, even though this >> might lead to incompatiblities with SGML name rules, which were done before >> URLs became popular.) > >It seems to me that a URL makes more sense as a system identifier than >a public identifier. You could use a public identifier and map it into >a URL via the catalog, but I wouldn't say something with a URL >fragment identifier needs to be able to be a public ID. Let me give an example of why I think there is a case for # in XML public IDs. My material on ODA, SGML and XML all sits in a single file. I could give this file a ISO 9070 conformant public id of +//EU::ECHO::IM::INFO2000::OII//TEXT Document Standards//EN This works fine in a catalog that is simply a catalog. The problem I have is in reusing this information as part of a XML XLG link group. Here I need to refer to a lower level, to the fragment IDs for ODA, SGML and XML. Now I could do something like: +//EU::ECHO::IM::INFO2000::OII//TEXT Document Standards::ODA//EN +//EU::ECHO::IM::INFO2000::OII//TEXT Document Standards::SGML//EN +//EU::ECHO::IM::INFO2000::OII//TEXT Document Standards::XML//EN OK, I'm still kosher SGML here, but the mapping between system IDs and public IDs would be easier if I could adopt the following alternative names: +//EU::ECHO::IM::INFO2000::OII//TEXT docstand.html#ODA//EN +//EU::ECHO::IM::INFO2000::OII//TEXT docstand.html#SGML//EN +//EU::ECHO::IM::INFO2000::OII//TEXT docstand.html#XML//EN This form would allow automatic translation of my existing anchors into public IDs, without having to add a manual intervention stage to define the name that the file is to be known as. It is with this in mind that I asked that we think carefully as to whether there would be advantages in allowing # to be used in XML public IDs. (I have also asked that it be added to the SGML minimum data character set when SGML is revised.) ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 10:09:56 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: Is XML-Link Rocket Science? Lines: 96 Thanks for the reassurances that are starting to appear :-) In message <32FD332C.4599@hiwaay.net> len bullard writes: > Jon Bosak wrote: > > > > I'm not sure that it's realistic to expect the mlinks ever to be easy > > to understand right off the bat, because what they are expressing are > > relational structures that are difficult to fathom regardless of the > > syntax. If mlinks are to do their job, it will always be possible to I am glad to see a distinction here between various levels of XML-link. I am not sure what a tlink is - I assume that alink in the spec falls into that category? [BTW as a hypermedia non-expert I favour the use of monosemes which are new to me (mlink, ilink, clink, etc.) rather than polysemes which I would probably misinterpret (e.g. 'pointer').] It is the *usage* of these things that is the problem for people like me. I read the spec for mlink and I can get a feel for how it might be used, but I'm not clear whether it has a fairly limited use or whether it can, in practice, be combined in many different ways. It seems clear that it can be used for transmitting complex networks of links (a Good Thing), but can it be used in a one-off manner? (For example, would an mlink be useful in defining the connections between components on a circuit board? Would there be just one mlink, or lots of them? If there are lots, does it need another level of hierarchy to manage the first lot?) To draw an analogy with HTML. The A Element has attributes REL, REV and METHODS. AFAIK they are virtually never used. (I know that Murray Maloney and other wrote a proposal on their use, but I don't know where it got to.) In simple terms, when the first version of HTML was introduced, virtually noone knew what the semantics of REL and REV were. (There is a sentence or two for each, but it doesn't go as far as telling someone how to create a document which uses them or a browser which processes them.) I assume that REL and REV suffer from limited power (though HTML-hackers have been very good at adding implied semantics where necessary). If REL/REV had really been seen to fill a need then I suspect that people would have built systems to fill that need by hacking them. I assume that they could be used to *describe* bidirectional links in a primitive way, even though the maintenance of the system might be hairy. My worry is that if people read the spec for MLINK and ALINK and see a list of attributes that is 3-4 times larger than for A, they will switch off unless the point is very clearly presented in non-abstract terms. The other (probably worse) danger is that because there is no general understanding, non-communicating groups will start adding incompatible semantics to these attributes. Once added (in the 'market-place') they can't be disassembled. > > create structures that only a rocket scientist will understand. But > > in the area of the tlinks I feel confident that we will be able to > > produce something not much harder to understand than the HTML > > link, and we ought to be able to create an mlink syntax that ordinary > > people can use to express simple associations. I'm heartened by this :-) > > I second Jon on this issue. Again, from watching the VRML experience, > it was very rough sledding to master the complexities of 3D animation > given only the specification. I have been a reviewer for the > annotated 2.0 version and was already proficient with the 1.0 > version. It was still tough. However, as soon (and even before) > the actual specification was published, books were hitting the shelves > that made it possible to master by example. So, I think while Yes! > XML will be straightforward for those who are SGML literate and ^^^ XML+XML-LINK?? > understand hypermedia, for many, these concepts will require > hands-on experience. We can work as hard as we can to make > it clear in the spec, but the spec should err on the side of > being unambiguous particularly for implementors. The *average user* > (whoever that is) will master XML through the tools. Yes! > > Implementing mlinks is > > another matter, but that's something that will probably have to be > > left to the rocket scientists anyway. I don't disagree with this. Building semantic networks, dynamic topic maps, etc. is not trivial and there is no point in trying to make it less rigorous than it should be. But I would still strongly argue for philanthropists to make generic tools available in this area, because most of the commercial systems will probably hide the mlink-ing deep under the surface. Nothing wrong with that, but it doesn't help people develop by example. P. -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 09:55:33 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: Reference Implementation (Was: Re: XML catalog draft) I agree that reference implementations are good, Len. I don't agree that they should be used in order to avoid standardizing some things. If we can agree on an appropriate default resolution mechanism, then we should just do so and put it in the spec. On the other hand, if our resolution mechanism is so complex that there is a chance that vendors would balk at implementing it, then that's where a reference implementation would make sense. But maybe at that point, we've already made a mistake in making the mechanism complex. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 09:50:32 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft lee@sq.com wrote: > > Similarly, SGML did not specify a special syntax for system identifiers or > > a resolution mechanism for them. Thanks to that "omission" we can now use URLs > > in XML. Once again, that was a Good Decision. > That "omission" has been corrected, and SGML now has FSIs, because of > problems with SGML systems not being sufficiently interoperable in practice. I don't think that FSIs meet your criteria of being usable and reliable in the same way everywhere. They seem to me to be just a syntax for saying: "Here's something you may or may not understand. It has notation FOOBAR, so if you know how to deal with that, you know how to deal with this." So they are still open-ended in the way I am arguing public identifiers should be. But I'm certainly happy to be educated if I'm wrong.  > I think that again we are at cross-purposes. I am not proposing mandating > a single resolution mechanism. I am saying tht the proposal has to work, > in the sense that its proponents have to show how you can deliver XML > on the web (our Purpose) using it. What I am arguing for, primarily is a separation of baby and bathwater. We can add a default catalog resolution mechanism. I voted for that. But some may still vote against it. Jon is voting for a powerful and complex delegation mechanism. I voted against that. James wants us to figure out the interoperation with URNs and FSIs and everything else. The baby is the simple, opaque PUBLIC string that SGML people use to good effect today. The bathwater is the resolution argument which may or may not ever be resolved. If we can suggest a solution to the latter, great! Let's do it. I'm just arguing that we needent tie the former to the latter. What about interoperability? Interoperability is primarily what we came here for, but I don't think it is the *only* thing we came here for. For instance, we decided to let XML have processing instructions, despite the fact that we know that they can cause problems. But we decided that in the tug of war between a) the private interoperability cost and b) the private "usefullness" benefit, they were worth keeping. We made the same choice with character sets (though you can imagine the potential interoperability costs there are huge). What about the fact that you can use arbitrary URL schemes, even some that have not been invented? Or link to arbitrary binary objects that some clients may not know how to render? In fact, we made the same choice with DTDs. If we wanted to take interoperability to the extreme, we could fix the tag set available in XML. You and I know that multiple tag sets are a MASSIVE source of interoperability problems. But they are also a massive source of POWER and usefullness, and that's why we're here. On the other hand, we went the opposite way on some choices. For instance requiring a concrete delimiter set is a little less useful than allowing an abstract set, but it is much more interoperable. Back to the point: the baby is the string "PUBIC foobarbaz". By itself, it can't hurt anything. Used in conjunction with a system identifier, it can be skipped with a call to a single C function, and totally ignored. If we decide that we cannot work out the interoperability problems today, then we should not decide that we must remove the syntactic feature that a) is useful in legacy systems and systems under construction today and b) will allow us to build a globally interoperable system tomorrow. > Yes, there's a legacy problem, you can say -- if I can have a PUBLIC > identifier in an XML file that is ignored by all standard conforming > applications, then I can have my own private non-XML system using > them and that gives me a nice feeling. (is that a fair summary?) I would put it stronger than "gives me a nice feeling." I would put it: "SGML based systems already know how to use them, and use them to good effect and some people are building large, useful, important systems based upon them. I suspect that they could also be well used by new systems such as HTML editors and website maintainers." And the system only becomes "non-XML" if we make them illegal in XML. > But when XML 2 comes along (say) and PUBLIC identifiers are now > required to be sock weaving patterns, you're still hosed. How could this happen? The semantics of public identifiers are well understood, whether the resolution mechanism is or not. Was there any danger of the SOCAT spec. declaring that all public identifiers must be sock weaving patterns? Anyhow, there is always the danger that a future spec. will tromp on your namespace unless the specifiers are required to avoid that by namespace segmentation or something. > And if > someone else's implementation tries to look up PUBLIC IDs before > SYSTEM IDs, and produces an error message on failure, your files are > not interoperable. By not specifying how PUBLIC IDs work, that's > the sort of problem we'll have. If the language of the XML spec makes the system identifier primary, this will not be a problem. I think that it is clear that if we do not specify a mechanism for public identifier resolution and catalog resolution, the system identifier should be primary.  >Perhaps you should give us some clear, > concrete examples of how PUBLIC helps interchange XML documents > over the web, or how there is no circumstance, now or future, in > which it can hinder such interchange, and what other gain is made. There are several features in XML that could hinder interchange, including the fact that XML is a meta-language, but each must be weighed against the potential benefit. The act that XML is a meta-language will certainly impede interoperability (think of indexing metadata, or conversion to another file format), but the power offered by that feature is larger. I believe the same would be true of PUBLIC identifiers in the event that we cannot agree on a default handling mechanism for them. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 09:12:17 -0600 From: len bullard To: Paul Prescod CC: w3c-sgml-wg@w3.org Subject: Re: Reference Implementation (Was: Re: XML catalog draft) Paul Prescod wrote: > > I agree that reference implementations are good, Len. > > I don't agree that they should be used in order to avoid standardizing > some things. If we can agree on an appropriate default resolution > mechanism, then we should just do so and put it in the spec. It is not to avoid standardizing it. It is to avoid standardizing something for which perfectly good alternatives can and will be proposed and from quarters outside the working group, the consortium, perhaps even the SGML community. It is also to focus effort on an implementation that cn be widely shared quickly just as most of us use SGMLS and SP. It is also to avoid a long and very rough debate in which the only proof would be running code anyway. If the editors are to stick to their schedules, then a reference implementation effort may require a different approach than that used to manage this list. If the consortium were to sanction that, then it would be possible to have several groups propose a design for an RI from which the best of breed can be chosen. > On the other hand, if our resolution mechanism is so complex that there > is a chance that vendors would balk at implementing it, then that's where > a reference implementation would make sense. But maybe at that point, > we've already made a mistake in making the mechanism complex. They may not balk; they may not be interested. Paul, everyone knew how to design HTML in the eighties. Many understood what was required for HTTP. NO ONE WAS INTERESTED. Durand had it right when he said, "Berners-Lee said, let links break". Sometimes the quick way is to just build it and field it. It gets mindshare: it creates market: it makes substandard applications dominant. Netscape and IE don't break HTML because they are *greedy blue meanies*; they break it because they have to in order to make progress. This is what is about to happen: several vendors see XML as an opportunity to get products they already had in development to market under a single banner. There are those who think Panorama, HyBrowse, etc. represent viable implementations. They may, but there are not references to test. There are also different ways to build these just as there are better ways to build browsers than libWWW. If we do not wish a ground war to break out, a single implementation such as libWWW exemplified, is a good way to measure these implementations. If such an effort is begun soon, it will be possible to work out the technical difficulties of the XML spec before we get a lot further down the road. Remember, SGML Open and other organizations have an interest here. An RI doesn't mean, "this is the only way to do it"; it means, here is a library one MIGHT use and by which SOME tests can be conducted. It is also a way to meet the criticism that we have specified things that can't or won't be adopted because no resolution mechanism was provided. So, provide one, but leave some wiggle room for development. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 97 10:32:14 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > From: Martin Bryan > > Paul Grosso wrote: > > >> Why is # not included in SpecialChars? > > > >In other words, if we allowed # in SpecialChars, an XML PublicID would > >not be a value 8879 minimum literal and hence not a valid 8879 public id. > > I knew this, but the question I wanted to raise is whether there is a real > need to restrict XML public IDs to the same rules as SGML ones. I'm not > convinced there is, despite my strong allegience to SGML. My reasons are > stated below. A reasonable question to raise, but it seems we should have a good reason to do something incompatible with 8879 (not that I haven't been annoyed by the restrictions of minimum literals before, but we've decided many times before in this XML work that we would stick within the framework of 8879 unless we had a really good reason). > > Let me give an example of why I think there is a case for # in XML public IDs. > > My material on ODA, SGML and XML all sits in a single file. I could give > this file a ISO 9070 conformant public id of > +//EU::ECHO::IM::INFO2000::OII//TEXT Document Standards//EN > > This works fine in a catalog that is simply a catalog. The problem I have is > in reusing this information as part of a XML XLG link group. Here I need to > refer to a lower level, to the fragment IDs for ODA, SGML and XML. Now I > could do something like: > +//EU::ECHO::IM::INFO2000::OII//TEXT Document Standards::ODA//EN > +//EU::ECHO::IM::INFO2000::OII//TEXT Document Standards::SGML//EN > +//EU::ECHO::IM::INFO2000::OII//TEXT Document Standards::XML//EN > > OK, I'm still kosher SGML here, but the mapping between system IDs and > public IDs would be easier if I could adopt the following alternative names: > > +//EU::ECHO::IM::INFO2000::OII//TEXT docstand.html#ODA//EN > +//EU::ECHO::IM::INFO2000::OII//TEXT docstand.html#SGML//EN > +//EU::ECHO::IM::INFO2000::OII//TEXT docstand.html#XML//EN > > This form would allow automatic translation of my existing anchors into > public IDs, without having to add a manual intervention stage to define the > name that the file is to be known as. It is with this in mind that I asked > that we think carefully as to whether there would be advantages in allowing > # to be used in XML public IDs. (I have also asked that it be added to the > SGML minimum data character set when SGML is revised.) If by definition, a public id is something that gets mapped into a system id, I fail to see the need for # in a public id based on your example. Make your public id the "kosher SGML" one and map it into whatever system id you want (with #'s in it or whatever). Your non-kosher "public ids" are system ids. You've got file names and subnames embedded in them. I don't understand the automatic translation of which you speak. It sounds like you're talking about translating system ids into public ids, but that's "backwards." That may be something of interest for an authoring system, but an XML application still needs to map those public ids back into system ids to do anything. How is that to be done? If through a catalog, then you'll need to set up the catalog that maps the public ids to system ids, and I don't see why you can't do that for valid public ids as easily as for invalid ones. If you are suggesting that your invalid public ids "contain" the system id and can therefore be mapped back into the corresponding system id without a catalog, that sounds like a system-specific, non-interoperable mapping--which basically leads me back to saying your invalid public ids might as well be system ids. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 97 10:17:04 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > From: lee@sq.com > > > If we have PUBLIC identifiers in files, and catalogs in some standard > way, but no way to interchange catalogs, and no way to get a catalog > given an XML file, we have failed to specify enough details to get > interchange of XML files working over the web. And that's what we're > here for, so that's what we have to do. > > . . . Lee, I hear you expressing unhappiness with the catalog proposal as it stands, but all I can determine as your problem with it is that it doesn't specify how the XML implementation will determine what the catalog is. I'm failing to understand why go on at length about this. I understand you to say you don't want a final XML spec that says nothing about how an implementation should find its catalog. Okay. Point taken. Some might disagree and prefer to leave it unspecified, but I suspect a majority of us would at least like to see a non-binding recommendation as to how an XML implementation could find its catalog. So either (a) suggest some words right now that you'd like to add to the proposal or (b) let's agree now that, once we determine how an XML application will find its style sheet, we'll define an analogous way for it to find its catalog. It seems more important to me to determine first (1) if we will add public identifiers to XML, and (2) if so, if we will recommend a catalog-based resolution scheme in XML, and (3) if so, will we limit the right hand side of catalogs to the same things allowed in XML system identifiers, and (4) if so, will that be URLs or will we expand what we allow as XML system identifiers. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 9 Feb 97 14:42:44 EST To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Paul wrote: > I hear you expressing unhappiness with the catalog proposal as it > stands, but all I can determine as your problem with it is that it > doesn't specify how the XML implementation will determine what the > catalog is. I'm failing to understand why go on at length about this. I'm not actually compalaining about that proposal particularly. Sorry if I wasn't clear about that. I am saying that we can't stop there, because it doesn't solve enough of the problem to be useful. I think that there are two acceptable scenarios which will work: (1) no FPIs at all. I favour this very strongly indeed. (2) FPIs are used, and any XML application that needs to can turn the FPI into a system identifier and proceed. (This is what Paul Prescod is opposing. I _think_ he wants all resolution methods to be proprietary, so that we should not recommend one.) > I understand you to say you don't want a final XML spec that says > nothing about how an implementation should find its catalog. Okay. > Point taken. Some might disagree and prefer to leave it unspecified, > but I suspect a majority of us would at least like to see a non-binding > recommendation as to how an XML implementation could find its catalog. Yes. Otherwise, if ArborText and SoftQuad and Synex and InSo/EBT and TechnoTeacher and thirtyfive other companies all have XML products, and you put an XML file on the web, you may need to deal with 40 different ways of handling PUBLIC identifiers in order that your XML file "just works". > So either (a) suggest some words right now that you'd like to add to > the proposal or (b) let's agree now that, once we determine how an XML > application will find its style sheet, we'll define an analogous way > for it to find its catalog. I am happy with either of these. I will append a suggested mechanism. Thanks for the prod :-) > It seems more important to me to determine first (1) if we will add > public identifiers to XML I don't think we should decide to do that. When this first came up, I asked what problems were being solved. The answers were * backward compatibility with a different (not XML) language with which we were not otherwise compatible (i.e. existing SGML documents are very unlikely to work unchanged as XML, because of the different EMPTY syntax, the lack of CONREF, content model changes, etc.) * warm fuzzy feelings that public identifiers are better than system identifiers * the possibility of indirection -- which can be done in other ways -- to achieve document longevity Of these, only the last made or makes any sense to me. If you have URNs, you can put a URN in the system identifier and solve the problem that way. No extra language keyword is needed for that. The people who were arguing for the need for indirection seem to include those who are now arguing that we shouldn't say how to do it. I think PUBLIC is being added for no other reason than warm fuzzies > and (2) if so, if we will recommend a > catalog-based resolution scheme in XML, I don't have feelings on this as long as it's no more than a way to go from PUBLIC to SYSTEM identifiers (as James pointed out), and as long as we document carefully, completely and exactly how to get >from a PUBLIC identifier to a CATALOG file. > and (3) if so, will we limit > the right hand side of catalogs to the same things allowed in XML > system identifiers, Yes. Obviously we must. If you need to add more features to system identifiers, add them everywhere. If not, don't. > and (4) if so, will that be URLs or will we expand > what we allow as XML system identifiers. They must be the same. * OK, here is a suggested way to get to a CATALOG file. [0] do not look for a catalog file unless you come across a PUBLIC identifier. [1] if there is a processing instruction tht occurs before the DOCTYPE line of the form then that is the system identifier of the catalog and all other mechanisms are disregarded. [2] determine the base address of the XML document as a system identifier. This may come from a processing instruction before the DOCTYPE line, or may be known externally. The processing instruction always takes precedence. [3] search for "catalog.soc" as if it had been given as a relative URL embedded in the document at the point of the PUBLIC Idenntifier, using the mechansism described in RFC 1808, Relative Uniform Resource Locators. [4] an application may choose to keep a cache of PUBLIC entities. If so, it is up to the application whether to use CATALOG resolution if it has already stored a system identifier for that public Id; however, it should if possible check to see if any remote files have changed before using cached copies. What have I left out? Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 11:34:03 -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: Is XML-Link Rocket Science? [Peter Murray-Rust:] | I am not sure what a tlink is - I assume that alink in the spec falls | into that category? When anchors became termini, alinks became tlinks. See the draft of 970131. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 12:02:20 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Get rid of the leading hyphen! After looking at the examples in the link proposals I find that I cannot face the prospect of working for the next 10 or 20 years with this. We should get rid of the hyphen in front of XML in reserved names and attributes. "-XML" is ugly, it's hard to type, it looks dumb, and it doesn't really pollute the name space any less than any other reserved string. Reserve "XML" and be done with it. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 11:54: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: Section 0: Naming [Liora Alschuler:] | I have to side with XML Link or XML Linking (is a hyphen | necessary?). The XML-Hyper-X suggestions expand to something like: | hypertext enhanced extensible markup language. | | This is not only a mouthful but reads like a superset of XML, (if you | want the whole shebang you've got to have this stuff which is the | *enhanced* XML) where I believe we want to convey that the linking | spec is a module of the larger concept which is XML. XML Linking keeps | the proper relationship between XML and the XML linking spec (I don't | think the hyphen is necessary.) Yes, exactly. XML-link (or whatever) is the name for a modular piece of the XML specification, and what it specifies is part of XML, not some other language. The fact that we're trying to engineer this in a way that could make it usable with other markup languages (which is just a nice-to-have feature, not something essential to our goal) doesn't change this at all. There is a very close parallel between XML-link and the part of the TEI guidelines that describes extended pointers. When the link draft refers to this part of TEI, it uses phrases like "features of TEI extended pointers" and "a subset of the syntax defined for TEI extended pointers". It doesn't need to invent some fabulous creature like "the TEI Extended Pointer Language (TEIEPL)" to refer to a piece of the TEI specification. Similarly, a future application that uses the linking features of XML can simply refer to them as "the linking features of XML". We don't need to invent a special term for this purpose. As far as I can tell, the term "XML-link" (or whatever) is needed in exactly one place: the title page for the part of the spec that, for editorial reasons, we decided to put under a separate cover. I cannot find a single place in the spec itself where the term "XHL" or "XHA" cannot simply be replaced with "XML" except in the couple of spots where the current draft tries to set it up as a separate language. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lex@www.copsol.com (Alex Milowski) Subject: Re: XML catalog draft To: w3c-sgml-wg@w3.org Date: Sun, 9 Feb 1997 14:29:39 -0600 (CST) Hello all, I have been following the discussion of XML catalogs *very* close. I'm going to start this e-mail with something that many of you may not agree with: Catalogs are *not* sufficient for manipulation and transmission of XML (or SGML) documents. Let me regress,... Once upon a not-to-distant-past, I designed and wrote a simple SGML repository for a client. They had to have something quick and nothing in the industry really met their needs for the cost they would have to spend on buying one. So, I set out to build a repository. I had some simple design constraints stemming from decisions on "standards" for their authoring environment: 1. Every entity had a unique name across all documents. 2. Every public identifier is unique across all documents. 3. Every entity name starts with a "owner" code. 4. After the owner code, a code that identifies the entity use is required. For example, if the owner was 'CSI' and the entity was a passage of legal text, its use code was 'LNG' for 'language'. Thus, the entity would be named 'CSI.LNG.Something'. In addition, we were moving from a file-base authoring environment and the authors needed to be able to organize entities much like they had organized files. Thus, we needed a virtual directory structure that enforced unique entity names across all entities in the repositories. I created a simple object model that had a flat namespace for maintaining the constraints outlined above and had other organizational constructs for presenting a usable interface to a user. Note: This company has 11,000 "entities" for 100 documents. Now, once the repository was built, I had to import the data. Well, I thought: "Easy, I have an SGML Open catalog that has all of them defined." Wrong. It doesn't work. First, everything with a public identifier can't be imported because there is no entity name defined. From SGML, this really doesn't matter. That is, I can have two entities x and y that have the same public identifier. In this model--environment constraint--that would be wrong (illegal). We needed these constraints to maximize reuse and allow the ability for questions to be asked like: Who uses this entity? Now, what does this have to do with catalogs? I my mind (sometimes a scary place), if SGML Open catalogs can't do the above, it begs the question of *why* it is not complete. The answer--again, in my mind--is that they are single-purpose. Resolve this entity to something. We have a greater issue in XML of solving the fundamental problem that our documents exist as a collection of distinct information types with relationships (a hypertext relationship!), not single "files" or streams that can cascade resolution schemes for finding the rest of the pieces. Lets look at the simple case: If my document is self-contained, does an XML processor "know" that it doesn't need a catalog? Maybe. ...more complex: If I have a document which refers to an entity x, which has two possible choices (configurations), what do I have to do to configure this? If we keep expanding such questions, we can see that additional constructs would have to be put in place to handle different problems such as databases. We we have done is designed to the specific case when our problem is much more broad. We need to step back and see how we can orchestrate a broad solution that is, to some extent, future proof (extendible). In my thinking for this client I mentioned, we have already discussed the idea of "meta-documents". Documents that describe all the components necessary and all the variations (if possible) such that an application can load this meta-document. The essential idea is this: The XML (SGML) document is at the same "class" or "level" as the other information components--style-sheets, graphics, transformations, etc. It is a very important component in the system, but not very useful in a practical way without the other components. Thus, it is *not* the starting point. The collective information about all the components necessary to handle, process, identify, etc. this document--the meta-document--is the first-class construct. The meta-document is the starting point. >From this, I'm going to make some observations: 1. It is possible to define a known document type to encode such a meta-document. This is not necessary but it would seem unlikely to developed "yet-another-document-information-encoding" (YADIE). 2. The meta-document and its components could be encoded in one stream such that a request is made for the meta document "stream" and all information is shipped to the application. This does *not* require that all components are packed into this stream. It only requires that they be identified. Anyone familiar with the concept of JAR files can see where this is coming from. 3. For simple documents one-time documents, packing everything into a stream is very useful. The meta-document in this case may be very small--only a few bytes. 4. The need for "catalog location", "style-sheet location", etc. standards goes away and gets replaced with a uniform mechanism for describing component locations and relationships. I have attached a very simple DTD for such a meta-document. I wrote this very quickly and it *doesn't* contain all the ideas that I have about this subject but I wanted something concrete. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 12:52:14 -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 marketing contributions A slogan: "XML is HTML's big sister." Another slogan: "XML is what I thought SGML was in the first place." Another slogan: "XML gives Java something to do." Improved version by Tim Bray: "XML gives Java something to chew on." An observation by Eve Maler: People have been writing XML all along: ... ... I suggest the name "Natural XML" for such constructions. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 16:15:28 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > (2) FPIs are used, and any XML application that needs to can turn > the FPI into a system identifier and proceed. (This is what > Paul Prescod is opposing. I _think_ he wants all resolution methods > to be proprietary, so that we should not recommend one.) Sorry I wasn't clear. I don't mind that there exists a non-proprietary method as long as there is also the ability to create proprietary methods. In fact I favour it. I think it would be good if we could agree on a default standardized method. But don't think that the existence of PUBLIC in the grammar should be tied to our figuring out a resolution mechanism for them. You and I agree that XML documents can be interchanged without a well defined public identifier resolution mechanism (using system). You seem to believe that leaving PUBLIC in the grammar without a resolution mechanism will inevitably lead to interoperability, and I don't believe that. I think that it will just lead to people using public identifiers in prearranged systems and system identifiers on the Web. I believe that PUBLIC is useful without a well defined resolution mechanism, through pre-arranged conventions and systems, and you may not believe that. Or, to put it another way: in the days before SOCAT, would it have been better to have no public identifier mechanism at all? I certainly used it before there was a well defined mechanism. Author/Editor, in particular had/has a very powerful mapping format that does many things that SOCAT does not. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 9 Feb 97 16:05:45 EST To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: Get rid of the leading hyphen! > We should get rid of the hyphen in front of XML in reserved names and > attributes. I agree... and also for Notation names (which are inconsistent in the current draft and have no hyphen, as per the header). > "-XML" is ugly, it's hard to type, it looks dumb, and it doesn't > really pollute the name space any less than any other reserved string. > Reserve "XML" and be done with it. Couldn't agree more. Fiat XML. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 9 Feb 97 16:13:35 EST To: w3c-sgml-wg@w3.org Subject: Re: Section 0: Naming Jon wrote, very sensibly (as is his wont): > [...] a future application that uses > the linking features of XML can simply refer to them as "the linking > features of XML". We don't need to invent a special term for this > purpose. I agree. There's enough jargon in the world already. HTML has no special term for the way tht linking works with it, and SGML itself has no particualar term (in 8879) to distinguish ID/IDREF links from some other kind of linkage. > [...] I cannot find a single place in the spec itself where the term > "XHL" or "XHA" cannot simply be replaced with "XML" except in the > couple of spots where the current draft tries to set it up as a > separate language. I agree. XML is perfectly fine, and the cover sheet could just as well read HyperText Links in XML Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 16:29:27 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Your proposal sounds okay to me, except for one thing: 1] if there is a processing instruction tht occurs before the DOCTYPE line of the form then that is the system identifier of the catalog and all other mechanisms are disregarded. Why can't this be a relative URL? Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 15:29:08 -0900 To: w3c-sgml-wg@w3.org From: "W. Eliot Kimber" Subject: Re: XML catalog draft At 02:29 PM 2/9/97 -0600, Alex Milowski wrote: >Hello all, > >I have been following the discussion of XML catalogs *very* close. I'm >going to start this e-mail with something that many of you may not >agree with: > > Catalogs are *not* sufficient for manipulation and transmission of > XML (or SGML) documents. [...] > The XML (SGML) document is at the same "class" or "level" as the > other information components--style-sheets, graphics, transformations, > etc. It is a very important component in the system, but not > very useful in a practical way without the other components. Thus, it > is *not* the starting point. > > The collective information about all the components necessary to > handle, process, identify, etc. this document--the meta-document--is > the first-class construct. The meta-document is the starting point. This is what a HyTime hub document is (or can be used as): a document that lists all the other documents in the purview of the system at the moment (e.g., the document management system, retrieval system, etc.). This document would normally also provide some means to access the components, either by linking to them or by transcluding them (so that controllable access policies can be associated with the hub document--if access does not start through the hub document, then there's no telling which hub document's policies apply to a given access session, because you can always create a new hub document). The way I think about it is that any collection of documents is always represented by a (usually virtual but always generatable) "god" document that declares as entities either all the documents in the system or the first level of hierarchy of documents in the system (either will do). Thus, the contents of any document management system can be represented by creating a document that declares at least the top-level of documents (and other storage objects) in the system as entities. Note too that the set of entity declarations required by the god document becomes the catalog, with the difference that each entry in the catalog also has a unique name within the god document's entity name space (one reason to declare all entitites in the god document). In a document management environment, the entity names in the god document are synonymous with the unique object IDs of the objects as known to the document management system (and likewise, the public IDs of the entities (if defined) are synonymous with the object IDs (although there may be a many-to-one relationship of PUBIDs to object IDs)). In other words, outside a document management system, I can refer to entities by their god-document entity name, their publid ID (if defined), or by a document/entity name pair (as any entity name is always unique within a given document). If I load these documents into a document management system, I can use, in addition to the previous three forms of address, the unique object ID assigned to each document. Any SGML document management system that *doesn't* provide these forms of address for document entities *is not a document manager*. [Quick: how many "SGML" document management systems on the market today let you address documents by public ID or entity name? How many can create, on demand, a god document that represents their content? Why not?] This is why the idea of a BOS is so important: it's central to the basic problem of document management. BOSs, access policies, and so on are simply abstractions of the basic facilities that must be provided by any document management system. (One of the interesting implications of this is that any generalized SGML document manager (one that actually manages documents, of which I'm not actually aware of any in existence) can in fact manage anything for which there is an entity declaration, simply by creating the type of meta-structure document Alex presents in his note. I have, for example, a demo of using Panorama to manage Frame documents (read-only, of course)). Cheers, Eliot %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 9 Feb 97 16:39:44 EST To: w3c-sgml-wg@w3.org Subject: Re: Alex's JAR documents [was: XML catalog draft] lex@www.copsol.com (Alex Milowski) wrote: > [...] > Catalogs are *not* sufficient for manipulation and transmission of > XML (or SGML) documents. Yes, I agree. I am prepared to accept that they may be part of a solution, but they are not sufficient. [good example deleted; I have many more examples if they're needed :-)] > The XML (SGML) document is at the same "class" or "level" as the > other information components--style-sheets, graphics, transformations, > etc. It is a very important component in the system, but not > very useful in a practical way without the other components. Thus, it > is *not* the starting point. > > The collective information about all the components necessary to > handle, process, identify, etc. this document--the meta-document--is > the first-class construct. The meta-document is the starting point. One way to look at this is that when you make a link to an XML document, you actually point at a file that points to all the other files that you may need. That file could be an XML file with links, or it could be an SGML OPEN Catalog file. The XML file with links would at least be in an SGML-based syntax, which seems appropriate to me. When this has been discussed in the past, people have objected to the idea that they end up with (in essence) a separate catalog file for each document. But if that linking file actually contained the XML document itself (say), it would be more like a document header, and the resulting file would be self contained. > 2. The meta-document and its components could be encoded in one stream > such that a request is made for the meta document "stream" and > all information is shipped to the application. This does *not* > require that all components are packed into this stream. It only > requires that they be identified. Anyone familiar with the concept of > JAR files can see where this is coming from. I don't know what JAR files are (is it part of JavaBeans?) but want to ake this comment: for fast progressive display, you have to be able to be fetching multiple files at the same time. So you need to get the links as early as possible, and then fetch them (conceptually) in separate streams. Of course, with HTTPng you could use a new virtual stream over the same connection. I think we're agreeing with each other. I'm not alone any more! Yippee! I hereby bequeath Alex all my footwear :-) > 3. For simple documents one-time documents, packing everything into > a stream is very useful. The meta-document in this case may be very > small--only a few bytes. Yes -- where the "catalog" (and possibly style sheet itself and all the other gubbins") is small, the overhead of separate connections, or even separate local file opens, is greater, and the added ease of maintenance is an even bigger benefit. > 4. The need for "catalog location", "style-sheet location", etc. standards > goes away and gets replaced with a uniform mechanism for describing > component locations and relationships. Yes. > I have attached a very simple DTD for such a meta-document. I wrote this > very quickly and it *doesn't* contain all the ideas that I have about this > subject but I wanted something concrete. Although it's disgusting, it may be better to use one of (1) elements starting with XML, or (2) processing instructions. Another way would be to use entities with reserved notations: ]> the fabric of the document An XML system would reserve notations beginning with XML, and would understand what to do with XML-CATALOG and XML-STYLE. They don't need to be declared (can that be kosher SGML?), so this would be the only XML use of NDATA as it stands right now, I think. When we talk about how to mark up an inline TIFF image, we may need to rethink that. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 9 Feb 97 17:04:58 EST To: papresco@calum.csclub.uwaterloo.ca, w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > Your proposal sounds okay to me, except for one thing: > > 1] if there is a processing instruction tht occurs before the DOCTYPE > line of the form then that is the system > identifier of the catalog and all other mechanisms are disregarded. > > Why can't this be a relative URL? It can if you like. I didn't say it couldn't (I hope). But it can also be absolute (complete). You can't always work out the correct relative URL. Example: given the URL http://www.w.com/docs/manuals/prod5/chp3/sec26.xml it may be that this is being created on the fly by DynaWeb (say), and that the CATALOG is actually http://www.w.com/docs/manuals/catalog.soc Example: given the URL http://www.w.com/docs/overview.xml&lang=jp&vers=3&rep=docs/log the correct thing to look for might be http://www.w.com/docs/catalog.soc&lang=jp&vers=3&rep=docs/log or possibly just http://www.w.com/docs/catalog.soc and not the "obvious" http://www.w.com/docs/overview.xml&lang=jp&vers=3&rep=docs/catalog.xml (any or all of the ampersands (&) could be replaced with semicolons (;) in the above example) But it might also be on a different server, so it might be (say) http://catalog.w.com/docs/manuals/prod5/chp3/sec26/catalog.soc So you have to be able to override the default mechanisms. Panorama actually lacks this abiity right now, which is sometimes a problem. There, I've given you all a competitive secret :-) Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 9 Feb 97 16:58:23 EST To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > Sorry I wasn't clear. I don't mind that there exists a non-proprietary > method as long as there is also the ability to create proprietary methods. > In fact I favour it. I think it would be good if we could agree on a > default standardized method. Sorry that I misunderstood, then. So let's define such a method. > But don't think that the existence of PUBLIC in the grammar should be > tied to our figuring out a resolution mechanism for them. You and I > agree that XML documents can be interchanged without a well defined > public identifier resolution mechanism (using system). Yes, we do. But once you add PUBLIC, you have to specify how it changes the meaning of SYSTEM identifiers -- e.g. does a PUBLIC identifier override a SYSTEM one, and can you have bother, and what do you do if one isn't found but the other is, and what do you do if they are both found and are different, or should you only look for one? Minor differences in algorithms between packages can be a major headache. Panorama's method has changed slightly two or three times since the first release -- the biggest change was moving from CATALOG to catalog -- but even the slightest change causes a major support load. No change has been made without good reason, but some people now keep multiple SGML OPEN CATALOGs for a single SGML file. And that's with only one vendor. > You seem to believe that leaving PUBLIC in the grammar without a > resolution mechanism will inevitably lead to [lack of] interoperability, > and I don't believe that. I've seen it happen. > I think that it will just lead to people using > public identifiers in prearranged systems and system identifiers on the > Web. There can be no pre-arranged anything on the web unless you are publishing only to people who have permission or something. It all happens when it happens. > I believe that PUBLIC is useful without a well defined resolution > mechanism, through pre-arranged conventions and systems, and you may > not believe that. I don't. I think it's harmful in our environment. > Or, to put it another way: in the days before SOCAT, would it have been > better to have no public identifier mechanism at all? I certainly used > it before there was a well defined mechanism. So did I. At one point, I proposed a product called the SGML Exchanger. It would ask you for source and target systems, and then edit your SGML, rewriting system and public identifiers, moving DOTYPE lines into or out of the DTD, and updating a CATALOG, extdid.map, rb.map, or whatever file or files the application needed! That's how bad it was. People who used more than 3 or 4 SGML products had a nightmare. That's why SGML OPEN catalogs were designed (thanks, Paul!!!) and that's one big reason why SGML had difficulty in catching on -- more than half the time you couldn't even load someone else's SGML file into your SGML application, depsite SGML being a standard for document interchange -- and we can do better, and we have to do better. > Author/Editor, in particular had/has a very powerful mapping format > that does many things that SOCAT does not. And which we will get rid of as soon as we can in favour of CATALOG. Frankly, having regular expressions to match the public ids was a disaster -- can you imagine how often a public identifier contained a ( or ) or a + or *? We get support calls about extid.map from almost every A/E and R/B installation -- too much power. These days they mostly want to use CATALOG. I agree that the default entry in extid.map is useful, and so is the stuff to map system identifiers -- CATALOG could do with that. Maybe Paul and Peter should get together and make a proposal. But I don't want XML users on the web to have to say Ah, they're publishing this file for Netscape 5.2, but I am using Microsoft Internet Explorer, and I have to use the DNSMAP system, so I can't look at this file unless I download it to my hard disk and make a CATLOG file where Netscape expects it. I wonder if there's a PDF version? It has to "just work" in the common, simple cases. By all means go off and do more powerful things yourself. Imagine if you could only view HTML files by prearrangement... Sorry for the rant. I think that getting this wrong or right is probably more important than anything else, as it doesn't matter how good a language is if you can't deploy it smoothly. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 14:21:33 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@w3.org Subject: The Unoptimized SGML-Bundle Relations Schema for MIME I was going to wait longer before announcing this, but as Alex has broached the subject, I have a sketch of an SGML-and-MIME spec up at http://www.wco.com/~books/draft.5feb97.txt I'm sure my use of multipart/related is off, but the point of the draft is to determine what comprises the totality of the information needed to process an SGML document. It is deliberately prolix in syntax, and the DTDs are not serious. As it is about SGML and not XML, it is probably not suitable for this list, but some might find it interesting. I would be interested in hearing off list about information types or sets I've ignored. That is, I don't particularly want to read "you could do it better this way" or "you don't need foo", at this stage. I really do want to read "you need bar, and it isn't in there." Best regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 17:38:13 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: XML catalog draft (Please let's not argue resolution independence again!) At 5:23 PM 2/7/97, lee@sq.com wrote: >Paul Prescod wrote: >> The proposal leaves the resolution mechanism up to the application as it >> should. > >No it shouldn't. >I want something that works. In the same way. Everywhere. >That is what we all need. Can we stop this right here (I know it's already too late). The idea of _names_ is that they do _not_ have to be resolved that same way everywhere. No _required_ resolution protocol. _Protocol_ _Independent_. This is the key. It means that a client can always arrange _some_ mechanism, and that names do not go stale. In exchange for these benefits, you must be free to change resolution mechanisms, and must accept that some names may become unresolvable by clients who do not know how to resolve them. >There is no point saying the market will produce lots of competing >mechanisms and the best one will win. They will all lose. This discussion went on for 4 years in the URN group, and was stopped by fiat -- if URNs fail, they will fail, but it won't hurt anyone if they do. Let's not waste 4 years on the issue here. I'm interested in you experience with catalog resolution, but I'll let this point stand alone. It is _the_ key point. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 17:38:19 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 1.4 f: terms for links colocated with their ends At 9:59 PM 2/7/97, lee@sq.com wrote: >As long as they are not shortened to ilink and clink that's not too bad, >but there is no point in confusing 1000000 people because a community >of under 100 people who understand HyTime well would prefer those terms >with which they are the most comfortable :-) Exactly right. >I have just posted to suggest splitting the various concepts out >and having 3 names -- internal/external, implicit end, and participating. not _exactly right_ (but close): >An ilink can be internal or external, is not participating (since it is >not itself one of the link ends) and does not have an implicit end, >since all the ends are given in the linl. > >A clink is internal, and has an implicit end document which is the one >that contains it. It is not participating because it is not one of >its own link ends. > >An HTML is internal, participates in the link, and has an >implicit end document (this one). You don't need the distinction between participating and implicit as far as I can tell. The only cases where implicit links have been proposed are those where the link is participating. So we have two axes of variation, and four link types By the way, external, non-participating, 1-ended links are a way to handle external tagging of static documents, and thus are not useless (even if they are quite esoteric). Interestingly, in my 87.1 copy of Literary Machinces, Nelson proposes to use this mechanism for Xanadu (which dates, but does not necessarily recommend it). -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 17:38:16 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 1.4 h: Explainer? At 4:49 PM 2/7/97, Jon Bosak wrote: >I don't like "explainer" either (there seems to be a consensus >building on the dislike, anyway), but "caption" is too >presentationally specific; you wouldn't want to call this a caption if >it were an item in a menu list, for example. I would suggest "label" >(that is, more formally, "link label"). I like "explainer", actually, but then I learned it in high school when using an experimental Hypertext system at Brown -- so it's been in my vocabulary for a long time. I don't like the terms description or caption in any permutations or variations because they imply formatting semantics. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 17:38:05 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 1.4 h: Explainer? At 12:25 PM 2/7/97, Len Bullard wrote: >I think there will be no argument or choice that satisfies all >conditions in all cases. This is why I think it preferable >to use HyTime names where possible. In this coin toss, >the coin should be weighted to the side of the standard. >That is easy to explain(er)/describe/capture. Given the relative user-base size, implementation scope, and pulicity, the weight of "standard" naming would go to the inconsistent and incomplete HTML terminology, which unfortunately conflates several issues that the standard (though not necessarily authors) will have to distinguish. HyTime has the endorsement of the ISO going for it, but it is hardly a lingua franca very far outside this group (and even within it). I like some HyTime terms (like ilink and clink), but the verbosity of other parts confuses me, and given the time that I have devoted to HyTime, I can only assume that it will confuse others (who have not spent that time), as well. -- David I'm not arguing any specific point here, but contesting the general principle that HyTime terminology has special utility because it is standardized. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 14:46:38 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@w3.org Subject: Re "Natural XML" A happy phrase. But there's already another name, "Enriched Text Format" [nee richtext]. See http://mango.human.cornell.edu/kens/etf.html which is a primer on ETF and inter alia lists the relevant RFCs, software that produces it, and client that use it. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 9 Feb 97 18:38:04 EST To: w3c-sgml-wg@w3.org Subject: Re: 1.4 f: terms for links colocated with their ends David Durand wrote: > Liam Quin wrote: >> I have just posted to suggest splitting the various concepts out >> and having 3 names -- internal/external, implicit end, and participating. > > not _exactly right_ (but close): > > You don't need the distinction between participating and implicit as far as > I can tell. The only cases where implicit links have been proposed are > those where the link is participating. So I hereby propose external annotations, which are participating and external, and implicitly all point to the same XML file. Also, a link to a style sheet might be non-participating but internal. > By the way, external, non-participating, 1-ended links are a way to handle > external tagging of static documents, and thus are not useless (even if > they are quite esoteric). Yes -- TIPSTER uses them. The ability to apply styles to link-other-ends is very powerful if you can point to regions of text... as per SDQL. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 09 Feb 1997 15:34:14 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 1.4 f: terms for links colocated with their ends At 05:38 PM 2/9/97 -0500, David Durand wrote: >By the way, external, non-participating, 1-ended links are a way to handle >external tagging of static documents, and thus are not useless (even if >they are quite esoteric). > > Interestingly, in my 87.1 copy of Literary Machinces, Nelson proposes to >use this mechanism for Xanadu Ted still wants to do this. He calls it OSMIC now. -Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 18:28:33 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: "Natural XML" From: John_Lavagnino@Brown.edu How about "Folk XML" instead? "Natural XML" suggests that the real thing is also somehow unnatural. "Folk XML", on the other hand, makes the man-in-the-street version sound OK but untutored, without the unmistakable air of refinement that surrounds real XML. John Lavagnino Women Writers Project, Brown University %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 17:13: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: Re: 1.5: Discuss link characteristics? I'm still trying to figure out the right categories within which to think about formatting, presentation, and behavior. In section 1.5, the current draft says: 4. link formatting: Links commonly differ in how they should be presented. This includes both how the user is informed that a link is present (such as highlighting, perhaps conditioned on history or other factors as in typical Web browsers), but also how the other termini are presented, such as having their title, summary, or explainer shown, or even being completely followed and presented inline with no user action required for traversal. 5. link behavior: Links may have a wide variety of effects when traversed, such as opening, closing, or scrolling windows or panes; displaying the data from various termini in various ways; testing, authenticating, or logging user and context information; executing various programs. Ideally, link behavior should be determined by a semantic specification based on link types, pointer roles, user circumstances, and other factors; just as element formatting is determined by a stylesheet based on element type, context, and other factors. It is recognized that there is significant overlap between the areas of link formatting and link behavior. The list of things that need to be specified is very helpful, but I don't think that the division between formatting and behavior is quite right yet. For one thing, it seems clear to me that inline presentation without user action belongs to behavior rather than formatting. It's very difficult to get these things sorted out, but I persist in the belief that it's necessary to do so. I also persist in the belief that presentation and behavior are at root the same thing, but the list above has persuaded me for the moment that it's more useful to talk about all of this under the heading of behavior rather than presentation. I think that part of the problem is an unexamined tendency (in which I participate) to make the basic cut between that which is visible to the user and that which is not. While this distinction is important, perhaps it should not be the one with the highest logical priority. This leads me to suggest the following. Instead of the two categories "4. link formatting" and "5. link behavior", which I don't think are separable, make a single item number 4, "link behavior", and then distinguish between two categories of behavior, link display and link traversal, as follows: A. Link display How termini are presented to the user. - Possibly conditioned on history - Possibly including (e.g.) menus to display alternative link target labels ("explainers"), termini represented as animated figures, etc. as well as the usual underlining, etc. B. Link traversal What happens when a link is traversed. - Effects when traversed: opening/closing windows, scrolling, displaying data from termini in various ways (including the automatic transclusion of data without user action) - Testing, authenticating, and logging user context information - Running programs Note that in this taxonomy, the distinction between visible and invisible and the distinction between user-initiated and automatic are secondary to the distinction between display behavior and traversal behavior. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 17:32:33 -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 catalog draft [Peter Murray-Rust:] | I am not familiar with the URN process in detail - am I right in | assuming that it based on DNS? Yes. See draft-ietf-urn-naptr-01.txt draft-ietf-urn-http-conv-00.txt I don't understand the URN proposal completely, but it seems to be attempting vastly more than what we need. | > Let's suppose that "-//FOOCORP::FOOAUTH//DOCUMENT sometitle | > ver1.01//EN" fails to find resolution at the local level. Postulate | > the existence of a server (probably mirrored, but let's stay above | > that level of detail for the nonce) funded by every organization that | > wishes to use this mechanism. Let's call this server xmlid.net. That | > server does not have a listing for every FPI; all it has is one (and | > only one) entry for every publisher that has joined the cooperative. | ^^^^^^^^^ Jon, could you expand on this | word, please? If it means 'Those large corporations whose business is | publishing information and who are prepared to pay for a maintained | site (xmlid.net) to be set up'. If this is the case then it will lead | either to a fragmentation of the community, or to a proliferation of | 'xmlid.net's (e.g. 'xmlid.net.ac.uk', 'xmlid.bio.net') I mean what you think, but I don't agree that fragmentation follows. Let's postulate the existence of some organization whose function is to provide such a service and make just enough to pay for itself and the salaries of the people it employs. Take the net operating cost every year, divide by the number of "publishers", and that's how much you charge each publisher. The service provided is pretty simple: maintain one line in a lookup table and respond to HTTP queries giving the left hand side by returning the right hand side. This should cost no more to provide than the typical DNS entry. (And we might take advantage of the fact that this is not DNS by putting in place review and arbitration procedures that take advantage of what has been learned from the DNS registration experience.) I am quite unqualified to make a detailed proposal on how to set this up, but I believe that something along this line could effectively solve the FPI resolution problem. I know that at Sun we are setting up a collaborative authoring system that automatically assigns FPIs to every publication and resolves those FPIs in our distributed publishing system through distributed partial socats which all fall through, in the worst case, to a single socat that we maintain at docs.sun.com (not yet publicly visible, but soon to appear). So for our purposes, which I believe are commensurate with the needs of the great majority of publishers, a system that redirected someone trying to resolve an FPI beginning "-//SUN::SUNSOFT//" to docs.sun.com would work just fine. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 20:32:28 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 1.4 f: terms for links colocated with their ends At 6:38 PM 2/9/97, lee@sq.com wrote: >David Durand wrote: >> Liam Quin wrote: >>> I have just posted to suggest splitting the various concepts out >>> and having 3 names -- internal/external, implicit end, and participating. >> >> not _exactly right_ (but close): >> >> You don't need the distinction between participating and implicit as far as >> I can tell. The only cases where implicit links have been proposed are >> those where the link is participating. > >So I hereby propose external annotations, which are participating and >external, and implicitly all point to the same XML file. Nice. Do we need these enough to need to explain 3 distinctions instead of two? You can keep the destination file explicit, without duplication by using entities Personally I think implicit links to anything but the markup that declares a link are completely evil, as everyone has to understand the "implication" for them to be useful. Of course, if you're just funnin' me for having insufficient link-type imagination, there's no reason to take this note seriously... -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 18:06:02 -0800 (PST) From: Terry Allen To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Jon wrote: | [Peter Murray-Rust:] | | I am not familiar with the URN process in detail - am I right in | | assuming that it based on DNS? | | Yes. See | draft-ietf-urn-naptr-01.txt | draft-ietf-urn-http-conv-00.txt | I don't understand the URN proposal completely, but it seems to be | attempting vastly more than what we need. Not Yes, No. NAPTR is only one proposed URN resolution mechanism. URNs don't depend on NAPTR or DNS, or any one resolution mechanism. In the abstract, you'd have local URN resolution, local instructions to your URN resolution engine, and the ability to link up to larger-scale engines and locally coordinate the results therefrom. NAPTR can address Lee's fear that URNs will not be resolvable, however, and it is reasonable to think that some relevant entity such as (cough) SGML Open or GCA, would see advantage in offering URN resolution for the FPI name space. As for scope, see below. | Let's postulate the existence of some organization whose function is | to provide such a service and make just enough to pay for itself and | the salaries of the people it employs. ... Those would be good salaries with job tenure? Ah, for the Fifties! Anyway, someone else already pointed out the denial-of-service problems that can result from so direct a mechanism. Neither publisher nor user should rely on eternal resolution through a single source. NAPTR does avoid at least most of this problem. If you could manage to get on the wrong side of Internic, watch out, but they don't seem to have a wrong side yet. As a user, if your usual URN resolution setup fails, you want to try something else rather than believing some.org that the URN is no longer resolvable. The hard truth is that some things named by URNs will become unresolvable even though they still exist, just like misshelved books in library. Re scope, the URN effort encompasses no less than what we all need for generalized and indirect persistent naming. Jon doesn't need so much to meet his immediate publishing requirements, because his information has a relatively short shelf life, he can rely on a legal department to help him prevent or mitigate deliberate denial of service, and if some.org cut him off anyway he could make new resolution arrangements known to his audience, because Sun is both big and public and, more importantly, around to tend to matters. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sun, 9 Feb 97 22:54:34 EST To: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: 1.4 f: terms for links colocated with their ends David Durand wrote: > >So I hereby propose external annotations, which are participating and > >external, and implicitly all point to the same XML file. > > Nice. Do we need these enough to need to explain 3 distinctions instead of > two? You can keep the destination file explicit, without duplication by > using entities I'm not sure. SoftQuad Panorama has external annotations, but they are explicit, not implicit, as I recall. It's a ViewPort feature. > Personally I think implicit links to anything but the markup that > declares a link are completely evil, as everyone has to understand the > "implication" for them to be useful. Well, maybe I am evil then. I am barefooted and wearing black. I think implicit link ends are like relative paths and partial URLS. I introduced the three concepts (internal/participating/explicit) so that we could try and grab control of the terminology issue. I wanted to try and be reasonably complete, even though it isn't clear that XML will need all those distinctions. It might later. Lee * > Of course, if you're just funnin' me for having insufficient link-type > imagination, there's no reason to take this note seriously... No. I'd never do that. Well, maybe I would, but I amn't. A new terminology: links are like legs. The linked region is the footprint. The container of the address is a sock. Hmm, no forget it. XML can have 8-way links, and spiders don't wear socks. OK, I've consulted my 1736 dictionary: Link: part of a chain; also a Sausage, because made in that form. Link: a torch of pitch. To Link: to join or tie together. Terminus -- not listed in the dictionary Terminus Deus [among the Romans] the God of Bounds and Limits. The People of Rome were commanded to set Stones on the Confines of their Ground, which were call'd Terminalia; and upon them they offered to Jupiter, to whom they were consecrated; these Stones were every Year crowned with Flowers, and Milk was poured upon them to the God Terminus. The dict. does list Terminalia (a feast of land-marks), to terminate, termination (the end of a word), terminer (a commission...), and Termini censiales [old Records] Rent-Terms, the four quarterly Festivals on which Rent is usually paid. Also, Terminists, and Terminthus (which is very interesting but not relevant to XML). I haven't look'd in my Latin dictionary, Ainsworth's, which also dates >from the 18th C... nor in Johnson's, which is usually less fun. Since all the modern dictionaries (at least the British ones) say a terminus is a railway station, I think we should stick with the railway analogy. A multiway link is called a junction, and a document with no other links is a siding. But I still like the idea of pouring milk on all my links each year! Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 9 Feb 1997 21:41:14 -0800 (PST) From: Kurt Conrad To: w3c-sgml-wg@w3.org Subject: Re: XML marketing contributions On Sun, 9 Feb 1997, Jon Bosak wrote: > An observation by Eve Maler: > > People have been writing XML all along: > > ... > ... > > I suggest the name "Natural XML" for such constructions. or even "Natural Markup" /s/ kwc 2/9/97 21:43 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 09:00:54 +0000 To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 1.5: Discuss link characteristics? Cc: bosak@atlantic-83.eng.sun.com At 17:13 9/2/97 -0800, Jon Bosak wrote: > I also persist in the belief >that presentation and behavior are at root the same thing, but the >list above has persuaded me for the moment that it's more useful to >talk about all of this under the heading of behavior rather than >presentation. They are different. Presentation is concerned with how people recognize that there is behaviour associated with the text: do they prefer underlined text, a different colour, an in-line icon, a marginal note. These things are controllable through user preference, and are therefore overridable at client side. Colour-blind users must be able to use icons, whereas text only viewers must be able to replace icons by some textual indication of the possibility of action. Behaviour is not up to the user, it is up to the author. It is the author/server that has to control what happens when the link is selected by the user. Except in rare cases the user should not be able to change the action that selecting a link causes.This is why you must separate presentation from behaviour. >A. Link display > > How termini are presented to the user. > > - Possibly conditioned on history > > - Possibly including (e.g.) menus to display alternative link > target labels ("explainers"), termini represented as animated > figures, etc. as well as the usual underlining, etc. I like this terminology (except for the termini - how the hell do I present Gard du Nord or Waterloo to users?) >B. Link traversal > > What happens when a link is traversed. > > - Effects when traversed: opening/closing windows, scrolling, > displaying data from termini in various ways (including the > automatic transclusion of data without user action) > > - Testing, authenticating, and logging user context information > > - Running programs This would be better called Link Action. Traversal is not something non-rocket scientists understand. What most users understand by clicking on a hotspot is that some action should take place. This is what the behavioural side of the equation covers. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 09:00:51 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: XML catalog draft Paul Grosso wrote. > >I don't understand the automatic translation of which you speak. It >sounds like you're talking about translating system ids into public >ids, but that's "backwards." The question is "how do I create a public ID in a catalogue without asking the author to do more than point to the thing he wants added to the catalog?". What I am suggesting is a way wherby an author can supply in his system set-up a public identifier source specification and then just point to a file identifier and tick a box that says Add To Catalog? > That may be something of interest for an >authoring system, but an XML application still needs to map those >public ids back into system ids to do anything. How is that to be >done? The catalog still needs a map from the public ID to the system ID, but this is easy. In addition, if it can't find a system ID, it can check the contents of the public ID to see if it can identify a "word" that has a # in it, and try to use that as a system ID. > If through a catalog, then you'll need to set up the catalog >that maps the public ids to system ids, and I don't see why you can't >do that for valid public ids as easily as for invalid ones. If you are >suggesting that your invalid public ids "contain" the system id and can >therefore be mapped back into the corresponding system id without a >catalog, that sounds like a system-specific, non-interoperable >mapping--which basically leads me back to saying your invalid public >ids might as well be system ids. What I'm looking for is the minimal amount of work that a system would have to do to create a catalog entry for a linked document. There have been a number of comments in the link thread about needing to be able to create XML-links by point and click techniques. The same must be true for catalog entries. Somewhere in betweeen lies the management problem. Once the initial point and click operation creates a catalog entry it must be possible at a later date to change the system ID without altering the public ID, even if this means that the URL component of both no longer match. (The fact that they no longer match is a good indicator that the system identifier is a better bet than the original name, and could provide a useful check on which links should be validated first: those that still contain their original address could, for example, be given a higher priority in any checking process.) We need to understand better the relationship between catalog entries, link groups and link definitions before we finalize things. I just want us to keep the idea that having an # in the public ID could be useful in providing us with a minimalist method of creating catalog entries. > >paul > > ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 10 Feb 1997 12:47:10 +0000 (GMT) From: Peter Flynn Subject: Re: XML marketing contributions To: w3c-sgml-wg@w3.org > A slogan: "Practise Safe SGML" ? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 08:17:49 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: Re: 1.4 h: Explainer? >At 4:49 PM 2/7/97, Jon Bosak wrote: >>I don't like "explainer" either (there seems to be a consensus >>building on the dislike, anyway), but "caption" is too >>presentationally specific; you wouldn't want to call this a caption if >>it were an item in a menu list, for example. I would suggest "label" >>(that is, more formally, "link label"). >[David Durand] > >I don't like the terms description or caption in any permutations or >variations because they imply formatting semantics. "Description" does not speak to me of format, but neither does "link label" which is short and sweet. Liora ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 09:07:12 -0500 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft If nothing happens here, I'd be interested in kicking off and forming a catalog resolution group to produce an RC or something suchlike. Like you, I think it's vital. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 09:09:03 -0500 From: gtn@ebt.com (Gavin Nicol) To: bosak@atlantic-83.eng.sun.com CC: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: XML catalog draft >Add to the abilities assumed for the XML client under the XML catalog >proposal the following: it can query xmlid.net with the string >FOOCORP::FOOAUTH and get back foodocs.foo.com; it can then query >foodocs.foo.com for its corporate catalog; and it can add that >corporate catalog to its own for long enough to resolve the query (or >fail, but that's entirely FooCorp's responsibility). We could also use LDAP... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 08:58:40 -0500 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft I think Lee has made some very important points. A catalog is basically a packing list, and if it doesn't exist, or you can't find it, life get's difficult. I wonder if the MIME-SGML work can't be put to good effect here? The problem is basically the same, and Don Stinchfield's proposal could be made protocol independent. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 08:44:08 -0600 From: Len Bullard To: Martin Bryan CC: Jon Bosak , w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? Martin Bryan wrote: > > At 17:13 9/2/97 -0800, Jon Bosak wrote: > > I also persist in the belief > >that presentation and behavior are at root the same thing, but the > >list above has persuaded me for the moment that it's more useful to > >talk about all of this under the heading of behavior rather than > >presentation. > > They are different. Presentation is concerned with how people recognize that > there is behaviour associated with the text: do they prefer underlined text, > a different colour, an in-line icon, a marginal note. These things are > controllable through user preference, and are therefore overridable at > client side. Colour-blind users must be able to use icons, whereas text only > viewers must be able to replace icons by some textual indication of the > possibility of action. > > Behaviour is not up to the user, it is up to the author. It is the > author/server that has to control what happens when the link is selected by > the user. Except in rare cases the user should not be able to change the > action that selecting a link causes.This is why you must separate > presentation from behaviour. This is also in accordance with the way most people think about these issues. It is my expectation that I can use a button or a hotspot or a voice recognition system and still get the same behavior. > I like this terminology (except for the termini - how the hell do I present > Gard du Nord or Waterloo to users?) Termini and terminus look baked. I don't like these. Just trying to say them in a presentation makes one feel one is back in college. > >B. Link traversal > > > This would be better called Link Action. Traversal is not something > non-rocket scientists understand. What most users understand by clicking on > a hotspot is that some action should take place. This is what the > behavioural side of the equation covers. That is much better. Traversal is overworked and action expresses precisely the right notion. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 08:50:54 -0600 From: Len Bullard To: Liora Alschuler CC: w3c-sgml-wg@w3.org Subject: Re: 1.4 h: Explainer? Liora Alschuler wrote: > > >[David Durand] > > > >I don't like the terms description or caption in any permutations or > >variations because they imply formatting semantics. > > "Description" does not speak to me of format, but neither does "link label" > which is short and sweet. Agreed. So far, link label appears to be the most neutral and still conveys the use. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Mon, 10 Feb 97 10:08:16 EST To: w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? Martin Bryan wrote: > Behaviour is not up to the user, it is up to the author. It is the > author/server that has to control what happens when the link is selected by > the user. Except in rare cases the user should not be able to change the > action that selecting a link causes.This is why you must separate > presentation from behaviour. Note that in Netscape, clicking on a link with the middle mouse button opens the target of tht link in a new window; shift-clicking saves the target to disk. These are behaviours chosen by the reader. > I like this terminology (except for the termini - how the hell do I present > Gard du Nord or Waterloo to users?) I am beginning to wonder if "terminus" has a non-railway meaning to North Americans??? It really _is_ awfully comical! > >B. Link traversal > > > > What happens when a link is traversed. > This would be better called Link Action. Traversal is not something > non-rocket scientists understand. I agree. > What most users understand by clicking on > a hotspot is that some action should take place. This is what the > behavioural side of the equation covers. Hmm, no-one has suggested hotspot for the footprint of a link. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 09:52:10 -0500 From: gtn@ebt.com (Gavin Nicol) To: lex@www.copsol.com CC: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > The collective information about all the components necessary to > handle, process, identify, etc. this document--the meta-document--is > the first-class construct. The meta-document is the starting point. Fine. This is roughyl equivalent to the 2 MIME-SGML solutions, where one focused on the catalog as the meta-document, and the other focused on MIME structures. A meta-document is just a packing list, as is a catalog. Catalogs should only be used to identify peices in a given document, not for the basis for name resolution. >1. It is possible to define a known document type to encode such a > meta-document. This is not necessary but it would seem unlikely to > developed "yet-another-document-information-encoding" (YADIE). We already have MIME and catalogs. >2. The meta-document and its components could be encoded in one stream > such that a request is made for the meta document "stream" and > all information is shipped to the application. This does *not* > require that all components are packed into this stream. It only > requires that they be identified. Anyone familiar with the concept of > JAR files can see where this is coming from. Sounds like MIME to me.... >4. The need for "catalog location", "style-sheet location", etc. standards > goes away and gets replaced with a uniform mechanism for describing > component locations and relationships. Sure, instead of pulling the catalog in after accessing the instance, you pull in the instance after accessing the catalog. >I have attached a very simple DTD for such a meta-document. I wrote this >very quickly and it *doesn't* contain all the ideas that I have about this >subject but I wanted something concrete. Some people on this list know that I have little love for the SO catalog syntax, but that seems sufficient to me. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 10:54:05 -0500 From: Paul Prescod To: lee@sq.com CC: papresco@calum.csclub.uwaterloo.ca, w3c-sgml-wg@w3.org Subject: Re: XML catalog draft lee@sq.com wrote: > > > Your proposal sounds okay to me, except for one thing: > > > > 1] if there is a processing instruction tht occurs before the DOCTYPE > > line of the form then that is the system > > identifier of the catalog and all other mechanisms are disregarded. > > > > Why can't this be a relative URL? > > It can if you like. I didn't say it couldn't (I hope). No, but you went into detail elsewhere about how to resolve a relative URL, as if only if the direct pointer failed would you want to look for a relative URL. You even mention the RFC number (elsewhere). Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Mon, 10 Feb 97 15:43:22 GMT To: w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? Certainly it's termini and not links that in the first instance appear somewhere, and therefor may need to be displayed, if you have that kind of application (e.g. a browser). But neither traversal or action is at the right level of generality. [See next message about traversal] Both you and Martin are too focussed, in my view, on browsers and mouse clicks. As a possibly useful example, consider the case of external, non-participating 2-ended links to annotate the translation relationship between the sentences of french and english versions of a bilingual document. A terminology extraction tool will exploit the semantics of such a link (i.e. behave in a certain way) completely differently to a translation tutorial program. I realise this is dragging us back towards the whole link {semantics/type/behaviour} debate, which I have done my best to follow, but it leaves me feeling that although we need to clearly distinguish between 1) intrinsic XML semantics for links, i.e. termini, participation, etc.; 2) XML Application (in the strict SGML sense of 'application') semantics, e.g. the bilingual alignment example above; 3) Implemented application behaviour we are only in the business of specifying (1). ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Mon, 10 Feb 97 16:09:06 GMT To: w3c-sgml-wg@w3.org Subject: 1.2 link and 1.6 traversal I'm sorry to go back to basics, but I think we need to. I think a LOT of the terminological problems we're wrestling with stem >from a simple failure to distinguish things from their specifications, just like the SGML spec. failed to distinguish between text and tree. Our specific problem is not distinguishing between link descriptions and links. Links are out there in the ether, CONNECTING points in document groves. Link descriptions are things you find in documents. Links (types) have a topology (number of ends, directionality), sub-structure (e.g. terminus roles) and contextually-bound semantics (see previous message about Application semantics vs. application behaviour). Links (tokens) have actual end-points. Link descriptions have a syntax (GI, attribute names and values, etc.) and a semantics (what type of link they specify, how to instantiate individual links when processing a link description in a document context). Of course you all understand this distinction, the use of the words 'implicit' and 'explicit' makes that clear (when a link description (type) describes a link one of whose ends is the link description itself, that's the implicit case). But not making the distinction clear in the terminology sows confusion. Consider the text of 1.4.2: > 2. link: A data object which explicitly represents a relationship > between two or more termini. A link has link-type, a name intended to > communicate the overall significance of the relationship. This doesn't GIVE us a name for the thing itself (the 'relationship') and uses 'link' for the description thereof. This may be from a desire to stay close to ordinary usage, but it's causing more trouble than it's worth. The most obvious case is in 1.4.6 > 6. traversal: The action of using a link; that is, of accessing another > terminus from an initial terminus. Usually traversal is considered a > user action (commonly initiated by clicking on a displayed terminus), > but it can also occur under program control. where the incoherent (and not elsewhere defined) idea of an 'initial terminus' is appealed to. Point is, MOST applications will 'use' a link by starting from the link DESCRIPTION, which may or may not be a terminus. Note further that a particular link description may well describe DIFFERENT links at different times or if its host document moves, a point difficult to address if you can't distinguish between the two. I'll try to produce a redraft of 1.4 and 1.5 which points the way to how things might change if this distinction were made explicit. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 09:13:14 -0600 From: Len Bullard To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? lee@sq.com wrote: > I am beginning to wonder if "terminus" has a non-railway meaning to > North Americans??? It really _is_ awfully comical! Americans go to airport terminals. Railways are not used nearly as much. One American's opinion: it looks pedantic. We tend to steer away from such terminology as "high fallutin' BS". OTH, the rate of change in American speech patterns since the invention of mass communications is very high. I can't think of any cases off hand when adopting words from dead languages has been much in vogue. XML - "we can invoke the behavior to link to the terminus" American - "click here and bag that thing" len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 11:36:37 -0400 To: w3c-sgml-wg@w3.org From: murray@spyglass.com (Murray Altheim) Subject: Re: 1.5: Discuss link characteristics? Lee Quin writes: >Martin Bryan wrote: >> Behaviour is not up to the user, it is up to the author. It is the >> author/server that has to control what happens when the link is selected by >> the user. Except in rare cases the user should not be able to change the >> action that selecting a link causes.This is why you must separate >> presentation from behaviour. > >Note that in Netscape, clicking on a link with the middle mouse button >opens the target of the link in a new window; shift-clicking saves the >target to disk. These are behaviours chosen by the reader. There may be cases where the user wants to know where the link goes, but doesn't want to actually traverse the link, such as how Web browsers display the desitination URL. But in no case does clicking on a link take the user to a _different_ location than that intended by the author, and I believe this is the crux of the issue. There are two behaviours here: link destination and browser action. In no case should the browser alter the former. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 12:04:44 -0500 To: w3c-sgml-wg@w3.org From: Liora Alschuler Subject: Re: XML marketing contributions Cc: bosak@atlantic-83.eng.sun.com (Jon Bosak) I'm not wild about any of these, but maybe, like Jon's original list, they will give someone else a push in the right direction: "XML: certified organic SGML" "Faster than a SP'ding bullet, more powerful than an

-- it's hypertext, it's a database, it's XML!" or some variation on: "Link global, code local" [like "think global, act local"] (actually, I kind of like that one -- or should it be: "Link globally, code locally" -- I can't tell anymore.) or, after Eve's nice phrase, "XML: it's what you've been doing all along" "XML: it's what you already know" At 12:52 PM 2/9/97 -0800, Jon Bosak wrote: [condensed] > "XML is HTML's big sister." [you have a very kind idea of a big sister] > "XML is what I thought SGML was in the first place." > "XML gives Java something to do." > Improved version by Tim Bray: > "XML gives Java something to chew on." > >An observation by Eve Maler: > People have been writing XML all along: > ... > ... > >I suggest the name "Natural XML" for such constructions. or just "XML is SGML natural" Liora ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 12:01:03 -0400 To: Peter@ursus.demon.co.uk From: murray@spyglass.com (Murray Altheim) Subject: Re: Is XML-Link Rocket Science? Cc: w3c-sgml-wg@w3.org Peter Murray-Rust writes: >Let me suggest a spectrum of people who may potentially develop XML >applications and who may create documents >(** without using turnkey systems **). At one end are the rocket >scientists (RS) - and I fully support the need for XML to be able to support >RS. At the other end are webhackers like myself (WH). I certainly qualify as a WH. If this WG includes about one hundred members, how many are RS? As _many_ as five or ten? How many are capable of writing SP? >My concern at present is that XML-link will *only* be usable by RS. I >believe that this isn't the intention, but I'm worried that it might turn >out that way without the WG realising. My ideal would be to have a >solution that had a spectrum of potential applications ranging from WH to >RS, and this could be an evolutionary path for WHs, rather >than all-or-nothing [...] >XML spans the spectrum between WH and RS perfectly. A WH can hack a >_useful_ WF document from a very simple set of rules. Many people can >write a WF-parser from scratch (I've done this myself in an amateurish way). >However, it is RS to write a validating parser for XML (as evidenced by >the fact that there aren't any written yet :-). A validating parser is >required before an XML editor can be constructed (though document creation >tools do not necessarily require RS). Areas such as entity management and >catalogs can be omitted by the WH at the start of their exploration of XML. But will that be a generalized, functional system? Entity management and catalogs are (at least in my opinion) pretty foundational equipment, but of course it's precisely this sort of demand that increases the complexity of the final machine. Will a full implementation of XML plus all of its final component technologies (link, dsssl-o stylesheets, catalog support, etc.) require the likes of James Clark to make a complete system? It's fine that the W3C SGML Working Group Reference Implementation do the job, but if it's become another SP then we have another SP: an absolutely phenomenal tool, but an enormous hurdle for developers to create from scratch. If validation of XML is as complicated as SGML, then what is the point of differentiating it >from SGML? IOW, if you need SP (or its XML complex equivalent) to validate XML, then you might as well be using SGML tools. >I appreciate that this is a very challenging task, but I think it will have >to be undertaken before XML-Link takes off Agreed. Rocket scientists build rockets. We have rocket scientists in this group. While I'm certain that we could build a terrific rocket here, it's not in our best interest to make it unintelligible to our target market, particularly our target market of developers. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 11:13:56 -0600 From: Len Bullard To: "Henry S. Thompson" CC: w3c-sgml-wg@w3.org Subject: Re: 1.2 link and 1.6 traversal Henry S. Thompson wrote: We may have problems with "links in the ether" because that sounds an awful lot like a platonic form, but press on. > Links (types) have a topology (number of ends, directionality), sub-structure > (e.g. terminus roles) and contextually-bound semantics (see previous > message about Application semantics vs. application behaviour). Links > (tokens) have actual end-points. A record is a set of values which can be processed by some function. I do not know what a "contextually-bound semantic" is. I did not get that from the last post either, so please clarify. Tag soup is still tag soup. > Link descriptions have a syntax (GI, attribute names and values, etc.) > and a semantics (what type of link they specify, how to instantiate > individual links when processing a link description in a document > context). Ok. I prefer "link representation" but that is a thin difference. I also prefer element type definition where what is being described is in fact, an SGML element type. What is missing is the notion of the class by which one can declare that element types in different DTDs are in fact, instances of a class (e.g, arch form). However, as soon as you say, "processing a link" we are out of the world of declarative language and into functional language requirements. Whether defined axiomatically or indirectly, it is still a record or a structure. So far, none of this is simpler or more usable than HyTime. And in fact, it is getting harder to explain by the minute. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lex@www.copsol.com (Alex Milowski) Subject: Re: XML catalog draft To: w3c-sgml-wg@w3.org Date: Mon, 10 Feb 1997 12:05:23 -0600 (CST) > > The collective information about all the components necessary to > > handle, process, identify, etc. this document--the meta-document--is > > the first-class construct. The meta-document is the starting point. > > Fine. This is roughyl equivalent to the 2 MIME-SGML solutions, where > one focused on the catalog as the meta-document, and the other > focused on MIME structures. > > A meta-document is just a packing list, as is a catalog. Catalogs > should only be used to identify peices in a given document, not > for the basis for name resolution. In the simple case, yes. The meta-document could also describe relationships or alternate renderings. For example, there might be a set of style-sheets that could be applied depending on the user. There might be one for large-type, one for regular presentation, and so on. Thus, instead of a packing list that says, "here's all the stuff, go!", you can specify alternatives and relationships that more complex browser systems can utilize. What I am really interested in from XML is the ability to layer intelligent frameworks over the standard that can load semantics from the server (currently, Java code). Thus, just being able to specify the "packing list" isn't sufficient. Here's a wish list for the meta-document: 1. Specify multiple styles with semantics about who should use them and when they should be used. 2. Specify client-side transformations and associate with operation "classes" such as "Create me a summary". 3. Specify inter-document relationships. 4. Specify target documents (notice the plural). 3. Specify client-side workflow or "sequence of events" that can utilize (1), (2), (3), and (4). I really think we need to think about layer standards. XML is the document encoding standard. We may want to think about and "XML Super-BOS" or "XML-Mime-packing", etc. ancillary standard. Note: Maybe I'm confused on the structure of the XML standard. If I implement XML, do I have to implement everything we decide on in respect to the major components such as the XML document encoding, XHL, etc. For example, if someone has an XML parser/data-model toolkit but doesn't support the hyper-linking layer, are they XML compliant? If they add hyper-linking, are they then XHL compliant? I'm confused. I'm really like componentized architectures where I can pick and choose the technologies and standards I must adhere to. HyTime people: Can the BOS do this or this beyond what BOS was intended for? > >1. It is possible to define a known document type to encode such a > > meta-document. This is not necessary but it would seem unlikely to > > developed "yet-another-document-information-encoding" (YADIE). > > We already have MIME and catalogs. > > >2. The meta-document and its components could be encoded in one stream > > such that a request is made for the meta document "stream" and > > all information is shipped to the application. This does *not* > > require that all components are packed into this stream. It only > > requires that they be identified. Anyone familiar with the concept of > > JAR files can see where this is coming from. > > Sounds like MIME to me.... Could be. Can MIME accomplish the above? I always thought of MIME as a way of encoding in one data stream multiple parts and encodings. I didn't think there was a way to express the relationships between things. > >4. The need for "catalog location", "style-sheet location", etc. standards > > goes away and gets replaced with a uniform mechanism for describing > > component locations and relationships. > > Sure, instead of pulling the catalog in after accessing the instance, > you pull in the instance after accessing the catalog. Yes. Yes. Yes. Except, as below, I don't like the SO catalogs syntax either. ...but I'll support it if I *have* to. > Some people on this list know that I have little love for the SO > catalog syntax, but that seems sufficient to me. Its not sufficient for more complex constructs. It seems to me that we have two choices: 1. Accept an SO-catalog-like solution and fragment the resolution, location, and organization of other components that don't fit into the "catalog" concept of resolution into ancillary standards/constructs. 2. Find a generalized solution to these problems that is uniform and will allow us to capitalize on *infrastructure*. (1) does work, has some existing products that support *some* of the constructs, and is sufficient for displaying documents. (2) is required, in my opinion, for being able to go beyond displaying documents. It also doesn't exist. ...this all relates back to those tunnels under Chicago... ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 10:38:00 -0800 (PST) From: Todd Freter Subject: Re: XML marketing contributions To: w3c-sgml-wg@w3.org, Liora Alschuler cc: Jon Bosak Liora et al., These phrases and slogans about XML, big sisters, "link-global-code-local," and Java's molars are enjoyable, but to me they are either metaphorical and thus confusing or technical and thus limited. As one of Jon Bosak's co-workers, I just saw him give a major, half-day presentation about XML at Sun. After hearing the presentation, it's clear to me that XML is more effectively marketed as a solution to the problems it was designed to solve than as a triumph of technical specification. That is, XML provides a standard, vendor-free framework for Web applications in which information knows about itself and, potentially, about its consumers. (That last picks up >from a quotation that Jon used in his presentation.) Few if any SGML adherents will fail to understand the value of XML, and XML needs only to be explained, not marketed, to them. That's the XML as SGML-- paradigm. HTML users, the self-taught WH folks whom Peter Murray-Rust mentions, need to understand how XML lets them create robust information management applications beyond simple browsing. That's the XML as HTML++ paradigm. Long ago Len Bullard correctly reminded the WG that XML will be seen as competition for HTML even though that wasn't mentioned in any of the official XML documents as a goal. So if this group is interested in marketing XML, which is a valid and legitimate goal beyond describing and specifying XML, it should focus on XML's value to content providers. This group is describing and specifying XML with the precision, concern, and skill (not to mention the quantity ...) that I see because of content providers who want to deliver rich, self-aware, and functional information to consumers without having to reprogram a bazillion times for different flavors of networked platforms. "I just delivered eight patients' hospital records to eight different approved home healthcare agencies with drag and drop on the Web. Can your HTML do that?" I'm a big believer in solutions marketing, not technology marketing. People won't want XML because it's cool, which it is, but because it's effective. -Todd. ====== Todd Freter Sun Microsystems, Inc. todd.freter@sun.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 19:09:13 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? Lines: 66 In message <199702100113.RAA07568@boethius.eng.sun.com> bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: [...] > 5. link behavior: Links may have a wide variety of effects when > traversed, such as opening, closing, or scrolling windows or > panes; displaying the data from various termini in various ways; > testing, authenticating, or logging user and context information; > executing various programs. Ideally, link behavior should be ^^^^^ see below ^^^^^^^^^ > determined by a semantic specification based on link types, > pointer roles, user circumstances, and other factors; just as > element formatting is determined by a stylesheet based on element > type, context, and other factors. It is recognized that there is > significant overlap between the areas of link formatting and link > behavior. > > The list of things that need to be specified is very helpful, but I > don't think that the division between formatting and behavior is quite > right yet. For one thing, it seems clear to me that inline > presentation without user action belongs to behavior rather than > formatting. I would be very keen to separate 'formatting' and 'behaviour' completely if it were possible. Most of the discussion here has (rightly) concentrated on what happens when a document reaches a client where there is a human involved. Words like 'click', 'open a window', etc. are frequent. May I focus on 'executing various programs' and put ourselves in the position of a robot who receives an XML-link document. I might think about database entries in XML which were automatically and randomly sent over the WWW. A robot might be expected to parse them and their link structure, and take defined action (e.g. preparing a personal database). Presentation and formatting are not relevant to this process, but the 'behaviour' of links might be critical. For example, a link might carry the semantics of visiting the resource at the other end and abstracting that, possibly recursively. The author might wish to vary the 'behaviour' as might the robot's owner. An e-mail address/link might have a 'behaviour' involving sending a message to the recipient automatically. I get the implication that this behaviour can be completely determined by stylesheets. If so, the stylesheets need to carry 'behaviour' in a way that can be implemented as a robot action, rather than a document transformation, or a rendering. I think of XML(SGML) documents as mapping onto Java objects. Formally (I think this is right) SGML documents carry only part of the content of an object as they lack state and methods. I am not concerned about state (I assume it could be added via XML if required?) but I believe that for my purposes, precise behaviour can only be distributed via code (in my case Java classes and methods). Classes can be associated with Elements (which is what I do at present) and in principle different variations of those classes could be chosen for different 'styles' or 'behaviours. I assume that something like that will also be possible for LINK, but it will make it easier if the 'behaviour' is not inextricably mixed with presentation. P. -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 14:49:03 -0500 From: gtn@ebt.com (Gavin Nicol) To: lex@www.copsol.com CC: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft >> A meta-document is just a packing list, as is a catalog. Catalogs >> should only be used to identify peices in a given document, not >> for the basis for name resolution. > >In the simple case, yes. The meta-document could also describe relationships >or alternate renderings. For example, there might be a set of style-sheets >that could be applied depending on the user. This is one reason we suggested a SEMANTICS entry in SO catalog: you could bring across the document, and also know the various semantic processors that could be applied to it. >1. Specify multiple styles with semantics about who should use them and > when they should be used. >2. Specify client-side transformations and associate with operation "classes" > such as "Create me a summary". >3. Specify inter-document relationships. >4. Specify target documents (notice the plural). >3. Specify client-side workflow or "sequence of events" that can utilize > (1), (2), (3), and (4). OK. I agree that SO catalogs would be somewhat stretched by this. I think we might then go off and define the "packing list" and "meta-document" seperately. For simple cases, SO catalogs would be good enough, and for everything else, meta-documents. Perhaps the WG shoudl produce a spec for both? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 15:39:22 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 1.4 a-c: Basic Terminology At 12:18 PM 01/31/97 -0800, Tim Bray wrote: >During the ERB meeting, my esteemed Co-editor pointed out that a word >that is synonym for both "target" and "end" is... "butt". So instead of >termini, we could have butts. Multi-butt links. Butt modes. Butt >syntax. I like this. -Tim Actually, I was merely quoting the MS-Word thesaurus.... :) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 15:39:23 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 1.3, Notation: SGML? Reference Concrete? >>1.3.b If links are SGML elements, should require XML-style reference >>concrete syntax + quoted attribute values? I.e. assert that >>all links would fit into XML docs? > >I want this to be usable with real SGML. So I think we should *not* >restrict them to XML-style syntax, but insert a usage note saying it >won't work with XML unless you follow XML rules. - Tim I think I concur on this. Though the more strongly we can encourage people to use XML, the better. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 12:40:13 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@w3.org Subject: There Are No Metadocuments These "metadocuments" sound to me exactly like "the real, full document with all its trimmings." I know SGMLllers are used to thinking about the marked-up text as distinct from the style sheet, etc., but for the purposes of publishing that text, the whole ball of stuff can be considered to be not document+meta, but just document (including some meta, nothing wrong with that). Considering documents this way might clarify discussion (and then again, maybe not), and it would certainly clarify explanation: "An XML document can be a complex structure, including a style sheet or even choice of style sheets, and some metainformation about who and how it was produced, just like a Word document carries its formatting and some meta along with its text, although you don't see everything when you look at it in Word." Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lex@www.copsol.com (Alex Milowski) Subject: Re: XML catalog draft To: w3c-sgml-wg@w3.org Date: Mon, 10 Feb 1997 15:43:01 -0600 (CST) Gavin wrote: > > OK. I agree that SO catalogs would be somewhat stretched by this. I think > we might then go off and define the "packing list" and "meta-document" > seperately. For simple cases, SO catalogs would be good enough, and > for everything else, meta-documents. > > Perhaps the WG shoudl produce a spec for both? > Yes. I'd be happy with this. This is what I am calling "layered" standards. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 13:38:34 -0800 (PST) From: Bill Smith Subject: Re: XML marketing contributions To: w3c-sgml-wg@w3.org If we want a tag line for XML, I'd suggest something like one of the following: XML: Extending the Web XML: The future of the Web XML: Enabling the Web XML: Objects for the Web XML: What you want it to be XML: What HTML was meant to be The Web should be a central part of the message as should some indication that XML permits open extension to current Web pratice. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 14:00:01 -0800 (PST) From: Bill Smith Subject: Re: There Are No Metadocuments To: w3c-sgml-wg@w3.org Terry Allen wrote: > These "metadocuments" sound to me exactly like "the real, full > document with all its trimmings." I know SGMLllers are used to thinking > about the marked-up text as distinct from the style sheet, etc., > but for the purposes of publishing that text, the whole ball of > stuff can be considered to be not document+meta, but just > document (including some meta, nothing wrong with that). > > Considering documents this way might clarify discussion (and then > again, maybe not), and it would certainly clarify explanation: > "An XML document can be a complex structure, including a style > sheet or even choice of style sheets, and some metainformation > about who and how it was produced, just like a Word document > carries its formatting and some meta along with its text, although > you don't see everything when you look at it in Word." If we are going to go down this path, let's not call this "ball of stuff" a document. An object (WebObject) might be a better moniker since we should include behavior as well as appearance in the ball. My personal preference would be to include references to behavior (code) and appearance (style sheets). Without that separation reuse is difficult and object management is seriously impaired. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 17:48:17 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 1.4 a-c: Basic Terminology At 03:34 PM 02/03/97 -0800, Tim Bray wrote: >Sign me up for link, pointer, and terminus. Motivation: a link is >what people expect, fewer suprises are better. Pointer: I could >be swayed on this one, but it's nicely mnemonic, a single word, and >not already used by any of the existing hypertext tribes. Terminus: >I like this one a lot, same reasons as pointer, plus both the denotation >and connotations are good. -Tim Like he said. Except I like target about as well as terminus, despite the possibly greater directional connotation. At 09:41 AM 02/07/97 -0500, Liora Alschuler wrote: >1.4.c terminus --> link end I don't think this is safe, since it invites confusion with HyTime "linkend", which is a different thing entirely. I suppose there's always "pointees". :) At 05:16 PM 02/04/97 -0500, John Lavagnino wrote: >I'd suggest "selection" as a possible alternative, because it focuses This has some tradition behind it in hypermedia, in that InterMedia refers to its pointees that way (sometimes also as anchors). It does bring the useful intuition that most selections are contiguous, though cooler applications allow discontiguous selections; and the way people typically create links is by selecting something and then making a pointee out of it. Steve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 17:48:17 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 1.4 f: terms for links colocated with their ends At 04:51 PM 02/07/97 -0800, Jon Bosak wrote: >[Liora Alschuler:] > >| Is there a reason why we can't just call these "direct" and "indirect" >| links? > >I agree with Liora. These work very well intuitively and are about as >apropos as anything else that's been suggested. I disagree on this one; Len said it pretty well: direct and indirect are more natural terms for a quite different distinction, namely whether indirection is used in the location specification. "Indirect addressing" is so well-established a term that I can't imagine re-assigning it to another use, when we need the equivalent of its standard meaning to. I'm also with James in disliking 'contextual'; I don't mind 'independent' too much; but just 'i' and 'c' doesn't do it for me. S %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 17:48:18 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 1.4 h: Explainer? At 04:49 PM 02/07/97 -0800, Jon Bosak wrote: >[Liora Alschuler:] > >| This is a link caption so call it a "link caption" or if there are >| reasons not to use caption, then some of the other common words >| already used to describe what it does: "link title" or "link subtitle" It may or may not be a title. > >I don't like "explainer" either (there seems to be a consensus >building on the dislike, anyway), but "caption" is too I like explainer. Its purpose is to explain to the user why they might want to follow this link (rather, this particular linkend of it). (See Landow '87, for example). The explanation might be rendered in lots of ways: subtitle, audio, icon choice, menu-item-name, etc. The reason it's there in the first place is that it is quite standard terminology in the hypermedia community (which is not to say we have to follow it; I actually like caption almost as well). >presentationally specific; you wouldn't want to call this a caption if >it were an item in a menu list, for example. I would suggest "label" >(that is, more formally, "link label"). I find 'title' about as presentation-specific as 'caption'. it makes me think of big print at the beginning of something. Steve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 17:43:36 -0400 To: w3c-sgml-wg@w3.org From: murray@spyglass.com (Murray Altheim) Subject: Re: Get rid of the leading hyphen! bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: >After looking at the examples in the link proposals I find that I >cannot face the prospect of working for the next 10 or 20 years with >this. > >We should get rid of the hyphen in front of XML in reserved names and >attributes. > >"-XML" is ugly, it's hard to type, it looks dumb, and it doesn't >really pollute the name space any less than any other reserved string. >Reserve "XML" and be done with it. Please do. The hyphens add a measure of oddity that seems unwarranted. Unless there is some other justification (and last week I spent a fair amount of time poring over the listserver archives), let's strike this one. Please add my vote to Jon and Lee's. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 16:58:26 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: Get rid of the leading hyphen! Murray Altheim wrote: > > bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: > >After looking at the examples in the link proposals I find that I > >cannot face the prospect of working for the next 10 or 20 years with > >this. > > > >We should get rid of the hyphen in front of XML in reserved names and > >attributes. > > > >"-XML" is ugly, it's hard to type, it looks dumb, and it doesn't > >really pollute the name space any less than any other reserved string. > >Reserve "XML" and be done with it. > > Please do. The hyphens add a measure of oddity that seems unwarranted. > Unless there is some other justification (and last week I spent a fair > amount of time poring over the listserver archives), let's strike this one. > > Please add my vote to Jon and Lee's. > > Murray Another "me too". Chuck the hyphen. Tres uggggly. - len - %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 14:53:22 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@w3.org Subject: Re: There Are No Metadocuments [Alex sent this to me instead of the list; per his request I'm forwarding it to the list. This should confuse everyone about who's saying what!] > These "metadocuments" sound to me exactly like "the real, full > document with all its trimmings." I know SGMLllers are used to thinking > about the marked-up text as distinct from the style sheet, etc., > but for the purposes of publishing that text, the whole ball of > stuff can be considered to be not document+meta, but just > document (including some meta, nothing wrong with that). In my opinion, no. The meta-document is information about a *set* of data--including XML documents. To extent, it is instructions on what makes up units of information and what to do with those units of information. I think it is very important to distinguish between XML as a document and meta-documents (sets of documents) described in XML. Further, we must concede that XML is only *one* form that a document can be encoded in. In some applications (existing applications), the SGML documents are *not* useful to an end user unless they are augmented by other SGML documents, SGML processors, and instructions for those users. Rather than having a "server-does-it-all" model, I would like to be able to deliver the "packing-list" of information as well as instructions to the client and let the client take care of merging and transforming the information. > Considering documents this way might clarify discussion (and then > again, maybe not), and it would certainly clarify explanation: > "An XML document can be a complex structure, including a style > sheet or even choice of style sheets, and some meta-information > about who and how it was produced, just like a Word document > carries its formatting and some meta along with its text, although > you don't see everything when you look at it in Word." Except that I'm not talking about formatting only. I'm talking about transformations, workflows, user interaction, down-loadable semantics, and on, and on. In one view, the meta-document is just a regular XML document that "starts" an client-application specific processing model. In another view, the meta-document is formal part of the XML infrastructure for delivering client-application independent semantics. I prefer the latter. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 23:23:58 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: There Are No Metadocuments Lines: 34 In message Bill Smith writes: [...] > > If we are going to go down this path, let's not call this "ball of stuff" > a document. An object (WebObject) might be a better moniker since we should ^^^^^^^^^ I think this is an excellent term and it certainly describes how I use XML documents. I don't know enough about objects to know whether we are taking too simple view, as we have state and inheritance to consider. > include behavior as well as appearance in the ball. > > My personal preference would be to include references to behavior (code) > and appearance (style sheets). Without that separation reuse is difficult > and object management is seriously impaired. I think this is a very useful distinction, which will also help when it comes to considering style sheets. If the term WebObject is acceptable for some or all XML documents then it is a very useful way of reaching out to the wider community. 'Objects' and 'CORBA' are the current buzzwords although a lot of people naively think that 'CORBA' will solve their problems. It won't - they have to build IDLs (Interface Definition Language) on top of it. Again I may be simplistic, but for my problems I see DTDs as providing a large part of an IDL, so that by using XML you are making life much easier for object interoperability. P. -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 16:24:48 -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: 1.5: Discuss link characteristics? [Liam Quin:] | I am beginning to wonder if "terminus" has a non-railway meaning to | North Americans??? It really _is_ awfully comical! As far as I know, terminus has no association with railroads for most Americans. We call these things "train stations". The word "terminus" simply means an end point, if it means anything. The hilarity that "terminus" seems to engender in our Friends Across the Sea is probably a good reason to use some other term. ("Link end", for example.) Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 11 Feb 1997 00:44:30 +0000 (GMT) From: Peter Flynn Subject: XML FAQ To: w3c-sgml-wg@w3.org OK, thanks to a lot of effort and comment, there's a draft XML FAQ at http://www.ucc.ie/xml There's obviously lots of bits missing at this stage, and probably a lot of mistakes too, so I'd be grateful for all comments. PLEASE, if you've got stuff to say, could you use a subject line of XML FAQ like this one, so I can filter it to /dev/nu^H^H^H^H^H^H^H^H the right place. THose who have Panorama might want to give it a try too, as it's done in DocBook, use http://www.ucc.ie/xml/faq.sgml ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 19:22:39 -0400 To: Peter@ursus.demon.co.uk From: murray@spyglass.com (Murray Altheim) Subject: Re: There Are No Metadocuments Cc: w3c-sgml-wg@w3.org >In message Bill >Smith writes: >[...] >> >> If we are going to go down this path, let's not call this "ball of stuff" >> a document. An object (WebObject) might be a better moniker since we should > ^^^^^^^^^ >I think this is an excellent term and it certainly describes how I use XML >documents. I don't know enough about objects to know whether we are taking >too simple view, as we have state and inheritance to consider. I hate to do this again, but unfortunately 'WebObject' is an already trademarked term from NeXT Inc.: http://www.next.com/WebObjects/Welcome.html Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 16:48:58 -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: Is XML-Link Rocket Science? | Will a full implementation of XML plus all of its final component | technologies (link, dsssl-o stylesheets, catalog support, etc.) | require the likes of James Clark to make a complete system? It's fine | that the W3C SGML Working Group Reference Implementation do the job, | but if it's become another SP then we have another SP: an absolutely | phenomenal tool, but an enormous hurdle for developers to create from | scratch. If validation of XML is as complicated as SGML, then what is | the point of differentiating it from SGML? Because you don't need validation for XML to be useful. XML makes possible a very large number of lightweight applications that only need to know that a document is well-formed. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 16:39:28 -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: 1.2 link and 1.6 traversal [Henry Thompson:] | Our specific problem is not distinguishing between link descriptions | and links. I think that Henry is on to something. | I'll try to produce a redraft of 1.4 and 1.5 which points the way to | how things might change if this distinction were made explicit. Please do. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 18:49:14 -0600 From: len bullard To: Peter@ursus.demon.co.uk CC: w3c-sgml-wg@w3.org Subject: Re: There Are No Metadocuments Peter Murray-Rust wrote: > If the term WebObject is acceptable for some or all XML documents then it > is a very useful way of reaching out to the wider community. 'Objects' and > 'CORBA' are the current buzzwords although a lot of people naively think > that 'CORBA' will solve their problems. It won't - they have to build > IDLs (Interface Definition Language) on top of it. Again I may be > simplistic, but for my problems I see DTDs as providing a large part of > an IDL, so that by using XML you are making life much easier for object > interoperability. While I agree with this, I say we cannot even consider the use of the terms unless we are able to relate these "current buzzwords" to the programming community to whom they are not just buzzwords. If an IDL is required, that is what you design. Tell me how a DTD can provide an IDL. That's the point I'm fuzzy on here. But fairy dust or no, it has advantages. Once you make objects out of it, interoperability quits being an impossible goal. If we are too proud to understand that, we are also too dumb. Separation of data and behavior are fine in theory, but in implementation that is not the way things are done. Unless we give them the architecture in code, we haven't given them what they need. Jeez... I think this is a no-brainer. Java/XML - a Source Reference. Proves we can do what we say we can do. Gives a university student a base of code. Free. Best cross-platform. Easiest implementation. AWT library. Lots of kids learning it. What's the downside? Yeah, Sun owns Java. So what? Everyone is building the VM support in their operating systems. Looks like a pretty big first fielding. Also, the network engines are there. Quick to the Web. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 17:29:37 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: XML catalog draft On reflection, and although I agree with pretty well every word in the XML catalog draft, and think it's a fine piece of work, I cannot support its inclusion in XML. Background: 1. We left out PUBLIC originally because we didn't want to bless a syntax (e.g. FPI or URN) or a resolution mechanism. Making everything a URL had the virtue that it works. 2. People said they wanted PUBLIC. Michael asked: "even without a single resolution mechanism?" Several, most eloquently Deb Lapeyre, said "Yes." I for one (and I think most of the ERB) could find no good reason to resist this desire. 3. The recent draft blesses a resolution mechanism (Socats) which it specifies at some length, in a process that encodes a lot of design decisions (DELEGATE/CATALOG, prefix rules) very compactly, but does not really provide a solution to find the catalog. I think the design decisions are good. What bothers me is: a. The length and complexity of the discourse on catalog usage; I think the XML spec should be shorter, not longer. b. The fact that this discourse overlaps with TR9401; I think that we should avoid rewriting parts of other specs; with the obvious exception of ISO 8879. We do not do this with URLs, for example. c. The fact that some but not all of TR9401 is here; notably missing is the find-the-catalog logic. Are the parts of 9401 where there is overlap guaranteed not to change? Are the parts of 9401 that are omitted notably lacking implementations? I think we should: - allow a PUBLIC keyword/string as appropriate - make a decision as to what should be done when both PUBLIC and SYSTEM are there - provide a pointer to TR9401 in the write-up on the PUBLIC identifier, saying that this is one proven-in-practice way to resolve them - provide support to catalogs by providing a special PI, as recommended by a couple of WG-ers, to help define the BASE and thus find the catalog - investigate the problem of what seems like the unnecessary restrictions on MINIMUM LITERAL; I don't think it's legitimate to say that a PUBLIC identifier can't be a URN, which this would do. I'm not sure what the right thing to do is with the current catalog proposal. It seems to represent the best thinking of the people who know on how to get good mileage out of Socats; it would be a pity to lose that. But at the time it just doesn't seem like a good call to wire this into XML. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 18:26:52 -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: There Are No Metadocuments [Peter Murray-Rust, responding to Bill Smith:] | > My personal preference would be to include references to behavior (code) | > and appearance (style sheets). Without that separation reuse is difficult | > and object management is seriously impaired. | | I think this is a very useful distinction, which will also help when | it comes to considering style sheets. The problem I'm having with a distinction between behavior and appearance is that it just won't stay nailed down. Most behavior can be (and is) described with regard to an appearance, and most appearances are the result of some behavior. Peter has a system that uses Java code to perform (among other things) the formatting functions that in some other system might be expressed in a stylesheet. Is that behavior or appearance? Allow me to generalize that. For any DSSSL stylesheet that specifies that a certain appearance should be associated with a given node in the XML tree, I can imagine a Java program that causes exactly the same appearance to be associated with the same node. Suppose that it is impossible to tell the difference between the way the document is rendered by a DSSSL engine under the control of a stylesheet and the way that the same document is rendered by a collection of Java programs. Does the DSSSL stylesheet constitute a specification of appearance and the collection of Java programs constitute a specification of behavior? Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 21:16:24 -0500 To: Martin Bryan , bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 1.5: Discuss link characteristics? Cc: bosak@atlantic-83.eng.sun.com At 4:00 AM 2/10/97, Martin Bryan wrote: >Behaviour is not up to the user, it is up to the author. It is the >author/server that has to control what happens when the link is selected by >the user. Except in rare cases the user should not be able to change the >action that selecting a link causes.This is why you must separate >presentation from behaviour. I'm sorry. Color blind users should be able to see fromthe link type that Kringle.class implements a "pop-up-list" instead of failing to see Green text on a red background when they have equal brightness. Similarly it may help a blind user to see a series of hierarchically organized links instead of an animated display of shuffling cards. Similarly, it may help a web-walker to see that two pages are connected by a link rather than having to execute a java script in a "sandbox area" and trap calls to AppletContext.showDocument(). We need to be able to specify behavior, but we need not be ruled by our need to specify behavior. >This would be better called Link Action. Traversal is not something >non-rocket scientists understand. What most users understand by clicking on >a hotspot is that some action should take place. This is what the >behavioural side of the equation covers. I like "Link Action". It's a much less predjudicial term than traversal, and it covers the same field beautifully, as well as many things beyond that field, that traversal slights. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 18:42:51 -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 FAQ Thanks to everyone who contributed to the FAQ and to Peter Flynn for putting it together. This is going to me a major resource. Peter, when do you plan to go public with this? Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 22:13:45 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 1.5: Discuss link characteristics? At 10:43 AM 2/10/97, Henry S. Thompson wrote: >But neither traversal or action is at the right level of generality. >[See next message about traversal] >Both you and Martin are too focussed, in my view, on browsers and >mouse clicks. As a possibly useful example, consider the case of >external, non-participating 2-ended links to annotate the translation >relationship between the sentences of french and english versions of a >bilingual document. A terminology extraction tool will exploit the >semantics of such a link (i.e. behave in a certain way) completely >differently to a translation tutorial program. Thank you... Those of us in the business of being broken records appreciate another voice joining us in... > >I realise this is dragging us back towards the whole link >{semantics/type/behaviour} debate, which I have done my best to >follow, but it leaves me feeling that although we need to clearly >distinguish between > >1) intrinsic XML semantics for links, i.e. termini, participation, etc.; >2) XML Application (in the strict SGML sense of 'application') > semantics, e.g. the bilingual alignment example above; >3) Implemented application behaviour > >we are only in the business of specifying (1). And we need to specify clearly what is involved in binding 1 -> 2 and 3. That is the effort currently called stylesheet that needs a different name, desperately. Just for kicks how about using "Display and processing spec" to replace the linking +formatting language I keep referring to as a style sheet? > >ht _________________________________________ 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 Feb 1997 22:51:44 -0500 To: Bill Smith , w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: There Are No Metadocuments At 2:00 PM 2/10/97, Bill Smith wrote: >Terry Allen wrote: >> Considering documents this way might clarify discussion (and then >> again, maybe not), and it would certainly clarify explanation: >> "An XML document can be a complex structure, including a style >> sheet or even choice of style sheets, and some metainformation >> about who and how it was produced, just like a Word document >> carries its formatting and some meta along with its text, although >> you don't see everything when you look at it in Word." > >If we are going to go down this path, let's not call this "ball of stuff" >a document. An object (WebObject) might be a better moniker since we should >include behavior as well as appearance in the ball. > >My personal preference would be to include references to behavior (code) and >appearance (style sheets). Without that separation reuse is difficult and >object management is seriously impaired. Just as some would like to see SGML Link declaration information be separate >from "the document". And others insist vociferously that it *must* be part of "the document". And others would like "the document" to be just the SGML document element/instance. What should and should not be part of "the document" is a religious war. :-( Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 20:38:20 -0800 (PST) From: Terry Allen To: Bill.Smith@Eng, davep@acm.org, w3c-sgml-wg@w3.org Subject: Re: There Are No Metadocuments Strange. I can publish a print book, which binds together in what everyone recognizes as a book font, size, kerning, paper type, thumbtabs, page numbers, line numbers, verse numbers, and footnote markers that cause the eyes of literate viewers to flicker involuntarily to the bottom of the page (behavior). Yet when I bind all this together (with the text) in a document, somehow this becomes a metadocument. If I reprinted the book in another font, font size, etc., I'd have another book, perhaps "The Large Type Document for Presbyopters," which I would call attention to as different from "The Document," although for some purposes it is "the same". This group must eventually determine how to associate all the information that comprises the "metadocument". It must also determine how to associate the parts of a "document". Why should these be separate tasks? And where is the description of the overall architecture? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html >From w3c-sgml-wg-request@w3.org Mon Feb 10 20:12 PST 1997 Date: Mon, 10 Feb 1997 22:51:44 -0500 To: Bill Smith , w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: There Are No Metadocuments At 2:00 PM 2/10/97, Bill Smith wrote: >Terry Allen wrote: >> Considering documents this way might clarify discussion (and then >> again, maybe not), and it would certainly clarify explanation: >> "An XML document can be a complex structure, including a style >> sheet or even choice of style sheets, and some metainformation >> about who and how it was produced, just like a Word document >> carries its formatting and some meta along with its text, although >> you don't see everything when you look at it in Word." > >If we are going to go down this path, let's not call this "ball of stuff" >a document. An object (WebObject) might be a better moniker since we should >include behavior as well as appearance in the ball. > >My personal preference would be to include references to behavior (code) and >appearance (style sheets). Without that separation reuse is difficult and >object management is seriously impaired. Just as some would like to see SGML Link declaration information be separate >from "the document". And others insist vociferously that it *must* be part of "the document". And others would like "the document" to be just the SGML document element/instance. What should and should not be part of "the document" is a religious war. :-( Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 00:00:56 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: There Are No Metadocuments At 8:38 PM 2/10/97, Terry Allen wrote: >Strange. I can publish a print book, which binds together in >what everyone recognizes as a book font, size, kerning, paper >type, thumbtabs, page numbers, line numbers, verse numbers, >and footnote markers that cause the eyes of literate viewers >to flicker involuntarily to the bottom of the page (behavior). > >Yet when I bind all this together (with the text) in a document, >somehow this becomes a metadocument. If I reprinted the book >in another font, font size, etc., I'd have another book, >perhaps "The Large Type Document for Presbyopters," which >I would call attention to as different from "The Document," >although for some purposes it is "the same". The "pre-SGML", if you will, concept of a document was simply something that is printed. SGML looks at a document as a collection of potentially reusable information, which may be reused in many ways besides republishing it on paper again in a slightly different format. "The document" is something that can be published, searched, spoken (a very non-paper form of publishing), indexed, etc., etc. If, as you suggest, that this something together with its publishing specifications is a document but that with different publishing specifications is a different document, then with its indexing specifications it's yet another document, when published by speech synthesizer it's yet another, etc., etc., etc.,... Put all these things together and you've got a metadocument, in many people's mind. If the union of all of your related-by-having-the-same-content documents is a metadocument in some people's mind, there are others that would like in this brave new world to use "document" to mean the intersection: the core structured data set. ...And those who draw the line somewhere in between. Isn't English fun? Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 10 Feb 1997 22:50:35 -0600 From: len bullard To: Dave Peterson CC: Bill Smith , w3c-sgml-wg@w3.org Subject: Re: There Are No Metadocuments Dave Peterson wrote: > >My personal preference would be to include references to behavior (code) and > >appearance (style sheets). Without that separation reuse is difficult and > >object management is seriously impaired. > > Just as some would like to see SGML Link declaration information be separate > from "the document". And others insist vociferously that it *must* be > part of "the document". And others would like "the document" to be just > the SGML document element/instance. What should and should not be part of > "the document" is a religious war. :-( That is so. But just as a DSSSL processing spec can be a Java applet or Active-X object instead, religion is where we find it. It's all values. Split it up anyway you like, it's still just a tag soup of values without the DTD. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 01:27:56 -0500 From: Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Despite the fact that I was on the committee that came up with the socat-subset, I would support this decision. I have always been on the fence about whether we should do a default resolution mechanism or not. I would love to see SOCATs widely implemented, but don't know if the extra burden may put some potential XML implementor over the edge into: "Maybe I'll just do HTML 4.0 instead." It's a gamble I was never thrilled about, though the potential win is large. All I've ever asked for (begged, really), is to keep the PUBLIC syntax in so that we can continue to use it by pre-arranged convention and perhaps standardize a default resolution mechanism when the XML community is a little more mature. Your proposal preserves this, and I am about as happy with it as I would be with a simple default resolution mechanism (though not as happy as I would be if we could both specify a default resolution mechanism and *guarantee* that it would be implemented - but that's not an option!). > - make a decision as to what should be done when both PUBLIC and SYSTEM > are there Whichever goes first, the failure of one should not be a reportable error, only the failure of both should be, in my opinion. > - investigate the problem of what seems like the unnecessary > restrictions on MINIMUM LITERAL; I don't think it's legitimate to > say that a PUBLIC identifier can't be a URN, which this would do. Aren't URNs more transport-resilient than that? They can probably be URN-encoded to use only minimum literal characters, can't they? > I'm not sure what the right thing to do is with the current > catalog proposal. It seems to represent the best thinking of the people > who know on how to get good mileage out of Socats; it would be a > pity to lose that. But at the time it just doesn't seem like a good call > to wire this into XML. This proposal is different than TR 9401. For one thing it could be tuned for XML a little more (ie URLs instead of system literals), and for another it has delegate which TR 9401 does not (as I recall). We could consider publishing it as a W3C Technical Report. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 06:55:08 +0000 To: lex@www.copsol.com (Alex Milowski), w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: XML catalog draft At 12:05 10/2/97 -0600, Alex Milowski wrote: >I'm really like componentized architectures where I can pick and choose the >technologies and standards I must adhere to. > >HyTime people: Can the BOS do this or this beyond what BOS was intended >for? I think you are confusing the BOS with the componetized architectures. HyTime gives you a method for componentizing architectures, architectural forms. It also gives you a mechanism for componentizing entity sets - the BOS. Its the old split of logical elements against storage entities. The problem is that for SGML on the Web you need somthing that segments entities into logical components (the fragment identifiers?). The entities on the web are too large for logical control by architectures. Yet how to impose an architecture on the entities referenced on the Web using URLs is a problem. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 09:51:20 +0000 To: w3c-sgml-wg@w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Marketing Contributions... I agree with Jon/Liora etc. on naming this thing XML-Link. Hyper-X sounded good at the time but I now see the wisdom of XML-Link. As for slogans, how about:- "XML: Call a spade a " Regards, Sean Mc Grath digitome@iol.ie %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Tue, 11 Feb 97 09:20:39 GMT To: w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? David Durand writes: > Thank you... Those of us in the business of being broken records appreciate > another voice joining us in... You're welcome -- it's not lack of interest, just lack of time. > >. . . although we need to clearly > >distinguish between > > > >1) intrinsic XML semantics for links, i.e. termini, participation, etc.; > >2) XML Application (in the strict SGML sense of 'application') > > semantics, e.g. the bilingual alignment example above; > >3) Implemented application behaviour > > > >we are only in the business of specifying (1). > > And we need to specify clearly what is involved in binding 1 -> 2 and 3. Agreed. Particularly what properties of links are available to rendering and processing (small 'a') applications. Jon mentioned history a few days ago -- the thin end of a long wedge. > That is the effort currently called stylesheet that needs a different name, > desperately. Just for kicks how about using > > "Display and processing spec" > > to replace the linking +formatting language I keep referring to as a style > sheet? How about "rendering and processing spec", although my guess is that processing beyond rendering is too open-ended to be much more than a name for a problem. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Tue, 11 Feb 97 09:37:19 GMT To: w3c-sgml-wg@w3.org Subject: Re: There Are No Metadocuments Jon Bosak writes: > The problem I'm having with a distinction between behavior and > appearance is that it just won't stay nailed down. Most behavior can > be (and is) described with regard to an appearance, and most > appearances are the result of some behavior. Peter has a system that > uses Java code to perform (among other things) the formatting > functions that in some other system might be expressed in a > stylesheet. Is that behavior or appearance? > > [example deleted] On the one hand, Yes. That is, rendering (creating an appearance for a medium, e.g. 256 colour raster display) is behaviour. It can be specified by appeal to less (LaTeX) or more (DSSSL) or most (Java) procedural means, but processing is always involved or implied. On the other hand No. That is, it is attractive to suppose that rendering behaviour will treat link descriptions in the same way as the rest of the markup in a document, encouraging us to use the same mechanism, namely style specifications, to determine rendering behaviour for link descriptions as we do for the rest of the document. The SGML Way is to use DSSSL for this when you can. It remains to be seen whether this group thinks that XSL (= an XML-targeted DSSSL subset) will do the job, or whether augmentations will be necessary. I for one would NOT be happy if such augmentations took us outside the domain of rendering into e.g. user interactions. In other words, all rendering is processing, but not all processing is rendering, and specifying ALL processing needs a general-purpose programming language. SMF, TNMJ. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Tue, 11 Feb 97 09:42:34 GMT To: w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? Oh yes, a further point that arises in response to David's response: I wrote: > >although we need to clearly > >distinguish between > > > >1) intrinsic XML semantics for links, i.e. termini, participation, etc.; > >2) XML Application (in the strict SGML sense of 'application') > > semantics, e.g. the bilingual alignment example above; > >3) Implemented application behaviour > > > >we are only in the business of specifying (1). > David replied: > And we need to specify clearly what is involved in binding 1 -> 2 and 3. But note that historically by far and away the most common language for defining large-A Applications is NATURAL language---English, German, Japanese, whatever. I expect somewhere someone has used, for instance, Z to formally specify an SGML Application, but that's the exception rather than the rule. So (2) is really Not Our Problem. As for what aspects of (3) ARE our problem, see my reply to Jon on the 'There Are No Metadocuments' thread. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Kurt Conrad To: "w3c-sgml-wg@w3.org" Subject: RE: Marketing Contributions... Date: Tue, 11 Feb 1997 02:29:36 -0800 Another slogan: "Go there, do that, design the t-shirt" /s/ kwc 2/11/97 02:29 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 12:59:03 +0000 To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: There Are No Metadocuments Cc: bosak@atlantic-83.eng.sun.com At 18:26 10/2/97 -0800, Jon Bosak wrote: >The problem I'm having with a distinction between behavior and >appearance is that it just won't stay nailed down. Most behavior can >be (and is) described with regard to an appearance, and most >appearances are the result of some behavior. Peter has a system that >uses Java code to perform (among other things) the formatting >functions that in some other system might be expressed in a >stylesheet. Is that behavior or appearance? If the running of this code is controlled by user interaction at the client its appearance: if it is action that is forced on the application by information from the server it is behaviour! (Author defined formatting is currently being referred to as behaviour: user defined formatting is currently being referred to as appearance. Both types are required - its the point of control that defines whether it is a behaviour or not.) > >Allow me to generalize that. For any DSSSL stylesheet that specifies >that a certain appearance should be associated with a given node in >the XML tree, I can imagine a Java program that causes exactly the >same appearance to be associated with the same node. Suppose that it >is impossible to tell the difference between the way the document is >rendered by a DSSSL engine under the control of a stylesheet and the >way that the same document is rendered by a collection of Java >programs. Does the DSSSL stylesheet constitute a specification of >appearance and the collection of Java programs constitute a >specification of behavior? The DSSSL style sheet as sent by the author is a behaviour. The version as modified by the user, or the overrides issued by the user, is what constitutes a change of appearance. The terms appearance and behaviour are misleading, like addresses/locators/explainers.... They say what the result is, not what you need to get there. What we need is something like local control parameters and remote control parameters to distinguish where control actually lies. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 10:04:58 -0500 From: gtn@ebt.com (Gavin Nicol) To: bosak@atlantic-83.eng.sun.com CC: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: There Are No Metadocuments >Allow me to generalize that. For any DSSSL stylesheet that specifies >that a certain appearance should be associated with a given node in >the XML tree, I can imagine a Java program that causes exactly the >same appearance to be associated with the same node. Suppose that it >is impossible to tell the difference between the way the document is >rendered by a DSSSL engine under the control of a stylesheet and the >way that the same document is rendered by a collection of Java >programs. Does the DSSSL stylesheet constitute a specification of >appearance and the collection of Java programs constitute a >specification of behavior? It's just a matter of interpretation. Code is data is code. Java bytecodes are nothing more than a processing specification until they are interpreted, and there are a number of ways *that* can be done as well... As soon as you start defining objects that have some behavioural semantics associated with them, you also open up the possibility of people interpreting the semantics. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 11 Feb 1997 15:16:07 +0000 (GMT) From: Peter Flynn Subject: Re: XML marketing contributions To: w3c-sgml-wg@w3.org > "XML: certified organic SGML" "Homegrown" might be closer to the mark. "Organic" is too close to BS. > "Faster than a SP'ding bullet, more powerful than an

-- it's hypertext, > it's a database, it's XML!" "XML - where would you like to go tomorrow?" OK, sosumi... ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 11 Feb 1997 15:07:57 +0000 (GMT) From: Peter Flynn Subject: Re: 1.5: Discuss link characteristics? To: w3c-sgml-wg@w3.org Len writes: > This is also in accordance with the way most people think about these > issues. It is my expectation that I can use a button or a hotspot or > a voice recognition system and still get the same behavior. I'm not sure of that, I know a lot of people (complete non-techies) who expect different behaviors precisely because the modes of activation are different. > Termini and terminus look baked. I don't like these. Just trying to > say them in a presentation makes one feel one is back in college. This is like Tom Lehrer's spiel about football stadia... > > This would be better called Link Action. Traversal is not something > > non-rocket scientists understand. Traversal also has a meaning in a court of law wrt a plaintiff's claim on a defendant, I think. Use it here but avoid it outside. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 15:32:28 +0000 From: Lou Burnard To: gtn@ebt.com CC: W3C-SGML-WG@w3.org, lou@vax.ox.ac.uk Subject: Re: There Are No Metadocuments Please don't use the term "meta-document". It invites confusion with the term "metadata" (currently much bandied around). Some documents contain information. Others contain information about information (metadata). I would expect every XML piece of content worth its salt to have an associated metadata document (or metadocument) describing what it is and where it came from, in the same way as a catalogue card describes a book, or a tei header describes a tei document. I think this usage is now sufficiently established that applying it differently here (to include a lot of things which wd normally be the *subject* of a metadata description) is just going to make people's brains hurt. While I'm commenting on terminology: I like "link end", but I still prefer "target". I don't like "explainer". It sounds like an annoying elderly female relative. What's wrong with "caption"? (a caption can be explanatory or titular). Or if you want to be really confusing... how about "tag" (as in what people spraty opn on tunnel walls with aerosol paint...) Lou %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 11 Feb 1997 15:43:29 +0000 (GMT) From: Peter Flynn Subject: XML FAQ To: w3c-sgml-wg@w3.org Before going public with the FAQ, I would like to pass the URL to a mailing list of Internet authors, for their comments as technical writers who are not involved with the development (and an embargo on publicising the URL until it's fit to release). Unless anyone has any rooted objections to this. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 10:56:21 -0400 To: bosak@atlantic-83.eng.sun.com (Jon Bosak) From: murray@spyglass.com (Murray Altheim) Subject: Re: Is XML-Link Rocket Science? Cc: w3c-sgml-wg@w3.org bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: >| Will a full implementation of XML plus all of its final component >| technologies (link, dsssl-o stylesheets, catalog support, etc.) >| require the likes of James Clark to make a complete system? It's fine >| that the W3C SGML Working Group Reference Implementation do the job, >| but if it's become another SP then we have another SP: an absolutely >| phenomenal tool, but an enormous hurdle for developers to create from >| scratch. If validation of XML is as complicated as SGML, then what is >| the point of differentiating it from SGML? > >Because you don't need validation for XML to be useful. XML makes >possible a very large number of lightweight applications that only >need to know that a document is well-formed. I don't deny this -- it's obviously one of the reasons we're all excited about XML. But as has been pointed out in various messages, building authoring tools that validate, that provide the level of link markup complexity to support current proposals, that provide either CSS or DSSSL-O support, these all may obtain a hefty development effort. I know simply adding CSS support to the Stonehand HTML Viewer was not a trivial effort. But I'm not worried about browsers -- they certainly seem trivial by comparison to what is required by an authoring tool. I suspect most authoring tools will do well-formedness checking but not validation, and therefore some of the XML advantages over HTML may be lost. In my head I'm trying to get a handle on an ideal balance between a simple and fully-supported authoring tool, and what developing that would entail. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Tue, 11 Feb 97 16:05:04 GMT To: w3c-sgml-wg@w3.org Subject: Ontology and Epistimology for Links in XHL OK, it's REALLY time for back to basics. I'm getting close to a redraft of section 1, but here's the background for the (aspiring) rocket scientists, since I'm doing my best to write the redraft for the web heads. We've really got (wait for it) SIX sorts of things, types and tokens versus notation, description and thing itself, viz: notation description ding an sich type DTD fragment linkd class link class instance linkde linkd instance link instance You can start at the lower left and get the sense of this. We have the following link description element in an XML document, say Windows 95 This is a instance of a type specified by the following DTD fragment (apologies to Tim and Steve, not quite as per the existing document): The text is notation for a link description instance, whose internal representation in some object language we could notate as follows: [tlinkd name=tm source=[epd loc= name=owned] target=[epd loc=[url ttype=http host=xyzzy.com doc='']] name=owner]] That's an instance of a (subclass of) link description, with values for various properties. The values of the source and target properties are themselves instances of endpoint descriptions. This in turn, in the context of a particular application, document and location thereof, might resolve to a link instance we could notate as follows: [link name=tm eps={[ep name=owned pt=*1], [ep name=owner pt=*2]}] where *1 and *2 are hard pointers to groves or grove fragments or whatever. Note that MANY different link descriptions might have given rise to this link, whereas the relationship between link description elements and link descriptions is much tighter. Link description types and link types are just the appropriate abstractions, with there being some structure to the family of link description types (i.e. at least we have tlinkd and ilinkd with some shared and some distinctive properties), but as far as I can see there is only one link type, since I don't grok directionality yet. Where is this headed? Well, here's a translation of old terms into new terms, easier first Old New terminus endpoint pointer endpoint description link-type link name pointer role endpoint name locator locator explainer gloss link link or link description or link description element All the terms 'link name', 'endpoint name', 'locator' and 'gloss' may be used informally to apply to the constituent parts of link descriptions and link description elements indiscriminately. Be patient, this all IS worth it, I promise. ht PS. Lest there be any confusion, I don't see this as an attempt to start over. I claim I'm engaged in a rational reconstruction of the draft on the table, with virtually no change to the fundamental content (Well, one, in that I don't see any way therein to give the pointer role (old name) for the implicit terminus (old name). In the above example, the attribute 'SROLE' (source role) gives the endpoint role for the (implicit) endpoint which is the link description element itself, while the 'TROLE' attribute (target role) gives the endpoint role of the endpoint explicitly described by the HRTYPE, HREF, etc. attributes.). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 11 Feb 1997 15:54:57 +0000 (GMT) From: Peter Flynn Subject: Re: Get rid of the leading hyphen! To: w3c-sgml-wg@w3.org > >We should get rid of the hyphen in front of XML in reserved names and > >attributes. > > > >"-XML" is ugly, it's hard to type, it looks dumb, and it doesn't > >really pollute the name space any less than any other reserved string. > >Reserve "XML" and be done with it. Having come in on this after the draft spec was out, I assumed this was set in Jell-O. Ditch it, IMHO. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 17:05:04 +0000 From: Lou Burnard To: W3C-SGML-WG@w3.org Subject: re: get rid of leading hyphen I forgot to add my voice to the swelling tide of opposition to the leading hyphen. Delenda est, in spades. Lou %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Tue, 11 Feb 97 17:26:20 GMT To: w3c-sgml-wg@w3.org Subject: The new perspective I'm pushing, continued The beginning of my redraft is now visible as http://www.cogsci.ed.ac.uk/~ht/new-xml-link.html Be gentle! ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 10:12:34 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: XML catalog draft [Apologies if you get this twice; the first seems to have evanesced into the aether. -T.] On reflection, and although I agree with pretty well every word in the XML catalog draft, and think it's a fine piece of work, I cannot support its inclusion in XML. Background: 1. We left out PUBLIC originally because we didn't want to bless a syntax (e.g. FPI or URN) or a resolution mechanism. Making everything a URL has the virtue that it works. 2. People said they wanted PUBLIC. Michael asked: "even without a single resolution mechanism?" Several, most eloquently Deb Lapeyre, said "Yes." I for one (and I think most of the ERB) can see no good reason to resist this desire. 3. The recent draft blesses a resolution mechanism (Socats) which it specifies at some length, in a process that packs in a lot of design decisions (DELEGATE/CATALOG, prefix rules) very compactly, but does not really provide a mechanism to find the catalog. I think the design decisions are good. What bothers me is: a. The length and complexity of the discourse on catalog usage; I think the XML spec should be shorter, not longer. b. The fact that this discourse overlaps with TR9401. I think that we should avoid rewriting parts of other specs, with the obvious exception of ISO 8879. We do not do this with URLs, for example. c. The fact that some but not all of TR9401 is here; notably missing is the find-the-catalog logic. Are the parts of 9401 where there is overlap guaranteed not to change? Are the parts of 9401 that are omitted notably lacking implementations? I think we should: - bless the PUBLIC keyword & associated identifier - make a decision as to what should be done when both PUBLIC and SYSTEM are there [I can't recall detecting a consensus; did I just miss it?] - provide a pointer to TR9401 in the write-up on the PUBLIC identifier, saying that this is one proven-in-practice way to resolve them - improve support for catalogs by providing a special PI, as recommended by a couple of WG-ers, to help define the BASE and thus find the catalog - investigate the problem of what seems like the unnecessary restrictions on MINIMUM LITERAL; I don't think it's desirable to say that a PUBLIC identifier can't be a URN, which this would do. I'm not sure what the right thing to do is with the current catalog proposal. It seems to represent the best thinking, by the people who know, on how to get good mileage out of Socats; it would be a pity to lose that. But at the moment it just doesn't seem like a good call to wire this into XML. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 13:26:47 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: There Are No Metadocuments At 8:38 PM 2/10/97, Terry Allen wrote: >Strange. I can publish a print book, which binds together in >what everyone recognizes as a book font, size, kerning, paper >type, thumbtabs, page numbers, line numbers, verse numbers, >and footnote markers that cause the eyes of literate viewers >to flicker involuntarily to the bottom of the page (behavior). >Yet when I bind all this together (with the text) in a document, >somehow this becomes a metadocument. If I reprinted the book >in another font, font size, etc., I'd have another book, >perhaps "The Large Type Document for Presbyopters," which >I would call attention to as different from "The Document," >although for some purposes it is "the same". For the kinds of purposes that SGML (and XML) propose to support -- i.e. re-use they _are_ the same. That is why some of us are so vociferous about separating processing from data content (and insistent as Len says, that we have only a bag of (structured) values, behavior and rendering free). Anytime we break that distinction, we make some form a reuse more difficult or impossible (depending on how central to the document markup the formatting decisions become). Now, if these reuse issues are not appropriate in a WWW context, then we should not be doing XML at all, but working on adding more kinds of behavior tag to HTML so that it can finish its metamorhphosis into "Postscript for the Web". This is all baby SGML, folks. It's the _point of the whole thing_. So let's finish it, but stop dragging over the same issues. I don't mind Postscript for the web, but if that's our goal then we don't need generic tagging to get there. >This group must eventually determine how to associate all the >information that comprises the "metadocument". It must also >determine how to associate the parts of a "document". Why >should these be separate tasks? Who cares. If we want the rendering/processing independent part of the document to retain those properties it must be separated from the rendering/processing instructions. So we need a mechanism to "glue" them together. >And where is the description of the overall architecture?] _________________ | | [document]---------------> | User viewing | | Engine | [link-action spec]-------> | or | | | [text layout spec]-------> | Web Walker | ^ | or | | | Something else | | _________________ +------------------------User choice and publisher choice may affect/replace these bindings and the contents of the specs. (therefore there is a separate binding entity that controls the existence of those arrows) [ secure systems will need to limit user choice, but the architecturally, all processing agents are equivalent ] _________________________________________ 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 Feb 1997 13:57:48 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: There Are No Metadocuments At 10:04 AM 2/11/97, Gavin Nicol wrote: >It's just a matter of interpretation. Code is data is code. >Java bytecodes are nothing more than a processing specification >until they are interpreted, and there are a number of ways *that* >can be done as well... true... >As soon as you start defining objects that have some behavioural >semantics associated with them, you also open up the possibility >of people interpreting the semantics. True, but essentially false: Once the interpretation of the data is a turing-complete problem, the possibility of _useful_ interpretation goes way, way down. Those unfortunates who stored data in hypercard scripts discovered that the hard way -- of course they're fine for the ages --- If you happen to have a hypercard interpreter in your pocket, along with a clone of the MacOS. -- David This is why I mistrust jumping to code _too soon_. To push the interaction envelope you need code, but you also lose reusability, because your environment sneaks into your data... We definitely will need to attach code to documents though. _________________________________________ 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 Feb 1997 13:57:43 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 1.5: Discuss link characteristics? At 4:42 AM 2/11/97, Henry S. Thompson wrote: >Oh yes, a further point that arises in response to David's response: > >I wrote: >> >although we need to clearly >> >distinguish between >> > >> >1) intrinsic XML semantics for links, i.e. termini, participation, etc.; >> >2) XML Application (in the strict SGML sense of 'application') >> > semantics, e.g. the bilingual alignment example above; >> >3) Implemented application behaviour >> > >> >we are only in the business of specifying (1). >> > >David replied: >> And we need to specify clearly what is involved in binding 1 -> 2 and 3. > >But note that historically by far and away the most common language >for defining large-A Applications is NATURAL language---English, >German, Japanese, whatever. I expect somewhere someone has used, for >instance, Z to formally specify an SGML Application, but that's the >exception rather than the rule. So (2) is really Not Our Problem. You are right. I misread your clearly written note. The "semantics of SGML applications" is indeed undefined in a CS sense. We do need to specify a mapping from 1 -> 3. I agree that we will need a way to invoke user-interaction, and a way to invoke general code. I am very unconvinced that these should be totally combined. HTML's forms, ugly as they are, get a big win in unsability on all platforms because their "declarative formatting" is abstract enough to map to native UI widgets on all platforms -- and also allows meaningful rendering for handicapped users and meaningful analysis by programs -- things that raw java code does not allow. (Java does have the AWT, so it gets the UI benefits, but that is not useful to a blind user). So I think that Java, Javascript, and whatever other general programming languages may also need to be supplemented by some standard behaviors that can be mapped usefully everywhere. This will also help the many web-noids who have critical graphic design and interaction design skills, but no ability to program. -- 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 Feb 1997 13:57:52 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: XML catalog draft > - bless the PUBLIC keyword & associated identifier Yes. > - make a decision as to what should be done when both PUBLIC and SYSTEM > are there [I can't recall detecting a consensus; did I just miss it?] Since PUBLIC is likely to be a point of user-tailorability, it should be looked at first -- implementations that don't implement PUBLIC resolution will simply ignore the PUBLIC, thus causing it to "fail". I can't think of a case where someone who _has_ working public resolution, would prefer to use the system ID -- andif they did, it seems they could always ensure that any given public ID (or all) would fail to resolve. > - provide a pointer to TR9401 in the write-up on the PUBLIC identifier, > saying that this is one proven-in-practice way to resolve them Since the new proposal is different from 9401 couldn't we issue it as the W3C's equivalent of an "experimental RFC". ie. well-defined, a potential candidate for standardization, but requiring practical experience before endorsement. That seems to describe DELEGATE to a T. > - improve support for catalogs by providing a special PI, as recommended > by a couple of WG-ers, to help define the BASE and thus find the > catalog I would like this even more if it is possible for the base to look like this: This would also allow things with PUBLIC IDs to announce their identifier -- which would be a great virtue, I think. > - investigate the problem of what seems like the unnecessary > restrictions on MINIMUM LITERAL; I don't think it's desirable to > say that a PUBLIC identifier can't be a URN, which this would do. I _think_ without having the proposal in front of me, that we can use %escape to handle this, and that may be the right thing until SGML fixes the Minimum literal restrictions. >I'm not sure what the right thing to do is with the current >catalog proposal. It seems to represent the best thinking, by the people >who know, on how to get good mileage out of Socats; it would be a >pity to lose that. But at the moment it just doesn't seem like a good call >to wire this into XML. That may be so, but I think it should go out there, and experience will tell _if_ it will need any changes. -- 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 Feb 1997 14:30:10 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@w3.org Subject: Re: There Are No Metadocuments >>As soon as you start defining objects that have some behavioural >>semantics associated with them, you also open up the possibility >>of people interpreting the semantics. >True, but essentially false: > >Once the interpretation of the data is a turing-complete problem, the >possibility of _useful_ interpretation goes way, way down. No disagreement here... I was just noting that data and behaviour are largely separated only in the way you interpret things. >This is why I mistrust jumping to code _too soon_. To push the interaction >envelope you need code, but you also lose reusability, because your >environment sneaks into your data... We definitely will need to attach code >to documents though. Yep. I tend to look at it as defining interfaces vs defining implementations. You reuse interfaces and throw away implementations in most systems I've seen. The problem we face is that it's hard to decide upon an interface until you are aware of the implementation constraints... and that interfaces often need to evolve over time. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 14:43:26 -0400 To: dgd@cs.bu.edu (David Durand) From: murray@spyglass.com (Murray Altheim) Subject: Re: XML catalog draft Cc: w3c-sgml-wg@w3.org dgd@cs.bu.edu (David Durand) writes: [...] >> - make a decision as to what should be done when both PUBLIC and SYSTEM >> are there [I can't recall detecting a consensus; did I just miss it?] > >Since PUBLIC is likely to be a point of user-tailorability, it should be >looked at first -- implementations that don't implement PUBLIC resolution >will simply ignore the PUBLIC, thus causing it to "fail". I can't think of >a case where someone who _has_ working public resolution, would prefer to >use the system ID -- andif they did, it seems they could always ensure that >any given public ID (or all) would fail to resolve. Actually, that's the opposite situation in my experience: This announces to the world that the document conforms to HTML 2.0, but tells the processor that a local copy of 'html.dtd' will provide the resource without resorting to a PUBLIC catalog lookup. IOW, why bother resolving the reference if the document seems to know where to look. Then, if the SYSTEM fails, resort to the more generalized process of a catalog lookup using PUBLIC. I believe Panorama has the same behaviour. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 15:10:07 -0500 To: murray@spyglass.com (Murray Altheim) From: dgd@cs.bu.edu (David Durand) Subject: Re: XML catalog draft Cc: w3c-sgml-wg@w3.org At 2:43 PM 2/11/97, Murray Altheim wrote: >dgd@cs.bu.edu (David Durand) writes: >>Since PUBLIC is likely to be a point of user-tailorability, it should be >>looked at first -- implementations that don't implement PUBLIC resolution >>will simply ignore the PUBLIC, thus causing it to "fail". I can't think of >>a case where someone who _has_ working public resolution, would prefer to >>use the system ID -- andif they did, it seems they could always ensure that >>any given public ID (or all) would fail to resolve. > >Actually, that's the opposite situation in my experience: > > "http://www.cm.spyglass.com/dtd/html.dtd"> > >This announces to the world that the document conforms to HTML 2.0, but >tells the processor that a local copy of 'html.dtd' will provide the >resource without resorting to a PUBLIC catalog lookup. IOW, why bother >resolving the reference if the document seems to know where to look. Then, >if the SYSTEM fails, resort to the more generalized process of a catalog >lookup using PUBLIC. This is correct for a local file system, but incorrect, I think, when SYSTEM IDs are URLs. A URL in general requires the invocation of a network query, whereas a catalog may be resolvable with purely local (and hence cheap) operations. In your example, I can, without a cache, determine from the PUBLIC ID that I have a local file containing the correct DTD. The SYSTEM ID just tells me that your HTTP server also has a copy in that place. Of course a local URL cache could invert this preference... Perhaps we should leave the resolution strategy to the client, as I can imagine rather complex, but very sensible strategies. For instance: Prefer local SYSTEM IDs to any CATALOG method Otherwise, use the local CATALOG to resolve by PUBLIC ID Otherwise try any (non-local) SYSTEM ID Finally, try non-local CATALOG resolution (perhaps extended SOCAT). The above strategy may actually be quite good for a typical browser application that. In fact each of the SYSTEM resolutions could be further modified by a SYSTEM ID cache check, which should precede any network-invoking operations... Depending on how the software caches data, the optimal strategy may be very complex. I'm now thinking we should not get in the way of processing agents defining their own strategies _however_ they 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: Tue, 11 Feb 1997 20:31:59 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: Ontology and Epistimology for Links in XHL For endpoint name I would prefer either endpoint role or endpoint type as this describes the purpose of the name better. As I almost painted over gloss why not use the key term it is defined under in Roget's Thesaurus - commentary. (Alternatives suggest by Roget include legend, inscription, notes and one that seems particularly apt for this discussion group, adversaria!) Another alternative, more in line with your link description, would be link descriptor (or should that be endpoint description?). ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 15:50:51 -0500 To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 1.5: Discuss link characteristics? Cc: bosak@atlantic-83.eng.sun.com At 05:13 PM 02/09/97 -0800, Jon Bosak wrote: >Instead of the two categories "4. link formatting" and "5. link >behavior", which I don't think are separable, make a single item >number 4, "link behavior", and then distinguish between two categories >of behavior, link display and link traversal, as follows: > >A. Link display > > How termini are presented to the user. > > - Possibly conditioned on history > > - Possibly including (e.g.) menus to display alternative link > target labels ("explainers"), termini represented as animated > figures, etc. as well as the usual underlining, etc. > >B. Link traversal > > What happens when a link is traversed. > > - Effects when traversed: opening/closing windows, scrolling, > displaying data from termini in various ways (including the > automatic transclusion of data without user action) > > - Testing, authenticating, and logging user context information > > - Running programs Here, here. On the other hand, Martin wrote a distinction between behavior and presentation that I think wrongly conflates two axes: 1) user vs. author control, and 2) geometric layour versus what happens on mouse-click You can't completely separate formatting behavior from interaction behavior, and you sure can't combine those two axes. Example: there's a quotation element. I, as a user, may want it: * Displayed in a footer or sider pane * Rendered as an inline block-quotish kind of layout * Hidden behind something clickable like an icon or a footnote number, and displayed on demand. * Hidden per last point, but in big pink type if I reached it via a link or type 'criticism' and small green if by a link of type 'support'. * flagged for different indexing treatment, or extracted along with all others of its kind to make a biblio. Now try to pin down just which of those are presentation and which are behavior. And then convince all the users that they only ever want control of presentations, and convince all the authors that they only ever want control of behavior. In *every* presentation, I may want to associate behavior. For example, when it's inline I may want to be able to click on it anyway, and retrieve the source being quoted. Or maybe I want my display of the quotation to have a scrollbar, so without following any link I can just scroll around to see its original context. I do not think it is possible to make a *principled* distinction between formatting behavior and interactive behavior. And they do not correlate precisely with the entirely separate notion of user vs. author control. If we conflate those two separate axes, we'll just impose a needless limitation. And Murray wrote: >But in no case does clicking on a link take the user to a _different_ >location than that intended by the author, and I believe this is the crux >of the issue. There are two behaviours here: link destination and browser >action. In no case should the browser alter the former. I find that tempting, but a bit too strong. There are at least a few cases where the destination depends on other factors, such as implicit links, links that depend on user configuration or environment data, etc. Take a look at any IETM, or any expert-system-assisted maintenance manual, or anything that supports stretchtext. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 15:57:29 -0400 To: dgd@cs.bu.edu (David Durand) From: murray@spyglass.com (Murray Altheim) Subject: Re: XML catalog draft Cc: w3c-sgml-wg@w3.org dgd@cs.bu.edu (David Durand) writes: [...] >This is correct for a local file system, but incorrect, I think, when >SYSTEM IDs are URLs. A URL in general requires the invocation of a network >query, whereas a catalog may be resolvable with purely local (and hence >cheap) operations. In your example, I can, without a cache, determine from >the PUBLIC ID that I have a local file containing the correct DTD. The >SYSTEM ID just tells me that your HTTP server also has a copy in that >place. Of course a local URL cache could invert this preference... Well, I inadvertently made the point that resolution is more complex than PUBLIC vs. SYSTEM. "www.cm.spyglass.com" is a local server *for me*, but not for you. >Perhaps we should leave the resolution strategy to the client, as I can >imagine rather complex, but very sensible strategies. For instance: > > Prefer local SYSTEM IDs to any CATALOG method > Otherwise, use the local CATALOG to resolve by PUBLIC ID > Otherwise try any (non-local) SYSTEM ID > Finally, try non-local CATALOG resolution (perhaps extended SOCAT). > >The above strategy may actually be quite good for a typical browser >application that. In fact each of the SYSTEM resolutions could be further >modified by a SYSTEM ID cache check, which should precede any >network-invoking operations... > >Depending on how the software caches data, the optimal strategy may be >very complex. I'm now thinking we should not get in the way of processing >agents defining their own strategies _however_ they want to. Agreed. It seems out of place for an XML specification to specify this type of behaviour. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 97 14:53:37 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > From: murray@spyglass.com (Murray Altheim) > > dgd@cs.bu.edu (David Durand) writes: > > > >Since PUBLIC is likely to be a point of user-tailorability, it should be > >looked at first -- implementations that don't implement PUBLIC resolution > >will simply ignore the PUBLIC, thus causing it to "fail". I can't think of > >a case where someone who _has_ working public resolution, would prefer to > >use the system ID -- andif they did, it seems they could always ensure that > >any given public ID (or all) would fail to resolve. > > Actually, that's the opposite situation in my experience: > > "http://www.cm.spyglass.com/dtd/html.dtd"> > > This announces to the world that the document conforms to HTML 2.0, but > tells the processor that a local copy of 'html.dtd' will provide the > resource without resorting to a PUBLIC catalog lookup. IOW, why bother > resolving the reference if the document seems to know where to look. Then, > if the SYSTEM fails, resort to the more generalized process of a catalog > lookup using PUBLIC. But suppose I have a local copy of the HTML 2.0 DTD (and who wouldn't), so my local system default catalog has: PUBLIC "-//IETF//DTD HTML 2.0//EN" "/home/dtds/html.dtd" If you prefer SYSTEM, then there is no way to find the local copy in favor of the spyglass one (unless the latter fails). Suppose I want to avoid the unnecessary http download. Suppose it's are very big file (not just the HTML 2.0 DTD). Suppose a few years >from now people start charging for accessing files. Suppose I retrieved the instance, its sgml declaration, its DTD, and all the entities it references in a MIME-SGML package so it makes no sense to redownload the DTD and all the entities once again. Suppose for whatever set of good reasons known only to me, I really need to use a slightly modified version of the DTD when my application reads HTML 2.0 document instances. For all these reasons, it seems important to attempt the lookup that allows end-user (or at least end-user-site) indirection before requiring that the system id be attempted. If (as Terry is about to say), the creator/publisher of the material does not want to allow indirection or replacement, then they would not have included a public id but would have only put a system id in the declaration. In other words, in answer to "why bother resolving the reference if the document seems to know where to look" I'd answer "why bother to have a public id that allows the all-important indirection if you going to ignore it in most cases." Public ids aren't just a fallback for broken URLs, they are a very important way to manage indirection of resource name resolution. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lex@www.copsol.com (Alex Milowski) Subject: Re: There Are No Metadocuments To: w3c-sgml-wg@w3.org Date: Tue, 11 Feb 1997 15:25:08 -0600 (CST) Dave Peterson wrote: > > The "pre-SGML", if you will, concept of a document was simply > something that is printed. SGML looks at a document as a > collection of potentially reusable information, which may > be reused in many ways besides republishing it on paper again > in a slightly different format. "The document" is something > that can be published, searched, spoken (a very non-paper form > of publishing), indexed, etc., etc. If, as you suggest, that > this something together with its publishing specifications is > a document but that with different publishing specifications > is a different document, then with its indexing specifications > it's yet another document, when published by speech synthesizer > it's yet another, etc., etc., etc.,... Put all these things > together and you've got a metadocument, in many people's mind. > > If the union of all of your related-by-having-the-same-content > documents is a metadocument in some people's mind, there are > others that would like in this brave new world to use "document" > to mean the intersection: the core structured data set. > > ...And those who draw the line somewhere in between. > Very well put. Now, I'm all for not drawing lines. I would prefer flexibility in infrastructure. Is it possible that we have: 1. An SO-catalog spec as minimal conformance. 2. Something describing the union/intersection model described above for metadocuments. ?? ...or, is this contrary to our goal? At some point in time, we are going to have to reject the premise that XML should be simple and built by a CS graduate in a week (or whatever silly premise it was). Was this a design premise when SQL was created? Complex problems never cease to be complex problems and simple solutions rarely solve them. Here is, again, my opinion: 1. The "Minimal-constructs-to-declare-success" is some kind of SO-catalog model. It has its drawbacks which was well pointed out. 2. The uniform and scalable infrastructure is a metadocument architecture or whatever you want to call it--a bootstrapping document that starts the whole process off. This is more complex and, to some extent, will require rejecting the premise that XML must be kept as simple to implement quickly. >From an implementor's standpoint, writing code to handle catalogs is pretty trival. It is just some amount of work to shake out the features and bugs. >From a development user's standpoint, using catalogs in a simple environment is quick easy, quick, and convient. Using catalogs in a complex environment is a *big* problem. They can be large or complex and difficult to handle (sound familiar?). Thus, they don't scale well for the non-simple user. Can we accept this? I am certain that SO-catalogs can be worked elegantly into a metadocument architecture such that we could be compatible with them if we choose to implement a metadocument architecture in the future. Is it possible we could have one specification that incorporates both? In addition, it would seem that the metadocument archictecture has somewhat been approached by Sun in Java. JAR files are "archive" files that allow delivery of class files, data (documents, images, etc.) all within one stream from the server. I haven't experimented with this very much but it would seem that they had a similar issue: my program is made up of distinct components that I must locate and load from the server. They decided that having one archive to retrieve would improve efficiency. In light of this, is a metadocument archive something that will be the new paradigm for delivery of content/applications arcoss the web? If so, do we need to consider this as a necessary component of XML? Remember, I want more than deliver of *documents* that can be printed/previewed. I want active documents that use components that are information and semantics. (Add one XML document and one DSSSL stylesheet into a blender, blend on highest setting until a soupy mixture results. Pour into computer.) I am always guilty of wanting the ideal (or at least, my ideal). ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 13:33:59 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: What to do given both SYSTEM and PUBLIC? At 02:53 PM 2/11/97 CST, Paul Grosso wrote: >> From: murray@spyglass.com (Murray Altheim) >> dgd@cs.bu.edu (David Durand) writes: Hmm, seems I was right - we do *not* have a consensus on this one. The argument in favor of SYSTEM-first is that this is apt to be quicker and cheaper (particularly if you assume that a PUBLIC id usually generates a SYSTEM id). The argument in favor of PUBLIC is simpler; it has another level of indirection, potentially some supporting catalog machinery; in fact, can be considered to be in some sense of "higher value". The argument in favor of saying nothing is that the right thing to do is [existence proof in the debate here] not crystal-clear and may be application-dependent. Any new arguments? - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 16:42:57 -0400 To: paul@arbortext.com (Paul Grosso) From: murray@spyglass.com (Murray Altheim) Subject: Re: XML catalog draft Cc: w3c-sgml-wg@w3.org paul@arbortext.com (Paul Grosso) writes: >> From: murray@spyglass.com (Murray Altheim) >> >> > "http://www.cm.spyglass.com/dtd/html.dtd"> >> >> This announces to the world that the document conforms to HTML 2.0, but >> tells the processor that a local copy of 'html.dtd' will provide the >> resource without resorting to a PUBLIC catalog lookup. IOW, why bother >> resolving the reference if the document seems to know where to look. Then, >> if the SYSTEM fails, resort to the more generalized process of a catalog >> lookup using PUBLIC. > >But suppose I have a local copy of the HTML 2.0 DTD (and who wouldn't), >so my local system default catalog has: > > PUBLIC "-//IETF//DTD HTML 2.0//EN" "/home/dtds/html.dtd" > >If you prefer SYSTEM, then there is no way to find the local copy in >favor of the spyglass one (unless the latter fails). I didn't mean to imply a behavior at all. What that DOCTYPE says is that there are both SYSTEM and PUBLIC available, not which one is given preference. I'm not advocating constraining UA behaviour. Your converse statement: >In other words, in answer to "why bother resolving the reference if the >document seems to know where to look" I'd answer "why bother to have a >public id that allows the all-important indirection if you going to >ignore it in most cases." is true iff the UA is set to prioritize SYSTEM over PUBLIC. Please note that I was not stating that converse, I was replying to David's statement: dgd@cs.bu.edu (David Durand) Tue, 11 Feb 1997 13:57:52 -0500 writes: >Since PUBLIC is likely to be a point of user-tailorability, it should be >looked at first -- implementations that don't implement PUBLIC resolution >will simply ignore the PUBLIC, thus causing it to "fail". I can't think of >a case where someone who _has_ working public resolution, would prefer to >use the system ID -- andif they did, it seems they could always ensure that >any given public ID (or all) would fail to resolve. by trying to state that a general, simplistic rule is not possible. >Public ids aren't just a fallback for broken URLs, they are a very >important way to manage indirection of resource name resolution. Agreed. I'm in agreement with David's last summary on the subject: >Depending on how the software caches data, the optimal strategy may be >very complex. I'm now thinking we should not get in the way of processing >agents defining their own strategies _however_ they want to. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 16:52:19 -0500 To: lee@sq.com, w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: XML catalog draft At 12:27 PM 02/07/97 EST, lee@sq.com wrote: >I think that it would be better to specify that URNs be used (which I >would support) than FPIs (which I do not support), as there is still no >resolution mechanism that will scale up to millions of FPIs even >proposed, let alone working, as far as I can see. ISO can mandate the See: Pearl, Amy. 1989. "Sun's Link Service: A Protocol for Open Linking." Proceedings of Hypertext 1989. ACM Press, pp. 137-146. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 14:23:02 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@w3.org Subject: XML process modelling [was No Metadocuments] Alex writes: |Complex problems never cease to be complex problems and simple solutions rarely | solve them. Right. Problems can be simplified. | Here is, again, my opinion: | | 1. The "Minimal-constructs-to-declare-success" is some kind of SO-catalog model. | It has its drawbacks which was well pointed out. | | 2. The uniform and scalable infrastructure is a metadocument architecture or | whatever you want to call it--a bootstrapping document that starts the | whole process off. This is more complex and, to some extent, will require | rejecting the premise that XML must be kept as simple to implement | quickly. This is argument by assertion. Let's begin at the beginning (where it would have been useful to start last year). Who's on first? I imagine that an XML pile-o'-stuff is first requested not by an XML "processor" but by an app. One scenario runs thusly: - App sends URL to URL-handling engine - URL-handling engine tickles the HTTP client to send a GET - Server responds by sending XML pile-o'-stuff, which can range from a single XML file (with pointers to other needful entities) to a complete set of entities, DTDs, and the like - This pile-o'-stuff is routed to the MIME unpacker (if need be) or to the app that requested it. If to the MIME unpacker, then the unpacker and the app probably need to communicate with each other. pile-o'-stuff gets unpacked suitably - App sends appropriate pieces of pile-o'-stuff to the XML parser (processor), possibly in a complex interaction - Parser returns parsed XML (for which there is, amazingly, no API specified) to the app, which may need to go back to square 1 to obtain additional info that wasn't included in the pile-o'-stuff - Eventually the app is happy and does something with the parsed XML that either the author or the user or the parser or the app or some combination decides is the Right Thang. Now where in this scenario do you want to use 1) catalogues and, or, 2) bootstrapping documents, and what is more complex about 2 than 1? Have I left out some steps? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 17:44:30 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: There Are No Metadocuments At 12:00 AM 02/11/97 -0500, Dave Peterson wrote: >The "pre-SGML", if you will, concept of a document was simply >something that is printed. >SGML looks at a document as a >collection of potentially reusable information, which may >be reused in many ways besides republishing it on paper again >in a slightly different format. "The document" is something Sorry, but I can't help objecting to the "if you will" above. Descriptive markup was around before SGML, before GML. Like Scribe for one example. Scholars had document ontologies ages before that (heck, that's the left-hand-side of a style manual). And if we just consider "the concept of a document", it was *way* broader than print for a very long time, particularly in the centuries *before* printing. This is especially clear when you consider heavily referenced and annotated documents such as Talmud, Bible, and so on, which were used in many ways beyond republishing in a slightly different format. And in consequence, few people referred to passages in them using print-specific means. For centures they have referred using structural pointers: book/chapter/verse, stanza/line, and so forth. "the text" is an abstraction beyond particular printings or manuscripts (hard as it is to get at the abstraction in many cases). Steve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 11:46:33 -0600 From: len bullard To: Murray Maloney CC: "Henry S. Thompson" , w3c-sgml-wg@w3.org Subject: Re: Winning battles but losing the war Murray Maloney wrote: > > I attended that meeting and tried to put in a plug > for XML whenever I could. The W3C folks tried hard > to downplay SGML and XML, but they did not manage > to keep me quiet. It seems clear that they consider > XML a bit of a threat and are trying to minimize > its role. The best way that we can overcome that > is to demonstrate the uefulness and practicality > of XML as compared to HTML. Interest in growing, > but it will take time and demonstrable software > to sway more people to our side. > > I expect to be atending the next AC meeting on June 17/18. > Having software to demonstrate at that meeting would > be a big help in pushing XML higher up on the agenda > for the consortium. > > Murray It is competitive. We have to live with that and understand the competition. The W3C consortium is a collection of conflicting interests. Go where they need this: not where they fear it. This is when alliance with ISO and WG8 plays to an advantage. Don't compare this to HTML. Don't compare this to Acrobat. This is SGML made practical for practical requirements. Figure out what those requirements are first. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 14:19:29 -0400 To: "Henry S. Thompson" From: murray@spyglass.com (Murray Altheim) Subject: Re: Winning battles but losing the war Cc: w3c-sgml-wg@w3.org "Henry S. Thompson" writes: >Who's supposed to be making our case at the W3C level? I've just seen >a lengthy report from a UK representative of last month's W3C meeting, >and XML is barely there: 2 one-line mentions in a 10-page report on a >3-day meeting. Numerous questions were raised to which XML is the >answer, but apparently no-one gave that answer, e.g. > > "Some felt that there should be an HTML extension mechanism (similar > to PEP for HTTP). Dan Connolly would produce a HTML briefing paper". > >Why doesn't this say "Dan Connolly pointed out that XML addressed this >need directly."? I think Dan, I and others were discussing some sort of HTML extension mechanism even as far back in the plastocene when the html-wg was still wandering the earth in search of small reptiles to eat. I remember attempting to get IANA to register extension names. A lifetime ago. The modularization of the HTML DTD was an early attempt at what Dan called a "platform for experimentation", and would still be (I believe) the mechanism whereby HTML extensions would be added. But as we all know, there's not too many HTML UAs that even bother to interpret the FPI in DOCTYPE, much less parse a DTD or perform entity management, so I think this effort is really doomed to failure. It's funny that we're just now discussing one of the features that HTML would need in order to provide some measure of ordered extension functionality: catalogs and entity management. Because in HTML there seems to be no movement towards greater interoperability and modularity (in fact, movement away from it if anything) I think the 'X' in XML will never make it over to prefix 'HTML', unless one counts ActiveX, etc. as extensibility. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 13:42:50 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: ERB meeting of Feb. 12th The ERB met Feb. 12th. Present were Bosak, Bray, Clark, DeRose, Magliery, Maler, Paoli. All decisions were unanimous. 1. The title of the spec will be "Hypertext Links in XML". There will be no new acronym, XHL or XHA or anything. The URL fragment will be WD-xml-link. The URL fragment for the XML syntax spec will be WD-xml-syntax. The URL fragment WD-xml will point to a tiny document just containing pointers to WD-xml-link, WD-xml-syntax, and presumably at least one more part in the future. 2. Links will be expressed as XML elements. We will write the spec so that the only other spec it depends on is xml-syntax. Obviously, links will be SGML elements as well. 3. We deferred the question of a link processor until we have more of the spec done; if we need to define a link processor in order to meet our specification goals, we will. 4. We deferred the question of a mechanism for signaling what link machinery is being used until we know what machinery is available. 5. We decided that formatting issues are outside the scope of XML linking, and we will neither discuss them nor provide a special attribute nor any other machinery in this specification for communicating formatting information. Note that we fully appreciate that the distinction between formatting and behavior is troublesome at best; this decision does not prejudice the possibility that XML links may contain behavior attributes and that the spec may predefine certain behaviors. In the ERB discussion it became obvious that lots more work is needed on this particular area. 6. We agreed that if we say that the links are elements and attributes, this provides all the syntax definition that we need; thus no additional BNF is required in the specification. [Ed note: Yes!] 7. We agreed that no special language is required in the spec to say that the links must be well-formed in the XML sense. While this spec is primarily designed for use in the XML domain, there seems nothing to gain in placing barriers in the way of full SGML processors that may wish to use this machinery in non-well-formed documents. 8. We spent the rest of the meeting arguing over details of terminology, without coming to a resolution; an additional meeting has been scheduled for Saturday morning [yecch] to enable us to finish working through this and the remaining 1.* questions. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 13:52:20 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 2.1 a-d: Link Recognition by Reserved Attribute? The ERB schedule calls for voting on these Feb. 19th. I've take the liberty of grouping a few here that seem totally related. 2.1.a Should we allow link recognition via a reserved attribute? 2.1.b If so, should we generalize this and say that it's an AF? 2.1.c If so, should we provide an introduction to AF's? 2.1.d If we allow such recognition, what should the attribute be, and what should be the values for each element type we define? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 13:52:21 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 2.2 a-b: Link Recognition by Reserved GI? The ERB schedule calls for voting on these Feb. 19th. I've take the liberty of grouping a few here that seem totally related. 2.2.a Should we allow link recognition via a reserved GI? 2.2.b If so, what should the set of GI's be? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 16:05:57 -0600 From: len bullard To: Tim Bray CC: w3c-sgml-wg@w3.org Subject: Re: 2.2 a-b: Link Recognition by Reserved GI? Tim Bray wrote: > > The ERB schedule calls for voting on these Feb. 19th. > I've take the liberty of grouping a few here that seem totally related. > > 2.2.a Should we allow link recognition via a reserved GI? No. > 2.2.b If so, what should the set of GI's be? None. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 14:10:16 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 2.4: Link recognition by processor fiat? The ERB schedule calls for voting on these Feb. 19th. 2.4: Should we allow that processors can decide that something is a link for their own unspecified reasons, e.g. hardwired knowledge of their own private element types, or external interaction? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 14:10:15 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 2.3: Link Recognition by PI or other signal? The ERB schedule calls for voting on these Feb. 19th. 2.3 Should we provide a PI or other signaling mechanism whereby a document can specify that particular elements ought to be processed as link elements? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 16:12:35 -0600 From: len bullard To: Tim Bray CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Tim Bray wrote: > > The ERB schedule calls for voting on these Feb. 19th. > I've take the liberty of grouping a few here that seem totally related. > > 2.1.a Should we allow link recognition via a reserved attribute? Yes. That is the most unobtrusive way unless you want to use PIs. Then you have IADS. In general, arch forms bother me to this day. They still look like a way to have class inheritance without specifically defining the machinery for classes and inheritance. > 2.1.b If so, should we generalize this and say that it's an AF? It opens up an entirely new specification to write or a to reference HyTime. Is an archForm a real class indicator, or just a conventional set of parameter entities? Can an arch form inherit arch forms? > 2.1.c If so, should we provide an introduction to AF's? Yes. > 2.1.d If we allow such recognition, what should the attribute be, and > what should be the values for each element type we define? This doesn't seem possible to decide without a description of what XML archForms are. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 12:02:15 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: XML process modelling [was No Metadocuments] At 2:23 PM 2/11/97, Terry Allen wrote: >Alex writes: >|Complex problems never cease to be complex problems and simple solutions >rarely >| solve them. > >Right. Problems can be simplified. Only "sort of". You can find a simpler related problem. The less-simple problem is still there. Sometimes *but no guarantee* the solution to the simpler problem provides a tolerable solution to the less-simple. Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 12:32:30 -0500 To: Kurt Conrad , "w3c-sgml-wg@w3.org" From: davep@acm.org (Dave Peterson) Subject: RE: What to do given both SYSTEM and PUBLIC? At 5:06 PM 2/11/97, Kurt Conrad wrote: >I lean towards giving the public identifier precedence. > >The knee-jerk argument is "why bother" with public identifiers if the system >IDs take precedence. If I can't rely on the catalogs that I create, why >should I invest the effort to maintain them. This would be especially true >in an organizational setting, where such catalogs are increasingly likely to >be managed as shared resources to improve consistency across a collection of >documents. If as a publisher, I don't want the 'standard' component, I should >not code a reference to it. The original intent with SGML, as Goldfarb has explained it more than once, was that the system identifier is king; if it's not present, then the system is to try and impute one with whatever information (like a public identifier) it does have. If I understood correctly, the scenario he envisioned was that one would rarely use both, and if both were present it was because for some reason someone wanted to (presumably temporarily) override the standard system mechanism for resolving the public identifier. SGML's primary original purpose was to be a common interchange format, not only between systems sharing the same storage resources but between disparate systems with wildly different storage resources and organization formats thereof. And a system identifier on one system is not typically of much use on another. Under Goldfarb's scenario, if you're sending a document "off-site", you have a moral obligation to strip out your local system identifiers so as to avoid confusing the entity manager on the receiving system. (But many don't, so the receiver has to.) Point 1. "System identifier" is prime is not just a knee-jerk, lazy reaction. Point 2. The intended XML situation is complicated by the fact that "disparate" systems may be sharing storage systems via the web. From our point of view, a system identifier that is not a URL *should* have been stripped. (Will all who put XML on the web be so considerate?) But if the system identifier *is* a URL, should we have the capability to override it? I think so, and that's why I think the "original scenario" as described above is not the way to go. I think one should be able to override locally, and so, I favor: o If both identifiers are present, try to resolve the public identifier using the local system (catalog, whatever). o If bot are present but the public identifier has no resolution on the local system, then try the system identifier. Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 17:53:21 -0400 To: Tim Bray From: murray@spyglass.com (Murray Altheim) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Cc: w3c-sgml-wg@w3.org Tim Bray writes in separate messages: >2.1.a Should we allow link recognition via a reserved attribute? [...] >2.2.a Should we allow link recognition via a reserved GI? Is there any reason not to allow both as equivalents, where the reserved attribute is an AF similar to Eve's proposal? Then any element containing the AF attribute would be the equivalent of the reserved GI? I'm assuming any reserved GI would be something like . Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 14:50:34 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? At 05:53 PM 2/12/97 -0400, Murray Altheim wrote: >Tim Bray writes in separate messages: >>2.1.a Should we allow link recognition via a reserved attribute? >[...] >>2.2.a Should we allow link recognition via a reserved GI? > >Is there any reason not to allow both as equivalents Of course not; we can approve of neither, either, or both. I favor both myself. >I'm assuming any reserved GI would be something like . Me too. -Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 17:23: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: Winning battles but losing the war (This thread seems to have appeared out of nowhere. Did someone's private correspondence get forwarded to the list?) [Len Bullard:] | The W3C consortium is a collection of conflicting | interests. Go where they need this: not where | they fear it. This is when alliance with ISO | and WG8 plays to an advantage. Don't compare | this to HTML. Don't compare this to Acrobat. Yes. I cannot emphasize too strongly the importance of this point. HTML is almost perfectly suited to the problem space it was originally designed to address, and for that reason it will probably be around for decades to come. It is a big mistake to position XML as competition to HTML. XML is not going to take over HTML's problem space, and suggesting that it might just generates needless hostility. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 06:51:03 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: Improved, slightly modified version of my proposed redraft Henry I'm not sure I understand what you mean by this sentence: >A link description can be >understood as a mapping from document instances and their contexts to >links. What are the links - their endpoints? What contexts can document instances have? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 09:18:42 +0100 To: w3c-sgml-wg@w3.org From: haitto@synex.se (Hasse Haitto) Subject: Re: XML catalog draft Tim Bray wrote: ... >I think we should: >- make a decision as to what should be done when both PUBLIC and SYSTEM >are there [I can't recall detecting a consensus; did I just miss it?] As David, Paul, Steve, Kurt, and others, I would have PUBLIC take precedence over SYSTEM; only if the catalog lookup fails should one try the SYSTEM identifier. The PUBLIC identifier provides necessary indirection, and is essential for addressing portability. This is the approach we chose in Synex ViewPort (using the socat), and how e.g. Panorama works. Cheers, Hasse -- Synex Information AB Phone: +46 8 791 88 81 Stora Nygatan 20, 1tr Fax: +46 8 791 88 89 111 27 Stockholm Internet: haitto@synex.se Sweden WWW: http://www.synex.se %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Thu, 13 Feb 97 08:58:12 GMT To: w3c-sgml-wg@w3.org Subject: Re: Improved, slightly modified version of my proposed redraft Martin writes: > I'm not sure I understand what you mean by this sentence: > >A link description can be > >understood as a mapping from document instances and their contexts to > >links. > > What are the links - their endpoints? What contexts can document instances have? The link is the actual multi-ended relationship. The link description is the result of processing the link description element. It has all the information needed to build a link, but I call it a mapping because the SAME link description can result in DIFFERENT links depending on where it sits in its host document, and where that document sits itself, because of relative elements in the locators used to identify the endpoints. Your question also gets us into the metadocument thread, because the most obvious aspect of context which affects what link instantiates a link description in any particular case is the catalog, supposing the one of its locators uses an FPI. Does this clarify? ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 09:11:28 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 2.2 a-b: Link Recognition by Reserved GI? >2.2.a Should we allow link recognition via a reserved GI? Not necessary if link has an attribute indicating its type > >2.2.b If so, what should the set of GI's be? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 09:11:30 +0000 To: Tim Bray , w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 2.4: Link recognition by processor fiat? >2.4: Should we allow that processors can decide that something is a link for > their own unspecified reasons, e.g. hardwired knowledge of their own > private element types, or external interaction? Whilst there can be nothing to stop this happening with any XML or SGML application we should actively discourage the development of browser specific linking mechanisms, otherwise Netscape and Microsoft will never get interworking sets of XML documents! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 09:11:32 +0000 To: Tim Bray , w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 2.3: Link Recognition by PI or other signal? > >2.3 Should we provide a PI or other signaling mechanism whereby a document > can specify that particular elements ought to be processed as link > elements? No - link identifying attributes should be all that is needed by any browser. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Thu, 13 Feb 97 09:22:48 GMT To: w3c-sgml-wg@w3.org Subject: If no new syntax, and no API, then what are we doing here . . . The ERB voted (correctly, in my view) that the linking part of the spec. doesn't need any new syntax productions. Someone observed in the last few days that we have studiously avoided the issue of an API for XML processing. So what are we doing in this section? I think it is more than spec'ing a meta-DTD and a family of XML Applications which could use it. The API question points to the answer. DSSSL and the HyTime TC give the means for framing this answer: The xml-link document should define a new Property Set module, which (using the terminology from my proposed redraft) provides an HLINK class to represent links, with e.g. HLINKTYPE and ENDPOINTS properties. (Note: Irritatingly, the value of ENDPOINTS can't be a NamedNodeList, because several endpoints can have the same type, in my view, so there will have to be an ENDPOINT class as well, with something like TYPE, NODELOC and DATALOC properties.) On this account the result of processing an XML document with link definition elements in it is TWO groves: the document grove and a link grove. So-called 'Link databases' (I don't like the name) are just documents whose processing output is mostly in their link grove. One of the NODELOC properties of TLINKs will point back to the document grove; other NODELOC properties will be (lazy) pointers into the groves of other (..ML) documents altogether, while DATALOC is for non-SGML endpoints. More later, got to run. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 09:11:26 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? >2.1.a Should we allow link recognition via a reserved attribute? > Yes >2.1.b If so, should we generalize this and say that it's an AF? Yes > >2.1.c If so, should we provide an introduction to AF's? No - the SGML Extended Facilities Annex of 10744 has a more than adequate description. If you want a summary of this on the web I will do one on request for placing on a site of your choice. > >2.1.d If we allow such recognition, what should the attribute be, and > what should be the values for each element type we define? XML-link (mlink|slink|end|lg|ld) #FIXED #REQUIRED> Note: slink = self(-anchored) link ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 10:32:19 +0100 To: w3c-sgml-wg@w3.org From: haitto@synex.se (Hasse Haitto) Subject: Re: 2.3: Link Recognition by PI or other signal? >The ERB schedule calls for voting on these Feb. 19th. > >2.3 Should we provide a PI or other signaling mechanism whereby a document > can specify that particular elements ought to be processed as link > elements? Yes. Definitely. I would suggest PIs to be used to assign elements and/or attributes the role of links. This - I think - should simplify issues 2.1 a-d: Link Recognition by Reserved Attribute 2.2 a-b: Link Recognition by Reserved GI 2.4: Link recognition by processor fiat as well. Cheers, Hasse P.S. Not to push a badly veiled agenda, beneath is an excerpt from the Synex ViewPort documentation to illustrate what we have found to be a useful design. The PIs are used to register customized hypertext and elements using the TEI P3 extended pointer syntax. (Customized hypertext triggers callbacks, whereas the TEI extended pointers are handled internally). ViewPort supports two ways of registering link elements: - by element, or - by element if a specific attribute is non-implied The element can be specified either by its generic identifier (element name) or by an architectural form. Processing instructions are used for the registration. In the PI examples below, the "tag-link" registers a hyperlink element, and "att-link" a hyperlink defined using an element with a non-implied attribute. Examples: All elements named A become customized hypertext elements with the hyperform URL. All elements named A become customized hypertext elements with the hyperform URL if the corresponding element has an non-implied attribute named HREF. All elements having an attribute named HTMLFORM assigned the value ANCHOR become customized hypertext elements with the hyperform URL. All elements having an attribute named HTMLFORM assigned the value ANCHOR become customized hypertext elements with the hyperform URL if it has an non-implied attribute named HREF. The syntax of the processing instructions in formal terms is: tag-link :- 'TAGLINK' element hyperform [ param ] att-link :- 'ATTLINK' element attribute hyperform [ param ] element :- NAME | '#ARCHFORM' attribute value attribute :- NAME value :- LITERAL hyperform :- LITERAL param :- LITERAL A hypermedia form (hyperform) is an application-dependent keyword. ViewPort reserves "TEI-P3" internally, for the TEI extended pointer functionality. Panorama uses "URI" as the hyperform for its URL support. For ViewPort, the processing instructions must be included in the SGML document prior to the parsing of the document instance (in the DTD or document type declaration subset). -- Hasse Haitto Phone: +46 8 791 88 81 Synex Information AB Fax: +46 8 791 88 89 Stora Nygatan 20 Internet: haitto@synex.se S-111 27 Stockholm, Sweden WWW: http://www.synex.se %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 04:31:12 -0500 To: murray@spyglass.com (Murray Altheim), "Henry S. Thompson" , bosak@atlantic-83.eng.sun.com From: "Keith M. Corbett" Subject: Re: Winning battles but losing the war Cc: w3c-sgml-wg@w3.org At 02:19 PM 2/12/97 -0400, Murray Altheim wrote: >"Henry S. Thompson" writes: >>Who's supposed to be making our case at the W3C level? I've just seen >>a lengthy report from a UK representative of last month's W3C meeting, >>and XML is barely there: 2 one-line mentions in a 10-page report on a >>3-day meeting. Numerous questions were raised to which XML is the >>answer, but apparently no-one gave that answer, e.g. >> >> "Some felt that there should be an HTML extension mechanism (similar >> to PEP for HTTP). Dan Connolly would produce a HTML briefing paper". >> >>Why doesn't this say "Dan Connolly pointed out that XML addressed this >>need directly."? I suspect Dan would argue with that proposition; I'm fairly sure TBL would if pinned down. Nobody on W3C staff said a kind word for XML when I and others brought it up. XML was not given air time; or rather it was listed on the agenda but time ran out during the final "quiz the staff" session. I hope next year someone from the SGML ERB will be given an hour to present the glowing success story. But we'll have to get XML far up the pipeline in the W3C process for that to happen; that pipeline is clogged, and if XML doesn't burst loose in Santa Clara it might not get another chance this year. (I wish I could be there.) /kmc %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 11:00:17 +0000 To: w3c-sgml-wg@w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? >At 05:53 PM 2/12/97 -0400, Murray Altheim wrote: >>Tim Bray writes in separate messages: >>>2.1.a Should we allow link recognition via a reserved attribute? >>[...] >>>2.2.a Should we allow link recognition via a reserved GI? >> >>Is there any reason not to allow both as equivalents > >Of course not; we can approve of neither, either, or both. I favor >both myself. Count me in for both. Sean Mc Grath digitome@iol.ie %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 11:49:58 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: Marketing Contributions... Cc: digitome@iol.ie (Digitome Ltd.) At 10:51 11.02.97 +0100, Digitome Ltd. wrote: >As for slogans, how about:- > >"XML: Call a spade a " Sean, that is truly inspired! Fantastic! General point: Any slogans should emphasise the advantage of XML vis-=E0-vis HTML, *not* vis-=E0-vis SGML. That is: It's about the good stuff that SGML is bringing to the web, not about the bad stuff (and lots of good stuff) that's getting thrown out of SGML. So I don't like Peter's "Practise Safe SGML". (Sorry!) 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 From: "Henry S. Thompson" Date: Thu, 13 Feb 97 11:48:35 GMT To: w3c-sgml-wg@w3.org Subject: Re: If no new syntax, and no API, then what are we doing here . . . I said, in summary: > The xml-link document should define a new Property Set > module, with an HLINK class to represent links, with HLINKTYPE and > ENDPOINTS properties. There's an ENDPOINT class as well, > with something like TYPE, NODELOC and DATALOC properties. > > On this account the result of processing an XML document with link > definition elements in it is TWO groves: the document grove and a > link grove. NODELOC properties will be (lazy) pointers into the > groves of (..ML) documents, while DATALOC is for non-SGML endpoints. As promised, a bit more. 1) Note that I don't mean by the link grove proposal to say that all XML parsers have to buy in to the grove model, just that groves are a useful language for answering the question Jon implicitly asked a while back, namely, what do Applications have to work with when processing links. The link grove proposal answers that question in the abstract---the concrete representation of that information is up to implementors. 2) I'm sure a lot of this is crypto-HyTime, and Eliot would have said it first if he weren't too busy. 3) Using TC language again, the 'link description' in my terminology is pretty much isomorphic to the node in the document grove derived >from the link description element, as that node has (directly or indirectly) all the relevant information in its properties. On this account, we'd add a new (urefnode) HLINK property to the ELEMENT class, which would point to the appropriate HLINK node in the link grove from all such element nodes. 4) Note that since most locators take a lot of work to chase, the laziness of HLINK.ENDPOINTS is important, with the values of ENDPOINT.NODELOC properties on HLINK nodes in the link grove just being a node and property version of the original locators, with in a few cases, e.g. where the locator is an IDREF, a urefnode to the thing itself. So class ENDPOINT needs a LOCATOR property, value from a set of classes for the different locator languages, and a (urefnode) SOURCE property, pointing back to the ELEMENT node that gave it birth. If this is right, it means that conforming XML processors do NOT have to be capable of implementing most of the locator languages we bless, although the ability to do so will clearly make them more attractive to application developers. 5) I've redone the picture that goes with my partial redraft, and fixed a few things, see the URL below again, good luck getting Netscape to reload the image! http://www.cogsci.ed.ac.uk/~ht/new-xhl.html ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 04:07:16 -0800 (PST) From: Terry Allen To: ht@cogsci.ed.ac.uk, w3c-sgml-wg@w3.org Subject: Re: If no new syntax, and no API, then what are we doing here . . . Henry writes: >On this account the result of processing an XML document with link definition elements in it is TWO groves: the document grove and a link grove. The XML 1.0 spec doesn't require a parser to construct a grove, does it? will that be a requirement of xmllink? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 08:28:46 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? >>2.1.a Should we allow link recognition via a reserved attribute? >[...] >>2.2.a Should we allow link recognition via a reserved GI? Should this "allow" be read as "require" or "define"? XML/SGML allow this now... the question is whether we want to standardise on some recognition methodology. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 08:38:39 -0600 From: len bullard To: Terry Allen CC: ht@cogsci.ed.ac.uk, w3c-sgml-wg@w3.org Subject: Re: If no new syntax, and no API, then what are we doing here . . . Terry Allen wrote: > > Henry writes: > >On this account the result of processing an XML document with link > definition elements in it is TWO groves: the document grove and a > link grove. > > The XML 1.0 spec doesn't require a parser to construct a grove, > does it? will that be a requirement of xmllink? If the group could look carefully and with an unbiased view at the grove concepts, they could benefit from that work and put XML linking on much firmer foundation. eventually you have to work with the output of the parser. duh! len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 08:42:53 -0600 From: len bullard To: Gavin Nicol CC: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Gavin Nicol wrote: > > >>2.1.a Should we allow link recognition via a reserved attribute? > >[...] > >>2.2.a Should we allow link recognition via a reserved GI? > > Should this "allow" be read as "require" or "define"? XML/SGML > allow this now... the question is whether we want to standardise > on some recognition methodology. We do, I think. We have to make this simpler. Henry's descriptions are starting to read like ISO 10744 with new terms. That is regrettable. We can't prevent use of the GI, and in fact, it is in use. We should encourage use of the attribute. We can have both. The PIs are useful for registering forms. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 10:59:56 -0400 To: "Keith M. Corbett" From: murray@spyglass.com (Murray Altheim) Subject: Re: Winning battles but losing the war Cc: w3c-sgml-wg@w3.org "Keith M. Corbett" writes: >At 02:19 PM 2/12/97 -0400, Murray Altheim wrote: ! >>"Henry S. Thompson" writes: >>>Who's supposed to be making our case at the W3C level? I've just seen >>>a lengthy report from a UK representative of last month's W3C meeting, >>>and XML is barely there: 2 one-line mentions in a 10-page report on a >>>3-day meeting. Numerous questions were raised to which XML is the >>>answer, but apparently no-one gave that answer, e.g. >>> >>> "Some felt that there should be an HTML extension mechanism (similar >>> to PEP for HTTP). Dan Connolly would produce a HTML briefing paper". >>> >>>Why doesn't this say "Dan Connolly pointed out that XML addressed this >>>need directly."? > >I suspect Dan would argue with that proposition; I'm fairly sure TBL would >if pinned down. Nobody on W3C staff said a kind word for XML when I and >others brought it up. XML was not given air time; or rather it was listed >on the agenda but time ran out during the final "quiz the staff" session. > >I hope next year someone from the SGML ERB will be given an hour to present >the glowing success story. But we'll have to get XML far up the pipeline in >the W3C process for that to happen; that pipeline is clogged, and if XML >doesn't burst loose in Santa Clara it might not get another chance this >year. (I wish I could be there.) For the record, none of the text quoted was actually written by me, although I did participate in the thread. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 07:54:46 -0800 (PST) From: Terry Allen To: ht@cogsci.ed.ac.uk, w3c-sgml-wg@w3.org Subject: Re: If no new syntax, and no API, then what are we doing here . . . Henry wrote: >If this is right, it means that conforming XML processors do NOT have to be capable of implementing most of the locator languages we bless, although the ability to do so will clearly make them more attractive to application developers. To me this implies that the server must negotiate with the client to discover what processor the client uses (or vice versa, the client must negotiate with the server to discover whether it can handle the link syntax it's to be served). Is that right? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 97 09:44:21 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: 2.3: Link Recognition by PI or other signal? > From: Martin Bryan > > > > >2.3 Should we provide a PI or other signaling mechanism whereby a document > > can specify that particular elements ought to be processed as link > > elements? > > No - link identifying attributes should be all that is needed by any browser. If we cannot have multiple attlists (in particular, an attlist in the internal subset that declares only an element's "link identifying attribute"), then it might be worthwhile to have some PI syntax that allows the effective equivalent of an "attlist augmentation." Then this PI--which would look a lot like an attlist decl--could declare the #FIXED link identifying attribute. To restate: assuming we identify link elements via an attribute, I still think we need some way to avoid requiring the link identifying attribute to be set explicitly on every instance of this element type in the absence of the complete DTD. This capability seems best provided by some sort of "partial declaration" such as an "attlist augmentation" in the internal subset. Now whether this takes the form of a PI or not depends on what happens in the 8879 TC and what we do with regards to multiple attlist decls in general in XML. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 08:17:46 -0800 (PST) From: Todd Freter Subject: Re: Winning battles but losing the war To: Jon Bosak cc: w3c-sgml-wg@w3.org Jon Bosak: > (This thread seems to have appeared out of nowhere. Did someone's > private correspondence get forwarded to the list?) > > [Len Bullard:] > > | The W3C consortium is a collection of conflicting > | interests. Go where they need this: not where > | they fear it. This is when alliance with ISO > | and WG8 plays to an advantage. Don't compare > | this to HTML. Don't compare this to Acrobat. > > Yes. I cannot emphasize too strongly the importance of this point. > HTML is almost perfectly suited to the problem space it was originally > designed to address, and for that reason it will probably be around > for decades to come. It is a big mistake to position XML as > competition to HTML. XML is not going to take over HTML's problem > space, and suggesting that it might just generates needless hostility. > > Jon > Really? No comparison of XML and HTML? It makes sense to avoid denigrating HTML, but the question of how XML and HTML compare is going to ask itself, and loudly. People have been confused about HTML and SGML for years, and the introduction of XML into their vocabularies will only accentuate the need for rational comparisons. It doesn't matter whether comparing XML and HTML is the "wrong question." It's the question that everyone will ask. Even when we acknowledge the fit of HTML's design to its problem space, some folks will bristle when we suggest that HTML's problem space isn't infinite. (Doesn't Netscape's indifference to XML suggest a belief in the sufficiency of HTML?) Even if HTML users agree that XML solves certain problems more efficiently than HTML-plus-programs can, they will have to spend real money to take advantage of XML technology. People will need comparisons to make sensible business investments. And investments require that businesses assess *competitive* advantages of their investment options: XML or HTML, and for which applications? We certainly shouldn't generate needless hostility. And the XML initiative can certainly proceed without being hostile. But some hostility will greet whatever this initiative produces, and with a proper XML story, which includes SGML-XML-HTML comparisions, that hostility can be defused and can work to XML's advantage. IMO ... -Todd. Sun Microsystems, Inc. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 10:01: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: 2.1 a-d: Link Recognition by Reserved Attribute? [Sean Mc Grath:] | >At 05:53 PM 2/12/97 -0400, Murray Altheim wrote: | >>Tim Bray writes in separate messages: | >>>2.1.a Should we allow link recognition via a reserved attribute? | >>[...] | >>>2.2.a Should we allow link recognition via a reserved GI? | >> | >>Is there any reason not to allow both as equivalents | > | >Of course not; we can approve of neither, either, or both. I favor | >both myself. | | Count me in for both. I'm not following the reasoning for having both forms. If the reserved attribute method works, why do we need the reserved GI? If the reserved GI method has advantages, why use the reserved attribute? Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 10:17:38 -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: Winning battles but losing the war [Todd Freter:] | > Yes. I cannot emphasize too strongly the importance of this point. | > HTML is almost perfectly suited to the problem space it was originally | > designed to address, and for that reason it will probably be around | > for decades to come. It is a big mistake to position XML as | > competition to HTML. XML is not going to take over HTML's problem | > space, and suggesting that it might just generates needless hostility. | | Really? No comparison of XML and HTML? [...] I didn't say that XML should not be compared to HTML. I said that it should not be positioned as competition to HTML. You can compare a Honda Civic to a Mack truck. But you can't sensibly position a Honda Civic as competition to a Mack truck. They targeted for different markets. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 10:38:49 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? The question is whether to recognize link elements by attribute, GI, or both: Jon Bosak wrote: >I'm not following the reasoning for having both forms. If the >reserved attribute method works, why do we need the reserved GI? If >the reserved GI method has advantages, why use the reserved attribute? Well, if we're doing it by attribute, (in effect AF) then the AF is going to have to have a name, so why not just allow its use as a GI? I would think that the *easiest* way to do an XML link, both to explain and to do, would be just to adopt a hard-wired element nicely predeclared in the spec. This would be my first choice. I think would be desirable if everything whose GI was XML-TLINK was an XML TLINK, and every XML TLINK had a GI of XML-TLINK. (or whatever we call 'em) But in the XML discussions, there was some considerable reluctance to predefine particular elements; and it seems the conventional wisdom that the *right* way to do these things is with architectures; for reasons of namespace infringement, and general good karma. Thus we wrote this possibility into the spec. Having written this, I'm beginning to discover a new hard-minimalist enclave I can gleefully retreat into; why not always do it via GI? That question is not rhetorical; perhaps someone can explain the downside to this, and the upside to supporting AF-like attribute signalling? - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 13:44:54 -0400 To: bosak@atlantic-83.eng.sun.com (Jon Bosak) From: murray@spyglass.com (Murray Altheim) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Cc: w3c-sgml-wg@w3.org bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: >[Sean Mc Grath:] > >| >At 05:53 PM 2/12/97 -0400, Murray Altheim wrote: >| >>Tim Bray writes in separate messages: >| >>>2.1.a Should we allow link recognition via a reserved attribute? >| >>[...] >| >>>2.2.a Should we allow link recognition via a reserved GI? >| >> >| >>Is there any reason not to allow both as equivalents >| > >| >Of course not; we can approve of neither, either, or both. I favor >| >both myself. >| >| Count me in for both. > >I'm not following the reasoning for having both forms. If the >reserved attribute method works, why do we need the reserved GI? If >the reserved GI method has advantages, why use the reserved attribute? This would allow a designer to use either the reserved GI as the link element name, or modify a legacy name by adding an AF attribute. Not counting myself among the Hytime cognoscenti I'm going to stretch a little here, but this is my understanding: There might be an XML application that uses the XML GI: which could be equivalent to an XML-ized HTML: although I'm not sure from various sources if the attribute name should be 'XML', 'XMLNAME', etc. [Since I've probably got this skewed, I'm ready for my reeducation. *slap*] Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lex@www.copsol.com (Alex Milowski) Subject: Re: Winning battles but losing the war To: w3c-sgml-wg@w3.org Date: Thu, 13 Feb 1997 13:03:59 -0600 (CST) > > I suspect Dan would argue with that proposition; I'm fairly sure TBL would > if pinned down. Nobody on W3C staff said a kind word for XML when I and > others brought it up. XML was not given air time; or rather it was listed > on the agenda but time ran out during the final "quiz the staff" session. > > I hope next year someone from the SGML ERB will be given an hour to present > the glowing success story. But we'll have to get XML far up the pipeline in > the W3C process for that to happen; that pipeline is clogged, and if XML > doesn't burst loose in Santa Clara it might not get another chance this > year. (I wish I could be there.) > In addition, has anyone noticed that XML *doesn't* show up on the main web document at http://www.w3.org. You have to dig down in the SGML link to find XML. It would be a great benefit to have an XML link since we do have a 1.0 *standard*. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 19:33:41 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? >Having written this, I'm beginning to discover a new hard-minimalist >enclave I can gleefully retreat into; why not always do it via GI? That >question is not rhetorical; perhaps someone can explain the downside to >this, and the upside to supporting AF-like attribute signalling? The downside is that I can't retrofit any of my existing DTDs with XML links. For example, how do I say that is a valid XML embedded link? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 11:56:21 -0800 (PST) From: Bill Smith Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? To: w3c-sgml-wg@w3.org Murray Altheim wrote: > > There might be an XML application that uses the XML GI: > > > > which could be equivalent to an XML-ized HTML: > > > > This seems to be the "why have one way to do something when two ways will do". We shouldn't fall into this trap if we want XML to be accepted at places like W3C. Let's pick one syntax that is easy to understand and easy to implement. Ultimate flexibility leads to ultimate confusion. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 17:15:44 -0400 To: Bill Smith From: murray@spyglass.com (Murray Altheim) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Cc: w3c-sgml-wg@w3.org Bill Smith writes: >Murray Altheim wrote: >> >> There might be an XML application that uses the XML GI: >> >> >> >> which could be equivalent to an XML-ized HTML: >> >> >> >This seems to be the "why have one way to do something when two ways will >do". We shouldn't fall into this trap if we want XML to be accepted at >places like W3C. > >Let's pick one syntax that is easy to understand and easy to implement. >>Ultimate flexibility leads to ultimate confusion. Flexibility in a meta-language is an important ingredient for success. The two methods described perorm the same function, but are used for different purposes. The first example allows a designer to create an new SGML application. The second allows legacy applications like DocBook or HTML to be retrofitted with architectural form attributes to be used within an XML processing system. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 16:09: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: 2.1 a-d: Link Recognition by Reserved Attribute? [Tim Bray:] | Having written this, I'm beginning to discover a new hard-minimalist | enclave I can gleefully retreat into; why not always do it via GI? | That question is not rhetorical; perhaps someone can explain the | downside to this, and the upside to supporting AF-like attribute | signalling? (All Tim has to do is to label his position "hard minimalist" and I'm automatically for it...) I don't know how this discussion is going to turn out, but to me the burden of proof falls very strongly on the people who want to have multiple mechanisms to accomplish the same thing. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 16:22:10 -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: 2.1 a-d: Link Recognition by Reserved Attribute? [Murray Altheim:] | The two methods described perorm the same function, but are used for | different purposes. The first example allows a designer to create an | new SGML application. The second allows legacy applications like | DocBook or HTML to be retrofitted with architectural form attributes | to be used within an XML processing system. Now I'm hearing arguments in favor of using the attribute method. I'm not hearing anything about why we need both methods. Either the attribute method works or it doesn't; if it does, why do we need both? Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Thu, 13 Feb 97 22:40:42 GMT To: Liora@the-word-electric.com Subject: Re: If no new syntax, and no API, then what are we doing here . . . Cc: w3c-sgml-wg@w3.org Liora writes: > I can't find the graphic that > diagrams link parts and terms or a link to the graphic in the 1.02 Partial > Revision. In the first version it was inline, correct? Aw, *$*#, I blew it as I ran out the door. Fixed now. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 19:24:06 -0600 From: len bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Jon Bosak wrote: > > [Murray Altheim:] > > | The two methods described perorm the same function, but are used for > | different purposes. The first example allows a designer to create an > | new SGML application. The second allows legacy applications like > | DocBook or HTML to be retrofitted with architectural form attributes > | to be used within an XML processing system. > > Now I'm hearing arguments in favor of using the attribute method. I'm > not hearing anything about why we need both methods. Either the > attribute method works or it doesn't; if it does, why do we need both? you don't need both. attributes work fine. you will get both because common practice is to use the GI. It if inflexible unless one starts . appending in the GI. has anyone considered what happens when several arch forms must be applied to the same element type? For example, a community wants to use the XML type for a link, but specialize it further with arch forms only a set particular to a community shares? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 13 Feb 1997 21:34:56 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? At 07:24 PM 2/13/97 -0600, len bullard wrote: ... >has anyone considered what happens when several arch forms >must be applied to the same element type? For example, >a community wants to use the XML type for a link, but >specialize it further with arch forms only a set >particular to a community shares? We've discussed it a bit in Davenport. One idea was to add an empty placeholder parameter entity called something like "morph.elemname.attrib" to each ATTLIST, so that you could provide different modules containing non-empty morph.xxx.attrib definitions that map your elements to different AFs. You'd especially need this where LINK isn't available, but some of us found it an appealing idea regardless. (We decided not to adopt it for DocBook.) Eve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Christopher R. Maden" Date: Fri, 14 Feb 1997 14:34:41 GMT To: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? If there is to be a single mechanism, I strongly feel that it should be an indirect one; whether attributes, PIs, or arch forms, I'm not sure. My reason is that XML is supposed to be a *semantic* markup language. Both explanatory footnotes and bibliographic references could be the same species of hyperlink, but I want to mark them up differently, since they *are* different things. However, if an implementor is implementing this, would it really be hard for them to treat a GI that is identical to one of the known attribute values as equivalent to specifying that attribute value? -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: Fri, 14 Feb 1997 09:07:14 -0600 From: len bullard To: "Eve L. Maler" CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Eve L. Maler wrote: > > At 07:24 PM 2/13/97 -0600, len bullard wrote: > ... > >has anyone considered what happens when several arch forms > >must be applied to the same element type? For example, > >a community wants to use the XML type for a link, but > >specialize it further with arch forms only a set > >particular to a community shares? > > We've discussed it a bit in Davenport. One idea was to add an empty > placeholder parameter entity called something like "morph.elemname.attrib" > to each ATTLIST, so that you could provide different modules containing > non-empty morph.xxx.attrib definitions that map your elements to different > AFs. You'd especially need this where LINK isn't available, but some of > us found it an appealing idea regardless. (We decided not to adopt it for > DocBook.) Something like this is wanted. We used the hytime method in MID with the fixed attribute to simply point out to the architecture. In simpler SGML terms, that works out to be a parameter entity a la MIL-PRF-87269. It seems we should provide a recommended method. In practice, as Tim Bray points out, the minimalist position is a tag bag (sort of the data dictionary or tag registry concept). AFs appear to bridge the class(oop)/element type distinctions. That is, it is possible to have several levels of inheritance. My question is, if none of these levels contribute values (e.g., abstract), then is is necessary to define them, or to get behavioral interoperability, is it only necessary (say via the PI) to indicate that this is what is needed, in effect saying, these are the architectures/classes that should be supported? I'm unclear what requirements we are trying to meet. A class enables inheritance of data types and behaviors. If we use the PI plus element markers (attributes will be better I think), then we can define behavior axiomatically and ensure that the XML element types only define exposed public property values. Make sense? Sitting here with a dreadful cold and medicated, so... len len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 09:19:17 -0600 From: len bullard To: Martin Bryan CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Martin Bryan wrote: > > At 19:24 13/2/97 -0600, len bullard wrote: > > >has anyone considered what happens when several arch forms > >must be applied to the same element type? For example, > >a community wants to use the XML type for a link, but > >specialize it further with arch forms only a set > >particular to a community shares? > > The Architectural Forms Definitions Requirement section of the Extended SGML > Facilities annex to HyTime will cover this is great detail. It provides all > the mechanisms you need to differentiate between multiple architectures > associated with an element. Yes. Then the answer to "should we describe arch forms if used" would be, "No. Reference ISO 10744". len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 10:33:55 -0400 To: bosak@atlantic-83.eng.sun.com (Jon Bosak) From: murray@spyglass.com (Murray Altheim) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Cc: w3c-sgml-wg@w3.org bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: >[Murray Altheim:] > >| The two methods described perorm the same function, but are used for >| different purposes. The first example allows a designer to create an >| new SGML application. The second allows legacy applications like >| DocBook or HTML to be retrofitted with architectural form attributes >| to be used within an XML processing system. > >Now I'm hearing arguments in favor of using the attribute method. I'm >not hearing anything about why we need both methods. Either the >attribute method works or it doesn't; if it does, why do we need both? Well, I'm certainly an advocate for attributes, but I can imagine a family of SGML applications that conform to XML, ok, a family of XML applications. Within each, the hypertext mechanism could certainly be handled by AF attribute, but my little imagination is thinking of users whose understanding is that the base functionality of an element comes by way of its GI, not via its attributes. It's a bit of a stretch for some people to think you could transform important text to hypertext by adding something akin to important text It's an appealing idea (on cursory examination at least), but probably confusing to the unwashed masses(tm). We certainly don't want AF understanding to be a requirement for XML use, and while a simple explanation might suffice, it seems that simply stating that *one* method of providing hypertext markup would be to use the or elements (or whatever they end up being named). Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 09:41:34 -0600 From: len bullard To: Murray Altheim CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Murray Altheim wrote: > > bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: > >[Murray Altheim:] > > > >| The two methods described perorm the same function, but are used for > >| different purposes. The first example allows a designer to create an > >| new SGML application. The second allows legacy applications like > >| DocBook or HTML to be retrofitted with architectural form attributes > >| to be used within an XML processing system. > > > >Now I'm hearing arguments in favor of using the attribute method. I'm > >not hearing anything about why we need both methods. Either the > >attribute method works or it doesn't; if it does, why do we need both? > > Well, I'm certainly an advocate for attributes, but I can imagine a family > of SGML applications that conform to XML, ok, a family of XML applications. > Within each, the hypertext mechanism could certainly be handled by AF > attribute, but my little imagination is thinking of users whose > understanding is that the base functionality of an element comes by way of > its GI, not via its attributes. It's a bit of a stretch for some people to > think you could transform > > important text > > to hypertext by adding something akin to > > important text > > It's an appealing idea (on cursory examination at least), but probably > confusing to the unwashed masses(tm). > > We certainly don't want AF understanding to be a requirement for XML use, > and while a simple explanation might suffice, it seems that simply stating > that *one* method of providing hypertext markup would be to use the > or elements (or whatever they end up being > named). It's logical, but my experience is the great unwashed masses don't design DTDs or use arch forms. That argument is overrated. If I have to live with one and only one way of doing it, I prefer to have the GI left to my discretion, and the superclass assignment in the attribute as a silent but helpful partner. After all this talk of extensibility and something more powerful than HTML, I hate to see us return to precisely the same design by giving them a non-extensible set of link types. They don't get the power without the responsbility to learn the technique. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 11:04:37 -0400 To: cbullard@hiwaay.net From: murray@spyglass.com (Murray Altheim) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Cc: w3c-sgml-wg@w3.org cbullard@hiwaay.net writes: >Murray Altheim wrote: >> We certainly don't want AF understanding to be a requirement for XML use, >> and while a simple explanation might suffice, it seems that simply stating >> that *one* method of providing hypertext markup would be to use the >> or elements (or whatever they end up being >> named). > >It's logical, but my experience is the great unwashed masses don't >design DTDs or use arch forms. That argument is overrated. If >I have to live with one and only one way of doing it, I prefer >to have the GI left to my discretion, and the superclass assignment >in the attribute as a silent but helpful partner. After all >this talk of extensibility and something more powerful than >HTML, I hate to see us return to precisely the same design by >giving them a non-extensible set of link types. I don't assume that people will hand-code a DTD, but I could see a Microsoft Word-like application that builds its document storage model on a base DTD and stylesheet that the user unknowingly modifies as the document outline and styles are filled in. Tens of thousands of DTDs every day. XML applications may also be developed to fill niche roles in various industries, with the idea that interoperability is gained by using a commonly-available XML browser. CML might just be the first of many industries that would want to take advantage of a simplified, custom markup. Not thousands of DTDs, maybe a stable dozen. But browser vendors (and I'm guessing average users) would much better understand a common GI, with an option to use an attribute left to others. As I mentioned, I'm much more an advocate of using attributes, but a stable, understood GI might be a choice *some* people would prefer. Netscape, forinstance. >They don't get the power without the responsibility to learn >the technique. Whoa. You obviously don't work in marketing. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 14:26:05 +0000 To: w3c-sgml-wg@w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? [Tim Bray] > >Having written this, I'm beginning to discover a new hard-minimalist >enclave I can gleefully retreat into; why not always do it via GI? That >question is not rhetorical; perhaps someone can explain the downside to >this, and the upside to supporting AF-like attribute signalling? > Although I am a fully paid up minimalist I think we need both reserved attribute and reserved GI for XML-Link. The reason I think we nned both is in order to allow elements to participate in *multiple* architectures. Who knows what cool architectures might come along to do with XML search classification, agents etc. Regards, Sean Mc Grath %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 13:07:33 +0000 To: cbullard@hiwaay.net, Jon Bosak From: Martin Bryan Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Cc: w3c-sgml-wg@w3.org At 19:24 13/2/97 -0600, len bullard wrote: >has anyone considered what happens when several arch forms >must be applied to the same element type? For example, >a community wants to use the XML type for a link, but >specialize it further with arch forms only a set >particular to a community shares? The Architectural Forms Definitions Requirement section of the Extended SGML Facilities annex to HyTime will cover this is great detail. It provides all the mechanisms you need to differentiate between multiple architectures associated with an element. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 11:20:43 -0600 From: len bullard To: Murray Altheim Cc: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Murray Altheim wrote: > > >It's logical, but my experience is the great unwashed masses don't > >design DTDs or use arch forms. That argument is overrated. If > >I have to live with one and only one way of doing it, I prefer > >to have the GI left to my discretion, and the superclass assignment > >in the attribute as a silent but helpful partner. After all > >this talk of extensibility and something more powerful than > >HTML, I hate to see us return to precisely the same design by > >giving them a non-extensible set of link types. > > I don't assume that people will hand-code a DTD, but I could see a > Microsoft Word-like application that builds its document storage model on a > base DTD and stylesheet that the user unknowingly modifies as the document > outline and styles are filled in. Tens of thousands of DTDs every day. The utility of a DTD is in its ability to provide a validatible agreement. Style should not be filled in to the DTD. Otherwise, use HTML and be done with it. If they want Word, use Word. If they want markup according to a prearranged set of element type definitions, use XML or SGML. Right now, Word does have a base DTD. It is the set of properties that make up RTF, the Para as divider, et al. For XML to be useful, it should act as a recognizable signal in a communications process. That is, send the Request for Information, get Information. Send Request for Quote, get Quote or RFI. It is the ability to pair schema like this that gives XML a utility. As a way of configuring Intranet/Internet enterprise communications where that enterprise is itself classified by either the product or service it provides, XML has utility. As merely a way to export flat files between word processors, RTF is more compact and more efficient. > XML applications may also be developed to fill niche roles in various > industries, with the idea that interoperability is gained by using a > commonly-available XML browser. A niche is as wide as its requirement. Interoperability? For that, Word is just as and probably more effective. Buy from Gates and solve the world's interoperability problems. COM/OLE is very good for that. It is only when one wants to be independent of the "commonly-available" browser that markup has utility. Repurposing of information, rehosting of information, archival of information, these are the utilities of generalized markup. Satisfying the architecture of "a common browser" is how HTML works. If we can't do better than that, then XML is a failure and we'd best return to SGML before the XML effort confuses the market to the point of washing their hands of all of us. > CML might just be the first of many > industries that would want to take advantage of a simplified, custom > markup. Not thousands of DTDs, maybe a stable dozen. But browser vendors > (and I'm guessing average users) would much better understand a common GI, > with an option to use an attribute left to others. A community of interest can define a DTD, agree to it, publish it, and use it to establish configured communications. If all we build here is a common set of tags, this is Docbook or 28001. We already have those. We know how to do that now, have done it, and in some cases, had good success. XML as a common tag set is just the CALS registry. > As I mentioned, I'm much more an advocate of using attributes, but a > stable, understood GI might be a choice *some* people would prefer. > Netscape, forinstance. Screw Netscape. They don't want this. We want this. That is why we are doing this day in and out. When Netscape sees a market advantage, they will buy in. If they don't, bully for us. > >They don't get the power without the responsibility to learn > >the technique. > > Whoa. You obviously don't work in marketing. No, I have an honest job. ;-) My boss says that marketing is everyone's job. It is. But selling water by the river takes a mighty persuasive salesman. We have to sell XML to an a customer who already has HTML, knows about SGML, and in some cases prefers SGML. It is the latter cases we can sell to most effectively. I've already received one review from a customer considering that transition. XML: for those who need SGML but can't afford to wait. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 14:03:45 +0000 To: "Steven J. DeRose" , bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 1.5: Discuss link characteristics? Cc: bosak@atlantic-83.eng.sun.com At 15:50 11/2/97 -0500, Steven J. DeRose wrote: >On the other hand, Martin wrote a distinction between behavior and >presentation that I think wrongly conflates two axes: > > 1) user vs. author control, and > > 2) geometric layour versus what happens on mouse-click I was not trying to make a case for user control v author control per se, only using that idea to make a plea for not putting all of the control into a single object that replaces the style-sheet. What I _was_ trying to make a distinction between was what could be done at the client and what had to be done through interaction with the server. I agree that there a multiple axes, including time related ones. For example, consider what happens if you call up an image map or a link containing an image to a browser for which automatic image loading has been disabled. For the image map you may need to force the first click call up the image (which may cause the formatting to change on the client), and only let the second click generate the query to send to the server. For the link the first click could either go direct to the linked point or it could call up the image. Behaviour itself is a complex thing. I am currently using this generic term as a place holder for all the things Netscape does with its OnMouseOver, OnClick, OnSubmit... type options, some of which defined client-side behaviour and some of which defined a server-side behaviour and some of which can do both. How we segment this beastie is a problem, but if we mix it up with style sheets we end up with an uncontrollable mush. >You can't completely separate formatting behavior from interaction behavior, >and you sure can't combine those two axes. > >Example: there's a quotation element. I, as a user, may want it: > > * Displayed in a footer or sider pane Formatting dependent on user preference > > * Rendered as an inline block-quotish kind of layout Formatting dependent on user/author preference (You can't choose to inline material that the author has placed elsewhere easily, but an author can say 'this should be displayed in-line') > > * Hidden behind something clickable like an icon or a footnote number, > and displayed on demand. Formatting with behaviour attached > > * Hidden per last point, but in big pink type if I reached it via a link > or type 'criticism' and small green if by a link of type 'support'. Formatting with behaviour dependent on link type attached > > * flagged for different indexing treatment, or extracted along with all > others of its kind to make a biblio. Behaviour with subsequent formatting. > >Now try to pin down just which of those are presentation and which are >behavior. I've tried:-) > And then convince all the users that they only ever want control >of presentations, and convince all the authors that they only ever want >control of behavior. You can't convince anyone, you can only offer them more than one alternative, and the key thing is where control of the alternatives lies - at the delivery point or the consumer end of the the process. >In *every* presentation, I may want to associate behavior. For example, when >it's inline I may want to be able to click on it anyway, and retrieve the >source being quoted. Or maybe I want my display of the quotation to have a >scrollbar, so without following any link I can just scroll around to see its >original context. Now thats what I call a real neat need, but it is based on the presumption that the quoted text is a transclusion rather than a copy (which would form the traditional type of 'quotation element' referred to above). The rules for transclusions are necessarily behaviour driven rather than formatting driven! >I do not think it is possible to make a *principled* distinction between >formatting behavior and interactive behavior. Agreed. The principled distinction must be between whether control is to be placed with the document delivery server or the document receiving client. However, I don't want to define my interactive behaviour in a style sheet - I need a script element for this. >And they do not correlate >precisely with the entirely separate notion of user vs. author control. If >we conflate those two separate axes, we'll just impose a needless limitation. I agree that we should not coflate the axes, any more than we should conflate the definitions that control the formatting and the interaction. The author/user (or client/server) aspect brings in two points. Firstly you need the ability to cascade both the options. The most important thing about CSS is the C (the SS is a pain!). We need something like C-DSSSL-O and an equivalent C-Interact. For the latter we need a way for servers to send down a pointer to a default behaviour and have users say "replace the default behaviour with this behaviour" (a catalog for Java applets?). If we can then get DSSSL to call applets, and applets to call specific sets of DSSSL-O formatting rules, we will get what is needed. DSSSL-O style sheets cannot provide the behaviour, and applets cannot properly control formatting. There must be an interaction between the two to define all the options you suggest above. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 12 Feb 1997 00:31:44 +0000 (GMT) From: Peter Flynn Subject: Re: XML FAQ Feb 10, 97 06:42:51 pm To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Cc: w3c-sgml-wg@w3.org > Thanks to everyone who contributed to the FAQ and to Peter Flynn for > putting it together. This is going to me a major resource. > > Peter, when do you plan to go public with this? I guess when people agree it's usable enough to start with. Thanks to all those who have been sending in stuff. I guess I'll make the mods next weekend and launch it on an unsuspecting world next Monday unless anyone feels strongly... ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Wed, 12 Feb 97 14:55:57 GMT To: w3c-sgml-wg@w3.org Subject: Winning battles but losing the war Who's supposed to be making our case at the W3C level? I've just seen a lengthy report from a UK representative of last month's W3C meeting, and XML is barely there: 2 one-line mentions in a 10-page report on a 3-day meeting. Numerous questions were raised to which XML is the answer, but apparently no-one gave that answer, e.g. "Some felt that there should be an HTML extension mechanism (similar to PEP for HTTP). Dan Connolly would produce a HTML briefing paper". Why doesn't this say "Dan Connolly pointed out that XML addressed this need directly."? ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Tue, 11 Feb 97 23:00:51 EST To: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: XML catalog draft > IC, thus causing it to "fail". I can't think of > a case where someone who _has_ working public resolution, would prefer to > use the system ID -- andif they did, it seems they could always ensure that > any given public ID (or all) would fail to resolve. Panorama uses SYSTEM in preference to PUBLIC, and I think this is the right behaviour. If you don't want the SYSTEM identifier used, don't give it. What's it for if not to override the PUBLIC resolution? > > "http://www.foo.org/bar/"> > This is an interesting idea. Better to combine them: By the way, you forgot the ? at the end of the PI. So do I. So does everyone else. This syntax won't fly,. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 17:44:32 -0600 From: len bullard To: Peter Flynn CC: w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? Peter Flynn wrote: > > Len writes: > > This is also in accordance with the way most people think about these > > issues. It is my expectation that I can use a button or a hotspot or > > a voice recognition system and still get the same behavior. > > I'm not sure of that, I know a lot of people (complete non-techies) > who expect different behaviors precisely because the modes of > activation are different. True in some cases, but really, very application dependent. When organizing a web page, I can use a form and submit, and a target=, but I get the same result. From the user perspective, you are right. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 17:42:24 -0600 From: len bullard To: "Steven J. DeRose" CC: w3c-sgml-wg@w3.org Subject: Re: 1.5: Discuss link characteristics? Steven J. DeRose wrote: > > I find that tempting, but a bit too strong. There are at least a few cases > where the destination depends on other factors, such as implicit links, > links that depend on user configuration or environment data, etc. Take a > look at any IETM, or any expert-system-assisted maintenance manual, or > anything that supports stretchtext. Right. Depends on the application. The problem of XML link (and every dammed hypertext standard anyone has tried to create to date) is that we can't put a hotspot/clink/meatball (you choose) in running text, expect it to act as a control, look like a bold font, and pretend to be "just another declaration". What I see emerging is that no matter how long you try, there is some overlap in these sets. It is the ecotone that is interesting in any ecology. In the words of Dick Clark, "that's where the action is". Action="gosub" is "pernicious" but action="submit" is somehow Ok? Picking victims again aren't we? One can declare a process, or process a declaration. SGML doesn't care. XML shouldn't either. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 09:58:57 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: XML catalog draft At 02:53 PM 02/11/97 CST, Paul Grosso wrote: >But suppose I have a local copy of the HTML 2.0 DTD (and who wouldn't), >so my local system default catalog has: > > PUBLIC "-//IETF//DTD HTML 2.0//EN" "/home/dtds/html.dtd" > >If you prefer SYSTEM, then there is no way to find the local copy in >favor of the spyglass one (unless the latter fails). > >Suppose I want to avoid the unnecessary http download. Suppose it's >are very big file (not just the HTML 2.0 DTD). Suppose a few years >from now people start charging for accessing files. Suppose I retrieved ... >Public ids aren't just a fallback for broken URLs, they are a very >important way to manage indirection of resource name resolution. I think Paul's exactly right here. PUBLIC identifiers are supposed to abstract away from *one* particular user's environment; that is precisely what allows the two crucial things: * indirected resolution that works for everybody * local override that may happen to be different for the overrider. this may occur because they create a slightly different local version (say, adding archform attributes for ICADD or whatever), or because you sent it to an Orwellian country where MiniTrue must rewrite it, or, most likely of all, simply becaue their directory has a different name than the one on the original author's disk. Those are only a few of the reasons I think PUBLIC should be tried first. But I could live with a system that let you choose (that's where we ended up in SGML Open, after all); that does have the downside that two conforming implementation that are installed in an identical environment and given identical catalogs and other data, can conformingly produce quite different results. That seems bad to me. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 23:07:41 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: Get rid of the leading hyphen! Lines: 38 In message <199702111554.PAA20960@curia.ucc.ie> [... Jon Bosak...] writes: > > >We should get rid of the hyphen in front of XML in reserved names and > > >attributes. > > > > > >"-XML" is ugly, it's hard to type, it looks dumb, and it doesn't > > >really pollute the name space any less than any other reserved string. > > >Reserve "XML" and be done with it. Does this mean (as I infer and hope) that all XML-* (elements starting with 'XML-') are reserved? If so, it should presumably be stated in the XML spec. Otherwise the spec will need to list the (?5) reserved element types. Would it be a reportable error to have other tags starting with 'XML-'? The reason I mention this is that it seems that a managed XML- namespace may be extremely useful. I'm NOT making a proposal, but suggest the following scenario. We shall shortly create the primordial tag-soup where anything goes, but it is possible that order may evolve out of chaos. As an example, I expect lots of authors to create a tag. Its semantics could be formalised (perhaps by using the ISO standard) and XML/W3C might play a role in this. Perhaps it could evolve through (by analogy with unregistered MIME types) to . When discussing how we add semantics to elements, one approach (where appropriate) is to develop a set of such information components. These could be used in WF documents without the need for a DTD, or alternatively could be bolted into individual DTDs without needing to supply explicit semantics. At this stage the question would be whether any/all 'XML-' strings other than those in XML-LINK were reserved, and perhaps whether an XML-X- mechanism was allowed. P. -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Tue, 11 Feb 97 23:11:04 GMT To: w3c-sgml-wg@w3.org Subject: Improved, slightly modified version of my proposed redraft Thanks to Tim for supplying the XML original and the tools to work with it. This URL http://www.cogsci.ed.ac.uk/~ht/new-xhl.html has only my new bits now. I decided Martin was right, and I've gone back to link types and endpoint types. Here's the plain text of the new version, without the pretty picture. ht ------ Abstract Extensible Hyper Linkage (XHL) is a simple set of constructs that may be inserted into SGML documents to describe links between objects. XHL is designed to use the power of SGML to create a structure that can describe both the simple unidirectional links of today's HTML, as well as more sophisticated multi-ended, typed, self-describing links. The SGML constructs used in XHL are simple enough to be available in the Extensible Markup Language (XML) subset of SGML. XHL is completely described in this document. Extensible Hyper Linkage Version 1.01 PARTIAL DRAFT 11 February 1997 1. Introduction Extensible Hyper Linkage (XHL) describes a set of constructs which may be inserted in SGML documents to describe links between objects (the objects may or may not be (in) SGML documents). A link, as the term is used here, is a relationship between two or more data objects or portions of data objects, called its endpoints. Not all relationships are links: the relationship of a chapter to its paragraphs, of one word to the next, or any non-explicit relationship, are not considered links here. The relationship expressed using SGML's id and idref attributes is a link, subsumed within the framework presented here. Links in XHL are described by elements contained in SGML documents. Such an element is called a link description, or linkd. The link description element itself may, but need not, be one of the endpoints of the link it describes. A link description can be understood as a mapping from document instances and their contexts to links. Just as SGML Applications consist of a DTD and a specification of the meaning or significance of the structures defined therein, so an XHL Application must include a specification of the meaning or significance of the link types and endpoint types it employs. 1.1 Origin and Goals XHL is part of the overall XML effort, on which see .... It aims to provide an effective yet compact means for describing links that can have multiple typed endpoints, indirection, and flexible yet precise means for locating endpoints in all kinds of data. It also aims to represent the abstract structure and significance of links, leaving rendering and other issues of link-engendered behaviour to stylesheets or other mechanisms as far as practical (it is acknowledged that there is a grey area here). 1.2 Relationship to Existing Standards Three standards have been especially influential on XHL: 1.HTML: Defines several SGML element types that describe links, as well as popularizing a locator type, the URL, mainly focused on locating entire data objects, though with some provision for linking to elements with IDs, regions in graphics, and so on. 2.HyTime: Defines locator types applicable to all kinds of data, as well as in-line and out-of-line link description elements and some semantic features including traversal control and placement of objects into a display or other space. 3.Text Encoding Initiative: Provides a formal syntax for locators for structured data, graphics, and other data, and elements incorporating these for describing links and collections of links. Many other relevant linking systems have also informed this design, including Dexter, MicroCosm, InterMedia, and others. 1.3 Notation 1.4 Terminology The following basic terms for parts of links and link descriptions apply in this document. They also appear on the following structural diagram of a simple link.
1.5 Types of links Many papers have been written on how to categorize links. The XHL effort distinguishes several major axes for categorization. XHL provides ways to identify a link along each axis, but only provides a standard vocabulary for the first kind of categorization, namely link types. The vocabulary of XHL link types can be extended by creating hierarchies of sub-types. 1.link types: Links express various kinds of relationships between the things they connect, in terms of their role in the defining XML Application. Some links may be criticisms, others add support or background, while others have a very different meaning such as providing access to demographic information about a data object (its author's name, version number, etc), or to navigational tools such as index, glossary, and summary. A link's link type provides a simple hierarchically structured starting point for specifying link semantics. 2.link topology: In-line versus out-of-line links differ in their structure, as do links with varying numbers of endpoints. 3.locator language: Links descriptions may differ in what formal language their locators use to specify endpoints. Different locators in the same link description may use different languages. 2. Link Recognition An XHL Link description element is contained in an SGML document. The fact that an element is a link description must be recognized reliably by software in order to provide appropriate display and behavior. XHL links may be recognized based on the use of specially reserved attributes (as in the example above), the use of specially reserved element types, or through other means not described in this specification. 2.1 Link Description Element Recognition by Attribute A link description element may be recognized based on the value of a reserved attribute named XHL appearing as part of its start tag, either directly in the element itself, or indirectly in the definition of the element type in (the external subset of) the DTD for the document. Possible values are MLINK, TLINK, ELEMENT, XLG, and XLD, signalling in each case that the element may be treated as a link description element of the indicated type, as described in this specification. An example of such a link description element with an explicit attribute: The W3C See the figure above for an example of the approach where the attribute is specified in the DTD. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 16:42:16 -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 catalog draft [Steve DeRose:] | Pearl, Amy. 1989. "Sun's Link Service: A Protocol for Open Linking." | Proceedings of Hypertext 1989. ACM Press, pp. 137-146. Is there something in there we can use, Steve? Jon P.S. Where Are They Now Department: Amy is now in charge of HotJava. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 11 Feb 1997 16:16:51 -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 catalog draft [David Durand:] | Since the new proposal is different from 9401 couldn't we issue it as | the W3C's equivalent of an "experimental RFC". ie. well-defined, a | potential candidate for standardization, but requiring practical | experience before endorsement. That seems to describe DELEGATE to a T. I would favor something like this. An awful lot of good thinking has gone into the proposal. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 12 Feb 1997 00:27:19 +0000 (GMT) From: Peter Flynn Subject: Re: What to do given both SYSTEM and PUBLIC? "Tim Bray" at Feb 11, 97 01:33:59 pm To: w3c-sgml-wg@w3.org Tim Bray writes: > The argument in favor of SYSTEM-first is that this is apt to > be quicker and cheaper (particularly if you assume that a PUBLIC id > usually generates a SYSTEM id). > > The argument in favor of PUBLIC is simpler; it has another level of > indirection, potentially some supporting catalog machinery; in fact, > can be considered to be in some sense of "higher value". > > The argument in favor of saying nothing is that the right thing to do > is [existence proof in the debate here] not crystal-clear and may be > application-dependent. > > Any new arguments? - Tim There's a danger of missing the point on this one: it's not whether you should take PUBLIC first or SYSTEM first, but that having picked one (assuming both were provided), _and failed to resolve it_, the other one ought also to be tried. Too many systems try one, fail to resolve, and just give up without having tried the other one. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Path: usenet From: Dan Connolly Newsgroups: w3c.w3c-sgml-wg Subject: Re: There Are No Metadocuments Date: Tue, 11 Feb 1997 19:51:18 -0400 Lines: 39 NNTP-Posting-Host: beach.w3.org To: Terry Allen Terry Allen wrote: > > These "metadocuments" sound to me exactly like "the real, full > document with all its trimmings." I know SGMLllers are used to thinking > about the marked-up text as distinct from the style sheet, etc., > but for the purposes of publishing that text, the whole ball of > stuff can be considered to be not document+meta, but just > document (including some meta, nothing wrong with that). Yeah verily! This is the "minimally constraining" view -- it allows folks to manage data however they choose -- lump the content and the metadata together, or store them separately and link them. ----------- Axioms of Web Architecture: 2 Tim Berners-Lee Date: Januray 6, 1997 http://www.w3.org/pub/WWW/DesignIssues/Metadata.html Documents, Metadata, and Links The thing which you get when you follow a link, when you de-reference a URI, has a lot of names. Formally we call it a resource. Sometimes it is referred to as a document because many of the things currently on the Web are human readable documents. Sometimes it is referred to as an object when the object is something which is more machine readable in nature or has hidden state. I will use the words document and resource interchangeably in what follows and sometimes may slip into using "object". ----------- See also: http://www.w3.org/pub/WWW/Architecture/Terms#document Dan %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 09:46:41 -0500 To: "Steven J. DeRose" From: Liora Alschuler Subject: Re: 1.4 f: terms for links colocated with their ends Cc: w3c-sgml-wg@w3.org . >>[Liora Alschuler:] >> >>| Is there a reason why we can't just call these "direct" and "indirect" >>| links? >> [Jon Bosak] >>I agree with Liora. These work very well intuitively and are about as >>apropos as anything else that's been suggested. [Steve DeRose] >I disagree on this one; Len said it pretty well: direct and indirect are >more natural terms for a quite different distinction, namely whether >indirection is used in the location specification. "Indirect addressing" is >so well-established a term that I can't imagine re-assigning it to another >use, when we need the equivalent of its standard meaning to. > >I'm also with James in disliking 'contextual'; I don't mind 'independent' >too much; but just 'i' and 'c' doesn't do it for me. > There seems to be no single, descriptive term that encompasses all the qualities of each type of link so I suggest names that emphasize none of the qualities (not, then, in-line or direct or independent). I think that "simple link" and "complex link" would be good, but if shortened into slink and clink, while they have a nice sound, would conflict with HyTime. Maybe "simple" or "basic" as James suggested coupled with "xlink" for the sophisticated, complex types of linking now possible with XML. I think it would be easy to present simple links as what you get now with HTML and XML links as the future made possible by XML applications. Liora ///////////////////////////////////////////////////////// The Word Electric \I sing the body electric I key the word electric\ POB 177, Route 5 / -- Walt -- Liora / E. Thetford, VT 05043 \ or, as Henry Miller said, \ 802/785-2623 /"Anyone can write, but writers can't do anything else."\ \\\\\\\\\\\\liora@the-word-electric.com\\\\\\\\\\\\\\\\\ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? Date: Tue, 11 Feb 1997 20:11:07 -0800 From: Joe English Tim Bray wrote: > Hmm, seems I was right - we do *not* have a consensus on this one. > > The argument in favor of SYSTEM-first is that this is apt to > be quicker and cheaper (particularly if you assume that a PUBLIC id > usually generates a SYSTEM id). That's not what I assumed. I figured that -- for Web applications anyway -- the most sensible resolution strategy for would be something like: 1) See if there's a local catalog entry for the PUBLIC identifier "myname". If so, use it. 2) Otherwise, try to resolve the SYSTEM identifier "oneofmyaddresses" (probably a URL). 3) If this fails, or no SYSTEM ID is supplied, attempt strategy [B] (see below). 4) If this fails, tell the user "Sorry, can't resolve entity FOO. Please try to dig up the entity with PUBLIC ID "myname", add it to your local catalog, and try again." Strategy [B] would initially be a stub routine that always fails. If and when the URN group and/or SGML Open and/or the W3C SGML ERB hammers out the details of how to do automatic FPI/URN resolution, it would do an indirect PUBLIC ID -> SYSTEM ID mapping based on whatever strategy they/we finally come up with. (But quite frankly, I don't expect to see this happening in my lifetime.) I suspect that the heuristic in step (4) would be effective in many cases, since most people who currently publish SGML on the Web tend to put a "Click _here_ to download the DTD and supporting entity sets" link somewhere on their entry page; XML publishers would likely do the same (until of course the URN group/u.s.w./... comes up with a more reliable mechanism, as above), and failing that, there's always comp.text.sgml, Robin Cover's bibliography, InfoSeek, e-mail to webmaster@sun.com asking "Could you send me a copy of '-//SUNSOFT//DTD Yabba Dabba Doo//EN'? I can't find it on your Web page", whatever. In other words, basically the same way public PUBLIC identifiers are used today; I'd be happy with that. But I digress: the point is, I assume that PUBLIC identifier resolution will in fact be *cheaper* than SYSTEM identifier resolution, since typically (for XML anyway) the former will only involve a local catalog lookup whereas the latter will involve a network transaction. --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Kurt Conrad To: "w3c-sgml-wg@w3.org" Subject: RE: What to do given both SYSTEM and PUBLIC? Date: Tue, 11 Feb 1997 17:06:53 -0800 ---------- From: Tim Bray Sent: Tuesday, February 11, 1997 1:33 PM To: w3c-sgml-wg@w3.org Subject: What to do given both SYSTEM and PUBLIC? At 02:53 PM 2/11/97 CST, Paul Grosso wrote: >> From: murray@spyglass.com (Murray Altheim) >> dgd@cs.bu.edu (David Durand) writes: Hmm, seems I was right - we do *not* have a consensus on this one. I lean towards giving the public identifier precedence. The knee-jerk argument is "why bother" with public identifiers if the = system IDs take precedence. If I can't rely on the catalogs that I = create, why should I invest the effort to maintain them. This would be = especially true in an organizational setting, where such catalogs are = increasingly likely to be managed as shared resources to improve = consistency across a collection of documents. If as a publisher, I = don't want the 'standard' component, I should not code a reference to it. Another argument is that public identifiers should be given precedence, = not just to support server-based catalogs, but to support client-side = catalogs. It is these local catalogs, in fact, which should be given = highest precedence to allow entities, DTDs, style specifications, etc. = to be stored locally 1) to cut down on network traffic and/or 2) to = support local customizations. Expanding the precedence to three layers raises additional issues about = managing multiple, possibly conflicting versions of a file, but as long = as the rules of precedence are clearly spelled out, I believe that the = problem is small, compared to the potential benefits from enhanced = flexibility. This approach would give both publishers and recipients a number of = options: - The simplest system is to use system identifiers with the absolute = control that they bring. - Next would be to use a server-based catalog. By doing so, the = publisher gains the power of a level of indirection, but also assumes = additional responsibility. - Finally, if I decide to create a client-side catalog, I have assumed = responsibility for managing it and accept the risks associated with it. In effect, this approach 'layers' the more powerful methods around the = simpler making them (and the risks that they bring) optional. But for = the choices to be meaningful, the system has to enforce these choices = through precedence. >From this perspective, the idea that system behavior should be = application-dependent scares me. It means that as a publisher, I can't = put confidence in my decision to use catalogs. Likewise, if I have a = concern about mismatched public and system identifiers, I can evaluate = and test them as part of the publishing process, using whatever = evaluation method I deem appropriate (e.g., location, time and date, = byte-level comparisons, logical comparisons, etc.). As a publisher, I am = in a much better position to resolve the conflict than a piece of = software running on some client. >From the standpoint of a recipient, I could see value in having a way to = determine that my local catalog file is 'overriding' the choices of a = publisher, but again, the responsibility is mine if I choose to use = client-side catalogs. /s/ kwc 2/11/97 17:06 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lex@www.copsol.com (Alex Milowski) Subject: Re: XML process modelling [was No Metadocuments] To: w3c-sgml-wg@w3.org Date: Tue, 11 Feb 1997 18:27:04 -0600 (CST) My stuff: > | Here is, again, my opinion: > | > | 1. The "Minimal-constructs-to-declare-success" is some kind of SO-catalog model. > | It has its drawbacks which was well pointed out. > | > | 2. The uniform and scalable infrastructure is a metadocument architecture or > | whatever you want to call it--a bootstrapping document that starts the > | whole process off. This is more complex and, to some extent, will require > | rejecting the premise that XML must be kept as simple to implement > | quickly. Terry Allen wrote: > This is argument by assertion. Let's begin at the beginning (where it would > have been useful to start last year). Who's on first? > > I imagine that an XML pile-o'-stuff is first requested not by an XML > "processor" but by an app. One scenario runs thusly: > > - App sends URL to URL-handling engine > > - URL-handling engine tickles the HTTP client to send a GET > > - Server responds by sending XML pile-o'-stuff, which can range > from a single XML file (with pointers to other needful entities) > to a complete set of entities, DTDs, and the like > > - This pile-o'-stuff is routed to the MIME unpacker (if need be) > or to the app that requested it. If to the MIME unpacker, then > the unpacker and the app probably need to communicate with each > other. pile-o'-stuff gets unpacked suitably > > - App sends appropriate pieces of pile-o'-stuff to the XML parser > (processor), possibly in a complex interaction > > - Parser returns parsed XML (for which there is, amazingly, > no API specified) to the app, which may need to go back to > square 1 to obtain additional info that wasn't included in > the pile-o'-stuff > > - Eventually the app is happy and does something with the > parsed XML that either the author or the user or the parser > or the app or some combination decides is the Right Thang. > > Now where in this scenario do you want to use 1) catalogues > and, or, 2) bootstrapping documents, and what is more complex > about 2 than 1? Have I left out some steps? > Well, yes and no. What I am trying to differentiate is deliver of documents >from document applications. There is one level of target applications that *only* need to be told where to get the data and the respective components. For example, an XML browser needs the XML document, the respective entities, and a style-sheet--others need more. What if I view an XML application as a framework of services. This model is already prevalent in the web today. Currently, I can do the following: * Render information in HTML * Display "applets" in java. * Send data to plugins. What if I view each of these as a set of client side services (or as a server in the X11 model) and state that I want to deliver XML documents, DSSSL stylesheets, DSSSL transformation, etc. as data and a description--the metadocument in my model--of how these things go together. In this model, retrieval of the components (entities) of any particular XML document is only part of the problem. I am beginning to think that I am talking about a layered application standard rather than something directly related to the *XML* standard. There is no reason why we couldn't come up with a layer standard that allows us to transmit more complex document applications and, on the way, solve some of the more problematic things like "where is my catalog anyway?". The big benefit of the metadocument approach for entity resolution is that there is only one way of getting configuration and instruction information rather than having catalogs for one thing and something else for the rest. One of the things I would really like to see out of an XML environment on the web is the ability to deliver complex document applications to arbitrary XML client environments. Catalogs alone won't do this.... but maybe this "want" has little to do with catalogs and more to do with a client application profile. The problem I'm having with catalogs is that you have to start adding in all kinds of other "things" to allow a browser to operate intelligently. Things like: "a list of style sheet options", auto-table-of-contents-stuff, etc. The object-purist in me raises a red flag as says that we are designing to the specific case. On the other hand, XML is not just for browsing across the web. We need to cleanly solve both situations. Do we want to parse documents or define application frameworks? That is my question. The latter will happen regardless of the standards we produce. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 12 Feb 1997 11:47:58 -0500 To: "Henry S. Thompson" From: Murray Maloney Subject: Re: Winning battles but losing the war Cc: w3c-sgml-wg@w3.org I attended that meeting and tried to put in a plug for XML whenever I could. The W3C folks tried hard to downplay SGML and XML, but they did not manage to keep me quiet. It seems clear that they consider XML a bit of a threat and are trying to minimize its role. The best way that we can overcome that is to demonstrate the uefulness and practicality of XML as compared to HTML. Interest in growing, but it will take time and demonstrable software to sway more people to our side. I expect to be atending the next AC meeting on June 17/18. Having software to demonstrate at that meeting would be a big help in pushing XML higher up on the agenda for the consortium. Murray At 02:55 PM 12-02-97 GMT, Henry S. Thompson wrote: >Who's supposed to be making our case at the W3C level? I've just seen >a lengthy report from a UK representative of last month's W3C meeting, >and XML is barely there: 2 one-line mentions in a 10-page report on a >3-day meeting. Numerous questions were raised to which XML is the >answer, but apparently no-one gave that answer, e.g. > > "Some felt that there should be an HTML extension mechanism (similar > to PEP for HTTP). Dan Connolly would produce a HTML briefing paper". > >Why doesn't this say "Dan Connolly pointed out that XML addressed this >need directly."? > >ht > > > Murray Maloney Technical Director SoftQuad Inc. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg