From jjc at jclark.com Wed Apr 2 18:32:31 1997 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 16:57:39 2004 Subject: SP with XML support available Message-ID: <2.2.32.19970402161947.00aa8e40@jclark.com> I've made a new version of SP available as part of the latest Jade snapshot at ftp://ftp.jclark.com/pub/test/jade.zip. I've only compiled this on Windows. If you try compiling this on Unix, please let me know whether it works, and if not what the problems are. SP now supports DTD-less parsing. In particular you should now be able to parse well-formed (but invalid) XML documents. You must of course use an appropriate SGML declaration (I've included one in the distribution). Some XML features that are incompatible with SGML (without the proposed SGML TC) are not supported, notably hex character references. Use -wno-valid to turn off validation. James xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From bosak at atlantic-83.Eng.Sun.COM Wed Apr 2 22:24:42 1997 From: bosak at atlantic-83.Eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 16:57:39 2004 Subject: WD-xml-lang-970331 available Message-ID: <199704022023.MAA06326@boethius.eng.sun.com> The first revision of the XML spec since November is now available at http://www.textuality.com/sgml-erb/WD-xml-lang.html The revision has been submitted to the W3C and is expected to become available from there within the next 24 hours. (The W3C site in Cambridge is experiencing a number of problems due to the weather.) Jon xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From bosak at atlantic-83.Eng.Sun.COM Wed Apr 2 22:26:16 1997 From: bosak at atlantic-83.Eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 16:57:39 2004 Subject: PS, RTF versions of WD-xml-lang-970331 Message-ID: <199704022024.MAA06328@boethius.eng.sun.com> PostScript and RTF versions of the revised xml-lang spec are available from http://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml-lang.ps.gz http://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml-lang.ps.zip http://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml-lang.rtf.gz http://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml-lang.rtf.zip Note that the RTF version was created simply as an intermediate file in the production of the PostScript version. It is provided for the convenience of those wishing to use an RTF viewer, but the quality of display will vary depending on the page settings. Jon xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Ingo.Macherius at tu-clausthal.de Thu Apr 3 11:05:46 1997 From: Ingo.Macherius at tu-clausthal.de (Ingo Macherius) Date: Mon Jun 7 16:57:39 2004 Subject: MBone In-Reply-To: <4715@ursus.demon.co.uk> from "Peter Murray-Rust" at Mar 16, 97 09:55:46 am Message-ID: <199704030905.LAA00491@kneipfix.rz.tu-clausthal.de> > > I don't have the opportunity to go to WWW6, but luckily I have MBone > > connection and see there are four channels prepared. > If you get information, Ingo, it would be useful to post it here, along > with any other necessary information for connection. Any feedback from > the meeting would be useful. Using the WWW6 ICE engine I found these three XML events for WWW6: 4/7/97 9:00 am XML: Where Do We Go From Here? (Workshop) Jon Bosak 4/7/97 2:00 pm Enriching Document Structure: HTML, CSS, and XML (half-day Tutorial) Tim Bray/Lauren Wood 4/11/97 11:00 am Structured Documents -- Technical Bootstrap on Structured Documents: HTML, SGML, CSS, DSSSL, XML (Presentation DevDay) Jon Bosak/Dan Connolly I was not able to find out, if all/any are broadcast via Mbone. The WWW6 Mbone page came to live just today. See http://volunteers.www6conf.org/www6conf/mbone6/welcome.html The problems with bandwith for Germany were solved by a new 2MBit/s tunnel yesterday. It would be great if someone of the "physical present" would try to have the XML sessions broadcast. Any information would be appreciated. ++im -- Snail : Ingo Macherius // L'Aigler Platz 4 // D-38678 Clausthal-Zellerfeld Mail : Ingo.Macherius@tu-clausthal.de WWW: http://www.tu-clausthal.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Frank Zappa) xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Ingo.Macherius at tu-clausthal.de Mon Apr 7 00:39:24 1997 From: Ingo.Macherius at tu-clausthal.de (Ingo Macherius) Date: Mon Jun 7 16:57:39 2004 Subject: Comment delimiter (was: Entity replacement) In-Reply-To: <01BC3DB9.21A3AC70@sqruffy.west.sq.com> from "David Seibert" at Mar 31, 97 09:51:39 am Message-ID: <199704062239.AAA01307@kneipfix.rz.tu-clausthal.de> In this list the terminals for ending and beginning comments are mentioned as "<--*" and "*-->" several times, e.g. in the one this reply is based on: > 1) PEs aren't supposed to be recognized inside comments (nothing is except the > terminal '*-->'), so they aren't supposed to be expanded. In both WD-XML drafts a comment is declared without the "*" star, so are the examples given (Clause [17] (9700331) and [21] (961114)). Could someone of the knowing kind explicitly confirm the draft ? ++im -- Snail : Ingo Macherius // L'Aigler Platz 4 // D-38678 Clausthal-Zellerfeld Mail : Ingo.Macherius@tu-clausthal.de WWW: http://www.tu-clausthal.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Frank Zappa) xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Mon Apr 7 17:54:24 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:39 2004 Subject: Comment delimiter (was: Entity replacement) Message-ID: <5468@ursus.demon.co.uk> I can only give a second-hand version of the status of the drafts, but hope this helps xml-dev'ers. (Most of the ERB are busy with the WWW6 conference - I'm sure that some will amplify or correct stuff here). The drafts are produced by the Editorial Review Board at regular intervals for discussion. It is stressed strongly that these are subject to frequent change, and this is especially true in the XML process. So, at the fundamental level, nothing is 'definite' :-) - [but that doesn't mean that development can't take place.] There is a list - XML-WG - on which invited members make comments on the drafts, sometimes in response to the draft, sometimes in anticipation. The ERB reads this discussion carefully and takes it into consideration in producing drafts. However nothing in the discussion - even if apparently generally accepted - is guaranteed to form part of the next draft. The ERB votes on what should and shouldn't go in the drafts and the voting is recorded in the XML-WG mail. WWW6 forms a special milestone for the ERB and ERB members have been printing the drafts for the meeting. I hope that they will give some sort of report after WWW6 which will update us. In message <199704062239.AAA01307@kneipfix.rz.tu-clausthal.de> Ingo Macherius writes: > > In this list the terminals for ending and beginning comments are mentioned > as "<--*" and "*-->" several times, e.g. in the one this reply is based on: > > > 1) PEs aren't supposed to be recognized inside comments (nothing is except the > > terminal '*-->'), so they aren't supposed to be expanded. > > In both WD-XML drafts a comment is declared without the "*" star, so are > the examples given (Clause [17] (9700331) and [21] (961114)). > Could someone of the knowing kind explicitly confirm the draft ? I haven't been involved in XML-WG from the but when I joined (Jan) comments were , then they changed to and now they have changed back. But note that there is a difference from SGML in that -- ... -- is not allowed inside comments. As a general point I feel that the current XML draft is sufficiently close to what the final outcome will be that it's worth developing applications (including documents) in it. Since any XML document is also an SGML document it should be fairly straightforward to retransform them if there are minor changes to XML. Of course this is only my personal opinion and I don't at present have customers who will lose faith if the spec is promoted too early and then changed. XML-LANG (the draft you are referring to) has gone through several revisions and IMO the recent changes have been mainly tidying up rather than fundamental. A lot of work has gone into clarifying areas where interpretations can differ (e.g. 4.4 Treatment of entities). We should realise that some apparently minor changes (e.g. the introduction of PUBLIC) may have large consequences and this is an area that the ERB had to take a view on. (There was a *lot* of discussion about PUBLIC on the WG). The ERB has to balance many things including compatibility, interoperability, ease/possibility of implementation, ease of learning, uniqueness of interpretation, acceptability in the market, etc. The next draft of XML-LINK has also been prepared for the WWW6 and will no doubt be announced here when it's formally public. P. BTW. the fact that xml-dev is not very busy at present doesn't mean that nobody's doing anything :-) - in fact the reverse. There are about 10 demos scheduled for WWW6 and I know that most of the major contributors here (including me) have been getting something together to present. I think after this milestone, then some goals will be clearer and there will be time to address the next stage. Finally I should like to congratulate the members of the ERB in having managed this process so fast and with so much harmonisation. I am sure that contributors here have helped, in that a language is not much use if it cannot be implemented or is flawed, and some important issues have been thrashed out here. And don't be afraid to post - a lot of people read this list. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From bosak at atlantic-83.Eng.Sun.COM Tue Apr 8 07:57:48 1997 From: bosak at atlantic-83.Eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 16:57:39 2004 Subject: WD-xml-lang-970331 Message-ID: <199704080556.WAA11996@boethius.eng.sun.com> [This went out to a couple of newsgroups yesterday.] Subject: Extensible Markup Language (XML) XML is a new language for advanced Web applications proposed by a working group of the World Wide Web Consortium (W3C). A revised working draft of the XML syntax specification is now available at http://www.w3.org/pub/WWW/TR/WD-xml-lang-970331.html This draft replaces the previous one dated November 14, 1996. PostScript and RTF versions of the new draft are available at: http://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml-lang.ps.gz http://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml-lang.ps.zip http://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml-lang.rtf.gz http://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml-lang.rtf.zip BACKGROUND Extensible Markup Language (XML) is a standardized text format specially designed for transmitting structured data to Web applications. The new language addresses the needs of Web publishers who encounter limitations in the ability of HTML to express structured data. XML differs from HTML in three basic ways: 1. Information providers can define new tag and attribute names at will. 2. Document structures can be nested to any level of complexity. 3. Any XML document can contain an optional description of its grammar for use by applications that need to perform structural validation. XML has been designed for maximum expressive power, maximum ease of implementation, and maximum teachability. The XML character set is Unicode. XML is not backward-compatible with existing HTML documents, but documents conforming to the W3C HTML 3.2 specification can easily be converted to XML, as can documents conforming to ISO 8879 (SGML) and documents generated from databases. XML is not designed to be a replacement for HTML. It is designed to complement HTML by enabling a different kind of data to be exchanged over the Web. The current draft only addresses syntax, and consequently XML alone can at present only be used for interprocess communication and for the delivery of documents to specialized applications (or plug-ins) that have been configured to interpret a particular XML grammar. The first draft of a companion specification for hypertext linking between XML documents is scheduled for release April 9 at the Sixth World Wide Web Conference. ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems 2550 Garcia Ave., MPK17-101, Mountain View, California 94043 Davenport Group::SGML Open::NCITS V1::ISO/IEC JTC1/SC18/WG8::W3C XML ---------------------------------------------------------------------- xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From n.bradley at pindar.co.uk Tue Apr 8 09:43:18 1997 From: n.bradley at pindar.co.uk (Neil Bradley) Date: Mon Jun 7 16:57:39 2004 Subject: various issues Message-ID: 1. Is there a list of changes between XML language specs, to save me comparing them in detail? 2. Do others agree that there should be recommended models for representing complex structures such as tables and mathematical formulae, even if this just means referring to an existing standard, such as CALS tables or HTML tables, and ISO 12083 math? At this early stage it would be great if potential XML software developers had a common goal, that would ultimately benefit users of XML. 3. Will CSS1 be likely to be considered an official style sheet format for use with XML? Neil. _________________________________________________________ Neil Bradley, SGML Consultant, Pindar plc Author of "The Concise SGML Companion" Addison-Wesley Longman (ISBN: 0-201-41999-8) The third-rate mind thinks with the majority; the second-rate mind thinks with the minority; the first-rate mind is only happy thinking (A. A. Milne) Tel: +44 (0)1904 613040 EMail: n.bradley@pindar.co.uk Fax: +44 (0)1904 613110 URL: http://www.pindar.co.uk _________________________________________________________ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From tbray at textuality.com Tue Apr 8 19:13:44 1997 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 16:57:39 2004 Subject: various issues Message-ID: <3.0.32.19970408095211.00b2edc0@pop.intergate.bc.ca> At 08:41 AM 08/04/97 +0000, Neil Bradley wrote: >1. Is there a list of changes between XML language specs, to save me >comparing them in detail? No. Sorry. >2. Do others agree that there should be recommended models for representing >complex structures such as tables and mathematical formulae, even if this >just means referring to an existing standard, such as CALS tables or HTML >tables, and ISO 12083 math? At this early stage it would be great if >potential XML software developers had a common goal, that would ultimately >benefit users of XML. Not as part of the XML language spec. This might be a good ancillary activity for somebody. Our bandwidth is fully occupied just getting the language right. >3. Will CSS1 be likely to be considered an official style sheet format for >use with XML? Undetermined. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Tue Apr 8 19:41:00 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:40 2004 Subject: various issues In-Reply-To: <3.0.32.19970408095211.00b2edc0@pop.intergate.bc.ca> References: <3.0.32.19970408095211.00b2edc0@pop.intergate.bc.ca> Message-ID: <199704081739.NAA00223@localhost> Tim Bray writes: > > 3. Will CSS1 be likely to be considered an official style sheet > > format for use with XML? > Undetermined. This may be determined by the implementors, one way or another, before Tim and his colleagues get to it. Right now, I think that things might lean a little more towards DSSSL-online, simply because almost all XML-related software (real or promised) is Java-based, and there is already a Scheme interpreter for Java. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From trafford at sq.com Tue Apr 8 20:12:25 1997 From: trafford at sq.com (Ben Trafford) Date: Mon Jun 7 16:57:40 2004 Subject: various issues Message-ID: On Tue, 08 Apr 1997 10:00:05 -0700 Tim Bray wrote: > >3. Will CSS1 be likely to be considered an official style sheet format for > >use with XML? > > Undetermined. There's been some talk on the DSSSL list about the coordination of DSSSL with XML. Is this anything the ERB has been discussing? Does anyone have any input on the implementation of style sheets with XML? I've seen some discussion, but not very much in terms of a fleshed-out idea. ---------------------- Ben Trafford trafford@sq.com SoftQuad Inc. xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From cbullard at hiwaay.net Wed Apr 9 01:43:41 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:40 2004 Subject: Netscape XML story References: <2.2.32.19970408043654.00701cb4@sover.net> Message-ID: <334AD560.27B@hiwaay.net> Liora Alschuler wrote: > > Follow news summary link at http://www.webweek.com or go directly to: > > http://www.webweek.com/current/news/warms.html Congratulations one and all! They've decided not to bleed to death after all. len bullard xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From bosak at atlantic-83.Eng.Sun.COM Wed Apr 9 18:38:15 1997 From: bosak at atlantic-83.Eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 16:57:40 2004 Subject: various issues In-Reply-To: (message from Ben Trafford on Tue, 8 Apr 1997 14:10:02 -0400 (EDT)) Message-ID: <199704091636.JAA01038@boethius.eng.sun.com> [Ben Trafford:] | There's been some talk on the DSSSL list about the | coordination of DSSSL with XML. Is this anything the ERB has been | discussing? Does anyone have any input on the implementation of style | sheets with XML? I've seen some discussion, but not very much in terms | of a fleshed-out idea. Please don't cross-post to the WG list. None of us need the duplicate messages. The WG's deliverables with regard to stylesheets and everything else are described on http://www.w3.org/pub/WWW/MarkUp/SGML/Activity . Jon xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Thu Apr 10 01:55:52 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:40 2004 Subject: various issues Message-ID: <5526@ursus.demon.co.uk> In message Neil Bradley writes: > > 2. Do others agree that there should be recommended models for representing > complex structures such as tables and mathematical formulae, even if this > just means referring to an existing standard, such as CALS tables or HTML > tables, and ISO 12083 math? At this early stage it would be great if > potential XML software developers had a common goal, that would ultimately > benefit users of XML. I am extremely keen on this idea and have suggested that we have 'Generally Agreed Conventions'. [The WG/ERB has rightly agreed that *it* doesn't have the resources and perhpas isn't the right place anyway.] What I *don't* want to happen is that everyone sits down and hacks a set of XML tags and fires off WF documents at random (especially if there is no processing software or 'to read this document you must have installed FOO.exe on an XYZ platform running BAZ with PQR libraries... I've seen a horrible example of this in a talk today...). So we should promote the *existence* of existing DTDs and explain what they can offer. So, for example, it is foolish for me to hack CML so that it includes FIGURES - much better to interoperate with CGM (recently mentioned on c.t.s). I would hope that any chemical applications would consider using some or all of the CML tagset. And when parsable maths comes along I will certainly adopt that. The major problem is namespace collisions between ElementTypes. Does anyone have a solution? What if the incompatible document is in a separate valid document (i.e. with DOCTYPE). I'd value ideas/epxerience here, otherwise we will have to produce some kludge. If we can get this off the ground before too many uncoordinated hacks appear we have a chance to reduce the worst namespace pollution. Yes, I realise that formally every XML application is completely distinct from every other, but it won't always work that way. XML is EXTENSIBLE, so people will want to combine DTDs or parts of DTDs... It would be EXTREMELY valuable if someone were to offer to run a Generally Accepted Conventions page. This would include some basic guidelines about what makes agood XML document and what doesn't, some commonly used tag sets, advice on using (say) IDs, etc. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Thu Apr 10 01:55:58 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:40 2004 Subject: tei xptr WR checker? Message-ID: <5528@ursus.demon.co.uk> In message <199704071545.IAA24061@bolt.sonic.net> Terry Allen writes: > > Has anyone made a program to check that TEI pointers are > well formed (per their specification)? Something that > authors could use? This is perhaps more appropriate for xml-dev and I've crossposted the reply. JUMBO is trying to track the spec as it evolves. At present it supports TEI pointers before the last draft (i.e. with spaces) but I'll hack in the commas tomorrow. As far as I know it behaves as the spec, but I's really like some torture tests to see no only if it parses properly but also performs properly. (The msg from James Clark shows that certain elements might not be found or that there is ambiguity in the spec (e.g. does *IMPLIED match *). For myself I find it easiest to have real examples to develop code against and then when that is done, the authors can match against the code. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Thu Apr 10 02:29:19 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:40 2004 Subject: various issues In-Reply-To: <5526@ursus.demon.co.uk> References: <5526@ursus.demon.co.uk> Message-ID: <199704100019.UAA00272@localhost> Peter Murray-Rust writes: > The major problem is namespace collisions between ElementTypes. > Does anyone have a solution? What if the incompatible document is > in a separate valid document (i.e. with DOCTYPE). I'd value > ideas/epxerience here, otherwise we will have to produce some > kludge. The solution is to define tables (etc.) as base architectures, and then to map specific DTDs using architectural forms, something like this: [notation and entity declarations omitted] Presto -- no element-type-name collisions! All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Thu Apr 10 09:56:16 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:40 2004 Subject: various issues Message-ID: <5547@ursus.demon.co.uk> David, This sounds exactly what is needed but the bad news is that I know nothing about architectural forms. I suspect this is true for some other readers of this list as well. I would be grateful for any pointers (and brief explanations here if possible.) Here are some very naive questions... - are AFs part of HyTime or more generally part of SGML? - does XML support AFs without further revisison? - if not, what has to be added? or is it possible to build this into tools without breaking the spec? - if tools have to be built, is the processing required at parser level? - do the components belonging to different DTDs have to live in separate files or can they be separated within a single file (e.g. by NOTATIONs)? - if someone decides they need AFs are they easy to implement? (for my requirements it looks like an aliasing mechanism would suffice. In message <199704100019.UAA00272@localhost> David Megginson writes: > Peter Murray-Rust writes: > > > The major problem is namespace collisions between ElementTypes. > > Does anyone have a solution? What if the incompatible document is > > in a separate valid document (i.e. with DOCTYPE). I'd value > > ideas/epxerience here, otherwise we will have to produce some > > kludge. > > The solution is to define tables (etc.) as base architectures, and > then to map specific DTDs using architectural forms, something like > this: > > > > [notation and entity declarations omitted] > > > xmlTable #FIXED "xmlTable"> > > > xmlTable #FIXED "xmlTableRow"> > > > xmlTable #FIXED "xmlTableCell"> > > Presto -- no element-type-name collisions! I'm assuming that you are taking HTML3.2 as an example (I'm happy with that :-). If so, which document does the above occur in? I can see that it might alias a 'foreign' DTD's TABLE to xmlTable but what if there is another DTD with TABLE in. Or does the ArcBase PI imply a scope for the declarations which only exists in a small region. (If so this is clearly something the parser has to resolve). If I'm on the right track, what do the parser authors think about implementing AFs? Is it a lot of work? P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Thu Apr 10 10:19:34 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:40 2004 Subject: Mirrors and ftp sites Message-ID: <5552@ursus.demon.co.uk> A number of people have told me that downloading my software (either as applets or *.tar.gz) is slow and unreliable (i.e. times out). I've experienced similar problems (especially to Austria). I think we would find it useful to have material related to XML-DEV mirrored and this is really an appeal to see if anyone is willing to offer some basic help. If such sites emerge they might usefully go in the XML FAQ ("Where is the most convenenient place to download XML software from..."). P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Thu Apr 10 12:42:27 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:40 2004 Subject: various issues In-Reply-To: <5547@ursus.demon.co.uk> References: <5547@ursus.demon.co.uk> Message-ID: <199704101041.GAA00273@localhost> Peter Murray-Rust writes: > This sounds exactly what is needed but the bad news is that I > know nothing about architectural forms. I suspect this is true for > some other readers of this list as well. I would be grateful for > any pointers (and brief explanations here if possible.) Here are > some very naive questions... For a quick introduction to Architectural Forms, see http://www.jclark.com/sp/archform.htm For other information, see http://www.sil.org/sgml/topics.html#archForms > - are AFs part of HyTime or more generally part of SGML? Architectural forms were originally specific to HyTime, but in the forthcoming Annex 1 of the standard, they have been generalised -- HyTime is one base architecture, but DSSSL is another, as is the Canadian GILS project. > - does XML support AFs without further revisison? > - if not, what has to be added? or is it possible to build this > into tools without breaking the spec? > - if tools have to be built, is the processing required at > parser level? There are different ways of dealing with AFs. James Clark's SP library can do special, smart AF processing, where it actually parses the document as if it were an instance of the base architecture rather than of the derived architecture, but that is not always necessary (or desirable). XML-based tools can simply look for the processing instruction and the associated notation declaration, and then use the attribute values for processing. NXP-based apps, for example, should be able to handle this, but DTD-less parsing will not be possible unless the attribute values are included in the document instance itself (I consider this a feature rather than a bug). The one short-coming is that XML does not support data-attributes, so it will not be possible to customise the AF support -- you'll have to stick with the defaults. > - do the components belonging to different DTDs have to live in > separate files or can they be separated within a single > file (e.g. by NOTATIONs)? They should be stored in separate files (etc.), just like public entity sets. > - if someone decides they need AFs are they easy to implement? > (for my requirements it looks like an aliasing mechanism > would suffice. This _is_ an aliasing mechanism, of sorts. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Thu Apr 10 13:16:08 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:41 2004 Subject: various issues Message-ID: <5570@ursus.demon.co.uk> Thanks very much David, You have made me feel modestly optimistic - I'll be interested to hear from Norbert and Tim. I'll read your pointers asap. P. In message <199704101041.GAA00273@localhost> David Megginson writes: > Peter Murray-Rust writes: > [...] > > - are AFs part of HyTime or more generally part of SGML? > > Architectural forms were originally specific to HyTime, but in the > forthcoming Annex 1 of the standard, they have been generalised -- ^^^^^^^^^^^^ Which? 8879? > HyTime is one base architecture, but DSSSL is another, as is the > Canadian GILS project. > > > - does XML support AFs without further revisison? > > - if not, what has to be added? or is it possible to build this > > into tools without breaking the spec? > > - if tools have to be built, is the processing required at > > parser level? > > There are different ways of dealing with AFs. James Clark's SP > library can do special, smart AF processing, where it actually parses > the document as if it were an instance of the base architecture rather > than of the derived architecture, but that is not always necessary (or > desirable). XML-based tools can simply look for the > processing instruction and the associated notation declaration, and > then use the attribute values for processing. I'm getting the impression that this is at *processor* level, not parser. I.e. we might need an AFprocessor tool in our Java toolkit? Comes between the parser and the application? > > NXP-based apps, for example, should be able to handle this, but > DTD-less parsing will not be possible unless the attribute values are > included in the document instance itself (I consider this a feature > rather than a bug). This means they are added to the declaration subset or to the pointers to the entities? > > The one short-coming is that XML does not support data-attributes, so > it will not be possible to customise the AF support -- you'll have to > stick with the defaults. This sounds reasonable for a first step :-) > > > - do the components belonging to different DTDs have to live in > > separate files or can they be separated within a single > > file (e.g. by NOTATIONs)? > > They should be stored in separate files (etc.), just like public > entity sets. > > > - if someone decides they need AFs are they easy to implement? > > (for my requirements it looks like an aliasing mechanism > > would suffice. > > This _is_ an aliasing mechanism, of sorts. Excellent. I suspect this is likely to be critical when people start reusing tagsets. Other opinions? P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Ingo.Macherius at tu-clausthal.de Thu Apr 10 14:18:58 1997 From: Ingo.Macherius at tu-clausthal.de (Ingo Macherius) Date: Mon Jun 7 16:57:41 2004 Subject: Mirrors and ftp sites In-Reply-To: <5552@ursus.demon.co.uk> from "Peter Murray-Rust" at Apr 10, 97 09:11:32 am Message-ID: <199704101218.OAA03641@kneipfix.rz.tu-clausthal.de> Peter Murray-Rust said: | | A number of people have told me that downloading my software | (either as applets or *.tar.gz) is slow and unreliable (i.e. times out). | I've experienced similar problems (especially to Austria). | I think we would find it useful to have material related to XML-DEV | mirrored and this is really an appeal to see if anyone is willing | to offer some basic help. In my understanding your inention is the improved accessibility to software. Improvement in this case means bandwidth and the ability to download all related resources from one (mirror) server. It may include kind of HOWTO for the installation of the various tools. Exactly the same problem is solved for the distribution of Perl object classes (-> http://www.perl.com/CPAN) by some very sophisticated system based on mirrors, author ids and categories. Of course this is overkill now, it might be better to start top down than bottom up. Have a look and comment. Also with CPAN software it's easy to mirror whole websites, IMHO this should be left to caches. The collection of links is covered (pun intended) very well at www.sil.org/sgml, so no need. My suggestion is to concentrate on ftp level and daily mirrors in a standardized way. This means all mirrors should have the same organisation regarding directories, filenames and help texts. Just like CPAN. What CPAN lacks is a nice HTML GUI. This is of course a field, where XML should by applied to produce HTML and other documents. My idea is the following: We make up a very simple minded DTD to describe resources. Every site holds a document consisting of a base element and (external) entities. The entities contain resource description elements and are maintained by the author of mirrored software on his/her distri- bution server. They should include things like anchor text for entry in HTML pages, link to documentation and download sites, author information etc. The entities are collected by running a XML/SGML parser using http-SYSTEM identifiers. The software packages themselves are fetched by CPAN (or other) mirror software. Based on the document resulting after the collection of all (error mechanism needed for sites being down) external entities it should be easy to create various views on the archive. BTW: There is a crude prototype implementation using this mechanism at http://www.tu-clausthal.de/cgi-bin/wwwdocd/homepage.cgi It's written in 100% Perl and is kind of DynaWeb for the poor. You may browse the software and DTD behind this at http://www.tu-clausthal.de/~inim/hp2/hp2/ What you see is just a surface, any networking code is missing. But it may be a start. Java probably would be nicer. But hey, wasn't XML an independet standarrd for exchange of documents between different applications ? If you think this sounds like overkill, let me know. IMHO this could be a very usefull application of XML. ++im -- Snail : Ingo Macherius // L'Aigler Platz 4 // D-38678 Clausthal-Zellerfeld Mail : Ingo.Macherius@tu-clausthal.de WWW: http://www.tu-clausthal.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Frank Zappa) xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From jjc at jclark.com Thu Apr 10 15:29:51 1997 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 16:57:41 2004 Subject: XML validation capability added to SP Message-ID: <2.2.32.19970410131651.009e1c70@jclark.com> I spent the day adding XML validation support to SP. You can get an SP snapshot that has this from ftp://ftp.jclark.com/pub/test/sp.zip. The support takes the form of a -wxml option which will cause SP to give a warning for the use of any SGML construct that is not allowed in XML. Actually -wxml is short-hand for enabling 45 new warnings, each of which can be enabled or disabled individually. I haven't yet documented these, but you can read ParserApp.cxx to find a list. There are a couple of things I know I don't yet detect: - XML's additional restrictions on parameter entity references - XML's requirements about quoting &, < and > - XML's additional restrictions on the content of ignored marked sections There are probably others I don't know about. If you find any, please report them. James xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Thu Apr 10 16:08:52 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:41 2004 Subject: various issues In-Reply-To: <5570@ursus.demon.co.uk> References: <5570@ursus.demon.co.uk> Message-ID: <199704101406.KAA00211@localhost> Peter Murray-Rust writes: > > Architectural forms were originally specific to HyTime, but in the > > forthcoming Annex 1 of the standard, they have been generalised -- > ^^^^^^^^^^^^ > Which? 8879? HyTime. > I'm getting the impression that this is at *processor* level, not parser. > I.e. we might need an AFprocessor tool in our Java toolkit? Comes between > the parser and the application? Absolutely -- they are still SGML (or in this case, XML) documents, parsed according to the normal rules -- usually, architectural forms just add some semantics to the parsing. As I mentioned before, however, it is _possible_ to involve the parser, as James Clark does in SP. > > > > NXP-based apps, for example, should be able to handle this, but > > DTD-less parsing will not be possible unless the attribute values are > > included in the document instance itself (I consider this a feature > > rather than a bug). > > This means they are added to the declaration subset or to the pointers > to the entities? I'd imagine that they would have to appear in the attribute specifications themselves, though you could put them in the subset if you wanted. The DTD is by far a better choice, and since NXP uses the DTD anyway, there hardly seems to be a practical excuse now for DTD-less parsing. > > > > The one short-coming is that XML does not support data-attributes, so > > it will not be possible to customise the AF support -- you'll have to > > stick with the defaults. > > This sounds reasonable for a first step :-) Perhaps -- some of the configuration is quite important, however (do you want to provide a bridge element for the targets of IDREFs, for example?). All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Thu Apr 10 16:09:50 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:41 2004 Subject: Mirrors and ftp sites Message-ID: <5589@ursus.demon.co.uk> Firstly , to say I'm very gratified by the response - several people have mailed and offered to mount my software, for which many thanks. Perhaps I wasn't clear enough but it was closer to what Ingo is suggesting that I was asking for. In message <199704101218.OAA03641@kneipfix.rz.tu-clausthal.de> Ingo Macherius writes: > Peter Murray-Rust said: > [...] > > In my understanding your inention is the improved accessibility to > software. Improvement in this case means bandwidth and the ability to > download all related resources from one (mirror) server. It may include > kind of HOWTO for the installation of the various tools. Exactly. For mature software an excellent service is provided by Robin Cover, Steve Pepper and others. For xml-dev however, it is particularly useful to be able to go to a single site and make sure that you have: - the closest version - the latest version - any ancillary material that may be useful. [...] > > My suggestion is to concentrate on ftp level and daily mirrors in a > standardized way. This means all mirrors should have the same organisation > regarding directories, filenames and help texts. Just like CPAN. I think that there is a lot to be said for this communality, because of the way that XML is developing. We are going to need to get used to transporting collections of resources (e.g. catalogs, stylesheets, java classes) in a coherent manner and it's important that all the components are present on a site. I think it's going to be critical for those who are new to the field: 'How do I set up an XML environment?' 'just go to XYZ and download a parser, a browser, the beginner's XML-catalog, the core entity sets, ...' [... idea of using XML deleted...] I think it's a very nice idea to use XML to create tools to manage our resources, but I wouldn't want to wait until this is built. Perhaps it can be done in parallel. > [...] Ingo, assuming this is an offer to set up a resource site you don't need permission from anyone :-) - just go ahead. And many thanks. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From peter at techno.com Thu Apr 10 18:12:52 1997 From: peter at techno.com (Peter Newcomb) Date: Mon Jun 7 16:57:41 2004 Subject: various issues In-Reply-To: <199704101406.KAA00211@localhost> (message from David Megginson on Thu, 10 Apr 1997 10:06:30 -0400) Message-ID: <199704101609.MAA03330@exocomp.techno.com> > From: David Megginson > > Peter Murray-Rust writes: > > > > The one short-coming is that XML does not support data-attributes, so > > > it will not be possible to customise the AF support -- you'll have to > > > stick with the defaults. > > > > This sounds reasonable for a first step :-) > > Perhaps -- some of the configuration is quite important, however (do > you want to provide a bridge element for the targets of IDREFs, for > example?). There are a number of architecture support attributes, all of which appear as data attributes of the architecture notation (the notation pointed to by the ArcBase PI). Some of these attributes are critical (i.e. needed 90% of the time), and one of them is required. They are used to specify: - the name of the architectural form attribute, used to identify the architectural form to which an element conforms (default: same as architecture notation name) - the name of the architectural attribute renamer attribute, used to resolve attribute name conflicts between multiple architectures (default: no renaming) - the name of the architecture suppressor attribute, used to control the recognition of architectural forms from this architecture within the content of an element (default: no suppression) - the name of the architecture ignore data attribute, used to control whether the data content an element is to be considered part of the architectural instance (default: data is included or ignored according to the architecture's meta-DTD) - the name of the architecture document element form, to which the document element must conform (default: same as architecture notation name) - the name of the meta-DTD entity (REQUIRED for validation) - a list of quantity set variations for the architecture (default: same as document) - the default notation form for data entities (the bridge data form) (default: data entities are not necessarily propagated to the architectural document instance, and therefore cannot be used to satisfy ENTITY architectural attributes) - the default element form for elements with IDs (the bridge element form) (default: element with IDs are not necessarily propagated to the architectural document instance, and therefore cannot be used to satisfy IDREF architectural attributes) - whether or not to automatically map element types to element forms of the same name (default: perform automatic mapping) - the names of parameter entities to give the replacement text "INCLUDE", used to identify the facilities of the architecture required by the document (default: use only non-optional facilities) - other architecture-specific options (e.g., in HyTime, the maximum resolution required for finite coordinate spaces) I would very much like to be able to use the SGML architecture mechanism with XML, but XML's lack of data attributes makes it impossible to do so, except in the simplest of cases. (And even in those cases we cannot prove architectural validity for lack of a meta-DTD entity name.) Either we need data attributes in XML, or a different architecture binding mechanism needs to be devised. My personal opinion is that the former would be easier, and more generally useful, but I have to admit to a tendency to the more general and therefore less easily implementable. -peter -- Peter Newcomb TechnoTeacher, Inc. 233 Spruce Avenue P.O. Box 23795 Rochester, NY 14611-4041 USA Rochester, New York 14692-3795 USA +1 716 464 8696 (home) +1 716 464 8696 (direct) +1 716 755 8698 (cell) +1 716 271 0796 (main) +1 716 529 4304 (fax) +1 716 271 0129 (fax) peter@petes-house.rochester.ny.us peter@techno.com http://www.petes-house.rochester.ny.us http://www.techno.com xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Thu Apr 10 19:31:13 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:41 2004 Subject: various issues In-Reply-To: <199704101609.MAA03330@exocomp.techno.com> References: <199704101406.KAA00211@localhost> <199704101609.MAA03330@exocomp.techno.com> Message-ID: <199704101729.NAA00223@localhost> Peter Newcomb writes: > - the name of the meta-DTD entity (REQUIRED for validation) XML could work around this problem by specifying that the meta-DTD entity have the same name as the notation (and as the base architecture itself). > - whether or not to automatically map element types to element forms > of the same name (default: perform automatic mapping) This is an important one -- I rarely use the default value here, because automatic mapping will often cause conflicts with small architectures embedded in complex document types. > I would very much like to be able to use the SGML architecture > mechanism with XML, but XML's lack of data attributes makes it > impossible to do so, except in the simplest of cases. (And even in > those cases we cannot prove architectural validity for lack of a > meta-DTD entity name.) No following the scheme in annex 1, but we could provide validation using the convention I mentioned above. > Either we need data attributes in XML, or a different architecture > binding mechanism needs to be devised. My personal opinion is that > the former would be easier, and more generally useful, but I have > to admit to a tendency to the more general and therefore less > easily implementable. It would not be hard to implement data-attribute support in XML, but the committee might not be thrilled with the idea -- it will probably seem too much like creeping featurism. I imagine that they will probably end up using processing instructions instead of data attributes. I agree with Peter in preferring data attributes. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From lee at sq.com Fri Apr 11 03:56:54 1997 From: lee at sq.com (lee@sq.com) Date: Mon Jun 7 16:57:41 2004 Subject: Mirrors and ftp sites Message-ID: <9704110156.AA14749@sqrex.sq.com> > I think we would find it useful to have material related to XML-DEV > mirrored and this is really an appeal to see if anyone is willing > to offer some basic help. I am investigating making a mirror on our servers in Canada and England. Does anyone know how much traffic there is? We should be able to do something within a few days, I think. I hope. Lee -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com/ | the barefoot programmer xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Fri Apr 11 12:39:46 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:42 2004 Subject: various issues In-Reply-To: <5601@ursus.demon.co.uk> References: <5601@ursus.demon.co.uk> Message-ID: <199704111037.GAA00242@localhost> Peter Murray-Rust writes: > Thanks for the discussion - I am certainly finding it very > interesting. My impression is that implementing AFs at this stage > is a lot of work and also that there is a considerable amount of > simple tutorial material required (e.g. the SP material assumes you > are familiar with the HyTime standard.) That wasn't my impression -- James certainly makes passing reference to HyTime, but he does not seem to assume prior knowledge of the standard (I first learned about AFs from James's doc, without [at that time] any but a passing knowledge of HyTime). That said, his doc is not meant (I think) as a beginners' tutorial, though it is the closest thing we have right now. > I'm not clear what the meta-DTD looks like, so here is a possible > problem: It usually looks exactly like a regular DTD, unless you use a couple of minor syntax extensions allowed (but not required) by the annex. You could use DocBook, HTML 32, or TEI-Lite (to give three examples) as meta-DTDs. > My DTD (CML) includes (say) HTML 3.2 which contains a SUB element. > Now suppose I want to incorporate another DTD which does maths - > let's call it MATH.dtd, and find that it has a namespace collision > with SUB. Do I create a meta-DTD which describes two separate AFs? > If so, what does it look like (in very simple terms). You do not include either DTD -- instead, you map some elements to elements in the HTML DTD, some elements to elements in the math DTD, some to neither, and some to both. For example, [notations and entities omitted] You still have to declare every element in your own DTD, whether or not it is mapped to something in a meta-DTD. > > It would not be hard to implement data-attribute support in XML, > > but the committee might not be thrilled with the idea -- it will > > probably seem too much like creeping featurism. I imagine that > > they will probably end up using processing instructions instead > > of data attributes. I agree with Peter in preferring data > > attributes. > Presumably one attraction of PIs is that the current parsers (and > XML-LANG spec) won't have to be changed? The disadvantage is that, since data attributes are naturally associated with a single notation, and notations are naturally associated with a single base architecture, it is easy to keep track of what goes with what. Perhaps additional arguments to the PI would be the best alternative. > I assume that it's easiest to build these systems if the two DTDs > don't interact at all (i.e. represent completely separate pieces of > information.) Not necessarily: you will run into problems only if the overlapping structures are different; the names are not an issue. > [I liked the article by Steve Newcomb - although again it assumed > some familiarity with HyTime in places. It is clearly a vision > that I would wish to evolve towards though again the mian problem > is education.] There is __no__ need to learn HyTime to understand Architectural Forms. HyTime is simply one of many possible base architectures. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Fri Apr 11 14:07:59 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:42 2004 Subject: various issues Message-ID: <5616@ursus.demon.co.uk> You are very patient with me David, but light is beginning to dawn. I think that we ahave been addressing different problems and I now partially understand what you are getting at... In message <199704111037.GAA00242@localhost> David Megginson writes: > Peter Murray-Rust writes: > > > Thanks for the discussion - I am certainly finding it very > > interesting. My impression is that implementing AFs at this stage > > is a lot of work and also that there is a considerable amount of > > simple tutorial material required (e.g. the SP material assumes you > > are familiar with the HyTime standard.) > > That wasn't my impression -- James certainly makes passing reference > to HyTime, but he does not seem to assume prior knowledge of the > standard (I first learned about AFs from James's doc, without [at that > time] any but a passing knowledge of HyTime). That said, his doc is > not meant (I think) as a beginners' tutorial, though it is the closest > thing we have right now. Understood and no criticism implied. But terms are used on the assumption that they are understood beforehand. It's clear that we need a ReallySimpleGuide to this for people like me. > > > I'm not clear what the meta-DTD looks like, so here is a possible > > problem: > > It usually looks exactly like a regular DTD, unless you use a couple > of minor syntax extensions allowed (but not required) by the annex. > You could use DocBook, HTML 32, or TEI-Lite (to give three examples) > as meta-DTDs. > > > My DTD (CML) includes (say) HTML 3.2 which contains a SUB element. > > Now suppose I want to incorporate another DTD which does maths - > > let's call it MATH.dtd, and find that it has a namespace collision > > with SUB. Do I create a meta-DTD which describes two separate AFs? > > If so, what does it look like (in very simple terms). > > You do not include either DTD -- instead, you map some elements to > elements in the HTML DTD, some elements to elements in the math DTD, > some to neither, and some to both. For example, > What follows is the meta-DTD, right? And the system knows it's a meta-DTD because of the inclusion of one or more > > [notations and entities omitted] > > > html NAME #FIXED "p"> > > > math NAME #FIXED "frac"> > > ^^^ (I assume this is 'symbol'?) > html NAME #FIXED "sym" > math NAME #FIXED "symbol"> > What this is doing is mapping elements in different DTDs to the same element in your meta-DTD. This implies that they are synonyms in some way. Does it assume that they have the same content model, attributes and that the elements in the content model have (recursively) been mapped onto the DTD. Or are you essentially aliasing SYM in HTML to SYMBOL and SYMBOL in MATH to SYMBOL but having to provide different content models and processing for each? (This is a superset of my problem which was simply what I did with the same GI in different DTDs. Effectively I would want something like: and I would provide something separate for each one. > You still have to declare every element in your own DTD, whether or > not it is mapped to something in a meta-DTD. This means your DTD is a superset of the other DTDs and your own elements? > > > > It would not be hard to implement data-attribute support in XML, > > > but the committee might not be thrilled with the idea -- it will > > > probably seem too much like creeping featurism. I imagine that > > > they will probably end up using processing instructions instead > > > of data attributes. I agree with Peter in preferring data > > > attributes. > > Presumably one attraction of PIs is that the current parsers (and > > XML-LANG spec) won't have to be changed? > > The disadvantage is that, since data attributes are naturally I assume that the syntax you have written above is an example of data-attributes?? If not, could you give an example :-) > associated with a single notation, and notations are naturally > associated with a single base architecture, it is easy to keep track > of what goes with what. Perhaps additional arguments to the ...?> PI would be the best alternative. > > > I assume that it's easiest to build these systems if the two DTDs > > don't interact at all (i.e. represent completely separate pieces of > > information.) > > Not necessarily: you will run into problems only if the overlapping > structures are different; the names are not an issue. I think I start to understand. By 'structure' you mean the tree structure of each DTD? In which case AFs are a way of providing multiple views of the same document? > > > [I liked the article by Steve Newcomb - although again it assumed > > some familiarity with HyTime in places. It is clearly a vision > > that I would wish to evolve towards though again the mian problem > > is education.] > > There is __no__ need to learn HyTime to understand Architectural > Forms. HyTime is simply one of many possible base architectures. Good! This Q+A is very useful for me. I can understand why the WG decided it was ambitious at present - if there were a minimal set of PIs or equivalent I can see that this could be less hairy to implement. > P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Fri Apr 11 14:08:13 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:42 2004 Subject: XML-LINK implementation Message-ID: <5617@ursus.demon.co.uk> I have nearly finished a prototype implementation of XML-LINK 970406 within JUMBO and hope to make this available in a week or so. Here are some interim comments. Of course it is all 'unusually volatile' :-). [I have not yet converted TEI to use commas, and negative numbers are not supported in PRECEDING, but these should be done shortly]. In document order: 1.4 'multi-directional link' There is no explicit syntactic support for this and at present this would have to be done be creating the appropriate number of SIMPLE or LOCATOR elements. I am assuming that this is the ERB's intention. 2.1 **Default Attribute Values**. This appears to be a parser requirement and I'd be grateful if Norbert and Tim (and any other parser writers) could express their views. At present all my test examples are based on explicit attributes in the document. Parser development would be highly desirable. **General point** XML-LINK applies to WF as well as valid documents. There are many things that can produce apparently meaningless documents (e.g. linking from one WF|valid document to another WF|valid which might reasonably throw errors but the spec has not (yet) commented on these - I hope it will later. 3.1 ROLE, BEHAVIOR, TITLE. I have treated these all identically and trivially (i.e. they are simple String variables available for later use). They may/maynot be present and they will be inherited if present in EXTENDED but not in the child LOCATORs. As a consequence, sibling locators may all end up with identical TITLEs - this may be an authoring concern. 3.2 ATTLISTs I struggled with these a bit, before coming to the conclusion that a link processor might have to deal with these in detail independently of the parser. I assume that these will be hardcoded into LINK-aware parsers (or at least into tables that parsers read.) A parser might then identify all the elements with attribute XML-LINK and apply the 5 tables to the documents. Remember that the document may not have a DTD. **Can the parser assume that if one element FOO in a WF doc uses XML-LINK then all FOO do?** However we must also assume that some parsers are NOT LINK-aware and therefore willhave to validate the tables and provide the defaults and inheritance. *** any XML-LINK processor must therefore cater for this***. I thought about re-using Norbert's code but in the end (also being very tired) hacked something internally. **However this is an important area for an API - we need tools off the shelf that deal with these tables - it's just conceivable they may be subject to future revision :-)*** I haven't run into any obvious problems implementing defaults and inheritance. *** formally it is allowed to have a LOCATOR element not contained within an EXTENDED. This seems meaningful - is it what the ERB intends?** 4.1 ***general point*** It seems quite possible and desirable to have a LINK processor which is independent of the application. Of course it depends what is an application, and JUMBO may be called an application. However I think it could be broken into components. Essentially JUMBO holds the parsed document as a tree of nodes (==elements). At present every node has a button linked to display(). This corresponds to NEW/USER. When the button (an element-specific icon) is clicked a separate window is launched with that node displayed. [The default Node.display() is simply to print the node structure on System.out.] display() is overriden for DrawableNodes (which extend Node) and where a general purpose window is provided. If the user wants to draw to the same screen as the referrer (EMBED) there is a module display(Graphics g). The control of the Graphics area is under the referring window, although the target may be able to say something about its size, scalability, isometricity, etc. In this way EMBED/USER is possible at present - when clicked the target is redrawn onto an appropriate place on the referring window. (Since I didn't know I was going to be writing a browser when I started there are some things which need rewriting. Also JDK1.02 is horrible for multiple window components and I shall not change to 1.1 until it's in the browsers.) REPLACE/USER is also dealt with. This means that the current tree (in the TOC) is overwritten with the new one - the only question is one of window management and some Java tweaks - I think it needs a shallowCopy of the tree). All the */AUTO imply that the first time the tree is traversed these operations have to be done. When initially creating the tree I now note whether there are any XML-LINKs in it, so I don't have to wait for a paint(). For example the first REPLACE/AUTO in the document simply involves creating the referred resource (recursively if required - I hope it's not cyclic!!). NEW/AUTO requires one or more new windows to be created. EMBED/AUTO sets an embed flag in just the same way as if the EMBED/USER had been clicked. All of these can be done ***independently of any application*** so long as we agree on an API. At present an Element/Node seems to need (minimally): void display(Graphics g) boolean isEmbedded void createNewWindow() beyond that I suspect that everything else is likely to be part of the application. I have commented on Section 5 here and to the WG, and won't repeat that here. There are no real implementation issues but I am arguing for some clarification and feature creep. JUMBO does nothing with GROUP/DOCUMENT (other than throw an error for absent HREF). This would seem to be entirely application-dependent. Comments welcome. I will notify the WG of this posting. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From srn at techno.com Fri Apr 11 15:13:08 1997 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 16:57:42 2004 Subject: various issues In-Reply-To: <199704111037.GAA00242@localhost> (message from David Megginson on Fri, 11 Apr 1997 06:37:13 -0400) Message-ID: <199704111309.JAA01623@bruno.techno.com> > > [I liked the article by Steve Newcomb - although again it assumed > > some familiarity with HyTime in places. It is clearly a vision > > that I would wish to evolve towards though again the mian problem > > is education.] > > There is __no__ need to learn HyTime to understand Architectural > Forms. HyTime is simply one of many possible base architectures. YES! If my article on SGML architectures (see http://www.techno.com) doesn't make that point clear, I feel duty-bound to underline David's remark. HyTime is only one possible base architecture. Other architectures can inherit features of HyTime if desired, but there is no requirement that they do so. Best regards, --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Fri Apr 11 15:13:20 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:42 2004 Subject: various issues In-Reply-To: <5615@ursus.demon.co.uk> References: <5615@ursus.demon.co.uk> Message-ID: <199704111310.JAA00567@localhost> Peter Murray-Rust writes: > What follows is the meta-DTD, right? And the system knows it's > a meta-DTD because of the inclusion of one or more PI, unless it is mapped to yet another meta-DTD. If you write a DTD, and include in that DTD, you are suggesting that your DTD uses HTML as a base architecture. The HTML DTD is the meta-DTD, and it is not modified in any way. > What this is doing is mapping elements in different DTDs to the > same element in your meta-DTD. This implies that they are synonyms > in some way. Does it assume that they have the same content model, > attributes and that the elements in the content model have > (recursively) been mapped onto the DTD. Or are you essentially > aliasing SYM in HTML to SYMBOL and SYMBOL in MATH to SYMBOL but > having to provide different content models and processing for each? No, it's the other way around -- the DTD for the derived architecture maps some of its elements to those in one or more meta-DTDs (though you don't have to do the mapping in the DTD itself). If you're creating document type X, and you're including architectures from CALS, HTML, and TEI-L, then you put the mappings in the X DTD. They don't have to have exactly the same content models -- the content model in the derived DTD can be more restrictive (but not less). > This means your DTD is a superset of the other DTDs and your own elements? Not exactly -- it means that there is an intersection between the semantics of your DTD and the semantics of each of the meta-DTD. Your DTD may have element types that are not in the meta-DTD, and the meta-DTD may have element types that are not in your DTD. > I think I start to understand. By 'structure' you mean the tree structure > of each DTD? In which case AFs are a way of providing multiple views of the > same document? I don't follow. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From silberh at forwiss.uni-erlangen.de Fri Apr 11 17:00:34 1997 From: silberh at forwiss.uni-erlangen.de (Horst Silberhorn) Date: Mon Jun 7 16:57:42 2004 Subject: endless loops ? Message-ID: <199704111500.PAA09777@bfws00.forwiss.uni-erlangen.de> Hallo to all, I 'd have one short question: To prevent the possibility of endless loops, in SGML exist the open entity. But I haven 't found something like that in the XML Working Draft. So, is it possible to construct endless loops in XML? --Horst -------------- Horst Silberhorn FORWISS Am Weichselgarten 7 D-91058 Erlangen Email: silberh@forwiss.uni-erlangen.de --------------- xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From tbray at textuality.com Fri Apr 11 17:21:49 1997 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 16:57:42 2004 Subject: XML-LINK implementation Message-ID: <3.0.32.19970411080723.00b326d8@pop.intergate.bc.ca> >2.1 **Default Attribute Values**. This appears to be a parser requirement >and I'd be grateful if Norbert and Tim (and any other parser writers) could >express their views. At present all my test examples are based on explicit >attributes in the document. Parser development would be highly desirable. Yes. Lark (and I'm nearly certain NXP) both do default attributes now, if declared in the internal subset, properly; so there's no need for those explicit attributes. >**General point** XML-LINK applies to WF as well as valid documents. There are >many things that can produce apparently meaningless documents (e.g. linking >from one WF|valid document to another WF|valid which might reasonably throw >errors but the spec has not (yet) commented on these - I hope it will later. Huh? I don't understand this point at all. -Tim xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From digitome at iol.ie Fri Apr 11 18:12:15 1997 From: digitome at iol.ie (Digitome Ltd) Date: Mon Jun 7 16:57:42 2004 Subject: various issues Message-ID: <199704111611.RAA12153@GPO.iol.ie> >Peter Murray-Rust writes: > I think I start to understand. By 'structure' you mean the tree structure > of each DTD? In which case AFs are a way of providing multiple views of the > same document? An AF is like a virtual class in OO-speak. HyTime is a bit like a set of virtual class definitions. From these virtual classes you derive your own classes (DTDs) that inherit from their super-class(HyTime). Multiple inheritance is allowwed. That is, a given DTD can inherit from multiple AF super-classes. I am on dodgier ground now but I think AF's are virtual rather than pure virtual classes. I.e. an AF can be a DTD if you want it to. Hope this helps, Sean xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From cbullard at hiwaay.net Fri Apr 11 19:21:11 1997 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 16:57:42 2004 Subject: various issues References: <199704111611.RAA12153@GPO.iol.ie> Message-ID: <334E72E1.4478@hiwaay.net> Digitome Ltd wrote: > > >Peter Murray-Rust writes: > > I think I start to understand. By 'structure' you mean the tree structure > > of each DTD? In which case AFs are a way of providing multiple views of the > > same document? > > An AF is like a virtual class in OO-speak. HyTime is a bit like a set of > virtual class definitions. From these virtual classes you derive your own > classes (DTDs) that inherit from their super-class(HyTime). > > Multiple inheritance is allowwed. That is, a given DTD can inherit from > multiple AF super-classes. This ties back to the thread on CTS where someone was asking about why SGML could not inherit. Someone should explain in terms virtual inheritance, and interface and code inheritance, how AFs can be adopted by the OOPMen. That explanation of SGML, architectures, and OOP technique is a missing piece of the implementation puzzle and a considerable opportunity for a college text. len bullard xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Fri Apr 11 19:27:02 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:42 2004 Subject: various issues Message-ID: <5633@ursus.demon.co.uk> Thanks very much - it's becoming clearer, and at least I've got the direction correct :-). But I'm not clear what quantities are inherited... For discussion assume that the declarations belong to MYDTD In message <199704111037.GAA00242@localhost> David Megginson writes: > > So in C++ terms MYDTD has two base classes, HTML and MATH. > > [notations and entities omitted] > > > html NAME #FIXED "p"> This means that PARA (in MYDTD) inherits properties from P (in HTML). Does that mean it automatically inherits the content model and the attributes? For example, the content model of P is (%text)* which expands to (#PCDATA | IMG | BR | EM)* Can PARA assume these or does it have to map each of these (e.g. IMG) onto html: etc. similarly does PARA have to explicity declare the same attributes as P in HTML? > > > math NAME #FIXED "frac"> > > > html NAME #FIXED "sym" > math NAME #FIXED "symbol"> > This is - presumably - multiple inheritance in that SYMBOL inherits something from HTML.SYM and MATH.SYMBOL (though I'm not clear what). How does the content of SYMBOL relate to either of its two base classes? P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From jenglish at crl.com Fri Apr 11 21:33:03 1997 From: jenglish at crl.com (Joe English) Date: Mon Jun 7 16:57:42 2004 Subject: various issues In-Reply-To: <5633@ursus.demon.co.uk> References: <5633@ursus.demon.co.uk> Message-ID: <199704111930.AA09253@mail.crl.com> Peter@ursus.demon.co.uk (Peter Murray-Rust) wrote: > For discussion assume that the declarations belong to MYDTD > David Megginson writes: > > > > > > So in C++ terms MYDTD has two base classes, HTML and MATH. It may be easier to understand architectural forms if you _don't_ think of it in C++ terms... The mechanism is more like, in Java, declaring that a class (DTD) implements an interface (architecture) than inheriting an implementation from a base class. Even this is not really accurate, since in SGML elements don't _do_ anything, they just _are_; it's up to the application to interpret them. The architectural mapping simply tells applications that know how to process the architectural forms ("meta"-DTD) how to interpret instances conforming to a document type ("real" DTD) based on that architecture. > > > > > html NAME #FIXED "p"> > > This means that PARA (in MYDTD) inherits properties from P (in HTML). Does > that mean it automatically inherits the content model and the attributes? I'm not sure I understand the question. If you're asking if it's now possible to write: ... (where the ALIGN attribute is defined in the HTML meta-DTD but not in MYDTD), the answer is no. However, when it's interpreted by an HTML-architecture-aware processor, any "P" attributes with a default or #FIXED value in the meta-DTD will be (considered to be) present. > For example, the content model of P is > (%text)* > which expands to > (#PCDATA | IMG | BR | EM)* > Can PARA assume these or does it have to map each of these (e.g. IMG) onto > html: > > html NAME #FIXED "img> A "PARA" element can contain whatever is allowed by its content model in MYDTD. The only restriction is that when the children of a PARA element are mapped to HTML, the result must conform to "P"s content model in the meta-DTD. > similarly does PARA have to explicity declare the same attributes as P in HTM > L? Only if it wants to use those attributes in the source document. > > > > > html NAME #FIXED "sym" > > math NAME #FIXED "symbol"> > > > This is - presumably - multiple inheritance in that SYMBOL inherits something > from HTML.SYM and MATH.SYMBOL (though I'm not clear what). How does the > content of SYMBOL relate to either of its two base classes? When an HTML-architecture processor encounters a SYMBOL element, it treats it like an HTML "SYM" element (which does not exist AFAIK, so this would probably be an error). When a MATH-architecture processor encounters a SYMBOL element (in a document conforming to MYDTD) it treats it like a SYMBOL element (as defined in the MATH meta-DTD). --Joe English jenglish@crl.com xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Fri Apr 11 22:56:58 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:42 2004 Subject: XML-LINK implementation Message-ID: <5640@ursus.demon.co.uk> I'm having difficulty understanding the XML-LINK spec section about PRECEDING (and implicitly FOLLOWING). I'd be grateful for guidance from those who are TEI experts. My understanding of PRECEDING is that it can choose from 'the set of all elements and strings in the entire document which occur or begin before the location source'. So in the example: Bstring Cstring I'd be grateful to know if I've got these right: ID(D)PREVIOUS(1) gives 'CString' ID(D)PREVIOUS(2) fails ID(F)PREVIOUS(-2) gives ID(D)PRECEDING(1) gives 'CString' ID(D)PRECEDING(2) gives ... ID(D)PRECEDING(5) gives ... ID(D)PRECEDING(6) fails ID(D)PRECEDING(ALL) gives Bstring Cstring ID(D)PRECEDING(-2) gives However I can't understand the section beginning 'thus designates the fifth element', where it says: "The location source must have at least as many elder siblings as the absolute value of the instance number". By this criterion ID(D)PRECEDING(2), (5) (6) and (-2) all fail. I can't see how siblings are important in PRECEDING, since this is what PREVIOUS is for. Since FOLLOWING is not perfectly (anti)symmetrical I assume that (ALL) returns elements which still occurr in document order rather than reversed. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Ingo.Macherius at tu-clausthal.de Sat Apr 12 00:41:03 1997 From: Ingo.Macherius at tu-clausthal.de (Ingo Macherius) Date: Mon Jun 7 16:57:42 2004 Subject: XML-LINK implementation In-Reply-To: <5640@ursus.demon.co.uk> from "Peter Murray-Rust" at Apr 11, 97 09:31:08 pm Message-ID: <199704112240.AAA00055@florix.rz.tu-clausthal.de> Peter Murray-Rust said: | | I'm having difficulty understanding the XML-LINK spec section about | PRECEDING (and implicitly FOLLOWING). I'd be grateful for guidance from | those who are TEI experts. So do I. I was looking for TEI link model docs/examples/tutorial starting at http://www.sil.org/sgml/acadapps.html#tei, but did not find much on linkage. Could someone post few URL pointers, please ? ++im -- Snail : Ingo Macherius // L'Aigler Platz 4 // D-38678 Clausthal-Zellerfeld Mail : Ingo.Macherius@tu-clausthal.de WWW: http://www.tu-clausthal.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Frank Zappa) xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From robin at ACADCOMP.SIL.ORG Sat Apr 12 01:30:21 1997 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 16:57:42 2004 Subject: TEI links and extended pointers Message-ID: <199704112331.SAA27088@ACADCOMP.SIL.ORG> Ingo Macherius asked about URLs for TEI links and (I think) extended pointing mechanisms. Try Lou Burnard's tutorial: http://users.ox.ac.uk/~lou/papers/XR and also (more completely) chapters 14 and 16 of the TEI Guidelines, available online from several sources. Robin ------------------------------------------------------------------------- Robin Cover SIL Academic Computing Email: robin@acadcomp.sil.org 7500 W. Camp Wisdom Rd. Dallas, TX 75236 USA >>> The SGML Web Page <<< Tel: +1 (972) 296-1783 (h) http://www.sil.org/sgml/sgml.html Tel: +1 (972) 708-7346 (w) FAX: +1 (972) 708-7380 ========================================================================= xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Ingo.Macherius at tu-clausthal.de Sat Apr 12 04:59:36 1997 From: Ingo.Macherius at tu-clausthal.de (Ingo Macherius) Date: Mon Jun 7 16:57:43 2004 Subject: Terminology in WD-xml-link Message-ID: <199704120259.EAA10882@kneipfix.rz.tu-clausthal.de> WD-xml-link says to define XML links, but uses the term SGML (SGML elemment, SGML declatation, ...) through chapter 5.2. Is this intended or should it be replaced with XML on any occurance ? -- Snail : Ingo Macherius // L'Aigler Platz 4 // D-38678 Clausthal-Zellerfeld Mail : Ingo.Macherius@tu-clausthal.de WWW: http://www.tu-clausthal.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Frank Zappa) xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From jjc at jclark.com Sat Apr 12 05:44:38 1997 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 16:57:43 2004 Subject: XML-LINK implementation Message-ID: <2.2.32.19970412033137.00f0f4e0@jclark.com> At 21:31 11/04/97 GMT, Peter Murray-Rust wrote: >My understanding of PRECEDING is that it can choose from 'the set of all >elements and strings in the entire document which occur or begin before the >location source'. So in the example: > > > > Bstring > > > Cstring > > > > > > >I'd be grateful to know if I've got these right: > >ID(D)PREVIOUS(1) gives 'CString' >ID(D)PREVIOUS(2) fails >ID(F)PREVIOUS(-2) gives One might think so, but since C has mixed content and no white-space in mixed content is automatically ignored, the white-space following the D and E elements will be data and hence constitute pseudo-elements. Thus ID(F)PREVIOUS(-2) will actually designate E. James xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Sat Apr 12 18:07:32 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:43 2004 Subject: White Space Message-ID: <5648@ursus.demon.co.uk> In message <2.2.32.19970412033137.00f0f4e0@jclark.com> James Clark writes: [...] > > One might think so, but since C has mixed content and no white-space in > mixed content is automatically ignored, the white-space following the D and > E elements will be data and hence constitute pseudo-elements. Thus > ID(F)PREVIOUS(-2) will actually designate E. Having read this (helpful) reply pointed out a problem I had overlooked, I've gone back to the XML-LANG spec (2.8) to clarify my thoughts and failed to do so :-(. Regardless of how desirable the present policy is (and I'm sympathetic to those trying to formulate a policy) I can't put a precise meaning on 2.8. Please forgive my normal blundering through this. para 2: 'An XML processor which does not read the DTD must always pass all characters that are not markup through to the application'. The implication is that the processor (== 'parser' at this stage?) must recognise mixed content, so that [without a DTD]: is mixed content and contains 3 elements (the first and third being pseudoelements consisting of a newline). [My naive understanding of SGML is that there would only be one element, since start and end newlines are ignored in mixed content. Since all SGML applications require a DTD, SGML and XML give 'different' results here.] 'An XML processor which *does* read the DTD must always pass all characters in mixed content that are not markup through to the application.' [Presumably the newlines are not markup?] 'It may also **choose** to pass white space occurring in element content to the application. If it does so, it must signal to the application that...' [and the rest of the sentence appears to have been truncated in the public drafts; please can we have it back :-)] Presumably this latter occurs if something like: has been included, making it clear that C does not contain mixed content. My reading is that the *parser* can decide (choose) what to do with this whitespace, so that different *parsers* can give different results here. The *application* (e.g. browser) has to be prepared for differing inputs from the same document according to the parser used... The treatment of DEFAULT|PRESERVE is that the parser simply passes this flag to the *application* but takes no special action itself so that all parsers should behave identically. Presumably a parser without a DTD has to create pseudoelements when it encounters characters that are not part of markup. (Is the term pseudoelement used in the spec?) So according to whether the parser finds a DTD or not it will create different numbers of elements/pseudoelements for the application. It is under no obligation to tell the application how it arrived at what it is passing to it :-) So that the occurrence of pseudoelements consisting of newlines do not imple mixed content since they may have occurred in element content and the parser chose to pass them through. My current hope would be that this is a problem which we could separate into parser and application and that parsers could hide some of the intracies from the application developer (including those writing generic browsers like me.) I'm not clear whether (a) this distinction is clear in the spec. (b) whether current parser writers all agree on what should be done. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Sat Apr 12 19:41:38 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:43 2004 Subject: XML-LINK implementation Message-ID: <5647@ursus.demon.co.uk> In message <2.2.32.19970412033137.00f0f4e0@jclark.com> James Clark writes: > At 21:31 11/04/97 GMT, Peter Murray-Rust wrote: > [...] > > One might think so, but since C has mixed content and no white-space in > mixed content is automatically ignored, the white-space following the D and > E elements will be data and hence constitute pseudo-elements. Thus > ID(F)PREVIOUS(-2) will actually designate E. > Oh dear!! I wasn't even thinking of that problem. I was concerned about the words 'elder siblings ' in 5.3.4.5 which seem to make no sense to me although they are verbatim from Chapter 14 of TEI. As a webhacker the whitespace problem concerns me greatly. This isn't even 'pernicious mixed content' being talked about on c.t.s. at present. There are at least three areas where it will bite people. - authors. on c.t.s. someone (Joe English?) said that everyone gets bitten by this when writing a DTD and then they learn. Admittedly this isn't the same problem, but assuming DTD creators allow mixed content (I don't, except as HTML 2.0) most *document* authors will certainly fail to understand. (In fact I pretty-printed the example simply to make it readable!). The problem here is that one bite will put them off XML completely - they won't have a clue what's going on. - parser writers. I am not clear at present whether NXP and Lark, for example, give the same output for all possible combinations of whitespace. It's my impression that there are still some unsolved problems here (or at least the conventions are not completely finalised). Of course this is still a 'work in progress'... BUT I think it's very important that while this problem remains 'it should be easy to write programs which process XML documents [correctly]' is not true. The mythical CS student has a good chance of getting this wrong at present. At present I'd say it was impossible for anyone who wasn't highly competent in SGML to write a correct parser. - search implementers and authors. If the parser-writer has done a correct job, then the implementer of the algorithm shouldn't have a problem, so long as they all interpret 5.3 in the same way. (My problem was that I implicitly parsed the example incorrectly). So the *author of queries* is again the one who will come to grief on this unless they understand it. And it will be a mysterious and probably undebuggable problem for them. Indeed if the result of a search is a newline character which they didn't realise was part of the data, then it won't 'show up' on the display. They'll think there's a bug in the software. I can't see a simple solution to this for DTDs which allow mixed content. (It's because of this that CML has no mixed content - all #PCDATA is held in special containers). In general terms there seems to be the following. - keep document authors and readers as far away from the source as possible by using authoring tools which manage this problem. This would be a great pity as it would stifle the creativity that we've seen in HTML. And you might as well use SGML. - forbid/discourage mixed content DTDs. This would make XML very clunky for most text-based applications - firm up the conventions for DEFAULT|PRESERVE and build them more formally into such operations as the search procedure. This seems to be the only way I can see - that when mixed content is being processed at any stage the tools must be critically aware of this problem and maybe there is mandatory syntax required. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Mon Apr 14 18:38:47 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:43 2004 Subject: Mirrors and ftp sites Message-ID: <5667@ursus.demon.co.uk> The WWW6 JUMBO demo of last Friday is now available at the sites http://www.venus.co.uk/~pmr/demos.tar.gz (ca. 1.1 Mbytes) http://www.venus.co.uk/~pmr/README and http://www.nottingham.ac.uk/~pazpmr/demos.tar.gz http://www.nottingham.ac.uk/~pazpmr/README For those not at the demo, this is an INSTALLATION-FREE version in that after unpacking it runs under any Java-enabled browser. Start at w3_index.html. This is intended to remain as a stable demo version until further notice and is therefore suitable for including under definitive collections. (Many thanks to those who have offered). It is roughly compatible with XML as at 1997-0331 but does not explicitly support XML-LINK (although there are examples of hyperlinking from a pre-XML syntax - I've now converted them). The intention is not to be a 'production version' - that is not yet possible for *any* XML tool :-) - but to illustrate the principles of (primarily) non-textual applications of XML. It reads a subset of XML syntax although JUMBO will interoperate with Lark and NXP. (Indeed I intend to have a commandline switch for different parsers). The latest version also works with ESIS. Please feel to explore this version, and the accompanying files, but I shall not 'fix bugs'. I am particularly interested from hearing from people who have potential applications for JUMBO. [Two possibilities are: to write a converter from legacy format to TecML and use the TecML tagset and Java classes; or to develop DTD-specific classes which JUMBO can automatically load. Note that since much of the semantics are resolved through glossaries it's possible to manage many applications without writing serious amounts of code.] JUMBO will develop in true XML-style - snapshots when it becomes possible :-) The next likely release after WWW6 will be for a CML demo on CDROM. (BTW XML/Java is a fantastic technology for distributing maintenance-free packages, and ideal for read-only material such as technical manuals. JUMBO includes a primitive 'slide-show' mechanism which would be easy to develop.) The later version of JUMBO includes support for most XML-LINK stuff although the EMBED option isn't always implemented nicely (EMBED can refer to anything from a thumbnail to a monster GIF or new application). EMBED often would appear to require negotiation between the embbeder and the embedded on size, aspect ratio, etc. - so I don't expect to get it right first time... P. About 4-5 people have said they'd be happy to mirror XML material, and they are well spread between the continents :-). This doesn't need formal coordination, but those sites need to keep in reasonable touch to make sure that they offer roughly the same material of the same vintage. If the following is useful as a shopping list, I would find it useful if sites contained a selection from ... - latest drafts - parsers - browsers - XML-compatible DTDs - example files and torture tests - XML-compatible entitysets - tutorials, etc. and pointers to other sites if they know there is additional material there. As always it is caveat visitor, and there should be no expectation that a site is either comprehensive or rigorously up-to-date. Some of us occasionally indulge in sleep... P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Mike_Spreitzer.PARC at xerox.com Wed Apr 16 06:47:07 1997 From: Mike_Spreitzer.PARC at xerox.com (Mike_Spreitzer.PARC@xerox.com) Date: Mon Jun 7 16:57:43 2004 Subject: pointers to WWW6 D-Day XML track demos? Message-ID: <97Apr15.214556pdt."17827(10)"@alpha.xerox.com> I attended the XML track of WWW6 D-Day, and found it interesting. I'd like a list of links to the demos and/or information about what was demoed. When I asked Jon Bosak for this, he said it hadn't been collected, but suggested a query to this list would produce the desired responses. So, folks who demoed, could you please provide a pointer and/or brief description? Perhaps the owner of an XML page would like to collect the responses and put them on his page? Thanks, Mike xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From bosak at atlantic-83.Eng.Sun.COM Wed Apr 16 07:54:26 1997 From: bosak at atlantic-83.Eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 16:57:43 2004 Subject: pointers to WWW6 D-Day XML track demos? In-Reply-To: <97Apr15.214556pdt."17827(10)"@alpha.xerox.com> (Mike_Spreitzer.PARC@xerox.com) Message-ID: <199704160553.WAA06008@boethius.eng.sun.com> [Mike_Spreitzer.PARC@xerox.com:] | I attended the XML track of WWW6 D-Day, and found it interesting. I'd | like a list of links to the demos and/or information about what was | demoed. When I asked Jon Bosak for this, he said it hadn't been | collected, but suggested a query to this list would produce the | desired responses. So, folks who demoed, could you please provide a | pointer and/or brief description? | | Perhaps the owner of an XML page would like to collect the responses | and put them on his page? I'll put them on the W3C activity page if we can get a list together. Jon xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From nmikula at edu.uni-klu.ac.at Wed Apr 16 08:03:45 1997 From: nmikula at edu.uni-klu.ac.at (Norbert H. Mikula) Date: Mon Jun 7 16:57:43 2004 Subject: pointers to WWW6 D-Day XML track demos? References: <97Apr15.214556pdt."17827(10)"@alpha.xerox.com> Message-ID: <3354EC78.767A@edu.uni-klu.ac.at> Mike_Spreitzer.PARC@xerox.com wrote: > I attended the XML track of WWW6 D-Day, and found it interesting. > I'd like a > list of links to the demos and/or information about what was demoed. I have demoed my XML parser NXP and my DSSSL engine YADE. ============================= NXP - Norbert's XML Parser ============================= A XML parser that has been designed using JavaCC. All implemented in Java. (Status : Beta, release that conforms to WD-xml-lang-970331 *red-book*, can be expected around next week. Current release can be found at : http://www.edu.uni-klu.ac.at/~nmikula/NXP and http://www.edu.uni-klu.ac.at/~nmikula/NXP/beta - for the latest release) ============================= YADE - Yet Another DSSSL Engine ============================= A DSSSL browser/engine that is built on top of Per Gothner's Kawa - Scheme interpreter/compiler. All implemented in Java. (Status : Prototype, not yet public available) -- Best regards, Norbert H. Mikula ===================================================== = SGML, XML, DSSSL, Intra- & Internet, AI, Java ===================================================== = mailto:nmikula@edu.uni-klu.ac.at = http://www.edu.uni-klu.ac.at/~nmikula ===================================================== xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Wed Apr 16 08:53:41 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:43 2004 Subject: pointers to WWW6 D-Day XML track demos? Message-ID: <5725@ursus.demon.co.uk> In message <199704160553.WAA06008@boethius.eng.sun.com> bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: > [Mike_Spreitzer.PARC@xerox.com:] > > | I attended the XML track of WWW6 D-Day, and found it interesting. I'd > | like a list of links to the demos and/or information about what was > | demoed. When I asked Jon Bosak for this, he said it hadn't been A semi-virtual demonstration of my browser JUMBO was given by Jon Bosak. I have written a README for this which is appended below. This represents a 'snapshot' of JUMBO (and CML) development at D-Day which will be preserved as a (hopefully) working demonstration. Several people have offered to set up XML sites and have indicated that they will mirror this snapshot. *** AS stressed below, I shall continue to develop JUMBO to track the drafts, but the snapshot will not be updated.*** Current links are: http://www.venus.co.uk/~pmr/demos.tar.gz OR http://www.nottingham.ac.uk/~pazpmr/demos.tar.gz and, hopefully, in emerging mirror XML sites. ------------------------------------------------------------------------------- ******************************************************************* I am extremely grateful to Jon for demo'ing this. I've never met Jon - we had a phone call about the demo - and I think it is tremendous what he achieved, especially with all the rest that was happening. My limited feedback was that it went well (Jon mentioned that it is slow, and that's because it is Java, and large (about 500 Kbytes of *.class). Much of the size is due to the applications. My own experience is that there can be a factor of ~10 between apparently equivalent platforms.). So congratulations, Jon! ******************************************************************* One of the many positive messages is that this representa a *self-contained* XML system independent of the networks. {OK, this isn't the main rationale for XML, but it comes as a free bonus!} So the package can be put on CDROM and run by people who have never heard of XML or Java and who aren't allowed on the WWW (yes, they exist). The HTML_browser/XML/Java combination is therefore exactly what many technical publishers may want for run-anywhere, installation-free manuals, reports, etc. Some conventional dead-trees describing the demo were shipped but failed to make it. The main content of these is in: w3_blurb.html within the distribution. There are also copies of the demo under: w3_index.html Since I wanted people to be able to see at the back, the font has been ramped up in some of the *.html files and you may want to edit these for some platforms. [JUMBO also has its own font selection mechanism both through 'menus' and PIs in the documents, which you may wish to edit.] ------------------------------------------------------------------------------- *************************** README ******************************* JUMBO and XML/CML demonstration ------------------------------- This package is a snapshot at April 11 1997 of the development of: - Chemical Markup Language (an application of XML) - JUMBO (a Java-based browser for XML documents) - Java *.class add-ons for molecular processing - examples of the Virtual Hyperglossary project in XML - example files, data, glossaries, etc. and is arranged as a self-explanatory demonstration. The material was demo'ed at WWW6 1997 at Santa Clara by Jon Bosak of SUN Microsystems. Many thanks, Jon! The distribution contains (at least): demos the top directory pmr the JUMBO classes and the molecular software PLAY classes to display Jon's Shakespeare XML glossary a range of glossaries swissdata a small number of SWISSPROT files in XML icons some icons for Jumbo and classes *.cml, *.xml Example CML and/or XML files *.mol, etc. Files in chemical/* MIME *.html files to drive applets, demos, etc. w3_*.html the W3 demo (start with w3_index.html) index.html start of a more advanced demo The subdirectories contain: glossary 12620 terms from ISO12620 for terminology cif Crystallographic Information File jcamp terms from JCAMP spectroscopic standard local miscellaneous terms mol BUILTIN terms for CML pdb embryonic - terms from Protein Data Bank manual swissprot terms from Swissprot manual tecml BUILTIN terms from TecML units SI units (NOTE: The contents of the glossary entries are copyright the original authors.We have collaborated with all of these and are extremely grateful for permission to produce edited glossaries under XML. No material has been deliberately edited (other than for software compatibility and formatting). pmr euclid, util utility classes simplegraph customisation of Java AWT molecule support for molecular properties sgml application-independent XML support stat simple statistics cml CML support routines chemime support for chemical/* MIME filetypes To run the demo: ---------------- This distribution may be read by at least the following distinct groups: - those interested in XML - those interested in CML - those interested in the VHG so parts of it may not be relevant to everyone. The demo is arranged as an INSTALLATION-FREE distribution, after unpacking. You need only a: Java-enabled browser (e.g. Netscape or Microsoft IE). (if you aren't sure, check under the 'Options' on the menu and see if it has 'Java Console'. If not, it's probably not Java-enabled (e.g. under Windows3.1)) If you have problems later, messages appear in the java console. Simply load your browser and load the file demos/w3_index.html. This will give a brief overview of JUMBO and then give a series of demos which should be automatic. Points to note: - it takes a little while to load the classes initially (perhaps 15-60 sec) but subsequent *.html pages should be rapid. - the windows need manually resizing. (I have spent a LOT of time trying to solve this problem and am now waiting for the next JDK). Sometimes the windows get hidden, and sometimes they don't come back after they have been closed. - very occasionally the demo crashes. In this case, restart the browser and **clear the cache**. - some windows, etc. take a few seconds to respond - be patient and don't click the mouse more than once - you might get 10 windows! This demo will teach you how to run JUMBO and you should become familiar with the use of the folder icons in the tree, clicking on icons, etc. If you then want to go onto a more molecular demo, go to: demos/index.html [You shouldn't have to alter any setup on your machine. However, occasionally browsers do NOT need CLASSPATH set, and it may be worth removing this.] Running JUMBO with other files. ------------------------------- JUMBO can be run BOTH as an applet (above) and as an application. Another way of running as an applet is appletviewer foo.html (This may be useful if foo.html crashes under a browser). To run as an application you will need a Java interpreter (e.g. in JDK). Then type: java pmr.sgml.SGMLTree [] JUMBO will read XML files, ESIS files and chemical/* files. [There may be some restrictions (e.g. not all XML options are supported, although JUMBO can interoperate with NXP or Lark - not in this distribution, I think). Also some chemical/* converters do not cover all the file (especially Gaussian, MOPAC, etc.)]. JUMBO will use the MIMEtype if given, or else try to deduce it from the extension (see mimtypes file). Examples: java pmr.sgml.SGMLTree 1ins.pdb java pmr.sgml.SGMLTree scene1.sgm text/xml java pmr.sgml.SGMLTree junk.foo chemical/x-mdl-molfile java pmr.sgml.SGMLTree bar.esis (I'm not sure whether the last works in this distribution) JUMBO will read the DOCTYPE and try to load a DTD from dtd.classes. If it fails it assumes a DTD of ANY. It will then probably throw a large number of warnings that it can't identify GIs, but will still produce a display. If you want to hack your own WF *.xml, feel free. JUMBO tries to check for content and may throw some warnings - ignore them. JUMBO supports most of XML up to March 31 1997, but some has no obvious rendering (e.g. ID->IDREF has no icons or actions). JUMBO guesses the element title from Content, TITLE attribute or GI in that order. Future Developments ------------------- XML is developing extremely quickly and the spec warns that you cannot rely on anything within it to be 'final'. Future developments in XML *will* be incompatible with this distribution :-). CML is also developing and, again, this is a snapshot of CML1.0. CML1.0 is not completely XML-compatible - there is no support for XML-LINK in the DTD, for example and the use of links (XVAR | TYPE="URL") will be changed to accommodate XML. I believe the XML files are syntactically correct, but may not remain so. So you are advised to use only the components in this distribution, because they are unlikely to interoperate with future ones. Links ----- There is a lot more CML and JUMBO stuff (including FAQs, tutorials, etc) at: http://www.venus.co.uk/omf/cml/ The VHG home page (including other glossaries, a mailing list, ideas of concept maps, etc.) is at: http://www.venus.co.uk/vhg The OMF is at: http://www.ch.ic.ac.uk/omf/ and my home page is at: http://www.nottingham.ac.uk/~pazpmr/ Please mail me with ideas at: peter.murray-rust@nottingham.ac.uk Copyright --------- Most of the material in this distribution is Copyright Peter Murray-Rust, 1997. (The known exceptions are most of the glossaries, and Jon Bosak's Shakespeare). My material is available for personal use and evaluation, but not for redistribution or use within packages whether academic or commercial (unless agreement is obtained). (It is my intention that JUMBO classes will be made availble for widespread free distribution but will not be in the public domain.) Source code will not be available except to committed developers (e.g. through the OMF). However, JUMBO is structured so that it should be possible to do what you want by either extending or overrriding JUMBO classes. Since JUMBO uses the TEI extended pointer search, it's possible to retrieve any subobject from any other. A (slightly out-of-date) API is available on the CML WWW tree above. The author disclaims any responsibility for any loss or damage however caused and makes no representation of the suitability of this material for any purpose. PeterMR April 14 1997 -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Wed Apr 16 10:48:52 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:43 2004 Subject: APIs Message-ID: <5729@ursus.demon.co.uk> Now that D-Day has passed off so successfully it's important that we get back to APIs. It's very exciting to hear of manufacturers who are committed to XML and I hope this list can be a valuable place for them to trade ideas and information where it's appropriate. Lots of people will now be thinking about how to build an XML system :-) [Some of this is commercially sensitive, and xml-dev welcomes any members who are read-only :-).]. XML ideally lends itself to componentisation and I hope definition of some common components can arise soon. For example, there are terms like 'XML processor', 'application', 'link processor', 'parser', 'editor', 'browser' being mentioned. The present parsers (Lark and NXP) seem excellent examples of clear-cut components. I interface with them either through Esis_Stream (NXP) or Element (Lark). I think we are the stage (following some very helpful earlier contributions) where we could work towards an API at this level - we really need a volunteer to get a small virtual team off the ground, with some milestones. [I had to decline the offer to organise this as I have to get the Virtual School developed, and I've also got to develop CML. I'd be happy to take part]. I'd stress that this needs to be simple - in the spirit of XML - remembering that a significant number of developers may have relatively little prior experience of SGML. [I'm really waiting for this to happen so that I can rejig JUMBO internally - should I subclass its Nodes from Elements, or should I build a new tree, for example?] I would like comments on XML-LINK and a 'link processor'. It seems logical that parsers have some role in validating XML-LINK input (there are some syntactic constraints that cannot be easily expressed in a conventional DTD, such as that EXTENDED elements can only contain LOCATORs (and #PCDATA). Of course this can be done explicitly, perhaps through parameter entities.). I have ended up putting most of the XML-LINK processing under my Attlist class, so that a Node (Element) can be asked isLink() when being traversed (this is necessary for ACTUATE=AUTO functionality). We must remember that tree traversal can occur in different contexts and SHOW may not always be graphical. I have hacked some of EMBED yesterday and would like comments. In JUMBO there are two sorts of autonomous 'windows' (Java Frames) - one for the Tree (= TOC) and the others for individual nodes. EMBED/REPLACE/NEW are relatively straightforward for TOCs but less clear for the others (e.g. how does one EMBED a BIBliography in a MOLecule? Can the 'host' refuse :-) In fact I tend to come down to EMBEDing only in hypertextlike objects which work on an Event stream (e.g. HTML). In that context I use: XML-LINK="SIMPLE" SHOW="EMBED" ACTUATE="AUTO"> and require the target (say FOO) to have a FOO.display(Graphics) method. The hypertext provides a screen area into which FOO draws its normal output. This works quite nicely (though I'm not an expert here). Therefore there is an implicit convention that an Embeddable has a display(g) routine (this could be formalised in an API Interface). With inline strings I use XML-LINK="SIMPLE" SHOW="EMBED" ACTUATE=AUTO/USER> With AUTO the *text* of FOO is inserted automatically , and FOO must have a toString() method. With USER, it is inserted when the hypertext is clicked. (All these also allow clicking to display the whole target as a free-standing object, e.g. clicking on the first IMG will display() FOO as a free-standing Frame.). An important thing is that this is all largely *application-independent* The targets have no knowledge they will be embedded (and they often don't know even when they *have* been!). The Embedders are a select company, TOC, HyperFlow (my **crude** HTML renderer - anyone got a better one?), and one or two application classes. I am very keen that this interfaces with other browsers (I'm a chemist not a software person :-) and would like to be able to (say) get a browser from elsewhere and know that it supports XML-LANG, XML-LINK at an application-independent level (e.g. stuff like that above), and good interactivity with Java. One thing I'd really like to able to do is get an application class to create some hypertext, send it to the browser for display but know that the browser will route back any XML-LINK events. If that is achievable, WOW! HTMS P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Bertrand.Melese at grif.grif.fr Wed Apr 16 10:55:20 1997 From: Bertrand.Melese at grif.grif.fr (Bertrand Melese) Date: Mon Jun 7 16:57:43 2004 Subject: pointers to WWW6 D-Day XML track demos? Message-ID: <199704160854.AA00307@isis.grif.fr> At 08:12 16/04/97 -0700, Norbert H. Mikula wrote: >Mike_Spreitzer.PARC@xerox.com wrote: >> I attended the XML track of WWW6 D-Day, and found it interesting. >> I'd like a >> list of links to the demos and/or information about what was demoed. GRIF has demoed the alpha version of its new XML authoring tool. This demonstration shows how Grif's SGML-based authoring technology can be used to create and publish XML documents with or without a DTD, and how new tags can be added interactively to HTML documents using an XML-enabled HTML authoring tool. The demo also shows interactive definition of CSS rules to format these new tags, as well as to change the formating of other already existing tags. Documents describing this demos will be on our server http://www.grif.fr in the next few days. Bertrand MELESE President , Grif Bertrand.Melese@grif.fr http://www.grif.fr Phone: +33 1 30 12 14 30 Fax: +33 1 30 64 06 46 Grif SA, BP 266 78053 St Quentin en Yvelines CEDEX, FRANCE xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Wed Apr 16 20:44:35 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:43 2004 Subject: APIs Message-ID: <5734@ursus.demon.co.uk> In message <199704161317.JAA05023@nathaniel.ebt> gtn@eps.inso.com (Gavin Nicol) writes: [...] > > We should be aware that the W3C also has a working group called > the DOM WG (DOM = Document Object Model). It would be ideal if the > object models were one and the same. I tried to find this in the W3C pages and failed. Any pointers? P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Thu Apr 17 10:28:57 1997 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 16:57:43 2004 Subject: pointers to WWW6 D-Day XML track demos? In-Reply-To: Mike_Spreitzer.PARC@xerox.com's message of Tue, 15 Apr 1997 21:45:28 PDT References: <97Apr15.214556pdt."17827(10)"@alpha.xerox.com> Message-ID: <1085.199704170828@grogan.cogsci.ed.ac.uk> I demoed LT XML and DSC. LT XML is an XML developers' toolkit, based on LT NSL, our existing SGML developers' toolkit. Information about LT NSL can be found at http://www.ltg.ed.ac.uk/software/nsl/ LT XML, which will be free to all, will be released by the end of the month: its functionality will be very similar to LT NSL, as described at the above site, but for XML instead of SGML. DSC is a DSSSL syntax checker and development environment, based on a full R4RS Scheme embedded in SP. The current limited-functionality release is described at http://www.ltg.ed.ac.uk/~ht/dsc-blurb.html The release I demonstrated, including basic support for the transformation language, will be available by mid-June: watch this space. ht xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Fri Apr 18 10:19:29 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:43 2004 Subject: Performance Message-ID: <5764@ursus.demon.co.uk> The question of caching documents (Trees) has been raised on XML-WG and whilst I'm a believer in leaving performance until late in the day, it's useful to think about it now. (JUMBO is presently well-named as large, slow, and dumps on you at regular intervals). With AUTO/NEW one you start generating a lot of Trees, especially if you have a 'Back' button. Leaving them all around will (presumably) eat up memory quite quickly. Perhaps a PI could give hints that a tree was likely to be re-used? JUMBO is slow partly because there is 500 Kbyte of *.class (it covers everything from matrix algebra through stats, graphics, molecules as well as having a general XML GUI.) In cases where you know that there is only likely to be one tree the parser could be garbage collected, for example after it had been used. Again this could be done through a PI? Another problem is when you load new class libraries for a new DTD. E.g. when I have finished with molecules and go on to PLAY, I'd like to get rid of the molecule *.class. *** is there a way of telling Java to collect *classes* as well as objects?*** (Or will this only happen when the last object of that class has been garbaged?? P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From bosak at atlantic-83.Eng.Sun.COM Fri Apr 18 20:01:51 1997 From: bosak at atlantic-83.Eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 16:57:43 2004 Subject: "View Structure" Message-ID: <199704181759.KAA07880@boethius.eng.sun.com> Jumbo's ability to show *any* XML document based purely on its tree structure leads me to propose a convention among those who are developing XML browsers. All common Web broswers today have a "View Source" option that lets you look at the HTML source file. We all know how useful this is. Future XML browsers will presumably have a similar option. Because every well-formed XML document describes a tree, however, it's also possible to have a "View Structure" option that would give you a default navigable view of the document as a tree -- like the default Jumbo behavior. This view would allow you to expand and collapse the structure and it would show attribute nodes that could be opened to see the attributes on each element. It could use a file manager metaphor, like Jumbo, or it could use the plus-button/minus-button interface used for most dynamic browser TOCs, or it could use something else; the point is that it would be trivially autogenerated on request, show the document in XML terms, and provide a commonly understood base view independent of the application interface supplied for a given document type that would always be available to people trying to understand or debug an XML document. "View Structure" would presumably *not* use different type sizes, etc., but concentrate instead on exposing the guts of the document, so I would expect the display generated by character-mode browsers to look roughly the same as the display generated by the fancy graphics-mode browsers. This would just be an informal convention, like the inclusion of "View Source," but I think that it would be an extremely useful one. Jon xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From istvanc at microsoft.com Fri Apr 18 20:08:48 1997 From: istvanc at microsoft.com (Istvan Cseri) Date: Mon Jun 7 16:57:43 2004 Subject: Performance Message-ID: <91B7E292027DCF1195CD08002BB690B001917048@RED-93-MSG.dns.microsoft.com> The new JDK from Sun is garbage collecting classes (they said that in the JavaOne conference). Of course they can only do that when the last object of that class is garbage collected. Istvan > ---------- > From: Peter@ursus.demon.co.uk[SMTP:Peter@ursus.demon.co.uk] > Sent: Friday, April 18, 1997 1:18 AM > To: xml-dev@ic.ac.uk > Subject: Performance > > The question of caching documents (Trees) has been raised on XML-WG > and whilst > I'm a believer in leaving performance until late in the day, it's > useful to > think about it now. (JUMBO is > presently well-named as large, slow, and dumps on you at regular > intervals). > With AUTO/NEW one you start generating a lot of Trees, especially if > you have > a 'Back' button. Leaving them all around will (presumably) eat up > memory > quite quickly. Perhaps a PI could give hints that a tree was likely > to be > re-used? > > JUMBO is slow partly because there is 500 Kbyte of *.class (it covers > everything > from matrix algebra through stats, graphics, molecules as well as > having a > general XML GUI.) In cases where you know that there is only likely > to be one > tree the parser could be garbage collected, for example after it had > been used. > Again this could be done through a PI? Another problem is when you > load new > class libraries for a new DTD. E.g. when I have finished with > molecules and > go on to PLAY, I'd like to get rid of the molecule *.class. *** is > there a > way of telling Java to collect *classes* as well as objects?*** (Or > will this > only happen when the last object of that class has been garbaged?? > > P. > > -- > Peter Murray-Rust, domestic net connection > Virtual School of Molecular Sciences > http://www.vsms.nottingham.ac.uk/ > > xml-dev: A list for W3C XML Developers > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To unsubscribe, send to majordomo@ic.ac.uk the following message; > unsubscribe xml-dev > List coordinator, Henry Rzepa (rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Fri Apr 18 22:27:32 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:44 2004 Subject: "View Structure" Message-ID: <5785@ursus.demon.co.uk> Thanks Jon, This is extremely useful and I hope others like the approach. 'Show XML' (i.e. View Source) was added quite recently in JUMBO. There is also a 'Save as XML' [to file] which is essentially the same and brings up a file browser (only in (Java)applications - not applets, of course) 'Show source' is not completely trivial, and JUMBO shows the normalised source (essentially the ESIS output from SGMLS/NXP, etc.) [In fact JUMBO will read in ESIS]. I bow to the experts but essentially this means that JUMBO has destroyed some of the grove and does NOT contain: - comments (the spec is not normative about what a useragent may/must contain. - declaration subset. (or indeed any other part of the DTD) - DOCTYPE info (except JUMBO preserves the DTD name, although ESIS does not) - marked section information - character entities - knowledge about empty elements (ESIS doesn't know and I suspect that some of the parsers discard this) This means that JUMBO (and probably most other browsers) views 'normalised source'. Also, JUMBO is not quite clear about whitespace (Argh!). It does not honour the DEFAULT|PRESERVE because (a) it isn't absolutely clear that this is the final word on the subject and (b) I don't use this convention myself. Also (again because I do not expect my customers to understand REs), all my #PCDATA can have folded whitespace. Therefore I prettyprint (not very pretty) so that no characters run beyond 80 chars. (This is trivial and there could be a menu/switch for this.) Also I expect I have got the REs in mixed content wrong. At present I put each tag on a different line for human readability. It's possible that in some places this will introduce false REs (I need someone to soak test it). Also, since this is an area in the spec where the boundaries between the parser and application are not absolutley clear, we need more testing. JUMBO honours PIs (and uses them). I create PIs as Nodes under other Nodes e.g. would have a PI node hanging under FOO. When the tree was traversed, the PI would come immediately after FOO. JUMBO takes whatever comes out of a parser. If a PI in the middle of #PCDATA forms two Pseudoelements, it honours those, with a PI in between. i.e. This is HUGE would have three children of FOO (PCDATA1, PI and PCDATA2 in that order). I am assuming that a parser can only create the following NodeTypes: Elements (e.g. FOO) PCDATA PI Comment (if appropriate) I am assuming that (unlike CoST) there are no PELs such as RE. In JUMBO, PCDATA and PIs are dealt with in the same way as Elements (comments are ignored). [I gave them GIs of _PCDATA and _PI - thinking this was safe because underscore was forbidden. Now I will have to do something else (although anyone who gratuitously creates a _PCDATA GI is asking for trouble :).] The advantage of this is that they can have icons, buttons and I treat them like first-class citizens. The conclusion of this is that 'View source' will not necessarily help people who want to see every character in the source. (JUMBO may not even have access to this in some distributed system). I'd value comment if I've got my components wrong. Oh! I forgot attributes. JUMBO plays back the attributes in the order they were given, but will have folded the NAME to uppercase. Entities will have been resolved and space will have been normalised (mainly at the parser). In message <199704181759.KAA07880@boethius.eng.sun.com> bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: [...] > > Because every well-formed XML document describes a tree, however, it's > also possible to have a "View Structure" option that would give you a > default navigable view of the document as a tree -- like the default > Jumbo behavior. This view would allow you to expand and collapse the > structure and it would show attribute nodes that could be opened to > see the attributes on each element. It could use a file manager > metaphor, like Jumbo, or it could use the plus-button/minus-button > interface used for most dynamic browser TOCs, or it could use > something else; the point is that it would be trivially autogenerated > on request, show the document in XML terms, and provide a commonly > understood base view independent of the application interface supplied > for a given document type that would always be available to people > trying to understand or debug an XML document. "View Structure" would > presumably *not* use different type sizes, etc., but concentrate > instead on exposing the guts of the document, so I would expect the > display generated by character-mode browsers to look roughly the same > as the display generated by the fancy graphics-mode browsers. An additional thing in here is 'show attributes' (JUMBO has this as a button for those nodes which *have* attributes.) Of course some of the attribute information in the DTD may be lost - JUMBO does not always know which the IDs and IDREFs are. (I may have missed it in the spec, but I am not sure parsers have to keep this info). I assume that PCDATA can be displayed in the tree. (My code is suspect here, partly because I was not quite clear what was going to happen. However under certain circumstances it will create PCDATA nodes and display them. These nodes may not have children. The same is true for PIs. > > This would just be an informal convention, like the inclusion of "View > Source," but I think that it would be an extremely useful one. Agreed. It also helps to clarify the parser | treetool division of responsibilities the treetool | linkprocessor division and the processor | application division. I am still struggling with event streams. There is no formal way in the language to flag an event stream and at times I think this would be useful. It can save a lot on memory allocation for the tree (because the stream need not be parsed until viewed). It is also not much fun viewing an event stream as a tree :-) Point JUMBO at an HTML document (normalised to XML) and it isn't very intuitive... P. > > Jon > > > xml-dev: A list for W3C XML Developers > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To unsubscribe, send to majordomo@ic.ac.uk the following message; > unsubscribe xml-dev > List coordinator, Henry Rzepa (rzepa@ic.ac.uk) > > -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From kbest at Adobe.COM Fri Apr 18 23:59:45 1997 From: kbest at Adobe.COM (Karl F. Best) Date: Mon Jun 7 16:57:44 2004 Subject: "View Structure" References: <199704181759.KAA07880@boethius.eng.sun.com> Message-ID: <3357EE04.71F4@adobe.com> Jon Bosak wrote: > Because every well-formed XML document describes a tree, however, it's > also possible to have a "View Structure" option that would give you a > default navigable view of the document as a tree -- like the default > Jumbo behavior. This view would allow you to expand and collapse the > structure and it would show attribute nodes that could be opened to > see the attributes on each element. It could use a file manager > metaphor, like Jumbo, or it could use the plus-button/minus-button > interface used for most dynamic browser TOCs, or it could use > something else; the point is that it would be trivially autogenerated > on request, show the document in XML terms, and provide a commonly > understood base view independent of the application interface supplied > for a given document type that would always be available to people > trying to understand or debug an XML document. "View Structure" would > presumably *not* use different type sizes, etc., but concentrate > instead on exposing the guts of the document, so I would expect the > display generated by character-mode browsers to look roughly the same > as the display generated by the fancy graphics-mode browsers. An excellent example of this sort of view is found in FrameMaker+SGML's Structure View. It's useful for navigation, is easily expanded and contracted, and displays attributes too. (I loved this view even before I joined Adobe, honest!) ====================================================================== Karl F. Best voice 408-536-6531 Manager, Frame Developer Support fax 408-536-6883 Adobe Systems - San Jose, CA kbest@adobe.com ====================================================================== xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From ebaatz at barbaresco.East.Sun.COM Mon Apr 21 00:14:25 1997 From: ebaatz at barbaresco.East.Sun.COM (Eric Baatz - Sun Microsystems Labs BOS) Date: Mon Jun 7 16:57:44 2004 Subject: Motivation for "_" as a name Message-ID: In the 31-Mar-97 W3C Working Draft is the following definition: [5] Name ::= (Letter | '_') (NameChar)* This seems to allow "_" to be a name and "<_>" and "" to be start- and end-tags, which seems "odd" to this acknowledged alphabetics bigot. Is that the intent of the Draft? If not, is something like the following the intent: [5] Name ::= (Letter | "_" (Letter)+ ) (NameChar)* Or perhaps [5] Name ::= (Letter | "_" (Letter)+ | "_" (Digit)+ ) (NameChar)* Eric Baatz Sun Microsystems Laboratories 2 Elizabeth Drive, MS UCHL03-207 (508) 442-0257 Chelmsford, MA 01824 fax: (508) 250-5067 USA Internet: eric.baatz@east.sun.com xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From ebaatz at barbaresco.East.Sun.COM Mon Apr 21 01:19:43 1997 From: ebaatz at barbaresco.East.Sun.COM (Eric Baatz - Sun Microsystems Labs BOS) Date: Mon Jun 7 16:57:44 2004 Subject: What are XML's namespaces? Message-ID: I didn't notice any mention in the April Draft of XML having one or more namespaces. By that I mean if element names and attribute names share the same namespace then I can't have an element with the same name as an attribute. I suspect that the answer is "just like SGML," but I'm deathly ignorant of SGML, so I need a layman's explanation or a narrowly focused pointer into a document about SGML that I can borrow or find on the Web. Thanks for starting to educate me. Eric Baatz Sun Microsystems Laboratories 2 Elizabeth Drive, MS UCHL03-207 (508) 442-0257 Chelmsford, MA 01824 fax: (508) 250-5067 USA Internet: eric.baatz@east.sun.com xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From tallen at sonic.net Mon Apr 21 02:17:33 1997 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 16:57:44 2004 Subject: Test XML DTD derived from Docbook Message-ID: <199704210019.RAA29920@bolt.sonic.net> In order to determine what would need to be changed in Docbook to make it an XML DTD (a project the Davenport Group is contemplating under the working name Duckbook, "Docbook for the Webbed," as Jon dubbed it), I've constructed a first cut, available at http://www.sonic.net/~tallen/xdb01.zip This is not yet Duckbook, and the Public Identifiers and copyright notice are for convenience rather than an assertion of where this effort is going. The zip file contains a catalogue, a test file "blue", and four DTD/entity files: xdb.dtd, xdbhier.mod, xdbpool.mod, and xdbgen.mod. I tested a variant of this set (the variants included minimization parameters) and "blue" parses as SGML. I would be grateful if members of this group who are running XML parsers would take the time to see whether this DTD, XDB 0.1, is valid XML. Please send me comments at tallen@sonic.net. This release is not intended for real work, and I do not warrant that it is good for anything, will not cause data loss or equipment failure, or will not rot your mind. I excised all the table stuff, as I suspect that the CALS table module we used (from SO TR9502) is probably not XML-safe. If anyone has adapted it for XML and is willing to share, please let me know. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net http://www.sonic.net/~tallen/ Davenport and DocBook: http://www.ora.com/davenport/index.html T.A. at Passage Systems: terry.allen[at]passage.com xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From geirog at falch.no Mon Apr 21 12:05:13 1997 From: geirog at falch.no (geirog@falch.no) Date: Mon Jun 7 16:57:44 2004 Subject: XML and repeatable model groups Message-ID: <3.0.1.32.19970421120515.00ba9a58@falch.no> Hello, I've been trying to modify Jon Bosak's SHAKESPEARE dtd in order to make it work with the newest version of NSGMLSU (ver. 1.1.4), that came with Jade 0.7. Using this command: d:\sgml\instans\shakespe>nsgmlsu -wxml -s hamlet.xml ---------------------------------------------------------------------- >From the dtd: This is correct, so no errors are reported. ---------------------------------------------------------------------- >From the dtd: D:\WINUTILS\JADE\NSGMLSU.EXE:shakspe2.dtd:22:39:W: #PCDATA in model group that is not repeatable Why is this flagged as an error/warning? Isn't this a repeatable model group? Or isn't (#PCDATA | stagedir)+ a legal model group in XML? ---------------------------------------------------------------------- >From the XML-draft (970331) section 3.2.2: Mixed-content declaration[45]? Mixed::= '(' S? %( %'#PCDATA' ( S? '|' S? %(%Name (S? '|' S? %Name)*) )* ) S? ')*' | '(' S? %('#PCDATA') S? ')' '*'? The spec doesn't seem to allow '+' in a Mixed-content declaration. Is this correct? ------------------ Geir Ove Gr?nmo ------------------ Falch Infotek as, Stanseveien 21, 0902 Oslo, Norway Phone: +47 22 90 27 36 Fax: +47 22 90 25 99 [grove@falch.no | http://www.falch.no/people/geirog] ------------------------------------------------------- xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Mon Apr 21 12:21:43 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:45 2004 Subject: XML and repeatable model groups In-Reply-To: <3.0.1.32.19970421120515.00ba9a58@falch.no> References: <3.0.1.32.19970421120515.00ba9a58@falch.no> Message-ID: <199704211021.GAA00204@localhost> geirog@falch.no writes: > >From the dtd: > > D:\WINUTILS\JADE\NSGMLSU.EXE:shakspe2.dtd:22:39:W: #PCDATA in model group > that is not repeatable > > Why is this flagged as an error/warning? Isn't this a repeatable model group? > Or isn't (#PCDATA | stagedir)+ a legal model group in XML? The message should have read "#PCDATA in model group that is not optional and repeatable". The draft XML spec allows mixed content only as an optional and repeatable OR group, where #PCDATA is the first member. By the way, you gain nothing by using "+" instead of "*", since #PCDATA can be an empty string. For example, in full SGML, the following would satisfy (#PCDATA | stagedir)+ as well as it satisfies (#PCDATA | stagedir)*: All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From geirog at falch.no Mon Apr 21 12:51:08 1997 From: geirog at falch.no (geirog@falch.no) Date: Mon Jun 7 16:57:45 2004 Subject: #PCDATA in model group that is not optional and repeatable (was: XML and repeatable model groups) In-Reply-To: <199704211021.GAA00204@localhost> References: <3.0.1.32.19970421120515.00ba9a58@falch.no> <3.0.1.32.19970421120515.00ba9a58@falch.no> Message-ID: <3.0.1.32.19970421125119.007458a0@falch.no> At 11:21 21.04.97 +0100, you wrote: >The message should have read "#PCDATA in model group that is not >optional and repeatable". The draft XML spec allows mixed content >only as an optional and repeatable OR group, where #PCDATA is the >first member. >By the way, you gain nothing by using "+" instead of "*", since >#PCDATA can be an empty string. I know, but why isn't it allowed at all? (or why was it allowed in SGML in the first place?) >For example, in full SGML, the >following would satisfy (#PCDATA | stagedir)+ as well as it satisfies >(#PCDATA | stagedir)*: This means that I have to change all occurences of '+' to '*' in mixed-content declarations in my SGML dtds in order to make them XML compliant. Perhaps it is better if I change my existing SGML dtds instead... :-) Thank you, ------------------ Geir Ove Gr?nmo ------------------ Falch Infotek as, Stanseveien 21, 0902 Oslo, Norway Phone: +47 22 90 27 36 Fax: +47 22 90 25 99 [grove@falch.no | http://www.falch.no/people/geirog] ------------------------------------------------------- xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From dmeggins at uottawa.ca Mon Apr 21 12:58:36 1997 From: dmeggins at uottawa.ca (David Megginson) Date: Mon Jun 7 16:57:45 2004 Subject: #PCDATA in model group that is not optional and repeatable (was: XML and repeatable model groups) In-Reply-To: <3.0.1.32.19970421125119.007458a0@falch.no> References: <3.0.1.32.19970421120515.00ba9a58@falch.no> <199704211021.GAA00204@localhost> <3.0.1.32.19970421125119.007458a0@falch.no> Message-ID: <199704211056.GAA00366@localhost> geirog@falch.no writes: > >By the way, you gain nothing by using "+" instead of "*", since > >#PCDATA can be an empty string. > > I know, but why isn't it allowed at all? (or why was it allowed in SGML in > the first place?) Because full SGML treats all content models equally, while XML attaches special restrictions to those with mixed content. Full SGML also allows relatively useless expressions like (#PCDATA & foo)* (#PCDATA)+ and it will let you do many other strange things, as long as your content model does not become ambiguous. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com University of Ottawa dmeggins@uottawa.ca http://www.uottawa.ca/~dmeggins xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From eliot at isogen.com Mon Apr 21 14:38:48 1997 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 16:57:45 2004 Subject: What are XML's namespaces? Message-ID: <3.0.32.19970421063540.00aa6e80@swbell.net> At 07:15 PM 4/20/97 -0400, Eric Baatz - Sun Microsystems Labs BOS wrote: >I didn't notice any mention in the April Draft of XML having one or >more namespaces. By that I mean if element names and attribute >names share the same namespace then I can't have an element with >the same name as an attribute. I suspect that the answer is >"just like SGML," but I'm deathly ignorant of SGML, so I need >a layman's explanation or a narrowly focused pointer into a >document about SGML that I can borrow or find on the Web. The full set of name spaces in SGML is defined in the SGML property set, first published in the DSSSL standard (see www.jclark.com for an electronic copy) and soon to be re-published, slightly revised, in the HyTime standard. The primary name spaces in SGML are: o Element types: unique within a document o General entity names: unique within a document o Parameter entity names: unique within a document o Element IDs: unique within a document o Notation names: unique within a document o Attributes: unique within an element type o Name groups as attribute value prescriptions: Unique within an element type (today), soon to be unique within an attribute w/in an element type All names except entity names are not case sensitive in the reference concrete syntax. Note that architectures and applications could define additional name spaces by defining either extensions to the SGML property set (as HyTime does) or their own semantic property set (as HyTime also does) in which additional name space properties are defined. As a resource for further investigation, you may find the recently-published "The Concise SGML Companion", by Neil Bradley to be useful. It provides a compact and very accessible reference to the SGML standard. I found it to be very accurate (I only found a few errors of fact, and most of those were quibles that only SGML wonks like me would care about). ISBN 0-201-41999-9, 29.95 Dollars US, Addison Wesley. Cheers, Eliot xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Ingo.Macherius at tu-clausthal.de Mon Apr 21 15:22:45 1997 From: Ingo.Macherius at tu-clausthal.de (Ingo Macherius) Date: Mon Jun 7 16:57:45 2004 Subject: small questions Message-ID: <199704211322.PAA14496@kneipfix.rz.tu-clausthal.de> While writing my article (submitted to editor :) a few small questions came up. If anyone knows the answers, please let me know. 1) Link modell Given an instance like ... ...
... ...
... ... ... to model a monthly magazine, does the locator http://www.publisher.com/magazine#CHILD(2,article)(3,issue)(4,year) yield *all* children of 2nd article in 3rd issue in 4th year ? This is my understanding of WD-xml-link-970406, 5.3.2 ... but I am not sure. 2) WWW6 conference canonical URL Is there a browseable version if Jon Bosak's WWW6 talk. I just found the archives on sunsite. Is there something similar for Tim Brays talk on XML links ? 3) Javasoft Are there plans to integrate an XML parser into the future standard libs for Java ? Please ignore if this question is too political. 4) XML tools Have I missed a XML related tool ? Got NXP, LARK, JUMBO, JADE, LT NSL and all of sunsite's examples. Thanks in advance ++im -- Snail : Ingo Macherius // L'Aigler Platz 4 // D-38678 Clausthal-Zellerfeld Mail : Ingo.Macherius@tu-clausthal.de WWW: http://www.tu-clausthal.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Frank Zappa) xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Mon Apr 21 16:05:47 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:45 2004 Subject: small questions Message-ID: <5878@ursus.demon.co.uk> In message <199704211322.PAA14496@kneipfix.rz.tu-clausthal.de> Ingo Macherius writes: > > While writing my article (submitted to editor :) a few small questions > came up. If anyone knows the answers, please let me know. > > 1) Link modell > > Given an instance like > ... > ... >
... > ... >
... > > >
> ... > ... >
... > ... > ... > ... > > > > ... > > > to model a monthly magazine, does the locator > http://www.publisher.com/magazine#CHILD(2,article)(3,issue)(4,year) > yield *all* children of 2nd article in 3rd issue in 4th year ? This is my > understanding of WD-xml-link-970406, 5.3.2 ... but I am not sure. > I asked a similar question some time ago but none of the gurus replied. My interpretation of the TEI synatx (and I don't think it's clear in the draft) is that a sequence like: is identical to the (meaningful) sequence FOO(1,BAR1)FOO(2,BAR2)FOO(3,BAR3) and the operator is implicit in the shorter form. JUMBO would presently expand your query to: CHILD(2,article)CHILD(3,issue)CHILD(4,year) which would fail for your document. A typical query for me would be CHILD(1,YEAR)(2,ISSUE)(1,ARTICLE) which would be equivalent to ID(FOO) If you want ALL of something, you have to write ALL (the spec is clear on that :-) *** TEI experts/ERB *** please shine some light on this :-) ********* P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From eliot at isogen.com Mon Apr 21 16:56:04 1997 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 16:57:45 2004 Subject: What are XML's namespaces? Message-ID: <3.0.32.19970421085037.00aab5d0@swbell.net> At 06:35 AM 4/21/97 -0900, W. Eliot Kimber wrote: >Note that architectures and applications could define additional name >spaces by defining either extensions to the SGML property set (as HyTime >does) or their own semantic property set (as HyTime also does) in which >additional name space properties are defined. I mispoke here a bit about property sets. HyTime doesn't extend the SGML property set, it defines additional property sets that define objects and properties understood by a HyTime processor. Any application or architecture can do the same thing. The SGML Extended Facilities (Annex A to the corrected HyTime standard), does add a module to the SGML property set in order to support those facilities, but it does not modify the existing property set. Cheers, E. xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Peter at ursus.demon.co.uk Tue Apr 22 00:38:16 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:45 2004 Subject: Test XML DTD derived from Docbook Message-ID: <5892@ursus.demon.co.uk> In message <199704210019.RAA29920@bolt.sonic.net> Terry Allen writes: > > In order to determine what would need to be changed in Docbook to make > it an XML DTD (a project the Davenport Group is contemplating under > the working name Duckbook, "Docbook for the Webbed," as Jon dubbed it), ^^^^^^^^ I love this! Is it chance that we are getting a biological flavour to our tools? > I've constructed a first cut, available at > > http://www.sonic.net/~tallen/xdb01.zip > > This is not yet Duckbook, and the Public Identifiers and copyright > notice are for convenience rather than an assertion of where this > effort is going. The zip file contains a catalogue, a test file > "blue", and four DTD/entity files: xdb.dtd, xdbhier.mod, xdbpool.mod, > and xdbgen.mod. I tested a variant of this set (the variants > included minimization parameters) and "blue" parses as SGML. This is an impressive piece of work - ca. 5000 lines. I have run a first pass with a well-known XML parser - I shall honour confidentiality at this stage :-) For note; this references a variety of entitysets which I didn't have to hand. > > I would be grateful if members of this group who are running XML > parsers would take the time to see whether this DTD, XDB 0.1, > is valid XML. Please send me comments at tallen@sonic.net. I will do so. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From tallen at sonic.net Tue Apr 22 18:55:10 1997 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 16:57:45 2004 Subject: XDB v0.2 available (Docbook-derived) Message-ID: <199704221656.JAA18410@bolt.sonic.net> Thanks to James and Jade07, I've been able to rework the previously announced XDB DTD, derived from Docbook v3.0, removing all the errors Jade07 catches. This version, 0.2, is available at http://www.sonic.net/~tallen/xdb02.zip It contains a hand-hacked version of the TR 9502 SGML Open CALS table model, and except for the two elements that were included in content models, it is, I believe, looser than Docbook and not more restrictive anywhere. I haven't tested that belief. The two elements were BeginPage (which is gone; use processing instructions) and IndexTerm, which is available only where #PCDATA may be used (it is possible to allow it in component mixtures, too, as Eve has suggested, but I haven't). Ah, one more restrictive spot occurs to me as I write: Entry in Table does not allow mixed content in this DTD. I would be interested to hear whether mixed content (#PCDATA, inlines, blocks such as lists) would cause problems for style sheets if allowed in table cells. Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net http://www.sonic.net/~tallen/ Davenport and DocBook: http://www.ora.com/davenport/index.html T.A. at Passage Systems: terry.allen[at]passage.com xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From richard at light.demon.co.uk Tue Apr 22 23:01:19 1997 From: richard at light.demon.co.uk (Richard Light) Date: Mon Jun 7 16:57:45 2004 Subject: small questions In-Reply-To: <5878@ursus.demon.co.uk> Message-ID: In message <5878@ursus.demon.co.uk>, Peter Murray-Rust writes >I asked a similar question some time ago but none of the gurus replied. >My interpretation of the TEI synatx (and I don't think it's clear in the draft) >is that a sequence like: > FOO(1,BAR1)(2,BAR2)(3,BAR3) >is identical to the (meaningful) sequence > FOO(1,BAR1)FOO(2,BAR2)FOO(3,BAR3) >and the operator is implicit in the shorter form. JUMBO would presently >expand your query to: > CHILD(2,article)CHILD(3,issue)CHILD(4,year) >which would fail for your document. A typical query for me would be > CHILD(1,YEAR)(2,ISSUE)(1,ARTICLE) >which would be equivalent to > ID(FOO) > >If you want ALL of something, you have to write ALL (the spec is clear >on that :-) > >*** TEI experts/ERB *** please shine some light on this :-) ********* I'm not claiming guru status, but I think I can help with this one (if only because I've got the Big Green TEI Book which contains more examples!). You may find it non-intuitive, but the draft does state clearly that the value of CHILD is "a _series_ of steps", where each step is a bracketed expression. Thus there is no need to 'expand': CHILD(2 article) (3 issue) (4 year) to CHILD(2 article)CHILD(3 issue)CHILD(4 year) as it already has this meaning. This is in line with the general aim of the TEI extended pointer mechanism to be as concise as possible. (Note also that there are no commas between the numbers and the element names.) (Incidentally, it also says that the steps are "separated by white space", but there is nothing in the XML draft syntax, nor in the TEI source from which it was copied, which enforces this. Is this an issue, either for TEI or for XML?) Richard Light SGML and Museum Information Consultancy richard@light.demon.co.uk 3 Midfields Walk Burgess Hill West Sussex RH15 8JA U.K. tel. (44) 1444 232067 xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From Ingo.Macherius at tu-clausthal.de Wed Apr 23 20:59:55 1997 From: Ingo.Macherius at tu-clausthal.de (Ingo Macherius) Date: Mon Jun 7 16:57:46 2004 Subject: small questions (fwd) Message-ID: <199704231859.UAA23830@kneipfix.rz.tu-clausthal.de> I received this mail in answer of my xml-dev posting, but never saw it reaching the list, despite CC: It does not appear in the archives, too. So this is my forward :) C M Sperberg-McQueen said: | From cmsmcq@tigger.cc.uic.edu Tue Apr 22 15:08:07 1997 | Date: Tue, 22 Apr 1997 08:05:37 -0500 | Message-Id: <199704221305.IAA112158@tigger.cc.uic.edu> | From: C M Sperberg-McQueen | To: Ingo.Macherius@tu-clausthal.de | CC: xml-dev@ic.ac.uk, cmsmcq@uic.edu | In-reply-to: <199704211322.PAA14496@kneipfix.rz.tu-clausthal.de> (message from | Ingo Macherius on Mon, 21 Apr 1997 15:22:37 +0200 (MET DST)) | Subject: Re: small questions | | >While writing my article (submitted to editor :) a few small questions | >came up. If anyone knows the answers, please let me know. | > | >1) Link modell | > | >Given an instance like | > ... | >to model a monthly magazine, does the locator | > http://www.publisher.com/magazine#CHILD(2,article)(3,issue)(4,year) | >yield *all* children of 2nd article in 3rd issue in 4th year ? This is my | >understanding of WD-xml-link-970406, 5.3.2 ... but I am not sure. | | It yields (unless there is some undetected difference from TEI pointers | which I've missed) the fourth YEAR element within the third ISSUE | within the second ARTICLE directly contained within the root element. | | In other words, you have your parameter groups backwards. | | The result is the element named, not its tags. The children of | the element are part of the element, so they are addressed, as a | package. | | -C. M. Sperberg-McQueen | -- Snail : Ingo Macherius // L'Aigler Platz 4 // D-38678 Clausthal-Zellerfeld Mail : Ingo.Macherius@tu-clausthal.de WWW: http://www.tu-clausthal.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Frank Zappa) xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk) From jjc at jclark.com Thu Apr 24 13:55:31 1997 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 16:57:46 2004 Subject: XML xpointers in SDQL Message-ID: <2.2.32.19970424114123.00b48388@jclark.com> ftp://ftp.jclark.com/pub/test/xpointer.zip is an implementation of XML xpointers in SDQL. This works with Jade 0.7. It doesn't exactly follow the current draft (notably it doesn't count pseudo-elements), and some features are not implemented (eg wildcards for attribute names, spans). There's also a tiny SGML document and DSSSL style sheet that exercises this. Since Jade currently only supports a single input document this probably isn't yet very useful, but I thought people might find it interesting. James xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@ic.ac.uk the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@ic.ac.uk)