From Peter at ursus.demon.co.uk Fri Feb 21 17:23:38 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:21 2004 Subject: Welcome and Thanks Message-ID: <3721@ursus.demon.co.uk> This is a test message to XML-DEV. I am very grateful to Henry Rzepa for setting this up at my request. Henry is the one who has to field the problems of bouncing addresses and so on. Henry has been extremely supportive of the development of CML and of SGML-based publishing in chemistry, but please route any SGML/XML queries to me rather than him. This list is hypermailed which means that every posting is available on the WWW. The great advantage is that it's possible to revisit the pages for factual information. Please choose your threads and subjects carefully. Note, of course, that all postings are public and that you should not post anything that you would prefer only a small group to know (e.g. the location of pre-alpha code). I have written an 'info' which should appear shortly - there is no detailed agenda, but a general belief that if we take a collaborative approach to developing components (of whatever sort) we can get prototypes and demonstrators working very soon. We benefit from knowing that we are all working from the same draft, with the same beta-release, or whatever. Topics should always relate to XML in some form, although they may spring from existing SGML applications and installations. It is probably not appropriate to post large chunks of material (code, document instances, etc.) to this list, but to post URLs instead. It may be useful to evolve a page where these are listed, but I'm not offering this on day 1 (volunteers?). The development of XML is very rapid and it is always helpful if resources can be uniquely identified (i.e. have IDs, date stamps, or different URLs). I am probably as guilty as anyone in this matter :-). Peter -- 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 Feb 22 15:53:47 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:21 2004 Subject: Technology Demonstration Message-ID: <3779@ursus.demon.co.uk> Jon, This is in reply to your posting to XML-WG about the demonstration in April. You would be extremely welcome to demonstrate my JUMBO browser at that meeting - it can be done either with a Java interpreter or simply using a Java-enabled browser (e.g. Netscape 3). All it needs is some *.html, *.xml and *.class files which I will supply. Java running under Netscape/HTML makes for fantastic demonstrations - it's simply like running Netscape. (I believe that the equivalent vintage of MSIE also will work, though I haven't tried it.) I am sure that this technology can be used extremely effectively for advertising XML - not that it need not use remote files so that you get no bandwidth restriction and need not be connected to the 'Net. I hope that we shall enough surplus CDROMs that some demos could come available but they will represent Feb 22 vintage whereas we hope to make more progress by then and the whole demo can be downloaded beforehand. I'll give more details later. JUMBO (at present at http://www.venus.co.uk/omf/cml/moltest.tar.gz) is an experimental prototype for a technical browser with special emphasis on molecular science. I'll wait until people have had time to join the list but here is a brief overview of the *generic* functionality it has implemented in full or in part: - XML parser (to be junked for NXP/Lark/Foo) - ESIS reader - XML writer (doubtless to be revisited:-) - DTD classloader (i.e. knowledge of the ELEMENTs, but not yet content models or attributes) - MIME manager (primitive) - Tree GUI (Element-sensitive) for display and editing at the element level - Import and conversion of legacy files (chemistry) - subclassing of elements appropriate to different DTDs - Element-based help and icons - Primitive bookmark facility within documents These are all problem-independent (i.e. horizontal). Within the technical field there are some horizontal applications: - Table manager (linked to Elements) - Graphing tool (i.e. plotting) - Uni- bi- and multivariate statistics. - Glossary management (derived from ISO 12620 and in conjunction with active groups). I will omit the molecular classes (though they are fun and visual when it comes to a demonstration). The technical DTD (TecML) can be used for a wide range of non-textual applications including organograms and numeric data in any field where the semantics can be resolved by linkage to a glossary. (Linkages to glossaries and elsewhere are on hold until the white smoke emerges). The current serious limitations are: - a DTD parser (to abstract content models and attributes). Perhaps NXP provides this, Norbert? - a link engine - a proper SD search tool (mine is very crude) - an on-the-fly validator for an editor (validation against content model) - an HTML renderer. (I think I/we have to hack my own to inline the images, and hyperlinks) P. [This mail is also to encourage others to post. I shall post some suggestions on how we manage threads, but I don't want to steer the discussion in any pre-conceived directions. Since this list can be an extremely useful source of material for XML-FAQ, sticking to simple Subject lines will be very valuable.] -- 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 h.rzepa at ic.ac.uk Tue Feb 25 08:29:17 1997 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 16:57:21 2004 Subject: XML-DEV Info file Message-ID: I enclose a copy of the Info file that will be attached to this forum shortly. It was prepared by Peter Murray-Rust --------------------------------------------- INFO: XML-DEV is an informal unmoderated list to support those who are interested in the implementation and development of XML. XML is being developed as 'an extremely simple dialect' of SGML to 'enable generic SGML to be served, received, and processed on the Web in a way that is now possible with HTML'. Further information about XML or pointers to it can be found at: http://www.ucc.ie/xml/ (Peter Flynn's FAQ site) http://www.sil.org/sgml/ (Robin Cover's SGML page) The XML spec is still being actively developed and the latest draft is at http://www.textuality.com/sgml-erb/WD-xml.html This list is for those people actively involved in developing resources for XML. It is not restricted to members of the working group (WG) but many subscribers to XML-DEV will be actively working on implementing some part of the spec. Examples of what might be discussed: - the detailed implementation of the spec - resources such as documentation, test data, test results. - XMLification of components (DTDS, entity sets, catalogs, etc.) - APIs for software developers. - problems in implementation, and queries for XML-related resources - the use of existing SGML tools in creating XML resources. It is NOT appropriate to: - request general information on XML (use the FAQ) - discuss non-XML topics in SGML (use comp.text.sgml) - discuss revision of the spec (use the WG) The mail on this list is publicly hypermailed and all posting should be made with this in mind. The hypermail is seen as a useful resource for locating information, and for current awareness as to who is doing what. If there is sufficient volume, it may become valuable to abstract these pages from time to time. Peter Murray-Rust, Feb 21 1997 (There is no initial restriction on what software and other resources can be discussed, but the current impetus is on developing prototypes in parallel with the standard. Several WG members and others have promoted the use of interoperable components, and an informally managed namespace. Any tools may be discussed, but it should be remembered that some subscribers may not have access to some.) Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ 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 Feb 25 15:53:02 1997 From: bosak at atlantic-83.Eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 16:57:21 2004 Subject: Welcome and Thanks Message-ID: <199702251551.HAA21271@boethius.eng.sun.com> On behalf of the XML community I would like to express deep gratitude to Peter Murray-Rust for organizing this service and to Henry Rzepa for agreeing to administer it. This list is certain to become a major resource as we begin to develop applications of XML. Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, | Best is he that inuents, Mountain View, California 94043 | the next he that followes Davenport Group::SGML Open::ANSI X3V1 | forth and eekes out a good ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB | inuention. ---------------------------------------------------------------------- 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 Feb 25 23:32:47 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:22 2004 Subject: ANNOUNCE: GCA conference Message-ID: <3992@ursus.demon.co.uk> I am happy to forward this message which announces the GCA conference in San Diego. Personally I'd love to go but can't, and I think that GCA is showing foresight that will be rewarded. I am particular keen to see graphical approaches to SGML and shall post some suggestions later... Forwarded message follows: > From dthieme@printing.org Tue Feb 25 22:44:37 1997 [... header deleted ...] > > Hi Peter, > > Here's the message that refers to the XML conference in San Diego: > > To Users of SGML: > > Here at the Graphic Communications Association we've noticed numerous > postings on the subject of XML since we conducted our SGML'96 conference in > Boston last November. Due to the interest expressed at SGML'96 about XML, > the President and Board of Directors of GCA have decided to offer the first > conference devoted entirely to XML and how it will impact on SGML and its > use with HTML. > > The following information is being posted (30 January 1997) in the interest > of reaching the largest number of interested persons who may wish to attend > GCA's XML Conference, March 10 - 12, 1997 in San Diego, California. > > > XML: finally an easier way to gain full advantage of Web and Corporate > Intranet publishing! > > If: > > HTML doesn+t meet all your needs for Web publishing. > > HTML doesn+t support structured data on intranets. > > SGML is proving difficult to implement for your Web/Intranet applications. > > SGML has been hard to cost-justify to management. > > If these are your problems, XML may be the solution! XML is the on-ramp to > SGML, the Web and Intranet publishing! > > XML (Extensible Markup Language) provides the key benefits of SGML in a > lightweight, easy-to-use, easy-to-implement dialect that omits many of the > SGML standard+s complexities, but is still 100% compliant SGML. > > For a decade, SGML has been recognized as the right way to solve serious > publishing problems. And SGML is the right way to drive serious Web and > Intranet delivery. In 1997, with the annoucement of XML, the right way is > now the cheap and easy way. > > Conference Theme: The New Publishing Business Case: XML, SGML, and the > Intranet > Conference Chair: Tim Bray, Textuality, and co-editor of XML > > March 10-12, 1997 > Mission Valley Marriott > San Diego, CA > > The conference: > * introduces the XML standard > * examines where HTML is not the answer > * focuses on the business case for SGML and now XML in Web and Intranet > publishing > * takes a look at XML+s implications for the publishing industry-at-large > * looks at technology to support XML, Web, and Intranet publishing > * and more... > > Join us in San Diego, March 10-12! Find out how XML will change the way you > do business on the Web and Corporate Intranets! > > Who should come: > > * End-user staff with business case responsiblity > * Marketing executives for content management and Web technologies > * Curious users of Web and Intranet technologies seeking a jump start on an > alternative to HTML > * Sales reps who have to sell the standard to sell their product > > > Preliminary Schedule: > Monday, March 10, 1997 > > 7:30 am Registration > > Session 1: Tutorial: What is XML? > 9:00 am The XML Standard: A Top-to-Bottom Tutorial > Tim Bray, Co-editor of XML, Textuality > 12:15 pm Luncheon > > Session 2: Progress Report and Keynote > 1:30 pm Welcome > Norman W. Scharpf, President, Graphic Communications Association > 1:45 pm Conference Guide and XML Progress Report > Tim Bray, TEXTUALITY > 2:15 pm Conference Keynote: > Jim Sterken, President and CEO, ARBORTEXT, Inc. > 3:00 pm Break > > Session 3: Key Web Technologies > 3:30 pm XML: Enabling Knowledge Publishing on the Web > Bruce Sharpe, Vice President, Product Development, SOFTQUAD > 4:15 pm Client-Centered Computing for the Web > Jean Paoli, Data Product Team Manager, Internet Explorer, > MICROSOFT > 5:00 pm Adjourn - Reception - Software Gallery > > > Tuesday, March 11, 1997 > > Session 4: Case Studies > 9:00 am 10:30 am > Break > > Session 5: Business Case and Business Integration > 10:45 am The Business Case for Structured Documents on the Web > Eric Severson, Principal, IBM Global Services > 11:30 am Trends in Business Integration for Publishing Technologies > Peter Lamb, Partner, ANDERSEN Consulting > 12:15 pm Lunch > > > Session 6: The Publishing Dimension > 1:30 pm SGML-Driven Web Publishing > Wes Hair, INSO Corporation > 2:15 pm Implications of XML for Professional Publishing > Mark Walter, Editor, The SEYBOLD Report on Internet > Publishing > 3:00 pm Break > > Session 7: Distinguished Speakers > 3:30 pm Copernicus > Robert McHenry, Editor-in-Chief, ENCYCLOPAEDIA BRITANNICA > 4:15 pm Send-off: SGML, XML, HTML - Sorting it all out > Dr. Charles F. Goldfarb, Inventor of SGML, Information Management > Strategies > 5:00 pm Adjourn - Software Gallery - Reception > > Wednesday, March 12, 1997 > > 7:30 am Tutorial registration > 9:00 am Tutorials > Introduction to SGML > The Eliot Kimber HyTime Quickstart(tm) > Practical DSSSL Formatting Using JADE > > Noon Luncheon > > 1:30 pm Tutorials continue > > 5:00 pm Adjourn > > > Tutorial Descriptions > > Introduction to SGML > Instructor: Marco Caripichio, ISOGEN > > Are you considering an SGML implementation as a means of streamlining your > documentation process? Are you wondering how XML differs from SGML? If yes > to either of these questions, the Introduction to SGML Course is for you. > Upon completion of the course, attendees will have learned the benefits and > costs of SGML, who+s using SGML, and if SGML is the best solution for your > environment. All topics will be related to a final goal of how to perform a > successful SGML implementation. > > SGML syntax will be avoided. Emphasis will be placed on understanding the > committments placed on an organization implementing SGML. > > The Eliot Kimber HyTime Quickstart > Instructor: Eliot Kimber, ISOGEN > > The Eliot Kimber HyTime Quickstart introduces the key concepts in HyTime, > including hyperlinking, addressing, architectures, groves, and property > sets. Upon completion of the course, students will have a better > understanding of what HyTime is, what added value it provides as a standard, > > where it fits in relation to other standards, such as XML, and how it might > apply to the challenges they face in their own use of SGML. The lecture > includes many examples of HyTime documents and demonstrations of > HyTime-based tools. Discussion of syntax details is avoided: the focus is on > > concepts. Students should have a basic understanding of SGML concepts but > need not be versed in SGML syntax. > > Practical DSSSL Formatting Using JADE > > This one dat tutorial overviews the basics of formatting using the Document > > Style and Semantics Specification Language (DSSSL), understanding the ISO > 10179 standard document, and writing a formatting script suitable for > processing by JADE, James+ Awesome DSSSL Engine. The principles of DSSSL, > and the DSSSL Online Specification Profile with JADE extensions, are > described to understand the capabilities available in the software. Many > topics are covered in an introductory fashion using practical hands-on > examples. The attendees are then equipped, on their own, to further explore > in depth this powerful standard. > > Attendees are invited to download free copies of the latest copy of JADE > from the ftp://ftp.jclark.com/pub/jade directory (the file naed with the > largest number using the -jadew- prefix) and the Microsoft Word RTF viewer > in the file ftp://ftp.microsoft.com/softlib/mslfiles/WD95VW71.EXE, and to > brting their laptop system to the course for live work on the examples and > exercises. > > > REGISTRATION FORM > > The New Publishing Business Case: XML, SGML, and the Intranet > > March 10 - 12, 1997 > Marriott Mission Valley > San Diego, CA 92108 > > Registration Fees: > > Conference: > > GCA Member . . . . . . . . . . $595 US Nonmember . . . . . . $760 > US > Bank Transfer Fee . $25 US > > All registration fees must be paid at time of registration. > All fees must be in U.S. Dollars. > > Post-conference Tutorials: (Wednesday, March 12, 1997) > > I will attend the following tutorial: > > [ ] Introduction to SGML > [ ] The Eliot Kimber HyTime Quickstart > [ ] Practical DSSSL Formatting Using JADE > > GCA Member . . . . . . . . . . $245 US Nonmember . . . . . . $360 > US > Bank Transfer Fee . $25 US > > HOTEL INFORMATION > > The GCA has reserved a block of rooms at the Marriott Mission Valley, 8757 > Rio San Diego Drive, San Diego, CA 92108. The special rate is $105 > single/double. This rate will be valid until 2/14/97 After that, rooms > will be available on a space available basis at the group rate. Contact the > > hotel directly at 619-692-3800 (Fax: 619 692-0769) and identify yourself as > a GCA/XML conference registrant to qualify for the special rate. > > > PLEASE PRINT > > NAME: (as it will appear on badge) > > First Middle Initial Last/Surname > > > ____________________________________________________________________________ > > > Title > __________________________________________________________________________ > > Company/Organization > __________________________________________________________ > > Address _______________________________________ City > ________________________ > > State __________ Post Code/ZIP ________________ Country > _______________________ > > Telephone ( ______ ) _________________ Fax ( ______ ) _________________ > > E-mail _____________________________________________________________ > > Payment Information > > Check Enclosed for __ conference__ tutorial (Make checks payable to GCA) > Total $ ______ > __Credit Card: __American Express __MasterCard __Visa > > Account Number _______________________________ Expiration Date ___ /___ > > Name on Card _______________________ Signature _____________________ > International Monetary Transfer Bank: Crestar Bank > 7818 Parham Road, Richmond, VA 23294 > Acct.# 202 289 818 ABA# 051 000 020 Printing Industries of America > > [ ] Check here if you are disabled and have special requirements. > > Please Return Form to: > Graphic Communications Association > 100 Daingerfield Road > Alexandria, VA 22314-2888 USA > > Fax Your Registration Today to +1 703 548 2867 > For More Information Call +1 703 519 8174 or e-mail: jmorrison@gca.org > Photocopy for additional registrations. > > GCA Graphic Communications Association > Fostering SGML From Day One > > > > For more conference agenda and registration details, visit: > http://www.gca.org/conf/xml/index > > Thank you for sharing this information with your colleagues. > > Don Thieme, APR > Director, Marketing & Communications > 703-519-8190; dthieme@gca.org > [... PeterMR ...> > I am very much hoping the GCA will be a success. I would be happy for > anyone to demo my material _in absentia_. It's completely drop-and-flop > and runs under Netscape 3 with a 15-second installation time (i.e. the time > to put the CDROM in). You can also download the material off the WWW: > http://www.venus.co.uk/omf/cml/moltest.tar.gz (or moltest1 for later > version). > > 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 Tue Feb 25 23:32:51 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:22 2004 Subject: Suggested List Protocol Message-ID: <3994@ursus.demon.co.uk> Quite a number of people have joined the list and I'm looking forward to seeing some other contributions than mine :-). The hypermailing of the list makes it extremely useful for extracting information by topic for XML-related questions, such as the current FAQ from Peter Flynn or (possibly) a set of WWW pages for XML-DEV-like resources. I'd like to suggest that for commonly occurring topics we use the Subjects carefully. For example, if you wonder (as I will do shortly) how something in the current draft works, choose a general topic like "Interpretation of Draft" rather that "why doesn't X do Y when I do Z?". Similarly, if you want to know whether there is an XML-ised version of HTML, choose a subject "HTML DTD". I shan't prescribe or proscribe topics, but being mindful of the value of archiving, I may suggest changes of Subject. Please don't feel inhibited about topic - I expect to see "Where shall we meet for drinks at GCA?" and similar, but try to separate the exploratory, discursive or rambling ones from the precise topics that might be mined for jewels. It is also worth searching the topics before posting... One technical point which I'd like advice on is "What shall we do about posting markup itself?" There is no problem with mailers (?), but if hypermailers encounter (that read <Foo>) it could be missed. (I know when I browse a *.sgm file, Netscape tries to interpret the markup as HTML.) Does markup enclosed in 
 ...
escape? Suggested subject: Parsers Perhaps to start the ball rolling, I'll ask if anyone has used Lark or NXP (Java-based). I've used both. What are you looking for in Parsers? Is the API that Lark and NXP offer reasonable? Would you want to build in sgmls, SP, sgmlc, 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 crm at ebt.com Wed Feb 26 00:00:30 1997 From: crm at ebt.com (Christopher R. Maden) Date: Mon Jun 7 16:57:22 2004 Subject: Suggested List Protocol In-Reply-To: <3994@ursus.demon.co.uk> (Peter@ursus.demon.co.uk) Message-ID: <199702252345.XAA18606@phaser.EBT.COM> > One technical point which I'd like advice on is "What shall we do > about posting markup itself?" There is no problem with mailers (?), > but if hypermailers encounter (that read <Foo>) it could > be missed. (I know when I browse a *.sgm file, Netscape tries to > interpret the markup as HTML.) Does markup enclosed in 
> ...
escape? Hopefully, the Hypermailer will turn every < into <. I'd be surprised if it didn't; it's a trivial substitution, and potentially extremely damaging (even to non-SGML lists). -Chris -- Christopher R. Maden One Richmond Square DynaText SIT Technical Support Providence, RI 02906 USA Inso Corporation +1.401.421.9550 (voice) Electronic Publishing Solutions +1.401.521.2030 (facsimile) 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 h.rzepa at ic.ac.uk Wed Feb 26 09:16:06 1997 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 16:57:22 2004 Subject: Suggested List Protocol: Keyword indexing of archive Message-ID: >Quite a number of people have joined the list and I'm looking forward >to seeing some other contributions than mine :-). The hypermailing of the >list makes it extremely useful for extracting information by topic for >XML-related questions, such as the current FAQ from Peter Flynn or (possibly) >a set of WWW pages for XML-DEV-like resources. I'd like to suggest that >for commonly occurring topics we use the Subjects carefully. I am trying to get the entire archive indexed, so that a keyword search will be possible. That does not obviate the need for carefully chosen subjects (I am sure we all are experienced in this). Might I also ask about longer term archiving? After a year or so, and depending on how the list develops, I feel that a permanent record of these discussions 'might' be desirable (e.g a CD ROM with an ISBN number, probably as part of another project). So should we all bear this in mind when we post? Have any other IETF/W3C etc lists been so archived. I dont much prowl around them nowadays, although I have seen lists quite literally stop in mid air as they transfer elsewhere (or the moderator changes job!). Clearly, if a long term archive is considered, then how much/any editing should/can be applied etc etc. I think its worth raising these issues right at the start, so we dont have to fret later on. Aplogies for the fact that I did not mention XML once! Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ 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 gtn at ebt.com Wed Feb 26 15:12:27 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:22 2004 Subject: Suggested List Protocol In-Reply-To: <3994@ursus.demon.co.uk> (Peter@ursus.demon.co.uk) Message-ID: <199702261509.KAA23564@nathaniel.ebt> >Perhaps to start the ball rolling, I'll ask if anyone has used Lark or NXP >(Java-based). I've used both. What are you looking for in Parsers? Is the >API that Lark and NXP offer reasonable? Would you want to build in sgmls, >SP, sgmlc, etc.? I think that we should define a common parser API. 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 Feb 26 15:49:01 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:22 2004 Subject: Suggested List Protocol References: <199702261509.KAA23564@nathaniel.ebt> Message-ID: <331458A1.2635@hiwaay.net> Gavin Nicol wrote: > > >Perhaps to start the ball rolling, I'll ask if anyone has used Lark or NXP > >(Java-based). I've used both. What are you looking for in Parsers? Is the > >API that Lark and NXP offer reasonable? Would you want to build in sgmls, > >SP, sgmlc, etc.? > > I think that we should define a common parser API. Second that. The lack of this and a *standard* way to define the parser output (eg., what esis should do but doesn't, and grove/grove plans can do) have plagued SGML systems for years. A proposal for this is something that can be worked on a development list. len bullard lockheed martin 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 gtn at ebt.com Wed Feb 26 16:02:38 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:22 2004 Subject: Suggested List Protocol In-Reply-To: <331458A1.2635@hiwaay.net> (message from Len Bullard on Wed, 26 Feb 1997 09:37:05 -0600) Message-ID: <199702261559.KAA23605@nathaniel.ebt> >Second that. The lack of this and a *standard* way to define >the parser output (eg., what esis should do but doesn't, and >grove/grove plans can do) have plagued SGML systems for years. >A proposal for this is something that can be worked on a >development list. Quite. I think we can model these objects in a number of ways though. I would personally like to define the objects in IDL *and* SGML... (for information on IDL etc. look at www.omg.org). 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 Wed Feb 26 16:59:18 1997 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 16:57:22 2004 Subject: XML API specification Message-ID: <3.0.32.19970226084314.006953ec@pop.intergate.bc.ca> At 10:59 AM 26/02/97 -0500, Gavin Nicol wrote: >Quite. I think we can model these objects in a number of ways >though. I would personally like to define the objects in IDL >*and* SGML... (for information on IDL etc. look at www.omg.org). Fortunately, we're not starting from scratch. We have two strawman interfaces on the table right now, NXP and Lark. Seems to me that since XML is particularly likely to be processed in the client, you could do a lot worse than a Java API - the idea of having a set of superclasses for Element, Attribute, and so on seems awfully desirable to me. [Confession - I've been too busy putting proper attribute defaulting in Lark (hard!) to even get around to looking at the NXP interface, so I have no comment as to which straw I prefer at the moment]. I would propose seriously that Java be the basis of the first cut at an API spec; it is really very pleasingly clean, and also has the virtue that ideas can be tested more or less instantly because there's running parser code to graft them onto. - 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 cbullard at hiwaay.net Wed Feb 26 17:08:13 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:22 2004 Subject: Suggested List Protocol References: <199702261559.KAA23605@nathaniel.ebt> Message-ID: <33146B19.3521@hiwaay.net> Gavin Nicol wrote: > > >Second that. The lack of this and a *standard* way to define > >the parser output (eg., what esis should do but doesn't, and > >grove/grove plans can do) have plagued SGML systems for years. > >A proposal for this is something that can be worked on a > >development list. > > Quite. I think we can model these objects in a number of ways > though. I would personally like to define the objects in IDL > *and* SGML... (for information on IDL etc. look at www.omg.org). So, are you saying, in terms of a grove/grove plan and the implementing objects/IDL? That looks ideal. CORBA is a nice open spec. Last time I looked, the documents cost big bucks, but maybe that has changed. My concern with a design like this is the usual one: trying for something that works across the platforms dependably and so, is very useful. What would be the alternatives to CORBA? What would be the strengths of CORBA? It is hard to get around the Wintel quasi-monopoly on the low end. To be successful, I think one should not try. It is best to make sure whatever implementation is sampled, it runs on that platform or whatever else, and duck the platform wars as much as possible. It is a "goes nowhere, helps nothing" debate as we saw on the VRML list. How would you view this architecturally? How does the parser API work with the rest of the system? For example, a major concern for adopting XML and in fact, most Internet technologies into intranet apps is object identification and addressing. I follow the uri.bunyip debates and this is not as straightforward as it looks. What does a parser API know or care to know about that if anything? I don't want to conflate issues; I want to understand the separation of powers so to speak, in the architecture. I don't have enough experience as a programmer to look at more than the high level view of this although I understand most of the concepts. len 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 Feb 26 17:17:09 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:22 2004 Subject: XML API specification References: <3.0.32.19970226084314.006953ec@pop.intergate.bc.ca> Message-ID: <33146D54.7D4B@hiwaay.net> Tim Bray wrote: > > At 10:59 AM 26/02/97 -0500, Gavin Nicol wrote: > >Quite. I think we can model these objects in a number of ways > >though. I would personally like to define the objects in IDL > >*and* SGML... (for information on IDL etc. look at www.omg.org). > > Fortunately, we're not starting from scratch. We have two strawman > interfaces on the table right now, NXP and Lark. Seems to me that > since XML is particularly likely to be processed in the client, you > could do a lot worse than a Java API - the idea of having a > set of superclasses for Element, Attribute, and so on seems awfully > desirable to me. Milowski proposed this approach two years ago on comp-text-sgml and in private email for the same reasons. I think it is a very desirable spec to have. Could we go through the bone of contention up front and just settle it: are grove and grove plan definitions of use to an object-oriented API design? Really just asking here, so this gets settled and doesn't crop up again and again. > [Confession - I've been too busy putting proper > attribute defaulting in Lark (hard!) to even get around to looking at > the NXP interface, so I have no comment as to which straw I prefer at > the moment]. > > I would propose seriously that Java be the basis of the first > cut at an API spec; it is really very pleasingly clean, > and also has the virtue that ideas can be tested more or less > instantly because there's running parser code to graft them > onto. - Tim Wouldn't that also avoid the platform wars issues by settling on a virtual machine? Given that most operating systems are supporting it or will be soon, that it is fast becoming the choice of other web languages for "heavy lifter" scripting, I agree it looks ideal. Java is rather slow, but perhaps that is implementation and not an issue for an API spec. Correct me if that is wrong. len 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 gtn at ebt.com Wed Feb 26 17:22:14 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:22 2004 Subject: XML API specification In-Reply-To: <3.0.32.19970226084314.006953ec@pop.intergate.bc.ca> (message from Tim Bray on Wed, 26 Feb 1997 08:49:25 -0800) Message-ID: <199702261719.MAA23649@nathaniel.ebt> >Fortunately, we're not starting from scratch. We have two strawman >interfaces on the table right now, NXP and Lark. Seems to me that >since XML is particularly likely to be processed in the client, you >could do a lot worse than a Java API - the idea of having a >set of superclasses for Element, Attribute, and so on seems awfully >desirable to me. I have another set of API's that differ somewhat from NXP and Lark. While we're at it, perhaps we can define a common set of API's for name resolution? I have a fairly clean API for that that allows heirarchical name resolution services to be built. >I would propose seriously that Java be the basis of the first >cut at an API spec; it is really very pleasingly clean, >and also has the virtue that ideas can be tested more or less >instantly because there's running parser code to graft them >onto. - Tim I vote for IDL because it's language independent. 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 gtn at ebt.com Wed Feb 26 17:40:06 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:22 2004 Subject: Suggested List Protocol In-Reply-To: <33146B19.3521@hiwaay.net> (message from Len Bullard on Wed, 26 Feb 1997 10:55:53 -0600) Message-ID: <199702261737.MAA23688@nathaniel.ebt> >> Quite. I think we can model these objects in a number of ways >> though. I would personally like to define the objects in IDL >> *and* SGML... (for information on IDL etc. look at www.omg.org). > >So, are you saying, in terms of a grove/grove plan and the >implementing objects/IDL? That looks ideal. Yes. >CORBA is a nice open spec. Last time I looked, the documents >cost big bucks, but maybe that has changed. If you complain enough, they'll send you them free ;-) Also, if you pull down OpenDoc, you get SOM, which is based on it, and you get IDL docs. If anyone needs the IDL spec, I also have it. >What would be the alternatives to CORBA? What would be the strengths >of CORBA? ILU maybe. The benefit of using IDL or ILU is that they are language *and* platform independent. Also, they both have free programs that generate JAVA/C++/C stubs. They also have free object instantiation libraries available. I prefer IDL simply because it's closer to a standard. >It is hard to get around the Wintel quasi-monopoly on the >low end. To be successful, I think one should not try. Sure. The important point (which I tried but failed to make 2 years ago to a group of developers) is that you can wrap OLE in CORBA (a la OpenDoc), but it's very hard to go the other way! >How would you view this architecturally? How does >the parser API work with the rest of the system? >For example, a major concern for adopting XML and >in fact, most Internet technologies into intranet >apps is object identification and addressing. Right. That's why I brought up the though of specifying a name resolution API as well (entity management). You need both to do anything meaningful. In an ideal world, you don't really need an entity manager, but it's a little early for such radical concepts yet... another year or two, and the WWW will evolve as it should, and we'll be set. 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 gtn at ebt.com Wed Feb 26 17:50:49 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:22 2004 Subject: XML API specification In-Reply-To: <33146D54.7D4B@hiwaay.net> (message from Len Bullard on Wed, 26 Feb 1997 11:05:24 -0600) Message-ID: <199702261747.MAA23694@nathaniel.ebt> >Could we go through the bone of contention up front >and just settle it: are grove and grove plan definitions of >use to an object-oriented API design? Really just asking here, >so this gets settled and doesn't crop up again and again. This depends. You can model a grove *soooo* simply, and it's actually a very useful data structure. I find grove plans to not be all that useful (I'd rather just model the generic grove and leave the grove plan up to the contructing application). That said, slightly more concrete objects are also useful. This is the main difference between NXP, lark, my API, and groves: the level of generality in the objects. I tend toward absolute generality, where NXP and lark just model XML. >Wouldn't that also avoid the platform wars issues by settling >on a virtual machine? Given that most operating systems are >supporting it or will be soon, that it is fast becoming the >choice of other web languages for "heavy lifter" scripting, >I agree it looks ideal. > >Java is rather slow, but perhaps that is implementation and >not an issue for an API spec. Correct me if that is wrong. No. Java is just another implementation language (and it does have a number of drawbacks, like lack of continuations). The reason I argue for IDL is that it is language *and* platform independent. Is have JAVA/C++/C and other bindings specified, and *free* implementations of the resolution and object instantiation mechanisms. I would also argue that distributed objects are where the world is heading: code replication is fine for certain things, but not for others. 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 Feb 26 18:06:00 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:22 2004 Subject: XML API specification References: <199702261747.MAA23694@nathaniel.ebt> Message-ID: <3314789D.3E8E@hiwaay.net> Gavin Nicol wrote: > > >Could we go through the bone of contention up front > >and just settle it: are grove and grove plan definitions of > >use to an object-oriented API design? Really just asking here, > >so this gets settled and doesn't crop up again and again. > > This depends. You can model a grove *soooo* simply, and it's > actually a very useful data structure. I find grove plans to > not be all that useful (I'd rather just model the generic grove > and leave the grove plan up to the contructing application). Ok. Who would use the grove definition and for what? It is policy-wise, useful to have grove definitions. But if no one is using them, it may not be more than that. OTH, if it is that easy, it might be worth the effort. If nothing else, it might be the clearest explanation by example of what groves are and are good for. That in turn, might help those on the DSSSL track. > That said, slightly more concrete objects are also useful. This > is the main difference between NXP, lark, my API, and groves: the > level of generality in the objects. I tend toward absolute generality, > where NXP and lark just model XML. I'd have to side with specificity. Getting absolute generality seems to be the way things like HyTime took forever to get done, and then, were very hard to understand because of the generality. That is not meant to demean the effort of HyTime, but to say, if this is an implementation list, then the goal is to get implementations. Since it is the XML development list, I presume implementations of XML are what is wanted. This seems like a fuzzy issue. An initial API proposal only has to hit the basic requirements. I say, job one is to come to consensus on the basic requirements. > >Wouldn't that also avoid the platform wars issues by settling > >on a virtual machine? Given that most operating systems are > >supporting it or will be soon, that it is fast becoming the > >choice of other web languages for "heavy lifter" scripting, > >I agree it looks ideal. > > > >Java is rather slow, but perhaps that is implementation and > >not an issue for an API spec. Correct me if that is wrong. > > No. Java is just another implementation language (and it does have a > number of drawbacks, like lack of continuations). The reason > I argue for IDL is that it is language *and* platform independent. Is > have JAVA/C++/C and other bindings specified, and *free* > implementations of the resolution and object instantiation mechanisms. Ok. Here is where I have to defer to you and Tim and the more knowledgeable on the list. > I would also argue that distributed objects are where the world is > heading: code replication is fine for certain things, but not for > others. Agree. I would not be surprised to see an assault on HTTP's ubiquity start in the future. But that is not an issue for us to discuss here. len 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 ddb at criinc.com Wed Feb 26 18:17:52 1997 From: ddb at criinc.com (Derek Denny-Brown) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification Message-ID: <3.0.32.19970226101228.009139f0@mailhost.criinc.com> At 08:49 AM 2/26/97 -0800, you wrote: >At 10:59 AM 26/02/97 -0500, Gavin Nicol wrote: >>Quite. I think we can model these objects in a number of ways >>though. I would personally like to define the objects in IDL >>*and* SGML... (for information on IDL etc. look at www.omg.org). I like the idea of fleshing it out in IDL, but providing alternative interfaces, based on that API (Java Interfaces, OLE **shudder**, C++, etc) This gives implementers more leeway (i.e. I want a C++ DLL, because I need raw speed. Others want a Java Interface for protability, etc... CORBA IDL is a sufficiently general center that an interface in most any language should be derivable from that base. >Fortunately, we're not starting from scratch. We have two strawman >interfaces on the table right now, NXP and Lark. Seems to me that >since XML is particularly likely to be processed in the client, you >could do a lot worse than a Java API - the idea of having a >set of superclasses for Element, Attribute, and so on seems awfully >desirable to me. [Confession - I've been too busy putting proper >attribute defaulting in Lark (hard!) to even get around to looking at >the NXP interface, so I have no comment as to which straw I prefer at >the moment]. Does anyone have a reference to NXP? It might be useful to actually post a list of related docs w/ URL's where appropriate (i.e. Java Language Spec, CORBA IDL spec, NXP, Lark, SP, etc...) -derek -- Remember: Computers are here to make our lives easier -- ddb@criinc.com // software-engineer // www/sgml/java/perl/etc. 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 Wed Feb 26 19:00:50 1997 From: jenglish at crl.com (Joe English) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification In-Reply-To: <33146D54.7D4B@hiwaay.net> References: <33146D54.7D4B@hiwaay.net> <3.0.32.19970226084314.006953ec@pop.intergate.bc.ca> Message-ID: <199702261859.AA25143@mail.crl.com> Len Bullard wrote: > Could we go through the bone of contention up front > and just settle it: are grove and grove plan definitions of > use to an object-oriented API design? Really just asking here, > so this gets settled and doesn't crop up again and again. I think so. It's very straightforward to translate class definitions from a grove plan into class definitions in (Java|C++|Modula-3|OO-language-of-choice). That's pretty much what James Clark did for the generic SP interface. That's a good approach for processing XML-as-XML. A slightly different approach is useful when you want to add application semantics, namely, to create a new class for each element type of interest, (or better yet, for each architectural form). That's sort of what SGMLS.pm, the original CoST, and (I think) Peter M-R's CML tools do. --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 digitome at iol.ie Wed Feb 26 19:01:05 1997 From: digitome at iol.ie (Digitome Ltd.) Date: Mon Jun 7 16:57:23 2004 Subject: XML API Message-ID: <199702261900.TAA12652@mail.iol.ie> What exactly do people mean by "API" for XML. A function/method interface? An abstract data structure specification? Both? There is a degree of overlay between the two however, trench warfare experience leads me to prefer abstract data structure over functions/methods. As soon as you create function/method interfaces you are creating a backward compatability problem for yourself. If you want to make wholesale changes you must maintain the "old" functions/methods in order to avoid breaking existing apps. The thing I would like most to see tied down is the ESIS++ (or RAST) for XML so that tools can sensibly be tested against a reference test suite. Regards, sean@digitome@iol.ie Sean Mc Grath 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 gtn at ebt.com Wed Feb 26 19:01:35 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification In-Reply-To: <3314789D.3E8E@hiwaay.net> (message from Len Bullard on Wed, 26 Feb 1997 11:53:33 -0600) Message-ID: <199702261858.NAA23717@nathaniel.ebt> >> This depends. You can model a grove *soooo* simply, and it's >> actually a very useful data structure. I find grove plans to >> not be all that useful (I'd rather just model the generic grove >> and leave the grove plan up to the contructing application). > >Ok. Who would use the grove definition and for what? Grove plans are useful for validating the grove construction processor. Note that I think this is actually a very important capability, but I *personally* do not use it. [In general, I think that tool validation is *very* important, which is why I took the stand I did in the XML-WG] >I'd have to side with specificity. Getting absolute generality >seems to be the way things like HyTime took forever to get done, >and then, were very hard to understand because of the generality. Here I'll have to disagree with you. In this case, generality also brings about simplicity, and rightly so, because what we are modelling is simple (as are groves, fundamentally). The other benefit of a more general interface is that is is no longer tied to a specific syntax... and I'll let *that* point sink in slowly. >> I would also argue that distributed objects are where the world is >> heading: code replication is fine for certain things, but not for >> others. > >Agree. I would not be surprised to see an assault on HTTP's ubiquity >start in the future. But that is not an issue for us to discuss here. Want to bet where the next step afetr distributed objects falls? :-) 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 Wed Feb 26 19:39:33 1997 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 16:57:23 2004 Subject: XML references Message-ID: <199702261939.NAA07344@ACADCOMP.SIL.ORG> Derek wrote: Does anyone have a reference to NXP? It might be useful to actually post a list of related docs w/ URL's where appropriate (i.e. Java Language Spec, CORBA IDL spec, NXP, Lark, SP, etc...) Here are a few possibly useful references in URL notation: XML Quick Links -Robin ------------------------------------------------------------------------- Robin Cover Email: robin@acadcomp.sil.org 6634 Sarah Drive Dallas, TX 75236 USA >>> The SGML Web Page <<< Tel: +1 (972) 296-1783 (h) http://www.sil.org/sgml/sgml.html Tel: +1 (972) 708-7346 (w) FAX: +1 (972) 708-7380 ========================================================================= 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 Feb 26 22:35:44 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification Message-ID: <4028@ursus.demon.co.uk> I'm really impressed with the contributions - it seems clear that there are (rightly) some ambitious visions. In message <3.0.32.19970226084314.006953ec@pop.intergate.bc.ca> Tim Bray writes: [...] > Fortunately, we're not starting from scratch. We have two strawman [...] > I would propose seriously that Java be the basis of the first > cut at an API spec; it is really very pleasingly clean, > and also has the virtue that ideas can be tested more or less > instantly because there's running parser code to graft them > onto. - Tim I'd agree with this. I think there is a case for a completely basic parser which builds from Lark/NXP and explores the basic issues that PhaseI raises. There are usually grey areas on a spec however well it is written (admittedly I haven't found any!) and it's useful to have code to throw at trial documents. Both Lark and NXP are excellent products and I could use either. The main question is what API they present and how I would use it. From my point of view the namespace for objects is critical and I suspect it isn't difficult, so here goes. I wrote a parser , which I shall junk, which takes an SGMLStream, or an ESISStream, and parses it into an Tree which contains Nodes. (I actually call them SGMLTree and SGMLNode, but I don't think this is useful). Nodes have an Attlist, which consists of Attributes. This Tree is isomorphous to a Lark which contains Elements. The Nodes are then subclassed (Java terminology, and I'd like a Java namespace to evolve from this as well as an IDL - I don't know enough about IDL yet). The first subclass is DrawableNode (which manages whether the children are visible, what the icon is etc.). Any WF document reaches this stage. The next question is the DTD. I create a DTD class (e.g. HTMLDTD, CMLDTD) whose role is to provide the information from the DTD to the application. I think this should be strightforward but I'm not clear enough to be sure what it should present. At present mine simply contains GIs (someone suggested ElementType was a better name.) It should also contain all the information in the normalised DTD, e.g. ContentModels, Attlists - what else is needed? My code works like this - when it reads a DOCTYPE it loads the Class for the DTD (e.g. CMLDTD.class). This has to be located somewhere ... let's assume that is not a problem. This class also has to load the classes to support the ElementTypes. So, for example, when the parser finds an Element with ElementType 'MOL', it checks to see if MOL.class is part of CMLDTD, if it is it loads it if necessary, and then it creates an Element of subclass FOO. public class FOO extends DrawableElement {...} in my case This is all fine, but it needs rewriting, and I would like to see the namespace agreed reasonably soon. I'm happy to go along with anything that is suggested. The DTD class is (IMO) critical is we are going to have a validating editor so that we can refer to individual Attlists, etc. Does NXP (which validates) contain the DTD as a subcomponent, for example. On the general strategy, I think that it's important (though difficult) to balance the needs of a global approach (using groves, etc.) and something that implements PhaseI. I'd like to argue for a PhaseI tool, partly because most of it is there in pieces, and partly because the rest is at the mercy of the final spec. There will also be some users of XML who are quite happy to stay with PhaseI software for their problems initially and move on as they see the need. 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 Wed Feb 26 23:06:30 1997 From: bosak at atlantic-83.Eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 16:57:23 2004 Subject: Call for participants: WWW6 workshop Message-ID: <199702262305.PAA22327@boethius.eng.sun.com> I will be coordinating an all-day workshop on "Delivering Structured Documents over the Web" that will be held in conjunction with the WWW6 Conference in Santa Clara, California on April 7, 1997. For a description, see http://www6conf.slac.stanford.edu/workshops/structure.html Workshop participation is by invitation only. If you would like to participate, please send me a brief statement (1-2 paragraphs) setting forth your position on what you think the best approaches would be to implementing structured document delivery on the Web in the areas of syntax (structured HTML, generic XML, SGML), linking (HyTime, XML-Link, Hyper-G), processing/scripting (Java, JavaScript, Active-X), and style (CSS, DSSSL, dsssl-o). I'm looking to assemble a group of knowledgeable people who are dedicated to enabling structured document delivery on the Web but have differing viewpoints on how that delivery should best be accomplished. Jon (bosak@eng.sun.com) ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, | Best is he that inuents, Mountain View, California 94043 | the next he that followes Davenport Group::SGML Open::ANSI X3V1 | forth and eekes out a good ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB | inuention. ---------------------------------------------------------------------- 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 Thu Feb 27 09:57:58 1997 From: richard at light.demon.co.uk (Richard Light) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification In-Reply-To: <4028@ursus.demon.co.uk> Message-ID: In message <4028@ursus.demon.co.uk>, Peter Murray-Rust writes >On the general strategy, I think that it's important (though difficult) to >balance the needs of a global approach (using groves, etc.) and something >that implements PhaseI. I'd like to argue for a PhaseI tool, partly >because most of it is there in pieces, and partly because the rest is >at the mercy of the final spec. There will also be some users of XML who >are quite happy to stay with PhaseI software for their problems initially >and move on as they see the need. I don't claim to have fully grasped the mechanics of _applying_ grove plans, but isn't the principle that you use them to specify which subset of the SGML property set you want in your output grove? If so, can't we say that our PhaseI requirements are a 'grove plan', then use the relevant bits of the SGML Property Set as the primitives for our 'data structure' API? Does the SGML Property Set contains all the data constructs and properties we are interested in from an XML perspective? I'm not suggesting that the structures and their properties should be expressed as in the DSSSL standard (Section 9.6 - horrendous!), but if that section of DSSSL contains a complete description of all the concepts we want in the XML API, we simply have the job of re-expressing them in a different notation. This could even be reduced to a mechanical process. That is _much_ easier than re-inventing them all. It also means that we have a painless method of extending the API: we simply add to our grove plan and pull in the extra concepts. It also aligns the XML API as a practicable implenetation of a (useful!) subset of the standard SGML Property Set. 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 tms at ansa.co.uk Thu Feb 27 11:43:28 1997 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification In-Reply-To: Peter@ursus.demon.co.uk's message of Wed, 26 Feb 1997 22:09:12 GMT References: <4028@ursus.demon.co.uk> Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/plain (pgp signed) Size: 4628 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970227/7026e545/attachment.bin From Peter at ursus.demon.co.uk Thu Feb 27 11:52:15 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification Message-ID: <4034@ursus.demon.co.uk> Richard, This is very helpful. It is probably patently apparent that I am struggling with groves, grove plans and so on. I am also struggling with the SGMLPropertySet. It is clear to me that a very high priority for people like me is a 'Gentle Introduction to Groves and PropertySets". (Even if I could manage all of 10179 it's difficult to tell what is _important_ and what isn't :-). I notice that the property set is itself ISO:17044 - does that mean it's an add-on to 8879?) As always I present myself as an archetype of someone who has encountered SGML pragmatically and takes it as a voyage of exploration, going as far as is necessary to solve a problem. It's therefore a process of gradual extension of knowledge. Take my position as someone who can run sgmls and use the ESIS output via CoST (Joe English's version). My education is largely due to Joe's documentation and many helpful e-mails :-). My current understanding (PLEASE CORRECT THIS ANYONE!) is that a normalised WF XML document is isomorphic to its ESISStream. IOW having read the XML document, applied any conditional clauses, substituted any entities, the XML document contents can be automatically converted to ESIS and vice versa. [The reason this matters is that until recently I have been using sgmls to parse CML and input the ESIS into my tools. I also have a crude XML-like parser :-).] I think there will be quite a few people who think along these lines - the SGML/XML is validated and transformed into a single ESIS-equivalent. At present it's adequate for my (limited) requirements. My very crude vision of groves is that these are a set of tree-structured views of the ESIS/XML tree, with properties being added at nodes for various purposes that I do not yet understand. Am I on the right lines? :-) In message Richard Light writes: > In message <4028@ursus.demon.co.uk>, Peter Murray-Rust > writes > >On the general strategy, I think that it's important (though difficult) to > >balance the needs of a global approach (using groves, etc.) and something > >that implements PhaseI. I'd like to argue for a PhaseI tool, partly > >because most of it is there in pieces, and partly because the rest is > >at the mercy of the final spec. There will also be some users of XML who > >are quite happy to stay with PhaseI software for their problems initially > >and move on as they see the need. > > I don't claim to have fully grasped the mechanics of _applying_ grove > plans, but isn't the principle that you use them to specify which subset > of the SGML property set you want in your output grove? If so, can't we ^^^^^^^^^^^^^ This is a beast that I don't understand, and would be happy for an explanation. Since (I don't think) it occurs in PhaseI it's important that we make sure that any implementation of PhaseI-only material can be understood from the spec. > say that our PhaseI requirements are a 'grove plan', then use the > relevant bits of the SGML Property Set as the primitives for our 'data > structure' API? > > Does the SGML Property Set contains all the data constructs and > properties we are interested in from an XML perspective? > > I'm not suggesting that the structures and their properties should be > expressed as in the DSSSL standard (Section 9.6 - horrendous!), but if Ah... I am looking at the section. This was a bit I hoped was 'unimportant'. The XML-WG has been debating whether conecpts from standards outside XML can be used without being explicitly in the XML spec. I would hate to think that XML implicitly involved 10179:9.6. I can accept that it may/will come into PhaseIII. > that section of DSSSL contains a complete description of all the > concepts we want in the XML API, we simply have the job of re-expressing > them in a different notation. This could even be reduced to a > mechanical process. A human translation of 9.6 would be valuable as well :-) > > That is _much_ easier than re-inventing them all. It also means that we > have a painless method of extending the API: we simply add to our grove > plan and pull in the extra concepts. It also aligns the XML API as a > practicable implenetation of a (useful!) subset of the standard SGML > Property Set. I will have to leave this to others :-) The key questions seem to me to be: 'Can we provide an API for PhaseI, as it now stands (with any minor future revisions to the spec)?'. 'If we create such an API is it _extensible_ to PhaseII and/or PhaseIII, when we are not clear of their final detailed shape?' My gut feeling is that a PhaseI API can be extended to a PhaseII API without breaking it seriously. (We shall doubtless define things like Link, MultiLink extends Link, etc.) It seems (again from my position of ignorance) that your concern is 'if we create an API for PhaseI and don't think about the effect on PhaseIII, we could find ourselves in serious trouble'. I can't help there. However if we _can't_ easily extend NXP, Lark, etc then we are going to have a fairly hairy system to work with. 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 Feb 27 12:35:49 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification Message-ID: <4037@ursus.demon.co.uk> Toby, Your suggestions are very similar to my own way of thinking, and what is implemented (very crudely) in JUMBO. In message Toby Speight writes: [...] > > I think IDL is a worthy target, and one we ought to have in mind. But > if speed of development and deployment are important (I think they > are), a Java implementation makes a better "first-cut" prototype. My gut feeling is that if we pursue a Java implementation then (apart from the speed - which matters to me :-), we shall create a namespace that is reusable by the IDL. It may be that this has to be expanded but that's not a problem. > > > Peter> The next question is the DTD. I create a DTD class > Peter> (e.g. HTMLDTD, CMLDTD) whose role is to provide the information > Peter> from the DTD to the application. I think this should be > Peter> strightforward but I'm not clear enough to be sure what it > Peter> should present. At present mine simply contains GIs (someone > Peter> suggested ElementType was a better name.) It should also > Peter> contain all the information in the normalised DTD, > Peter> e.g. ContentModels, Attlists - what else is needed? > > An application may want to get at entity definitions (of both types). > Certainly, in writing an editor-type application (i.e. anything which > takes XML input, and transforms it into some related XML or SGML > output), there's a case for preserving entity references, rather than > expanding them. Totally accepted. (The sort of thing we might want to do is to create a 'ThesisEditor' for chemistry. This would have entities like &chapter1; &tables1; &molecules; etc. and these should be relocatable as entities as well as expanded subtrees. > > > Something I'd like to do is to use Java as a kind of stylesheet > mechanism, for interactive functionality not easy to do with DSSSL > (which is somewhat paper-oriented). For example, I'd like to be able ^^^^^^^^^^^^^^^ Agreed. > to write documents like > > > > > > package="UK.co.ansa.tms" ?> > > > > > > > > Picture Gallery > > > > > > and have the UK.co.ansa.tms.Picture class handle the rendering of the > Picture element (I'd probably want a Default class to deal with > elements that don't have corresponding classes - it would be tedious > to write a class for every element). Ignore the fact that most HTML Exactly. This is my DrawableElement class - it can be displayed, but probably only offers a subtree, attlist, PCDATA children, etc. in a standard fashion. > browsers can do something similar - in fact, one reason I'd want this > is to have the UK.co.ansa.tms.Picture class generate HTML markup like > >

ALT="My house"> > > This mechanism would enable anyone to write XML documents and the Java > classes to render them, if the receiver has the basic parsing engine - > you could provide the same document with different classes for > printing, for HTML production, for interactive use, etc - or your > Document class may have interactive options (menu items) for these > things, calling the appropriate methods in the rendering classes. > Exactly. Your document is WF (it doesn't have a DOCTYPE) but the author is saying "I have used a PICTURE tag. I suggest you retrieve the Picture.class method and apply it. Here's an address you might use (www.ansa.co.uk...)." The client doesn't need to know what a Picture is. IFF you agree with the client what a Picture is, the client might say "thanks, but I already have client.Picture.class and I'll use that". client.Picture might be a subclass of ansa.Picture. This is the Java equivalent of applying stylesheets at different times. > > Here's a rough skeleton: > > > > package UK.co.ansa.tms; > > > > public class Picture extends Default { > > // Default extends Component, for on-screen rendering > > private String title; > > > > public Picture(xml.Element e) { > > // or nxp.Element, or lark.Element - haven't read enough detail > > // on either, yet. Can we have DTD information in e? > > // Create from the parse tree > > title = e.getAttribute("TITLE", true); > > // We grab attribute values in their "cooked" state, after > > // entity expansion > > } > > > > public void draw() { > > // called by the parent element > > } > > > > public void print() { > > // called by the parent element in response to user input > > } > > } > > > That's a very simple class with empty content model, container > elements would in most cases implement draw(), print(), etc. by > calling the same method on each of their contained elements. An > editing class, of course, may override routines for inserting or > deleting content, or changing attributes. This is exactly what JUMBO does - every Element has a display(Graphics g) toString() toHTML() toSGML() // should be XML :-) debug() process() // for delayed processing and caching of complex Elements mouseUp(...) etc. addHelp() // element-based help drawIcon(...) // icon-based recognition of element One obvious example of a re-usable Element is DATE where the pointer can be to java.util.DATE. In that way we could use 8601-based dates and render them interactively. Other examples would be things like the various image types. With a WF document you have to be careful that the client picks up the right class and you have bound this via the APPLET mechanism. With a non-html-based document there needs to be some way of locating the methods precisely. You also have to download information for each class used. You need to have a mechanism for loading the classes (i.e. something has to recognise the ElementType and download the class, maybe creating an Element of this subclass - this is what JUMBO does.) A Valid document can also use the DTD information and in that way can pre-load the appropriate classes. It may also help to create a robust type of distribution, especially where the DTDs are accepted within a community and signed classes can be installed on the client side. [...] > 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 gtn at ebt.com Thu Feb 27 14:22:24 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification In-Reply-To: <4028@ursus.demon.co.uk> (Peter@ursus.demon.co.uk) Message-ID: <199702271419.JAA24115@nathaniel.ebt> I think that for the *parser*, we should define an event-handling interface, as it is much simpler to build certain applications that way, and because you can build a tree from a stream of events if you need to. Some questions that will affect the API is whether one sees empty element as elements containing nothing, or as elements unable to contain anything, and wether entity/attribute type information needs to be passed across thr API. What do people think? How much information must the parser pass along? 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 Feb 27 14:30:46 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification Message-ID: <4044@ursus.demon.co.uk> In message Toby Speight writes privately (with permission to publish quotes): [...] > > Do you have a URL where I can look at Jumbo? (Or at least read the > interfaces). [...] The latest version is at: http://www.venus.co.uk/omf/cml/moltest.tar.gz and .../moltest1.tar.gz (This is a distribution which runs under a simply browser on any platform though I have occasionally had crashes on one platform. I think this is a porting problem, not something in my code). However it has also been written as an applications as well as an applet so it can be run as standalone as well. The distrib is *.class and html+data. The API (not precisely up to date is at http://www.venus.co.uk/omf/cml/doc/api/sgml.html I'm still working out what to do :-) (a) there is a lot of bleeding code. Some is historical, and shows me learning Java. Other bits are experiments. Yet others are just a little tiny bit short on documentation. (b) JUMBO is a largish system. It consists of (well-separated) packages in a DAG. Thus pmr.sgml requires pmr.euclid (maths), pmr.util, and pmr.simplegraph (for the graphics). The graphics has the concept of a Drawable inside a ScrollableTopLevel. (The STL will disappear, I hope, when JDK 1.1 is released widely). All SGMLNodes (== Elements) are subclassed to DrawableSGMLNodes. Therefore quite a lot of code is taken up with the Graphics. There are classes pmr.cml, pmr.stat, pmr.molecule and pmr.chemime which are not relevant. (c) In production mode I expect it to be subclassed (just like I'm happy to subclass Lark). the current intention is to make source available to members of the Open Molecule Foundation (http://www.ch.ic.ac.uk/omf). The OMF has various types of membership which includes one for organisations who intend to help develop code collaboratively. My _intention_, is to make the source code available to people who are actively involved in collaborating, but to avoid the chance of mutations for whatever purpose. One thing we should all aim at is signed code (e.g. Java, PGP or whatever mechanism). The problem is that I'm not wildly proud of the pmr.sgml package at present. Amongst other things are the detritus of various attempts to support HTML, which I'm trying to do today (i.e. clean up and get it right). So I shall probably make cleaned up code available to identified collaborators. [...] > > Peter> One obvious example of a re-usable Element is DATE where the > Peter> pointer can be to java.util.DATE. In that way we could use > Peter> 8601-based dates and render them interactively. > > Yes, perfest! (At the moment, my HTML sources have stuff like > > > > > Thursday, 2' February 1997, at 12:01 PM (GMD) > > Where I'd liku to be able to replace the comments with real tags. > Note that "VALUE" is ISO-8601 and hence UTC, but the displayed part is > in local time. A xml.Date class would let the users choose either, or > perhaps their own local-time) > > Date may be a case for subclassing AttributeValue (or whatever we call > it). or CHECKED="19970227T120147"> > > > > I think I'd see the re-use through inheritance (or delegation), > though: > > > package myApp; > > > > public class Date extends xml.Date { > > // empty class; just to get into the right namespace > > } > > or > > > package myApp; > > > > public class Date extends BaseClass { > > xml.Date value; > > > > public Date(/* args */) { > > value = new xml.Date(/* args */); > > } > > > > public String toString() { > > return value.toString(); > > } > > > > //etc. > > } Yes. I'm keen to develop a semi-formal set of common 'tags' that there are XML-friendly Java classes for. > > [...] > Peter> A Valid document can also use the DTD information and in that > Peter> way can pre-load the appropriate classes. It may also help to > Peter> create a robust type of distribution, especially where the DTDs > Peter> are accepted within a community and signed classes can be > Peter> installed on the client side. > > I'd not thought this far. I'd seen Valid documents as being > semi-essential for editing (probably by having the elements superclass > check modifications against the appropriate declaration in the DTD, > and throwing an exception for an invalid change - you'd want some sort > of (lightweight) transaction mechanism to handle (C,B))>, though). An editor *ought* to be able to intelligently edit My understanding is that NXP will handle any valid XML content model. The question is how it's called from the application and when. E.g. you have got: ... ... ... ... and you add a _valid_ F after the D element. You need to re-validate the content of B, but nothing else (e.g. a B content of (D*, (E|F)) would originally be valid but now would fail. If you meant to _replace_ E by F, you might want to to the addition, then the deletion (of E) and only then revalidate. 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 cbullard at hiwaay.net Thu Feb 27 14:32:44 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:23 2004 Subject: XML API specification References: <4034@ursus.demon.co.uk> Message-ID: <33159856.3ECF@hiwaay.net> Peter Murray-Rust wrote: > > My gut feeling is that a PhaseI API can be extended to a PhaseII API > without breaking it seriously. (We shall doubtless define things like > Link, MultiLink extends Link, etc.) It seems (again from my position of > ignorance) that your concern is 'if we create an API for PhaseI and don't > think about the effect on PhaseIII, we could find ourselves in serious > trouble'. I can't help there. However if we _can't_ easily extend > NXP, Lark, etc then we are going to have a fairly hairy system to work > with. It appears that an IDL-specified API that expresses the SGML property set used in the XML application profile is the most flexible proposal. A Java-implementation from that would be the most flexible product. The XML Link specification is not, (I believe) an SGML property set issue since these are application semantics. It is important to express these in the IDL. len bullard lockheed martin 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 Thu Feb 27 14:38:38 1997 From: richard at light.demon.co.uk (Richard Light) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification In-Reply-To: <4034@ursus.demon.co.uk> Message-ID: In message <4034@ursus.demon.co.uk>, Peter Murray-Rust writes >Richard, > This is very helpful. It is probably patently apparent that I >am struggling with groves, grove plans and so on. I am also struggling >with the SGMLPropertySet. It is clear to me that a very high priority >for people like me is a 'Gentle Introduction to Groves and PropertySets". >(Even if I could manage all of 10179 it's difficult to tell what is >_important_ and what isn't :-). I notice that the property set is itself >ISO:17044 - does that mean it's an add-on to 8879?) Hands up anyone who _isn't_ struggling with this stuff! I know it makes my brain hurt ;-) All it's saying in DSSSL is that the _full_ definition of a property set is to be found in the HyTime standard (10744) - Section 6.7. One potentially relevant thing that I don't know about is the HyTime Technical Corrigendum, which I think re-defines the SGML Property Set so that HyTime, DSSSL, SGML etc. will be all in line with each other. And it's still being finalised. >My very crude vision of groves is that these are a set of tree- structured >views of the ESIS/XML tree, with properties being added at nodes for various >purposes that I do not yet understand. Am I on the right lines? :-) I think so. Anyway, as one pragmatist to another ... My understanding of groves is that they take the tree structure idea one step further than we are used to in dealing with SGML documents, and thereby make everything simpler, but more verbose. We are used to thinking of an SGML document as a tree structure of elements, each with lots of miscellaneous additional properties 'hanging off the side'. The grove idea says "let's take this additional stuff, and see that as part of the tree as well". So an element node, for example, now has a subnode containing its GI, and one subnode for each [non-implied?] attribute. Each of these attribute subnodes will in turn have subsubnodes containing e.g. the attribute name and value. The whole SGML Property Set is defined (naturally enough) as an SGML document. What you get is the definition of a number of groups, or 'property set modules' ( elements). Each contains the definition of classes ( elements), and each class has zero or more properties ( elements). The s must actually _contain_ the s that follow them, although there are no tags to make this explicit. (Roll on XML, I say!) So, to plunge right into 9.6 and take an example: An attribute assignment, whether specified or defaulted. In the base module because of data attributes. declares the class "attasgn" (full name "attribute assignment"). Below this: If the attribute value is tokenized, the children are of type attvaltk; otherwise, they are of the other allowed types. The attribute is not an impliable attribute for which there is no attribute specification. declares the first property of an attribute assignment, which is its "value", and: declares the second property of an attribute assignment, which is its "name". As well as giving names to all these things (so we don't have to make them up), this definition includes other potentially useful information. (In fact there are usually two names: a short 'Reference Concrete Syntax' name and a longer application name, which was specifically designed for use "in a programming or scripting language".) The DATATYPE attribute states what type of data the property contains (string, node list, integer, etc.). The AC attribute says what types of subnodes the property is allowed to have (= a 'content model' for property nodes!). STRNORM declares whether the value is to be normalized. And so on. >My current understanding (PLEASE CORRECT THIS ANYONE!) is that a normalised >WF XML document is isomorphic to its ESISStream. IOW having read the >XML document, applied any conditional clauses, substituted any entities, >the XML document contents can be automatically converted to ESIS and vice >versa. [The reason this matters is that until recently I have been using >sgmls to parse CML and input the ESIS into my tools. I also have a crude >XML-like parser :-).] I can't answer that, but can point out that DSSSL specifies three ps modules which together 'roughly' correspond to ESIS (baseabs, prlgabs0 and instabs). These would be the bits of the SGML Property Set to examine first. >> I'm not suggesting that the structures and their properties should be >> expressed as in the DSSSL standard (Section 9.6 - horrendous!), but if > >Ah... I am looking at the section. This was a bit I hoped was 'unimportant'. >The XML-WG has been debating whether conecpts from standards outside XML can >be used without being explicitly in the XML spec. I would hate to think >that XML implicitly involved 10179:9.6. I can accept that it may/will come >into PhaseIII. My take on this is that you start from the XML spec, and find the corresponding bits of 9.6 to give you a standard nomenclature. Richard. 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 Feb 27 15:06:06 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification Message-ID: <4048@ursus.demon.co.uk> Richard, Thanks very much. This is clearer that 300 pp of 10179. And it *does* have a bearing on how we write the API. In message Richard Light writes: [...] > > We are used to thinking of an SGML document as a tree structure of > elements, each with lots of miscellaneous additional properties 'hanging > off the side'. The grove idea says "let's take this additional stuff, > and see that as part of the tree as well". So an element node, for ^^^^^^^^^^^^ (in passing, it's clear that we have to resolve the Element/Node naming :-) > example, now has a subnode containing its GI, and one subnode for each > [non-implied?] attribute. Each of these attribute subnodes will in turn > have subsubnodes containing e.g. the attribute name and value. OK. So if, at present I write (using Node rather than Element): public class Node { NodeVector subnodes; Attlist attlist; PIVector piVector; StringVector pcdataVector; ... } What the grove approach will do is to call these all Nodes and (perhaps) subclass them: public class PI extends Node { ... } and the Node class becomes: public class Node { NodeVector subnodes; // Nodes, PCDATA, PIS, etc., ... } > [...] > So, to plunge right into 9.6 and take an example: > > conprop=value dsepprop=tokensep clause="79002"> > > An attribute assignment, whether specified or defaulted. > > In the base module because of data attributes. > [...] ormation. (In fact there are usually two names: a short 'Reference > Concrete Syntax' name and a longer application name, which was > specifically designed for use "in a programming or scripting > language".) The DATATYPE attribute states what type of data the PLEASE can we all agree to use the long names :-). I have spent much of my life hacking FRTRN and I value words that make sense! [...] > I can't answer that, but can point out that DSSSL specifies three ps > modules which together 'roughly' correspond to ESIS (baseabs, prlgabs0 > and instabs). These would be the bits of the SGML Property Set to > examine first. I saw that, and assume someone else will explain it! [...] ... I am looking at the section. This was a bit I hoped was > 'unimportant'. > >The XML-WG has been debating whether conecpts from standards outside > XML can > >be used without being explicitly in the XML spec. I would hate to > think > >that XML implicitly involved 10179:9.6. I can accept that it may/will > come > >into PhaseIII. > > My take on this is that you start from the XML spec, and find the > corresponding bits of 9.6 to give you a standard nomenclature. You have convinced my that this must be taken seriously and (much as I don't like the immediate consequences) suspect that it's the right thing to do. However *if* we all use (say) Attribute consistently, then presumably we can convert it later... ? It can always be subclassed... 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 Feb 27 15:06:17 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification Message-ID: <4049@ursus.demon.co.uk> In message <199702271419.JAA24115@nathaniel.ebt> gtn@ebt.com (Gavin Nicol) writes: > I think that for the *parser*, we should define an event-handling > interface, as it is much simpler to build certain applications > that way, and because you can build a tree from a stream of > events if you need to. In CoST Joe English supported both eventStreams and trees (I'm sure Joe will have some wisdom on this one). I started off using the event mechanism and switched to a tree-based one but I suspect that this was the nature of the application. My current problem may highlight this. A CML document is highly tree-structured and contains no mixed content, so that eventStreams don't contribute much. BUT it also includes chunks of HTML where a tree structure is quite inappropriate. If I take a Lark-based approach (or my own parser) the HTML gets rendered into a tree. I am now hacking this back into an event stream to render the hypertext. Not only does it take more effort, but I'm sure that holding HTML as a tree has a memory hit. Ideally when I'm parsing CML, and come to the tag (sic) which contains , I'd like to tell the parser 'stop parsing as a tree and just hold a hypertext string until . We *could* do this with a PI, but would have to all agree. > > Some questions that will affect the API is whether one sees empty > element as elements containing nothing, or as elements unable to Yes. > contain anything, and wether entity/attribute type information needs > to be passed across thr API. I have been convinced that entity information needs to be preserved and I assume there are people who are concerned about attribute_type. If nothing else, this is probably critical for ID/IDREF. > > What do people think? How much information must the parser pass > along? At least what comes out of sgmls/ESIS, probably with general entities added. We also need to know the DOCTYPE info. [...] 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 Feb 27 15:17:15 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:24 2004 Subject: Multiple mails Message-ID: <4055@ursus.demon.co.uk> I (and I suspect other authors) are getting multiple mails from some authors, presumably because they reply to [me] and also copy the list. I suspect that majordomo is not capable of realising that the CC:'ed author is also a member of the list. This problem was noted on XML-WG and it would be helpful if replies were posted just to the list (or privately to the author). :-) BTW I think the discussion is extremely valuable and on occasion some may form useful reference material. 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 gtn at ebt.com Thu Feb 27 15:17:24 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification In-Reply-To: (message from Richard Light on Thu, 27 Feb 1997 09:33:10 +0000) Message-ID: <199702271514.KAA24157@nathaniel.ebt> >I don't claim to have fully grasped the mechanics of _applying_ grove >plans, but isn't the principle that you use them to specify which subset >of the SGML property set you want in your output grove? If so, can't we >say that our PhaseI requirements are a 'grove plan', then use the >relevant bits of the SGML Property Set as the primitives for our 'data >structure' API? Right. The core grove is a very simple data structure. I do not think our *parser* API should be the grove that results from parsing an XML document though. In my JAVA/C++ API, I do something like the following: public class Property { public String m_name; public Node m_value; } public class Node { public Node m_parent; public Node m_left_sibling; public Node m_right_sibling; public Node m_first_child; public Vector m_properties; } public interface GroveEventHandler { public OnStartNode(Node node); public OnEndNode(Node node); } I think for XML, we should probably get more concrete. The question is how much more concrete? How much information *must* the API support? Do we *need* Element, Attribute, Comment, PI, Header, DTD, MarkedSection, EntityReference, Entity etc. etc? 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 gtn at ebt.com Thu Feb 27 15:23:06 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification In-Reply-To: <4034@ursus.demon.co.uk> (Peter@ursus.demon.co.uk) Message-ID: <199702271520.KAA24159@nathaniel.ebt> >If we create such an API is it _extensible_ to PhaseII and/or PhaseIII, >when we are not clear of their final detailed shape?' These are just application layers. 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 Thu Feb 27 15:23:47 1997 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification Message-ID: <3.0.32.19970227071327.00a32fe4@pop.intergate.bc.ca> At 02:54 PM 27/02/97 GMT, Peter Murray-Rust wrote: >In CoST Joe English supported both eventStreams and trees (I'm sure Joe will >have some wisdom on this one). > >If I take a Lark-based approach (or my own >parser) the HTML gets rendered into a tree. Lark always provides an event stream, and whether or not it also builds a tree can be toggled on and off by the calling app while it's running. This sounds like what you want. - 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 Peter at ursus.demon.co.uk Thu Feb 27 15:28:02 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification Message-ID: <4059@ursus.demon.co.uk> This is very helpful, thanks. In message <199702271514.KAA24157@nathaniel.ebt> gtn@ebt.com (Gavin Nicol) writes: [...] > I think for XML, we should probably get more concrete. The question > is how much more concrete? How much information *must* the API support? There are possibly two questions here. Do we need to _pass the information_, and do we need to _have special names_ (rather than just Property). I suspect that you will find it difficult to get rid of anything below that will satisfy everyone. My own simple experience is that I would actively use the following: > Do we *need* Element, Y Attribute, Y Comment, N (an XML processor _may_, but need not, pass these. where would they be attached?) PI, Y Header, Y DTD, Y MarkedSection, N EntityReference, Possibly, when I get brave Entity etc. etc? > I would, however, be prepared to receive them as Property, so long as they were clearly documented, and I assume that they might well be subclassed from Property anyway. 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 Feb 27 15:44:33 1997 From: Peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification Message-ID: <4065@ursus.demon.co.uk> Thanks very much Tim, In message <3.0.32.19970227071327.00a32fe4@pop.intergate.bc.ca> Tim Bray writes: > At 02:54 PM 27/02/97 GMT, Peter Murray-Rust wrote: [...] > > Lark always provides an event stream, and whether or not it also builds > a tree can be toggled on and off by the calling app while it's running. > This sounds like what you want. - Tim Exactly! Two ways of using it come to mind. (a) using a PI to switch this on and off. This is sufficiently fundamental that it might be made an XML PI ( and ) or similar (b) certain GIs or attributes could toggle this (e.g. ) 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 gtn at ebt.com Thu Feb 27 15:48:19 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification In-Reply-To: <4059@ursus.demon.co.uk> (Peter@ursus.demon.co.uk) Message-ID: <199702271545.KAA24209@nathaniel.ebt> >There are possibly two questions here. Do we need to _pass the information_, >and do we need to _have special names_ (rather than just Property). I suspect >that you will find it difficult to get rid of anything below that will >satisfy everyone. My own simple experience is that I would actively use >the following: OK. I think this is good arguments for actually defining these classes, because people who want abstract groves can take these, and build groves out of them. >I would, however, be prepared to receive them as Property, so long as they >were clearly documented, and I assume that they might well be subclassed >from Property anyway. Actually, from Node. 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 ddb at criinc.com Thu Feb 27 15:59:51 1997 From: ddb at criinc.com (Derek Denny-Brown) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification Message-ID: <3.0.32.19970227075431.009dc290@mailhost.criinc.com> At 09:19 AM 2/27/97 -0500, Gavin wrote: >I think that for the *parser*, we should define an event-handling >interface, as it is much simpler to build certain applications >that way, and because you can build a tree from a stream of >events if you need to. yes. Actually, it might be best to define an event interface (similar to SP?) first, and then define a grove interface. In terms if test-implimentations, that means we could build an general event->grove module which could be used on any (conforming) event generating parser >What do people think? How much information must the parser pass >along? It depends... In many cases an application could care less about resolved entities etc (e.g. a DSSSL-O engine) It just wants the structure. Other times, the application wants everything. (e.g. an editor) If you make it a runtime switch there is performance overhead (always checking to see if the client/application _wants_ the data you just derived) If it is not runtime selectable then the simple case sufferes... I would say that the event interface might have options (similar to SP) to control which events it generates (elements, attributes, entity start/end, dtd, etc.) The grove interface should be able to have a similar range... (though I am not sure that a SGML Grove can be usefully built w/o a DTD.) On Gavin's other point... the results from the parse should allow you to trivially build an identity transform application. This need not include keeping the exact format of the original source. This means that empty elements and elements with no content are different. etc. -derek -- Remember: Computers are here to make our lives easier -- ddb@criinc.com // software-engineer // www/sgml/java/perl/etc. 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 ddb at criinc.com Thu Feb 27 16:38:25 1997 From: ddb at criinc.com (Derek Denny-Brown) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification Message-ID: <3.0.32.19970227083301.009c3960@mailhost.criinc.com> At 10:14 AM 2/27/97 -0500, you wrote: >I do not think our *parser* API should be the grove that results >from parsing an XML document though. In my JAVA/C++ API, I do something >like the following: > > public class Property { > public String m_name; > public Node m_value; > } > > public class Node { > public Node m_parent; > public Node m_left_sibling; > public Node m_right_sibling; > public Node m_first_child; > public Vector m_properties; > } > > public interface GroveEventHandler { > public OnStartNode(Node node); > public OnEndNode(Node node); > } hmmm... How does is a Property which is a NodeList represented? What about a integer/string/boolean Property? Or even worse, and integer list or a string list! Unfortunately, at one point I spent over a week trying to come up with a simple but powerful grove interface. It just ain't that easy. I think it would go more like... public class Value { public String m_string; public int m_integer; public bool m_bool; public Vector m_list; public int m_type; // what kind of data does this value contain } public class Property { public String m_name; public Value m_value; } public class Node { .... as listed ... } The other minor problem is that the child(ren) are defined by the value of a property (which property is specified on the classdef). I am not convinced that it is really worth implimenting groves this way though. Groves are designed such that it is often easier to duplicate information, in a slightly different form, than to just reference it. Sometimes you have to. For example each element has it's GI as a string valued property. It also has the same information encoded as a reference to the element type. When I was working on a general Grove interface I came to decide that it really should be a grove specific set of classes which build on some more primitive interfaces (such as node, property_value), and which impliment properties as methods. This also opened the door to such functionality as concurent construction (a property value may be 'not-available-yet') which is necessary for an online environment. A the time I also had a SP Application which parsed property sets into some C++ data structures, which I then used to generate teh stubs for the grove interface. The project never was really finished, and I have since moved jobs... so I can't really go back an look at it, though I may be able to get a copy of the SP app. -derek -- Remember: Computers are here to make our lives easier -- ddb@criinc.com // software-engineer // www/sgml/java/perl/etc. 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 gtn at ebt.com Thu Feb 27 17:10:58 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification In-Reply-To: <3.0.32.19970227075431.009dc290@mailhost.criinc.com> (message from Derek Denny-Brown on Thu, 27 Feb 1997 07:54:32 -0800) Message-ID: <199702271708.MAA25035@nathaniel.ebt> >>I think that for the *parser*, we should define an event-handling >>interface, as it is much simpler to build certain applications >>that way, and because you can build a tree from a stream of >>events if you need to. > >yes. Actually, it might be best to define an event interface (similar to >SP?) first, and then define a grove interface. In terms if >test-implimentations, that means we could build an general event->grove >module which could be used on any (conforming) event generating parser Yes. It is also possible to validate the *parser* implementation based soley upon the event-stream. 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 gtn at ebt.com Thu Feb 27 17:21:30 1997 From: gtn at ebt.com (Gavin Nicol) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification In-Reply-To: <3.0.32.19970227083301.009c3960@mailhost.criinc.com> (message from Derek Denny-Brown on Thu, 27 Feb 1997 08:33:01 -0800) Message-ID: <199702271718.MAA25041@nathaniel.ebt> >I am not convinced that it is really worth implimenting groves this way >though. Groves are designed such that it is often easier to duplicate >information, in a slightly different form, than to just reference it. >Sometimes you have to. Quite right. My implementation is actually different, though conceptually like the model I demonstrated. >When I was working on a general Grove interface I came to decide that >it really should be a grove specific set of classes which build on >some more primitive interfaces (such as node, property_value), and >which impliment properties as methods. Yes. Properties as methods is a much better idea. In my actual implementation, I basically export a map interface that allows properties to be set/get by name, and have various flavors of property. 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 Thu Feb 27 17:39:36 1997 From: lee at sq.com (lee@sq.com) Date: Mon Jun 7 16:57:24 2004 Subject: XML API specification Message-ID: <9702271737.AA06782@sqrex.sq.com> > My current understanding (PLEASE CORRECT THIS ANYONE!) is that a normalised > WF XML document is isomorphic to its ESISStream. It depends on what you mean by normalised. An SGML editor based on ESIS would not be very popular, as it would delete comments, and general entities would be expanded, so you would not be able to read a file and save it without losing your comments and entities! > Ah... I am looking at the section. This was a bit I hoped was 'unimportant'. > The XML-WG has been debating whether conecpts from standards outside XML can > be used without being explicitly in the XML spec. I would hate to think > that XML implicitly involved 10179:9.6. I can accept that it may/will come > into PhaseIII. I would hate to think that too. You must not have to read DSSSL (still less understand it!) in order to work with or implement XML parsers. You might have to do that to work with XML styles, of course... Lee 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 Thu Feb 27 18:33:21 1997 From: richard at light.demon.co.uk (Richard Light) Date: Mon Jun 7 16:57:25 2004 Subject: XML API specification In-Reply-To: <3.0.32.19970227083301.009c3960@mailhost.criinc.com> Message-ID: In message <3.0.32.19970227083301.009c3960@mailhost.criinc.com>, Derek Denny-Brown writes >hmmm... > >How does is a Property which is a NodeList represented? >What about a integer/string/boolean Property? >Or even worse, and integer list or a string list! The way it's done in the Property Set approach is to start by defining a set of data types, some of which are 'lists of' more primitive data types. Excuse the home-grown notation: {node} {nodelist listof=node} {enum} (for enumerated sets of values) {char} {string listof=char} {integer} {intlist listof=integer} {strlist listof=string} {compname} {cnmlist} (the last two relate to the Property Set defns themselves, and don't concern us - I think!) Once you've got that out of the way, you simply associate a data type taken from this list with each property you declare. In a similar spirit, every {node} has intrinsic properties: PROPERTY SET: NODEPROP Module: INTRBASE Property: CLASSNM (class name) [COMPNAME] Property: GROVROOT (grove root) [NODE] Property: SUBPNS (subnode property names) [CNMLIST] Property: ALLPNS (all property names) [CNMLIST] Property: CHILDPN (children property name) [COMPNAME] Property: DATAPN (data property name) [COMPNAME] Property: DSEPPN (data sep property name) [COMPNAME] Property: PARENT [NODE] Property: TREEROOT (tree root) [NODE] Property: ORIGIN [NODE] Property: OTSRELPN (origin-to-subnode rel property name) [COMPNAME] 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 richard at light.demon.co.uk Thu Feb 27 18:51:43 1997 From: richard at light.demon.co.uk (Richard Light) Date: Mon Jun 7 16:57:25 2004 Subject: XML API specification In-Reply-To: <9702271737.AA06782@sqrex.sq.com> Message-ID: In message <9702271737.AA06782@sqrex.sq.com>, lee@sq.com writes >> be used without being explicitly in the XML spec. I would hate to think >> that XML implicitly involved 10179:9.6. I can accept that it may/will come >> into PhaseIII. > >I would hate to think that too. You must not have to read DSSSL (still >less understand it!) in order to work with or implement XML parsers. >You might have to do that to work with XML styles, of course... We're only delving into the DSSSL standard as a means of getting at the SGML Property Set. And that only for an 'authoritative' (i.e. thought- about-before) set of names for concepts that _are_ defined in the XML spec. And hopefully some helpful ideas on organising the properties that the parser will expose to the API. >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) 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 cbullard at hiwaay.net Thu Feb 27 19:59:03 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:25 2004 Subject: Current Markup Language Example References: <3.0.32.19970131121434.00a8dfb0@pop.intergate.bc.ca> Message-ID: <3315E44A.5D27@hiwaay.net> Something to consider from a company producing Web applications for cellular phones. This is their web example for their Handheld Device Markup Language. This snippet produces a menu. Cust Status Orders Balance Isn't this what the behavior= optional attribute is good for? 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 richard at light.demon.co.uk Thu Feb 27 20:54:02 1997 From: richard at light.demon.co.uk (Richard Light) Date: Mon Jun 7 16:57:25 2004 Subject: SGML properties Message-ID: Hi, In an attempt to be helpful on the name space issue, I've got hold of the SGML Property Names as SGML, written a DTD that doesn't crash (does anyone know where the 'proper' sgmlprop.dtd can be found?), and written a little script to output the modules, classes and properties as defined there. For each I've included the short name and application name, and for properties I've included the data type. I know that we thought we would start with the 3 modules that 'match' ESIS (baseabs, prlgabs0 and instabs - they're the first three declared), but I didn't think a full set would hurt. Might even be interesting! [ Section: 1/1 File: proplst.zip Encoder: Turnpike Version 1.12 ] begin 644 proplst.zip M4$L#!!0````(`'R*6R*VI558_0L``-L\```,````4%)/4$Q35#$N5%A4Y1O+ MDJ,X\CX1_0\ZNF^[U[E1(-.$>0V2:ZMB8@X45KF)QN#ET5O]]ZN4`&,C">/I M/FQL]*F+?"LSE0_YTV]Q$L4XH:^(8/H[(F[@PU\^_0;_@NK0%>QW]&01;#V1 M3[\A9!=ITT@X)[+1ICF>"G2HLN[$RO8S0"`4U]69U>T/"6832GJXK"J;-BW; MYC/Z,XP<_-OE<<@=#$"]T9"I?6CUQ)S_<( MG0'@V)L#3-10RC>!L2BUB!MRF=JVSM^ZEB'^]_Q8*C5^MOP]-D@36@'6ZN(% ML>]A!_WY%$4^ML(9`(UV."0X1INV^L9*U+`SMXS]Q4JF6G&)N1AT-Q7Y>UIT M#`FLFM)_*/6PIN].Q0M#E6WUE=YN41_+G]<68Z+W6H#R[3 M0S4H+0^HR,MOXG^`%(3.K:W`YDY!_F(CZ6>\K+@YQ M"'(>6`45:M"#V=,IRN1U]7RWJ!>%$]:] M;88OZZQC5&JP^AQHE@SW3P!R[MZ*/)-4-!S)*P'(/F9,D"X.>V#I2"T[("7: M)="\D-#^OKB*F\C&/@XF,<`*)K*HY@0!6OBP_N"$*WK8!.)L?2HCX<#>TZX` M!>Z)!>GE&M$4#C#]G.`M3C@!Q2E*G696]O2W@J/]M,;%[2BDHT2SB'ZA,HF. MWB72J,(D,DSZ*#8'R8T!K^L)XLP3\=\B_\M("?]Q)MYSE71G6OU303S!VU&2 MFKU_-A0(48Q#M.'_*]&!%?E)%QNV'Q&N7E94#3-#@I/$V)Y6`\V9928A9`5! MXGD%,<&<.RI7-/;M+VB3ERVKSUS5BQT%JMB_^\BY"$1?+QD=XB*! M8_L:B0AD8VHE=(R)IDWK M>2VM)/$3@_PB#0Z=D0@K#]/R/R!<9?!IT!.N/I;)KJ17?T51['$!)*T^/HPT M'HD+-5^7JX?]X%()2N_X&0R3R-=7-5'BN9)Q5>?'O!PYJWH-X*XB(`]X)#`_ MXAX_D8`U:UC]G4LO`!77\@#VON`M:WC['L6)Y3\:UTL]XUV1'>Z#)YS,[B[/ M]>AUSA@R`;>%S9$XW?ZF-*;RQI[3ANG!SB!;>"REV\96K0=T3.DEO M858>..&;9EIJ>WNQZ!IIA:,$LE\57JKI:#6'UT.KJ`:DST@W8?Y@9N+$Z)Y, M^IN1C4@U-TR&E+/`XE)J$,?V%04VC#.><=)/,[ZSNN'4]2[N1+;]A6`Z*"E!P,3-DG$0"\EQ7175<`-YB?F:):"5N;TVX>(7:@WGFB=?!Q"8]Q($U M6:.K`3@M@)V`SJC!=Q&:\!7X#5%Y'7-7\2F+@TTICO`V.J>04*8*XF]IP^XC M+BI;T%^@3'Q$YUAIEYSI=]:-/$1YOF:U<*?EE5 MMOP0&\/`0V")"Y#KH8[*U[!W^-XCQZQG<.,$:XH_J,64'TALV3HDRW&V^Q": MML.!'=`[5T^D@.'4M.V;;X@)RJ_%D``]ZSQYO4JZ9T%S'(N%D@"6N/AB^5IG15"2!J@.&NE^KNH4S%IB- M]$`UBN]1R:SWC-YI[^!F46I#6ZT+'M%^^3!@U887P7\8`1QJN0L`.##SX-;W MGWW]=S>)C5KP[ZY93PYAY,`M;)00[FLS0)0$T*9I`6+/B+]D1/A^J\!0MHBH M50;MNA&N[5MD6A8L%^^.'R0<"7(I>']=%4PZY;RX-=7BL@[7E]_D-10AT`<` MUR^[CH'Y;D=@*.#U]T*"B:I*5Y:GJD)COKB@EL\AC6Z_^/V+&<+'@1$`(L=( MX&49(C2S@!2S]-VLA?6\)$08F7G`=S,/SUGX#!V'"2*PS"+Z.X+-0OH[A25[ MCQK*NUED6)3_<_774!1XU`B06.'.5)9$B1F?P-X/&RP':T';HWH*^&6`T-&P MH]#>)_KO9/\$^USM]VV4!):O'GQ"-T(<93$RN:1MECZU$;E8VY[1.3ZQEM78G,EE<*#18LA M%J6_C)T4H;JJ?9\F]0C`/A?2*\ MA1NH!A-/75R'P(WEO5Q0+C;C%F8?ZKF?+F']OST#N+YH%)3D^0W0 M6SW(U;S;T1^9%=O?52[.OVAK]_7 M+19!EY7D,L^UA75HW#^\N)P3QA*#Z(=X*@@H]YZ:`[UE5'\2^1^$V#G55KZ:6 M^E..!N,_TK_2Y*>'6G8Z%ZF\[+0%"'5CP)N@G=/#`=X_#NCJUUW0[BKDA#^3 M_99;K$[+;ZCIWM_S#\,L",`IO`:3X)RG&5C4,0)V*&*FF@WGH*`ZCPS^75M7 M:%LI53=)$H4AN$WI:V!Q:;D987(%4VBQ:CBEVO:")!QC&%D/P`M3;HX1!C1?)=BJOD]?&'+PYB?D<(^C[W`^!MY3\@FYS%77OB8B:9Z7@[%]Y3Y M1H29OR-#F,$+;.,Z6DS9_!T7-3^="R81^A\7Z-=NP%QT$`+\OC8B(3YU/3'F MAE[HF!LR&P>5CV)[X'O&0X`DA>J1[A-+S$^]<-OK`JO?07W=B=R),GB#WL0J MN\I24,#TVC[XS'5\AC.GN2II63;UGK'^IO7ISH/:;"2/ON7B*E?VKR2Q94YJ MJJ[.&+KJ();R=+1/;`VJR2O&]0IXQ1J&"29[GZI1]>\]/>$?,.G*VSPM%F/0 MP5<40H-P^,B:NFE4JSIJV, M-;]$(G2"9#AF"1WJ*[+_[0Q\?8TI!D(B(,0-.F98TV#$W_7M^"4'W8(/SJJ! M7'TKJU/UJOF'3LF'9+D.]3DS2#*"UR3)_$)V0\!=5'N\1DPPH5%BNH%Z@73. MP;\MA!(5//&C_7GHSZK:@;LBM(R+P&WL M*8I*_E>T>:_J4UJ@Z:^H;@]=#3W5^;HVO M2`''M^!7B0*G2,MCEQX-YRB8$/S'A4E^+-,6!@\-^W?'RFP)6;QQE (message from Richard Light on Thu, 27 Feb 1997 17:28:47 +0000) Message-ID: <199702272102.QAA26317@nathaniel.ebt> Hmm. 71 classes with 316 properties. 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 Fri Feb 28 15:18:16 1997 From: richard at light.demon.co.uk (Richard Light) Date: Mon Jun 7 16:57:25 2004 Subject: XML API spec Message-ID: <5lx6vCAzGtFzEwII@light.demon.co.uk> Interface (API-related) jobs the XML processor has to do ======================================================== I've just read through the XML spec (as of 14 Nov 96), and tried to get an idea of the potential scope of the API. These notes summarise what I found/thought. It may all be painfully obvious (or wrong), but I haven't seen any other attempts at looking at the task this way, so here goes: Operation --------- Presumably the XML processor is a 'slave' to the application, and only does what it's told to. View of the XML document ------------------------ What does the application 'see' of the XML document it has asked the XML processor to open? The spec implies that it should have pretty direct access, e.g.: "An XML processor must inform the application of the length of comments if they are not passed through, to enable the application to keep track of the correct location of objects in the XML document." This fills me with gloom. Shouldn't there be a level of abstraction here, so the API simply hands the application objects, and information about objects? In this case, shouldn't it flag the presence of a comment and leave it at that? If the application wants the comment, it can ask the XML processor for it! Startup ------- The application needs to tell the XML processor to open a document. This could be by reference (system id) or the document could be piped straight in. The 'open document' command needs to have arguments to set the processing mode, e.g.: - check to 'valid' or 'well-formed' level; - pass back a complete parsed document or just await further instructions Passing characters to the application ------------------------------------- Will the XML processor tell the application what encoding is in use? Then simply pass stuff through 'as found' (apart from converting character references to bit patterns as described)? I'll stop there to see if this is on the right lines or not ... Richard. 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 dgd at cs.bu.edu Fri Feb 28 17:14:37 1997 From: dgd at cs.bu.edu (David Durand) Date: Mon Jun 7 16:57:25 2004 Subject: XML API specification In-Reply-To: <199702271419.JAA24115@nathaniel.ebt> References: <4028@ursus.demon.co.uk> (Peter@ursus.demon.co.uk) Message-ID: At 9:19 AM -0500 2/27/97, Gavin Nicol wrote: >I think that for the *parser*, we should define an event-handling >interface, as it is much simpler to build certain applications >that way, and because you can build a tree from a stream of >events if you need to. Funny, that is exactly what I was thinking. Since reading the design patterns book, I've become quite fond of the "Builder" pattern, where some process like a parser takes as input an object whose methods perform appopropriate processing as the input is recognized. It's even possible to use Builders with things other than parsers, as long as they make the same callbacks. The real advantage of such an interface is that we don't impose a data structure on an application that might not want it. For instance, many functions are easier if you have an abstract syntax tree, but some quick and dirty applications won't need an AST, nor will they want to take the memory hit of building one if they don't need it... It might also be of use to define a callback interface that allows automatic delegation of building for certain elements. To be non-cryptic, I can see an application for a standard interface to java applets that will automatically delegate the processing of the events representing a particular sub-trees of the document to a particular applet. For instance, the default Java applet interface might allow a document to declare that elements should be processed by the class "InteractionGraph.class" This would cause the Builder implementation to auto-invoke the Applet for the parser events in each interaction graph, and then would pass the Applet instance to the main application, in place of its contents. Think of this as (slightly goofy?) event-driven compound document renderings. >Some questions that will affect the API is whether one sees empty >element as elements containing nothing, or as elements unable to >contain anything, and wether entity/attribute type information needs >to be passed across thr API. > >What do people think? How much information must the parser pass >along? > All that information _must_ be available. The chief reason that I find ESIS useless is that I can't write SGML->SGML transformations without complete information. We should have as a goal that an identity transformation whould be possible. By Identity, I only mean to require equivalence up to "insignificant" whitespace normalization. I.E. We should be able to produce an instance lacking no information that the standard does not explicitly label insiginificant. We should have a way for a builder to signal its controller that information such as entity boundaries, and maybe some DTD info, is _insignificant for that execution_. I suppose a more-general thing would be to register the events that you are interested in -- and others would simply be silently ignored. This could be handled by having empty default implementations, so it may not require special handling. As to languages, I am sympathetic to the IDL argument, but I have a few practical notes: It seems that already more people know Java than IDL. IDL information seems to cost money. As to principles for making a decision: * Platform independence seems a hard requirement: in favor of both Java and IDL, against OLE/Active-X/other proprietary gunk. * Language independence is good (but not quite a hard requirement): This is a point in favor of IDL, but I think that many will be learning IDL by comparing the Official Standard against the Java binding produced by the nifty tools... In other words, if the IDL folks can write the syntax up and post the processed Java bindings here, we should do IDL, otherwise java is good enough, and the inverse binding -- though inelegant -- can be created later. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ 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 dgd at cs.bu.edu Fri Feb 28 17:23:07 1997 From: dgd at cs.bu.edu (David Durand) Date: Mon Jun 7 16:57:25 2004 Subject: XML API specification In-Reply-To: <4049@ursus.demon.co.uk> Message-ID: At 2:54 PM +0000 2/27/97, Peter Murray-Rust wrote: >In message <199702271419.JAA24115@nathaniel.ebt> gtn@ebt.com (Gavin Nicol) >writes: >> I think that for the *parser*, we should define an event-handling >> interface, as it is much simpler to build certain applications >> that way, and because you can build a tree from a stream of >> events if you need to. > >In CoST Joe English supported both eventStreams and trees (I'm sure Joe will >have some wisdom on this one). I started off using the event mechanism >and switched to a tree-based one but I suspect that this was the nature of >the >application. An addition to my previous advocacy of event-based processing. It may be worth defining/supplying classes for a standard tree representation, and a standard builder class that can create those -- so we define the stream, but provide a ready-cooked abstract sytnax tree representation for those who want it. Personally I see groves as semantically equivalent to the API, but as so obscure that they should not be a priority for our explanations of the API. We probably need to refer to groves, for those who already know about them. However, very few of our target audience of implementors will already know about groves, nor will they care, if they can understand the API without them. I see XML-groves and XML-API as parallel and needing to be in synch. I don't see either as having to depend on the other, though, and frankly, given the relative penetration of groves and Java into the "global developer consciousness", I don't see groves as that high a priority. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ 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 Feb 28 18:07:03 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:25 2004 Subject: XML API specification References: Message-ID: <33171BA7.1D89@hiwaay.net> David Durand wrote: > > I see XML-groves and XML-API as parallel and needing to be in synch. I > don't see either as having to depend on the other, though, and frankly, > given the relative penetration of groves and Java into the "global > developer consciousness", I don't see groves as that high a priority. If relative penetration is important, spec it in COBOL or C. This kind of argument went on in VRML and was wisely rejected. The commitment to a CORBA IDL is a commitment to a syntax for the spec and not a lot else. The commitment to JAVA for implementation is only a commitment to a slow language. The commitment to it in the spec is a commitment to SUN. That should never be a part of the spec. It should be something the spec can be bound to. It will anyway, but XML's future is in many languages and platforms. Groves, as Richard Light pointed out, at the very least gives us authoritative names for things. As Joe English and Gavin Nicol have pointed out, the bindings here are trivial. If that is the case, then groves-IDL-Whatever(Java, C++, etc) is the right thing to do. Let all implementors decide what they want to penetrate and with which device. 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 dgd at cs.bu.edu Fri Feb 28 19:11:42 1997 From: dgd at cs.bu.edu (David Durand) Date: Mon Jun 7 16:57:25 2004 Subject: XML API specification In-Reply-To: <33171BA7.1D89@hiwaay.net> References: Message-ID: At 11:53 AM -0600 2/28/97, Len Bullard wrote: >David Durand wrote: >> >> I see XML-groves and XML-API as parallel and needing to be in synch. I >> don't see either as having to depend on the other, though, and frankly, >> given the relative penetration of groves and Java into the "global >> developer consciousness", I don't see groves as that high a priority. > >If relative penetration is important, spec it in COBOL or C. > >This kind of argument went on in VRML and was wisely rejected. >The commitment to a CORBA IDL is a commitment to a syntax for the spec >and not a lot else. If Gavin's information is correct (and I assume it to be so) this is false. IDL means that we get language-specific bindings for several languages including Java and C++, simply by applyiing an automated tool. So there are concrete technical advantages to using IDL, though we must apply those tools for the programmers, so that I don't have to find an IDL tool to use XML with my Java codebase. > The commitment to JAVA for implementation >is only a commitment to a slow language. Again, verifiably false. There is no reason that native-code Java compilers cannot exist. Languages aren't slow -- implementations are. Something you learn sometime in your first 2 years of college... > The commitment to it >in the spec is a commitment to SUN. That should never be >a part of the spec. It should be something the spec can >be bound to. It will anyway, but XML's future is in many >languages and platforms. An argument for IDL, against Java (and one that I made, by the way, so that we appear to be in raging agreement). >Groves, as Richard Light pointed out, at the very least >gives us authoritative names for things. Which is good _if_ the names are meaningful to the audience, and is bad if they make things harder for people. I agree that _gratuitous incompatibility_ with grove terminology would be bad, but I think we should evaluate it on its inherent merits, and give it an epsilon of advantage (for being a standard) over any equivalent non-standard terminology. On the other hand if it seems to create confusion we should deep-six it without hesitation. > As Joe English >and Gavin Nicol have pointed out, the bindings here are >trivial. Great, then in the worst case, we need (at most) a "grove dictionary" if groves turn out to be confusing. Naturally, if they are not confusing we should use them. > If that is the case, then groves-IDL-Whatever(Java, C++, etc) >is the right thing to do. Well, something certainly is the right thing to do (we hope). Care to be more precise? I now incline to IDL, with compiled-into-Java and compiled-into-C++ versions for IDL ignorati like myself... -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ 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 Feb 28 20:06:07 1997 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 16:57:25 2004 Subject: XML API specification References: Message-ID: <331737EA.3A4E@hiwaay.net> David Durand wrote: > > At 11:53 AM -0600 2/28/97, Len Bullard wrote: > >David Durand wrote: > >This kind of argument went on in VRML and was wisely rejected. > >The commitment to a CORBA IDL is a commitment to a syntax for the spec > >and not a lot else. > > If Gavin's information is correct (and I assume it to be so) this is false. What is in the spec and what can be done with the spec are not the same issue. Use of the tool is something one can do with a spec. > IDL means that we get language-specific bindings for several languages > including Java and C++, simply by applyiing an automated tool. So there are > concrete technical advantages to using IDL, though we must apply those > tools for the programmers, so that I don't have to find an IDL tool to use > XML with my Java codebase. And if we commit to Java we get only one. An IDL plus an automated tool gets us multiple bindings. Sounds good to me. An IDL minus an automated tool gets us a syntax for interface definitions. It is also one which is a serious contender for world wide standardization of distributed objects. OMG has its supporters and distributed objects are the way things are going for real. > > The commitment to JAVA for implementation > >is only a commitment to a slow language. > > Again, verifiably false. There is no reason that native-code Java compilers > cannot exist. Languages aren't slow -- implementations are. Something you > learn sometime in your first 2 years of college... Guns don't kill; people kill. Something one learns from a bumper sticker. So, I avoid people and love my guns. ;-) > > The commitment to it > >in the spec is a commitment to SUN. That should never be > >a part of the spec. It should be something the spec can > >be bound to. It will anyway, but XML's future is in many > >languages and platforms. > > An argument for IDL, against Java (and one that I made, by the way, so that > we appear to be in raging agreement). Yes indeed. Now, on the other hand, if we need a sample implementation (not a reference yet), then the Java language is IMO, the best contender given the ubiquity of native support in the dominant frameworks. > >Groves, as Richard Light pointed out, at the very least > >gives us authoritative names for things. > > Which is good _if_ the names are meaningful to the audience, and is bad if > they make things harder for people. I agree that _gratuitous > incompatibility_ with grove terminology would be bad, but I think we should > evaluate it on its inherent merits, and give it an epsilon of advantage > (for being a standard) over any equivalent non-standard terminology. On the > other hand if it seems to create confusion we should deep-six it without > hesitation. Yes. I think Richard is trying to get some of that out for folks to look at. If it is a wad of badly applied terminology, then deepsix it. Doesn't this make life a bit hard for the DSSSL folks? > > As Joe English > >and Gavin Nicol have pointed out, the bindings here are > >trivial. > > Great, then in the worst case, we need (at most) a "grove dictionary" if > groves turn out to be confusing. Naturally, if they are not confusing we > should use them. Right. The question is, for what, and the answer may be, for the authoritative names of SGML properties and only where the properties used are those used in XML. IOW, not gratuitous use, but specific and normative use. This alignment could help anyone who is obligated to precisely define the relationship of their XML development to SGML development, and vice versa. > > If that is the case, then groves-IDL-Whatever(Java, C++, etc) > >is the right thing to do. > > Well, something certainly is the right thing to do (we hope). Care to be > more precise? That was as precise as needed. If a grove plan defines the SGML Properties, and then, the XML properties, use the grove plan to define the IDL. Use the IDL to compile to -> Whatever. > I now incline to IDL, with compiled-into-Java and compiled-into-C++ > versions for IDL ignorati like myself... I can live with that. The original question was whether the grove and grove plan concepts would be useful to defining the API given their use in DSSSL, HyTime, and SGML. XML is a proper subset of SGML, so on the surface, it appears that the SGML properties can be subset to express XML properties. Because at least some part of this group has invested resources to understanding them, and perhaps others should look, it is an issue that can come to consensus pretty quickly. The IDL is the more necessary piece because it leads directly to implementation. While implementation is the focus, because I assume and API spec leads to a document kept somewhere, choosing the definitional approach is the most vital decision to be made right now. len 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 fcha at Berger-Levrault.fr Fri Feb 28 22:36:01 1997 From: fcha at Berger-Levrault.fr (F. Chahuneau - General Manager) Date: Mon Jun 7 16:57:25 2004 Subject: Trees versus event streams Message-ID: <199702282234.XAA00682@cygne.ais.berger-levrault.fr> [Peter Murray-Rust (Peter@ursus.demon.co.uk), Thu, 27 Feb 1997] > My current problem may highlight this. A CML document is highly > tree-structured and contains no mixed content, so that eventStreams don= 't > contribute much. BUT it also includes chunks of HTML where a tree > structure is quite inappropriate. If I take a Lark-based approach (or m= y > own parser) the HTML gets rendered into a tree. I am now hacking this > back into an event stream to render the hypertext. Not only does it > take more effort, but I'm sure that holding HTML as a tree has a > memory hit. Ideally when I'm parsing CML, and come to the > tag (sic) which contains , I'd like to tell the parser > 'stop parsing as a tree and just hold a hypertext string until = From fcha at Berger-Levrault.fr Fri Feb 28 23:22:20 1997 From: fcha at Berger-Levrault.fr (F. Chahuneau - General Manager) Date: Mon Jun 7 16:57:25 2004 Subject: Trees versus event streams Message-ID: <199702282321.AAA03386@cygne.ais.berger-levrault.fr> [Peter Murray-Rust (Peter@ursus.demon.co.uk), Thu, 27 Feb 1997] > My current problem may highlight this. A CML document is highly > tree-structured and contains no mixed content, so that eventStreams don= 't > contribute much. BUT it also includes chunks of HTML where a tree > structure is quite inappropriate. If I take a Lark-based approach (or m= y > own parser) the HTML gets rendered into a tree. I am now hacking this > back into an event stream to render the hypertext. Not only does it > take more effort, but I'm sure that holding HTML as a tree has a > memory hit. Ideally when I'm parsing CML, and come to the > tag (sic) which contains , I'd like to tell the parser > 'stop parsing as a tree and just hold a hypertext string until =