From sun at ceresrc.com Fri Jan 1 04:59:05 1999 From: sun at ceresrc.com (Sun Koh) Date: Mon Jun 7 17:07:11 2004 Subject: XML and Java2 Tutorial Message-ID: <001801be3543$9bee9de0$7d4ac797@sun> I found this message on a newsgroup. It is very good. Check it out yourself. HAPPY NEW YEAR !!! >Dear fellow Java and XML Developers: > >I could not find a decent resource on the web which showed me >how to use XML and Java to build web and Internet based >applications. So I decided to write one myself :). > >Check it out at: > http://developerlife.com > http://developerlife.com/xmljavatutorial1 > >It shows you how to use: > 1) the IBM parser (IBM XML Parser for Java) > 2) the Sun parser (Sun ProjectX EA2) > 3) the DOM (org.w3c.dom.*) interfaces > 4) JFC/Swing with XML > 5) Servlets with XML > 6) and much, much more! > >Enjoy! >Have a Happy New Year!!! >Nazmul Idris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gcsfred at magma.ca Fri Jan 1 18:24:59 1999 From: gcsfred at magma.ca (Gustavo Frederico) Date: Mon Jun 7 17:07:11 2004 Subject: ANN: ChordML - simple music DTD Message-ID: <3.0.5.32.19990101133038.00942ae0@magma.ca> I invite the XML community to try and look at ChordML. The purpose of it is to define a way for people to exchange simple music with simple lyrics and chords. I posted it DTD and a sample xml file at http://www.cifranet.org/xml/ChordML.html. There is a brief description of the project at this page too. Comments and suggestions are more than welcomed. I became 'hands-on' xml only recently, although I felt in love with it since CDF was released. ><><><><><><><><><>< Gustavo Frederico gcsfred@magma.ca xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From moor0361 at tc.umn.edu Sat Jan 2 02:14:20 1999 From: moor0361 at tc.umn.edu (Kimberly S Moorman) Date: Mon Jun 7 17:07:11 2004 Subject: Call for Articles - Crossroads Magazine Message-ID: Call For Articles Crossroads, the Association for Computing Machinery Student Magazine Markup Languages (Winter 1999) DUE DATE: April 15, 1999 SUBMISSION ADDRESS: xrds-submit@acm.org INFORMATION: crossroads@acm.org http://www.acm.org/crossroads/ SPECIAL NOTE: If you are interested in being a Student Guest Editor for this issue, please contact us at crossroads@acm.org or fill out the online application for student guest editors. The Crossroads editorial staff invites authors to submit articles dealing with topics drawn from several areas pertaining to Markup Languages. The following partial list of topics is provided to give prospective authors ideas for articles and is by no means exhaustive; other relevant topics will be considered. History, future, and comparisons of markup languages like -Hypertext Markup Language (HTML), -Standard Generalized Markup Language (SGML), -Extensible Markup Language (XML), -Java Speech Markup Language (JSML), -Synchronized Multimedia Integration Language (SMIL), -Handheld Device Markup Language (HDML), -etc. Articles should include a basic description of the kinds of problems being worked on, the state of the art of research, the state of the art of commercial applications, open problems, or future research/commercial development trends. Interviews with researchers; reviews of related books, software, videos, or conferences; and opinion columns on related issues are also welcome. We especially encourage both undergraduate and graduate students to submit articles. However, articles written or coauthored by professionals will also be considered. Crossroads articles should be written for a broad audience. They should be easily understandable by someone who has had only the most basic computer science instruction, and yet still be interesting to the advanced computer enthusiast. Articles longer than 6000 words will generally not be considered for publication. Feature articles should be between 1500 and 6000 words; reviews should be between 800 and 2000 words; and opinion columns should be between 800 and 3000 words. Articles should be written in a magazine style rather than a research paper style. In consideration of our diverse readership, authors should try to use language that is inclusive of people regardless of their gender, race, religion, nationality, or field of study. Additional writing guidelines and submission information are available online at the Crossroads web site http://www.acm.org/crossroads/. Crossroads is published both online and in print. We have a print circulation of about 13,000. All back issues are available for free on our website. Authors that have an article printed in Crossroads can receive complementary copies of the issue they were published in. All submissions should be formatted in HTML or plain text format and emailed to xrds-submit@acm.org. Please include your submission in the body of your message: DO NOT include it as an attachment. Submissions are due April 15, 1999. They will be reviewed shortly thereafter and authors of accepted submissions will be notified within two to three weeks of the deadline. Prospective authors are invited to send email to the editors of Crossroads crossroads@acm.org indicating their intention to submit an article. In this way we can keep everyone informed of any changes in deadlines or formats and to make sure we have a good variety of articles. General questions should also be sent to the Crossroads editors. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sat Jan 2 03:23:14 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:07:11 2004 Subject: XP 0.5 available Message-ID: <368D8ED8.946B7A27@jclark.com> A new version of XP, my XML parser in Java, is now available. See http://www.jclark.com/xml/xp/index.html for more information. This release has few changes: some bug fixes, and better reporting of ID attributes (the type of ID attributes is now reported in SAX). James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Jan 2 22:09:22 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:07:11 2004 Subject: Why XML Over the Relational Model? References: <4.0.1.19981231154402.00ead460@> Message-ID: <368E987B.63CA@hiwaay.net> Nazmul Idris wrote: > > Dear fellow Java and XML Developers: > > I could not find a decent resource on the web which showed me > how to use XML and Java to build web and Internet based > applications. So I decided to write one myself :). > > Check it out at: > http://developerlife.com > http://developerlife.com/xmljavatutorial1 Sincere compliments and thanks to you, Nazmul Idris. That is a very fine tutorial and an excellent contribution. To XML developers: The tutorial by example does raise the question often asked and seldom answered by the XML community: precisely why should developers choose this approach (XML and Java objects) over a commercial relational database given the ease by which this example can be done using standard SQL, script, and an HTML browser? As this same question occupied many of the venerable CALS developers for some period, have any new answers emerged for XML? The only one I can think of is that we didn't have the DOM. Len Bullard Intergraph Public Safety xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dan at holle.demon.co.uk Sun Jan 3 09:58:09 1999 From: dan at holle.demon.co.uk (Dan Holle) Date: Mon Jun 7 17:07:11 2004 Subject: Why XML Over the Relational Model? Message-ID: <000801be36ff$06c840a0$0400a8c0@dan.perrysfield> IMHO, Occam's Razor between XML and DBMS revolves around data complexity and multiple updaters. If the XML phonebook had every US phone number, you wouldn't want to be on the receiving end of a servlet like this. If the query spans multiple XML files, or does complex operations to bring together related XML elements, you probably wouldn't want to write your own optimizer and join engine for the servlet. Likewise, if you have multiple people maintaining the phone book, you probably want a DBMS approach... unless you're keen to re-invent all the concurrency and access rights capabilities in a DBMS. Even if you have a DBMS on the server side, XML might be the best way of passing results and/or updates between the client and the server. -----Original Message----- From: len bullard To: xlxp-dev@fsc.fujitsu.com Cc: xml-dev@ic.ac.uk Date: 02 January 1999 22:31 Subject: Why XML Over the Relational Model? >Nazmul Idris wrote: >> >> Dear fellow Java and XML Developers: >> >> I could not find a decent resource on the web which showed me >> how to use XML and Java to build web and Internet based >> applications. So I decided to write one myself :). >> >> Check it out at: >> http://developerlife.com >> http://developerlife.com/xmljavatutorial1 > >Sincere compliments and thanks to you, Nazmul Idris. That is a very >fine tutorial and an excellent contribution. > >To XML developers: > >The tutorial by example does raise the question often asked >and seldom answered by the XML community: precisely >why should developers choose this approach (XML >and Java objects) over a commercial relational >database given the ease by which this example can be done >using standard SQL, script, and an >HTML browser? As this same question occupied >many of the venerable CALS developers for some period, >have any new answers emerged for XML? > >The only one I can think of is that we didn't have >the DOM. > >Len Bullard >Intergraph Public Safety > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sun Jan 3 15:38:21 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:11 2004 Subject: Why XML Over the Relational Model? In-Reply-To: <000801be36ff$06c840a0$0400a8c0@dan.perrysfield> References: <000801be36ff$06c840a0$0400a8c0@dan.perrysfield> Message-ID: <13967.35848.195303.78625@localhost.localdomain> Dan Holle writes: > IMHO, Occam's Razor between XML and DBMS revolves around data > complexity and multiple updaters. > > If the XML phonebook had every US phone number, you wouldn't want > to be on the receiving end of a servlet like this. [etc.] Actually, XML would be a wonderful way to transfer every U.S. phone number from one database to another, but querying an XML document (or a representation of it in a repository) would not be an efficient way to look up a specific phone number, and transferring the whole phonebook in XML to a thin client would be plain silly. In brief, then, XML is a very sophisticated exchange (import/export) format, and RDBMs are very sophisticated storage and retrieval tools. Different species, but they can be taught to play together nicely. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Jan 3 16:51:55 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:11 2004 Subject: Why XML Over the Relational Model? In-Reply-To: <368E987B.63CA@hiwaay.net> References: <4.0.1.19981231154402.00ead460@> Message-ID: <199901031651.LAA06833@hesketh.net> At 04:06 PM 1/2/99 -0600, len bullard wrote: >The tutorial by example does raise the question often asked >and seldom answered by the XML community: precisely >why should developers choose this approach (XML >and Java objects) over a commercial relational >database given the ease by which this example can be done >using standard SQL, script, and an >HTML browser? As this same question occupied >many of the venerable CALS developers for some period, >have any new answers emerged for XML? > >The only one I can think of is that we didn't have >the DOM. The primary answer I give this question is flexibility, though there is a significant cost in efficiency. XML documents can easily hold structures that make relational databases choke, though finding data in an XML document describing a table will be a lot slower than finding that data when it's stored in a relational database. If you're storing data that doesn't live happily in columns, rows, and tables, and especially if you need access to it across platforms and languages, XML is a lot more capable, though not as quick. XLink also has promise in this regard, offering far more flexible and descriptive connections between data sources (aka documents) than the relatively (and quite efficiently) austere connections between tables in an RDBMS. How this works out in the long run will depend on how that spec and XPointer come out, but there is promise as well. (The discussions surrounding XML query languages may have more direct impact, though.) XML isn't going to replace RDBMS systems, though it may relieve them of some burdens for which they weren't particularly well suited in the first place. As David Megginson puts it: >Different species, but they can be taught to play together nicely. Sounds good to me! Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arabbit at earthlink.net Sun Jan 3 18:32:27 1999 From: arabbit at earthlink.net (Paul Butkiewicz) Date: Mon Jun 7 17:07:11 2004 Subject: Why XML Over the Relational Model? In-Reply-To: <199901031651.LAA06833@hesketh.net> Message-ID: <000001be3747$9393df60$ac39bfa8@arabbit> >The tutorial by example does raise the question often asked >and seldom answered by the XML community: precisely >why should developers choose this approach (XML >and Java objects) over a commercial relational >database given the ease by which this example can be done >using standard SQL, script, and an >HTML browser? As this same question occupied >many of the venerable CALS developers for some period, >have any new answers emerged for XML? > >The only one I can think of is that we didn't have >the DOM. One important point is the scale of the implementation and the intended use. If you were developing a system for a company that was entirely Windows/Microsoft based, you probably wouldn't bother with XML, HTML, java or any of that --- the simplest solution might just involve Visual Basic and ODBC calls to a database or DCOM calls to an application server. (Unless you're trying to retain programmers by using "cool technology" or have a CEO that insists you build it around a corporate intranet because that's what he reads about in the newspaper :) And you would have all of your documentation in hand and people who needed it could get it. If you were trying to do this on a (big) enterprise-wide level or toward a global audience, the sort of arena where this web thing comes in handy, trying that approach might involve trying to make ERwin models available globally, publishing application server interfaces, somehow publishing what stored procedures are available, and possibly letting folks know what database or variant of SQL is being used. Or you could just publish a DTD and a bunch of XML and those clever folks in the Phoenix office or in another organization that wants to access your data would probably be able to figure it out. >The primary answer I give this question is flexibility, though there is a >significant cost in efficiency. XML documents can easily hold structures >that make relational databases choke. . . . I would love to see an example of this. As for the phone book example, perhaps XML works much better (even well) in making this data avilable if all of the data doesn't exist in one document. I know that if I'm personally searching through a book for something, I'll usually follow a URI (my almanac calls it a "General Index". There's also a "Quick Thumb Index") to an approximate location and start iterating from there, rather that just starting from the beginning and approaching the whole mass of the data as a single document (although in the almanac case this often makes for interesting reading, I'll usually get hungry or sleepy at some point and never find the data I was looking for :). Happy New Year, Paul xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dan at holle.demon.co.uk Sun Jan 3 19:28:31 1999 From: dan at holle.demon.co.uk (Dan Holle) Date: Mon Jun 7 17:07:12 2004 Subject: Why XML Over the Relational Model? Message-ID: <004901be374e$b124ac60$0400a8c0@dan.perrysfield> >>The primary answer I give this question is flexibility, though there is a >>significant cost in efficiency. XML documents can easily hold structures >>that make relational databases choke. . . . > >I would love to see an example of this. > Me too, Paul. Let's not think of XML as a representation for a complex multi-table multi-user shared database. DOM, as a database, is like a RAM-resident single user IMS/DB. (If you must barf, don't barf on your keyboard.) There is a reason why we fled from hierarchical linked databases to relational. Yes, there are databases you can do in XML that you can't do in relational. Just as there are things you can do in assembler language you can't do in Java. But if you are trying to do something useful with large, complex data, stick with relational. XML seems a good match for small but flexible structures on web-connected clients. David's comments, saying XML is for information exchange and relational is for storage/query, rings true... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Mon Jan 4 02:49:07 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:07:12 2004 Subject: Why XML Over the Relational Model? Message-ID: <006501be378b$a393b220$1aacdccf@ix.netcom.com> >The tutorial by example does raise the question often asked >and seldom answered by the XML community: precisely >why should developers choose this approach (XML >and Java objects) over a commercial relational >database >The only one I can think of is that we didn't have >the DOM. > I think this is exactly the reason why. Now with the DOM it is very easy to take an XML 'data source' and to run sorts, filters, finds and scrolls on it, just like a SQL data base. And for small data bases of less than a1000 records it is every bit as quick. I have a tutorial in the making which shows how to do this on the server side with ASP, and on the client side with IE5. If any one would like to see it please let me know. I would especially welcom criticism before I publish it. Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com ----- Original Message ----- From: len bullard To: Cc: Sent: Saturday, January 02, 1999 5:06 PM Subject: Why XML Over the Relational Model? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Mon Jan 4 09:02:14 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:12 2004 Subject: Why XML Over the Relational Model? Message-ID: <5F052F2A01FBD11184F00008C7A4A800011369A6@eukbant101.ericsson.se> The reason I tend to give for this is as follows: - Complex Data Structures. The data structure in your XML can more accurately represent so called "real world" structures. This is the same benefit you get from an OO DB over a relational database - Cost. This can be important for certain types of applications, e.g. open source/free applications. Although there are free relational databases (Postgresql, GNU Sql, and to some extent MySql), it would generally be overkill to distribute the whole postgresql package with your app. XML parser implementations are all (?) currently free (for certain values of "free"). - Future. It's currently not /really/ viable, but we hope that in the future we can display fragments of our database (or the whole thing) using XSL, either on the web or in print. - Lightweight. Most XML parsers are quite lightweight, whereas most DBMS's are not. Often this is outweighted by the indexing and searching speeds of DBMS's, but that's not always a priority. Anyway, as with all new tech, use the right tool for the job. Or use a combined approach. For example, I'm working on a timesheet application now that stores timesheets as XML, employee information in a relational database, and runs batch processes to import data from the XML into the database for reporting purposes. This gives us some advantages listed above, and makes for an interesting project! Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ R+++ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RalfW at www.basicworld.com Mon Jan 4 09:21:43 1999 From: RalfW at www.basicworld.com (Ralf Westphal / BasicPro) Date: Mon Jun 7 17:07:12 2004 Subject: Why XML Over the Relational Model? In-Reply-To: <004901be374e$b124ac60$0400a8c0@dan.perrysfield> Message-ID: <000801be37c3$4fe17a80$0300a8c0@alien> Very interesting topic! But how a about the following twist: We keep our relational databases for speed etc. and make them accessible thru the DOM. That way they?d appear as if they were huge XML files. It would be a win-win solution: -We?d retain all advantages of a dedicated API and a dedicated database file format, e.g. indexes. -Plus we?d gain a standard API/interface to the data. Now a user wouldn?t have to care whether data she needs to query resides in a true XML file or in a RDBMS. All she needs is a XQL processor (take XQL just as an example for a XML query language) and a list of filenames. She then would feed each filename (and her query) to the XQL processor, and leave it to the XQL processor to figure out how to get to the data. The XQL processor, for example, would look at the filename extension and instantiate an appropriate XML parser or DOM object. E.g. for files with the extension XML it would instantiate a regular XML parser (like MSXML from Microsoft), pass it the XML filename and then execute the query using the DOM. For MDB files on the other hand (MS Access database files) the XQL processor would not instantiate a XML parser (wouldn?t make much sense ;-), but instead a "DOM-component". A DOM-component implements XML DOM interfaces, so it looks just like a XML parser doing the same. So from the outside, one cannot discern if behind a DOM-component is a XML file or something else. Since the DOM-component for MDB files behaves just like a true XML DOM (no, even better, it _is_ a true XML DOM), the XQL processor again can execute the query itself. Benefits: -all files and data structures (e.g. file system, list of running processes) could be made accessible thru a single API: the DOM -a single query language could be used to query (manipulate?) any data structure -even transparent querying across data structures would be possible (e.g. a query could start in a DOM for the file system but could easily continue _into_ files pointed to). This kind of querying could be called "universal querying". Possible Objections: -Why don?t we just convert all files to XML? We wouldn?t need DOM-components. Current database file formats are optimized for the purpose. XML is a good format for read-mostly/read-only purposes (e.g. in data exchange scenarios); but I don?t see megabyte databases stored in XML. The POET ODBMS for example converts XML files to its proprietary ODBMS file format before publishing it thru a DOM. Where XML is a file format ideal for many purposes, but not for all, the XML DOM is a truely universal interface to any data, be it the file system or a text file. It?s just another kind of API. -But databases as no XML files so how can we see the thru a DOM? The existence of a DOM does not depend on a XML file. A DOM is just a hierarchy of objects. It?s easy to instantiate a hierarchy of DOM-node objects for a hierarchy of directories and files. A DOM-node for a directory, for example, could return "folder" as its tagName property; and a DOM-node for a file could have a attribute node called "dateCreated". We can see clearly a DOM-component does not need an external XML DTD or XML schema. Even the concepts of wellformedness and validity loose their values since their is not data to be parsed. Or the other way round: the data a DOM-component is always wellformed and valid (because the DOM-component sits on top of a specific API which ensures the correctness so to speak). The hierarchy of node objects in a DOM-component thus does not depend on a real DTD or real schema, but is predefined by "virtual" schema. The designer of a DOM-component simply maps a given data structure (e.g. a hierarchy of directories and files) to a hierarchy of DOM-node objects with certain tag names and attributes and values. -The same XQL query wouldn?t work on different data structures? True. But the same holds for queries on RDBMS once they have different table structures. If you want to query a couple of address databases you?d probably need to formulate several SQL queries, since ZIP information in one database is stored in a column called "ZIP" and in another it?s called "PostalCode". On the other hand universal querying would still work for files of the same type, e.g. all MDB files. If you assume a MDB file is represented by a hierarchy of nodes with tag names tables/table name=.../row/col name=... you could ask questions like "return all rows in all tables containing a column named either ?ZIP? or ?PostalCode? which contains the value ?20099?". Fed to a XQL processor with a couple of MDB filesnames you?d need only this one query to retrieve all addresses with ZIP ?20099?. -Universal querying could lead to bad performance! True. If you?d start a query on a file system DOM-component and let it recurse into files the performance could go down easily. But then: why not let the user decide. Maybe it?s more convenient for him to wait than not be able to get at the requested information at all. At leat he has the possibility to issue a very general query and not care about file types and file boundaries. DOM-components and XQL processors are a very powerful concept. Also, XQL processors and DOM-components could be made more "intelligent". For example, before querying a DOM the XQL processor could ask, "do you contain a hierarchy of row/col nodes at all?" If not, the XQL processor could immediately skip the whole data structure and continue with the next one. -But XQL doesn?t allow things like spanning of files etc. True, XQL can?t do that - yet. But why not think of extending XQL? Today folder/file/@name results in a list of attribute nodes. Today folder/file/@name/tables/table does not work. But tomorrow folder/file/@name/tables/table could mean, "use the values of the name-attributes as file names, for each file name instantiate the appropriate DOM-component, and continue the query with the rest of the query string into the DOM-component". Other ways of marking where spanning XML structures/DOMs could be thought of. Hope I didn?t bore you guys too much ;-) But wouldn?t a world with universal querying capabilities great? Cheers, Ralf -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Dan Holle Sent: Sonntag, 3. Januar 1999 20:25 To: Paul Butkiewicz; xml-dev@ic.ac.uk; xlxp-dev@fsc.fujitsu.com Subject: Re: Why XML Over the Relational Model? >>The primary answer I give this question is flexibility, though there is a >>significant cost in efficiency. XML documents can easily hold structures >>that make relational databases choke. . . . > >I would love to see an example of this. > Me too, Paul. Let's not think of XML as a representation for a complex multi-table multi-user shared database. DOM, as a database, is like a RAM-resident single user IMS/DB. (If you must barf, don't barf on your keyboard.) There is a reason why we fled from hierarchical linked databases to relational. Yes, there are databases you can do in XML that you can't do in relational. Just as there are things you can do in assembler language you can't do in Java. But if you are trying to do something useful with large, complex data, stick with relational. XML seems a good match for small but flexible structures on web-connected clients. David's comments, saying XML is for information exchange and relational is for storage/query, rings true... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jhb at software-ag.de Mon Jan 4 13:39:13 1999 From: jhb at software-ag.de (Juliane Harbarth) Date: Mon Jun 7 17:07:12 2004 Subject: sub-documents Message-ID: <007901be37ef$edbf4800$4ba2bd9d@pcjhb.software-ag.de> I admit I am rather late in answering this message, i.e. it has been posted 11.12.1998. But as far as I understood the archive no one else has answered it and so I'll give it a try. If there is a structure A and an other structure B that may occur as a part of A as well as on its own, one can model A including it's part B in one DTD, i.e. "ainclb.dtd". An instance of A that includes B looks like : ... ... ... An instance of B not surrounded by A looks like : ... Juliane Harbarth Technical Consultant Software AG Germany mailto:jhb@software-ag.de Tel +49 (0)6151 92 1147 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Mon Jan 4 14:51:06 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:07:12 2004 Subject: Why XML Over the Relational Model? In-Reply-To: <13967.35848.195303.78625@localhost.localdomain> References: <000801be36ff$06c840a0$0400a8c0@dan.perrysfield> <000801be36ff$06c840a0$0400a8c0@dan.perrysfield> Message-ID: <3.0.5.32.19990104065134.00aeb310@scripting.com> >>In brief, then, XML is a very sophisticated exchange (import/export) format, and RDBMs are very sophisticated storage and retrieval tools. Different species, but they can be taught to play together nicely. Excellent! That's exactly right, and I'd add.. XML opens the door for other kinds of storage systems that are more suited to the hierarchies that can be represented in XML but are awkward in the relational model. Dave ----------------------------- http://www.scriptingnews.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Jan 4 14:55:15 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:12 2004 Subject: Why XML Over the Relational Model? In-Reply-To: <004901be374e$b124ac60$0400a8c0@dan.perrysfield> Message-ID: <199901041454.JAA17903@hesketh.net> [I've dropped the cross-post to xlxp-dev because this is a pretty straight XML issue.] At 07:24 PM 1/3/99 +0000, Dan Holle wrote: >>>The primary answer I give this question is flexibility, though there is a >>>significant cost in efficiency. XML documents can easily hold structures >>>that make relational databases choke. . . . >> >>I would love to see an example of this. > >Me too, Paul. The simplest case is when your data store is keeping a bunch of documents for you, be they memos, lab notebooks, or documentation. While you can store documents in RDBMS systems, it... well, it kind of sucks, even on a good day. If you happen to be lucky enough to be dealing with the portion of data that all fits neatly into relational structures, without needed to build messy scaffolding around it, XML probably isn't that exciting. For those of us who would like to perform complex operations on documents and other information that doesn't fit relational systems neatly, XML is revelation. >Let's not think of XML as a representation for a complex multi-table >multi-user shared database. DOM, as a database, is like a RAM-resident >single user IMS/DB. (If you must barf, don't barf on your keyboard.) There >is a reason why we fled from hierarchical linked databases to relational. Plenty of reasons. But there is also lots of data - I'll retreat to documents if I must - that fits a lot better into a managed XML environment than a relational system. And there's plenty of development on the object store front that makes this a lot easier and more efficient than it has been. It makes relational purists irritable, but the rest of us can find the tools we need to do our jobs right. >Yes, there are databases you can do in XML that you can't do in relational. >Just as there are things you can do in assembler language you can't do in >Java. But if you are trying to do something useful with large, complex >data, stick with relational. As noted above, it depends on the kind of large, complex data you've got. If it's cash register records for stores across the country, a relational system is ideal. If it's lab notebooks for a major pharmaceutical company, stored alongside company memos, budgets, and other supporting documents, you probably want something else. >XML seems a good match for small but flexible structures on web-connected >clients. David's comments, saying XML is for information exchange and >relational is for storage/query, rings true... There are a lot more factors than just scale involved, and I suspect you're going to find a lot more hierarchical storage/query/processing systems getting built now that there's a decent standard (XML) to use as a foundation. Flexibility matters, and I think it will matter even more if we have any hope of putting the 80% of business and other information that lives outside of relational systems into any kind of reasonable computerized order. If the data is a good fit for a relational system, use an RDBMS. If not, look for something else, and look closely at XML. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jonathan.Irving at UK.Sun.COM Mon Jan 4 16:04:57 1999 From: Jonathan.Irving at UK.Sun.COM (Jonathan Irving - Sun UK) Date: Mon Jun 7 17:07:12 2004 Subject: Why XML Over the Relational Model? (fwd) Message-ID: This got bounced the first time I think - apologies if I'm duplicating. cheers Jonathan ---------- Forwarded message ---------- Date: Mon, 4 Jan 1999 10:00:29 +0000 (GMT) From: Jonathan Irving - Sun UK To: Ralf Westphal / BasicPro Cc: 'Dan Holle' , 'Paul Butkiewicz' , xml-dev@ic.ac.uk, xlxp-dev@fsc.fujitsu.com, simonstl@simonstl.com, bckman@ix.netcom.com Subject: RE: Why XML Over the Relational Model? Taking this point, Oracle 8i intends to support streaming XML resulting from queries which contain where clause XML-specific extensions. I take Matthew's point about cost and overhead (8i is unlikely to be lightweight by any definition) but it looks like a resolution to the main stumbling blocks here. 8i will allow mapping of some or all substructures within document definitions onto relational tables; the mapping is done seamlessly (ie when you "put" a document into the database, you don't need to do complex, mapping-aware inserts, and when you query a document, the results returned conform to the appropriate dtd). Check out the "technical whitepaper" (more appropriate would be "marketing document") at http://www.oracle.com/xml/documents/xml_twp/ In all, I agree with all the arguments about attempting to query large data sets represented in XML being a bit silly, given the optimisations which have already been done in most RDBMSs, but this seems to bridge the gap somewhat. I'm certainly looking forward to playing with it. Incidentally, although there are SQL extensions planned to query 8i in an XML way, there's nothing preventing further use of XQL or XML-QL or any analog on the resulting stream. cheers Jonathan On Mon, 4 Jan 1999, Ralf Westphal / BasicPro wrote: > Date: Mon, 4 Jan 1999 09:39:00 +0100 > From: Ralf Westphal / BasicPro > To: 'Dan Holle' , 'Paul Butkiewicz' , xml-dev@ic.ac.uk, xlxp-dev@fsc.fujitsu.com, simonstl@simonstl.com, bckman@ix.netcom.com > Subject: RE: Why XML Over the Relational Model? > > Very interesting topic! > > But how a about the following twist: > > We keep our relational databases for speed etc. and make them accessible > thru the DOM. That way they?d appear as if they were huge XML files. > > It would be a win-win solution: > -We?d retain all advantages of a dedicated API and a dedicated database > file format, e.g. indexes. > -Plus we?d gain a standard API/interface to the data. > > Now a user wouldn?t have to care whether data she needs to query resides > in a true XML file or in a RDBMS. All she needs is a XQL processor > (take XQL just as an example for a XML query language) and a list of > filenames. > > She then would feed each filename (and her query) to the XQL processor, and > leave it to the XQL processor to figure out how to get to the data. The > XQL processor, for example, would look at the filename extension and > instantiate an appropriate XML parser or DOM object. E.g. for files > with the extension XML it would instantiate a regular XML parser (like > MSXML from Microsoft), pass it the XML filename and then execute the > query using the DOM. For MDB files on the other hand > (MS Access database files) the XQL processor would not instantiate a > XML parser (wouldn?t make much sense ;-), but instead a "DOM-component". > > A DOM-component implements XML DOM interfaces, so it looks just like a > XML parser doing the same. So from the outside, one cannot discern if behind > a DOM-component is a XML file or something else. > > Since the DOM-component for MDB files behaves just like a true XML DOM (no, > even > better, it _is_ a true XML DOM), the XQL processor again can execute the > query > itself. > > Benefits: > -all files and data structures (e.g. file system, list of running processes) > could be made accessible thru a single API: the DOM > -a single query language could be used to query (manipulate?) any data > structure > -even transparent querying across data structures would be possible (e.g. > a query could start in a DOM for the file system but could easily continue > _into_ files pointed to). This kind of querying could be called "universal > querying". > > Possible Objections: > -Why don?t we just convert all files to XML? We wouldn?t need > DOM-components. > Current database file formats are optimized for the purpose. XML is a good > format for read-mostly/read-only purposes (e.g. in data exchange scenarios); > but I don?t see megabyte databases stored in XML. The POET ODBMS for example > converts XML files to its proprietary ODBMS file format before publishing it > thru a DOM. > Where XML is a file format ideal for many purposes, but not for all, the XML > DOM is a truely universal interface to any data, be it the file system or > a text file. It?s just another kind of API. > > -But databases as no XML files so how can we see the thru a DOM? > The existence of a DOM does not depend on a XML file. A DOM is just a > hierarchy > of objects. It?s easy to instantiate a hierarchy of DOM-node objects for > a hierarchy of directories and files. A DOM-node for a directory, for > example, > could return "folder" as its tagName property; and a DOM-node for a file > could > have a attribute node called "dateCreated". > We can see clearly a DOM-component does not need an external XML DTD or XML > schema. > Even the concepts of wellformedness and validity loose their values since > their > is not data to be parsed. Or the other way round: the data a DOM-component > is > always wellformed and valid (because the DOM-component sits on top of a > specific > API which ensures the correctness so to speak). > The hierarchy of node objects in a DOM-component thus does not depend on a > real DTD or > real schema, but is predefined by "virtual" schema. The designer of a > DOM-component > simply maps a given data structure (e.g. a hierarchy of directories and > files) to > a hierarchy of DOM-node objects with certain tag names and attributes and > values. > > -The same XQL query wouldn?t work on different data structures? > True. But the same holds for queries on RDBMS once they have different table > structures. > If you want to query a couple of address databases you?d probably need to > formulate several SQL queries, since ZIP information in one database is > stored in a > column called "ZIP" and in another it?s called "PostalCode". > On the other hand universal querying would still work for files of the same > type, e.g. > all MDB files. If you assume a MDB file is represented by a hierarchy of > nodes with > tag names tables/table name=.../row/col name=... you could ask questions > like "return > all rows in all tables containing a column named either ?ZIP? or > ?PostalCode? which > contains the value ?20099?". Fed to a XQL processor with a couple of MDB > filesnames > you?d need only this one query to retrieve all addresses with ZIP ?20099?. > > -Universal querying could lead to bad performance! > True. If you?d start a query on a file system DOM-component and let it > recurse into > files the performance could go down easily. But then: why not let the user > decide. > Maybe it?s more convenient for him to wait than not be able to get at the > requested > information at all. At leat he has the possibility to issue a very general > query and > not care about file types and file boundaries. DOM-components and XQL > processors > are a very powerful concept. > Also, XQL processors and DOM-components could be made more "intelligent". > For example, > before querying a DOM the XQL processor could ask, "do you contain a > hierarchy of > row/col nodes at all?" If not, the XQL processor could immediately skip the > whole > data structure and continue with the next one. > > -But XQL doesn?t allow things like spanning of files etc. > True, XQL can?t do that - yet. But why not think of extending XQL? > Today > folder/file/@name > results in a list of attribute nodes. > Today > folder/file/@name/tables/table > does not work. > But tomorrow > folder/file/@name/tables/table > could mean, "use the values of the name-attributes as file names, for each > file name > instantiate the appropriate DOM-component, and continue the query with the > rest of > the query string into the DOM-component". > Other ways of marking where spanning XML structures/DOMs could be thought > of. > > Hope I didn?t bore you guys too much ;-) But wouldn?t a world with universal > querying > capabilities great? > > Cheers, > > Ralf > > > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Dan Holle > Sent: Sonntag, 3. Januar 1999 20:25 > To: Paul Butkiewicz; xml-dev@ic.ac.uk; xlxp-dev@fsc.fujitsu.com > Subject: Re: Why XML Over the Relational Model? > > > >>The primary answer I give this question is flexibility, though there is a > >>significant cost in efficiency. XML documents can easily hold structures > >>that make relational databases choke. . . . > > > >I would love to see an example of this. > > > > > Me too, Paul. > > Let's not think of XML as a representation for a complex multi-table > multi-user shared database. DOM, as a database, is like a RAM-resident > single user IMS/DB. (If you must barf, don't barf on your keyboard.) There > is a reason why we fled from hierarchical linked databases to relational. > > Yes, there are databases you can do in XML that you can't do in relational. > Just as there are things you can do in assembler language you can't do in > Java. But if you are trying to do something useful with large, complex > data, stick with relational. > > XML seems a good match for small but flexible structures on web-connected > clients. David's comments, saying XML is for information exchange and > relational is for storage/query, rings true... > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > +----------------+-------------------------------------------+ |-- /\ --|-- mailto:Jonathan.Irving@Sun.COM --| |-- \\ \ --|-- phone:x16112/(+44/0)1276416112 --| |-- \ \\ / --|-- fax:(+44/0)127625941 /work --| |-- / \/ / / --+-------------------------------------------+ |-- / / \//\ --|-- http://flag-ir.europe --| |-- \//\ / / --|-- http://bast.uk --| |-- / / /\ / --+-------------------------------------------+ |-- / \\ \ --|-- mailto:J@browncat.com --| |-- \ \\ --+-- http://www.browncat.demon.co.uk --| |-- \/ --|-- phone:(+44/0)7801866443 /home --| +----------------+-------------------------------------------+ | ECHELON Fodder | USACIL Chicago Posse Salsa botux | | | STARLAN BITNET | +----------------+-------------------------------------------+ +----------------+-------------------------------------------+ |-- /\ --|-- mailto:Jonathan.Irving@Sun.COM --| |-- \\ \ --|-- phone:x16112/(+44/0)1276416112 --| |-- \ \\ / --|-- fax:(+44/0)127625941 /work --| |-- / \/ / / --+-------------------------------------------+ |-- / / \//\ --|-- http://flag-ir.europe --| |-- \//\ / / --|-- http://bast.uk --| |-- / / /\ / --+-------------------------------------------+ |-- / \\ \ --|-- mailto:J@browncat.com --| |-- \ \\ --+-- http://www.browncat.demon.co.uk --| |-- \/ --|-- phone:(+44/0)7801866443 /home --| +----------------+-------------------------------------------+ | ECHELON Fodder | munitions Gulf jack codes mania Merv | +----------------+-------------------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Jan 4 18:40:27 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:12 2004 Subject: Internationalization and naming Message-ID: <4.0.1.19990104133100.00e19ed0@pop.hesketh.net> While writing a blip about XML's support for multiple languages (Unicode, xml:lang, etc.), it occurred to me that XML still has a ways to go toward removing the language barriers with regard to element and attribute names. HTML imposed an element vocabulary roughly based on English upon document authors the world over, and not everyone was especially thrilled about it. XML avoids this issue - you can name your elements and attributes whatever you like - but it seems likely to crop up again any time people and organizations go to build document standards using XML. Will English vocabularies be used, or will other languages be used? In the current XML 1.0 spec, validation requires exact matching of tag names, and as far as I can tell, there isn't any discussion of validating a transformed document (via XSL or whatever) that converts documents using French or Chinese element/attribute names to English (or whatever the standard uses.) This seems like something that the next generation of schemas could address neatly, by providing room for something like a translation table, identifying elements and their 'standard' equivalents. This could open up validation considerably, and possibly make it a lot easier to get buy-in from user communities that perhaps have no input toward the standards or their choice of language. These translations could, of course, take place elsewhere in the process (editing tools, XSL, etc.), but it seems like addressing it where it matters - the validation process - is a cleaner solution, at least to me. (A clearer model for transformation and validation might help as well, if this proposal is too radical.) Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Mon Jan 4 18:59:14 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:12 2004 Subject: Internationalization and naming Message-ID: <5BF896CAFE8DD111812400805F1991F708AAECE3@RED-MSG-08> Thanks. One of the intentions of XML-Data was to make aliases for names explicit. See http://www.w3.org/TR/1998/NOTE-XML-data-0105/#Aliases Here is text from the proposal: ElementTypes can be know be different names in different languages or domains. The equivalence of several names is effected by the sameAs attribute, as in -----Original Message----- From: Simon St.Laurent [mailto:simonstl@simonstl.com] Sent: Monday, January 04, 1999 10:43 AM To: XML-Dev Mailing list Subject: Internationalization and naming While writing a blip about XML's support for multiple languages (Unicode, xml:lang, etc.), it occurred to me that XML still has a ways to go toward removing the language barriers with regard to element and attribute names. HTML imposed an element vocabulary roughly based on English upon document authors the world over, and not everyone was especially thrilled about it. XML avoids this issue - you can name your elements and attributes whatever you like - but it seems likely to crop up again any time people and organizations go to build document standards using XML. Will English vocabularies be used, or will other languages be used? In the current XML 1.0 spec, validation requires exact matching of tag names, and as far as I can tell, there isn't any discussion of validating a transformed document (via XSL or whatever) that converts documents using French or Chinese element/attribute names to English (or whatever the standard uses.) This seems like something that the next generation of schemas could address neatly, by providing room for something like a translation table, identifying elements and their 'standard' equivalents. This could open up validation considerably, and possibly make it a lot easier to get buy-in from user communities that perhaps have no input toward the standards or their choice of language. These translations could, of course, take place elsewhere in the process (editing tools, XSL, etc.), but it seems like addressing it where it matters - the validation process - is a cleaner solution, at least to me. (A clearer model for transformation and validation might help as well, if this proposal is too radical.) Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Jan 4 19:26:06 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:13 2004 Subject: Internationalization and naming In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAECE3@RED-MSG-08> Message-ID: <199901041925.OAA19001@hesketh.net> At 10:57 AM 1/4/99 -0800, Andrew Layman wrote: >Thanks. One of the intentions of XML-Data was to make aliases for names >explicit. See http://www.w3.org/TR/1998/NOTE-XML-data-0105/#Aliases > >Here is text from the proposal: > >ElementTypes can be know be different names in different languages or >domains. The equivalence of several names is effected by the sameAs >attribute, as in > > > I'm glad I'm not the first to come up with this, and glad to see as well that the idea's had a reasonably full expression. Aliasing seems not to be in DCD, and I know we didn't provide it in XSchema. Internationalization seems like a compelling reason to include it, though I can imagine people using it for other tasks, like minimization. Might be nice to include a language identifier for the alias, too. Neat stuff! Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From avirr at LanMinds.Com Mon Jan 4 19:36:52 1999 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:07:13 2004 Subject: Internationalization and naming In-Reply-To: <4.0.1.19990104133100.00e19ed0@pop.hesketh.net> Message-ID: At 1:42 PM -0500 1/4/99, Simon St.Laurent wrote: > While writing a blip about XML's support for multiple languages (Unicode, > xml:lang, etc.), it occurred to me that XML still has a ways to go toward > removing the language barriers with regard to element and attribute names. > There's a fascinating article about this issue and the Dublin Core set of simple metadata tags. Even with such a small set, the translation issues are quite difficult. Avi ________________________________________________________________ Avi Rappoport, Web Site Search Tools Maven: Guide to Site Indexing and Local Search Engines: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jan 4 20:00:23 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:13 2004 Subject: Internationalization and naming In-Reply-To: <4.0.1.19990104133100.00e19ed0@pop.hesketh.net> References: <4.0.1.19990104133100.00e19ed0@pop.hesketh.net> Message-ID: <13969.5324.799922.73383@localhost.localdomain> Simon St.Laurent writes: > Will English vocabularies be used, or will other languages be used? > In the current XML 1.0 spec, validation requires exact matching of > tag names, and as far as I can tell, there isn't any discussion of > validating a transformed document (via XSL or whatever) that > converts documents using French or Chinese element/attribute names > to English (or whatever the standard uses.) > This seems like something that the next generation of schemas could > address neatly, by providing room for something like a translation > table, identifying elements and their 'standard' equivalents. This > could open up validation considerably, and possibly make it a lot > easier to get buy-in from user communities that perhaps have no > input toward the standards or their choice of language. Simon: this is exactly the kind of thing that people can use architectural forms for. The full version of AFs suffers from the common SGML difficulty of trying to solve so many different problems that the complexity of the solution becomes yet another problem; however, a simplified profile, like the one I used for XAF (in retrospect, I'd simplify that much further) would fit the bill nicely. Basically, AFs let you declare that there exists a view of the document (an "architecture") where elements and attributes might have different names: you then declare what attribute(s) you will use to represent the canonical names. For example, using the simplified XAF profile (and using pig-Portuguese, since I don't claim to speak or understand the language), Exemplo em Portugues

Exemplo em Portugues

Este ? um exemplo simples no portugu?s muito in?bil.

The problem with using a schema is that you either kill light-weight XML processing or force the translation to take place upstream, so the client doesn't have the opportunity to take advantage of the non-English material. This example isn't all that complicated (though the declaration syntax will have to change a bit) -- it might even be fun to add namespaces to the mix. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Mon Jan 4 21:10:12 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:13 2004 Subject: Internationalization and naming Message-ID: <5BF896CAFE8DD111812400805F1991F708AAECEB@RED-MSG-08> David Megginson said: "The problem with using a schema is that you either kill light-weight XML processing or force the translation to take place upstream, so the client doesn't have the opportunity to take advantage of the non-English material." I don't follow your point about a schema killing lightweight processing. Any sort of mapping--such as might be indicated in a schema--would require obtaining the mapping rules and running a processor. And I also see that it would be useful to be able to process a document without doing any mapping. But would this not be equally true of of any mapping scheme, whether AFs, mappings packaged with schema, XSL-based or other? --Andrew Layman xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jan 4 21:24:12 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:13 2004 Subject: Internationalization and naming In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAECEB@RED-MSG-08> References: <5BF896CAFE8DD111812400805F1991F708AAECEB@RED-MSG-08> Message-ID: <13969.12425.458413.351183@localhost.localdomain> Andrew Layman writes: > I don't follow your point about a schema killing lightweight > processing. Any sort of mapping--such as might be indicated in a > schema--would require obtaining the mapping rules and running a > processor. And I also see that it would be useful to be able to > process a document without doing any mapping. But would this not > be equally true of of any mapping scheme, whether AFs, mappings > packaged with schema, XSL-based or other? Absolutely correct -- what I mean by "light-weight" processing is processing a document without reference to an external schema. Namespaces do allow this, even though namespace processing itself is non-trivial; I'd suggest that any name-mapping scheme should do the same. Simon's suggestion, as I recall, was to do the schema processing upstream (perhaps on the server side). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Jan 4 21:43:25 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:13 2004 Subject: XML Processing (was RE: Internationalization and naming) In-Reply-To: <13969.12425.458413.351183@localhost.localdomain> References: <5BF896CAFE8DD111812400805F1991F708AAECEB@RED-MSG-08> <5BF896CAFE8DD111812400805F1991F708AAECEB@RED-MSG-08> Message-ID: <199901042143.QAA08192@hesketh.net> At 04:22 PM 1/4/99 -0500, david@megginson.com wrote: >Andrew Layman writes: > > > I don't follow your point about a schema killing lightweight > > processing. Any sort of mapping--such as might be indicated in a > > schema--would require obtaining the mapping rules and running a > > processor. And I also see that it would be useful to be able to > > process a document without doing any mapping. But would this not > > be equally true of of any mapping scheme, whether AFs, mappings > > packaged with schema, XSL-based or other? > >Absolutely correct -- what I mean by "light-weight" processing is >processing a document without reference to an external schema. > >Namespaces do allow this, even though namespace processing itself is >non-trivial; I'd suggest that any name-mapping scheme should do the >same. Simon's suggestion, as I recall, was to do the schema >processing upstream (perhaps on the server side). This discussion is setting off a lot of alarm bells for me, most of which go off periodically anyway. I really wish that the XML spec had cleanly separated validation from well-formedness checking, thereby encouraging a clean separation of parsing a document (into events or a tree) from validating its structure. This would have made it a lot easier to accomodate both light-weight processing (without a schema) and the use of schemas/validation at any point in the processing of an XML document (before or after transformations of some kind). I like David's suggestion of architectural forms for this application very much; unfortunately, it's difficult in the current environment to perform such a transformation and then perform validation/schema checking on the results. That transformation would have to allow translation before validation if validation were important. XML-Data's approach, of putting the translation table into the schema, at least allows validation to operate on the translated version. If we don't separate the basic work of parsing from the more sophisticated work of checking document structures, it's very difficult to do anything to a document before feeding it into the structure check. In most circumstances, perhaps, this doesn't matter, but in others it's a pain in the neck. I'd love to see a validator that works on a DOM tree or SAX events separate from the parser itself. If only I had the time to write one... Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Mon Jan 4 21:54:31 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:07:13 2004 Subject: Internationalization and naming References: <199901041925.OAA19001@hesketh.net> Message-ID: <36913872.C425AA71@allette.com.au> Simon St.Laurent wrote: > Might be nice to include a language identifier for the alias, too. Neat > stuff! Some would say it would be crucial. Or are we precluding such translations between say, Korean and Japanese? There may still be some of that old anglocentric attitude lingering around... -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Mon Jan 4 22:48:31 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:13 2004 Subject: Internationalization and naming In-Reply-To: <199901041925.OAA19001@hesketh.net> References: <5BF896CAFE8DD111812400805F1991F708AAECE3@RED-MSG-08> Message-ID: <3.0.1.32.19990104174851.006bf0e8@pop.uunet.ca> >At 10:57 AM 1/4/99 -0800, Andrew Layman wrote: >>Thanks. One of the intentions of XML-Data was to make aliases for names >>explicit. See http://www.w3.org/TR/1998/NOTE-XML-data-0105/#Aliases >> >>Here is text from the proposal: >> >>ElementTypes can be know be different names in different languages or >>domains. The equivalence of several names is effected by the sameAs >>attribute, as in >> >> >> > At 02:28 PM 1/4/99 -0500, Simon St.Laurent wrote: >I'm glad I'm not the first to come up with this, and glad to see as well >that the idea's had a reasonably full expression. Aliasing seems not to be >in DCD, and I know we didn't provide it in XSchema. Since we're on the topic, SOX offers equivalence like so: This example allows in lieu of and in lieu of And SOX namespace allow you to create local aliases for elements, attributes, entities, and notations defined in any included namespace. This example allows in lieu of and in lieu of Localizing a SOX schema definition can be a simple remapping of the names of elements and attributes -- or a more complex remapping that adds new level in the document structure, adds to a base element's content model or attribute list, or redefines attributes and entities. For more info on SOX, see http://www.w3.org/Submission/1998/15/ Regards, Murray xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Mon Jan 4 22:53:18 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:13 2004 Subject: Internationalization and naming In-Reply-To: <3.0.1.32.19990104174851.006bf0e8@pop.uunet.ca> References: <199901041925.OAA19001@hesketh.net> <5BF896CAFE8DD111812400805F1991F708AAECE3@RED-MSG-08> Message-ID: <3.0.1.32.19990104175302.00751de0@pop.uunet.ca> I made an error in one of my examples. This line: should read: Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 5 01:42:48 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:13 2004 Subject: Docs for namespace and other processing instructions? Message-ID: <000701be384c$3a9a1900$5118a8c0@kuantech1.quokka.com> I have seen several references to the processing instruction " The processing instruction was used in drafts of the Namespaces specification until approximately August 1998, at which time it was supplanted by the attributes now described in the spec. -----Original Message----- From: Jeffrey E. Sussna [mailto:jes@kuantech.com] Sent: Monday, January 04, 1999 5:39 PM To: 'XML-DEV' Subject: Docs for namespace and other processing instructions? I have seen several references to the processing instruction " Simon St.Laurent writes: > Will English vocabularies be used, or will other languages be used? > This seems like something that the next generation of schemas could > address neatly, by providing room for something like a translation > table, identifying elements and their 'standard' equivalents. This > could open up validation considerably, and possibly make it a lot > easier to get buy-in from user communities that perhaps have no > input toward the standards or their choice of language. I think we can observe the rule that the more a name is like a "keyword", the less reason there is need for a local version. The more the name is like a variable, the less reason for an internationally understandable version. SGML allowed you to remap keywords: you could change CDATA to KDATEN or whatever. But no-one did. When a standard DTD is specified, I think there is good reason to avoid providing alternative names. The biggest one is documentation. If I write a book in English, and the examples cannot be directly used by people in other languages, then that makes life more complicated for foreigners than less. (The AF approach seems less satisfactory than the DCD approach because of this. ) I think we still have a few years before we need to seriously consider this issue: have CSS implementations been tested using non-Western Native Language Markup yet? My preliminary tests indicate that the current betas do not handle non-ASCII characters in attribute tests or element names. After these problems are fixed up, and after more XML products support character encodings that people actually use, then we can turn our attention to alternatives. Actually, IMHO the thing that is actually required for internationaliation is a Website giving error messages and commmon element names in multiple languages. That way you can write your code to return a URI, and content-negotiation can return the specific error message in the appropriate language. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 5 02:06:05 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:13 2004 Subject: FW: Docs for namespace and other processing instructions? Message-ID: <000901be384f$6a87a940$5118a8c0@kuantech1.quokka.com> Thanks to Andrew for the answer to my question. Unfortunately, it raises a couple of other questions: 1. I assume reserved attributes such as "xmlns" need not be declared in DTD's (or other schema mechanisms). Is this correct? 2. Is there, or will there be, a centralized definition of XML reserved objects (attributes, processing instructions, etc.) that may be defined outside the XML spec, but which cut across general usage of the language? I think there should be. Jeff -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk] On Behalf Of Andrew Layman Sent: Monday, January 04, 1999 5:47 PM To: 'XML-DEV' Subject: RE: Docs for namespace and other processing instructions? The processing instruction was used in drafts of the Namespaces specification until approximately August 1998, at which time it was supplanted by the attributes now described in the spec. -----Original Message----- From: Jeffrey E. Sussna [mailto:jes@kuantech.com] Sent: Monday, January 04, 1999 5:39 PM To: 'XML-DEV' Subject: Docs for namespace and other processing instructions? I have seen several references to the processing instruction " References: <000901be384f$6a87a940$5118a8c0@kuantech1.quokka.com> Message-ID: <13969.30013.350535.500837@localhost.localdomain> Jeffrey E. Sussna writes: > Thanks to Andrew for the answer to my question. Unfortunately, it > raises a couple of other questions: > > 1. I assume reserved attributes such as "xmlns" need not be > declared in DTD's (or other schema mechanisms). Is this correct? A valid XML 1.0 document has to declare all attributes used, even magic attributes like xml:space, xml:lang, and xmlns and xmlns:*. Nothing in the namespaces REC changes the interpretation of XML 1.0. > 2. Is there, or will there be, a centralized definition of XML > reserved objects (attributes, processing instructions, etc.) that > may be defined outside the XML spec, but which cut across general > usage of the language? I think there should be. All names beginning with the letters [xX][mM][lL] are reserved, and no other names are: only specs from the W3C's XML Activity should define names beginning with these letters, and even then, we're trying to avoid them. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Jan 5 03:10:28 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:13 2004 Subject: namespace conformance Message-ID: <199901050310.WAA00432@hesketh.net> Section 6 of the Namespace Proposed Rec, "Conformance of Documents", states that: ----------------------------- The effect of conformance is that in such a document: * All element types and attribute names contain either zero or one colon. * No entity names, PI targets, or notation names contain any colons. ------------------------------ I can understand the first part just fine. But why bar colons from every other use of Name in the spec? Why not just leave them as Name and be done with it? If namespaces don't apply to entities, PIs, or notations, why would a processor be checking them for colons? Just wondering... Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Tue Jan 5 03:22:46 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:07:13 2004 Subject: namespace conformance In-Reply-To: <199901050310.WAA00432@hesketh.net> (simonstl@simonstl.com) Message-ID: <199901050320.WAA01151@ruby.ora.com> [Simon St.Laurent] > * All element types and attribute names contain either zero or one > colon. > * No entity names, PI targets, or notation names contain any colons. > > I can understand the first part just fine. But why bar colons from > every other use of Name in the spec? Future use. The application of namespaces to entities isn't fully understood right now, but if colons in entity names are declared meaningless now, then any future attempt to attach meaning later will be a disaster. It's the same reason that colons in names (except xml:lang and xml:space) were declared to be reserved for experimental use in XML 1.0. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Jan 5 03:48:25 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:14 2004 Subject: namespace conformance In-Reply-To: <199901050320.WAA01151@ruby.ora.com> References: <199901050310.WAA00432@hesketh.net> Message-ID: <199901050348.WAA01181@hesketh.net> At 10:20 PM 1/4/99 -0500, Chris Maden wrote: >[Simon St.Laurent] >> I can understand the first part just fine. But why bar colons from >> every other use of Name in the spec? > >Future use. The application of namespaces to entities isn't fully >understood right now, but if colons in entity names are declared >meaningless now, then any future attempt to attach meaning later will >be a disaster. It's the same reason that colons in names (except >xml:lang and xml:space) were declared to be reserved for experimental >use in XML 1.0. Glad to hear that there's a good reason. Might be smart to put that explicitly into the final recommendation as well, assuming namespaces make it to that stage. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arabbit at earthlink.net Tue Jan 5 03:51:51 1999 From: arabbit at earthlink.net (Paul Butkiewicz) Date: Mon Jun 7 17:07:14 2004 Subject: Why XML Over the Relational Model? In-Reply-To: <199901041454.JAA17903@hesketh.net> Message-ID: <000301be385e$84845960$8636bfa8@arabbit> >The simplest case is when your data store is keeping a bunch of documents >for you, be they memos, lab notebooks, or documentation. While you can >store documents in RDBMS systems, it... well, it kind of sucks, even on a >good day. If you happen to be lucky enough to be dealing with the portion >of data that all fits neatly into relational structures, without needed to >build messy scaffolding around it, XML probably isn't that exciting. For >those of us who would like to perform complex operations on documents and >other information that doesn't fit relational systems neatly, XML is >revelation. >... But using XML for persistence in this case presents its own perils. Consider the case of modifying the database which is now implemented as an XML document. If I add an attribute, a node, or make some text longer, I may very well need to re-write the *entire* file to accommodate the changes I've just made and make them persistent. Of course, I could pad various parts of the document with spaces to get around this, but given that XML has no notion of field lengths this certainly isn't a sure-fire fix --- I'm still going to need to rewrite the whole document now and then, especially if I'm adding nodes ad hoc. And in addition to the overhead of actually writing out the whole document (which *must* be done as part of the transaction), when writing that document I would need to lock the *entire* document. This wouldn't be acceptable at all in a situation where many concurrent writes are going to data in the same document, even if on different nodes. And then there's the obvious problem that if I want to go directly to Article 14, Section 3, Subsection 41, Chapter 27, Paragraph 6, and I don't have that part of the document cached in memory, I may have to iterate through the entire document get that item. Maybe this part of the discussion should be XML vs RDBMS vs ODBMS. :) Paul xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Jan 5 04:07:46 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:14 2004 Subject: Why XML Over the Relational Model? In-Reply-To: <000301be385e$84845960$8636bfa8@arabbit> References: <199901041454.JAA17903@hesketh.net> Message-ID: <199901050407.XAA18144@hesketh.net> At 10:50 PM 1/4/99 -0500, Paul Butkiewicz wrote: >But using XML for persistence in this case presents its own perils. >Consider the case of modifying the database which is now implemented as an >XML document. If I add an attribute, a node, or make some text longer, I >may very well need to re-write the *entire* file to accommodate the changes >I've just made and make them persistent. Of course, I could pad various >parts of the document with spaces to get around this, but given that XML has >no notion of field lengths this certainly isn't a sure-fire fix --- I'm >still going to need to rewrite the whole document now and then, especially >if I'm adding nodes ad hoc. And in addition to the overhead of actually >writing out the whole document (which *must* be done as part of the >transaction), when writing that document I would need to lock the *entire* >document. This wouldn't be acceptable at all in a situation where many >concurrent writes are going to data in the same document, even if on >different nodes. > >And then there's the obvious problem that if I want to go directly to >Article 14, Section 3, Subsection 41, Chapter 27, Paragraph 6, and I don't >have that part of the document cached in memory, I may have to iterate >through the entire document get that item. > >Maybe this part of the discussion should be XML vs RDBMS vs ODBMS. :) I think we're in agreement here, mostly because I'd like to see XML documents stored in ODBMS-like systems rather than in the traditional filesystem goop we have today. When I talk about using XML in this way, I really see XML as a much friendlier face to an ODBMS rather than a big chunk of characters in sequence. On the other hand, I'd rather not have to address the ODBMS directly, ever - everything should be addressable through XML-based mechanisms. The problem with the view of XML presented above, in my mind, isn't XML - it's the crummy file systems we have to work with at present. This wouldn't be a great solution for data that really fits well into an RDBMS. The 'natural' fit of the data structures is still important. See my (old) essay Building the File System into the File (http://www.simonstl.com/articles/filesyst.htm) for more on this. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jan 5 06:49:10 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:14 2004 Subject: Why XML Over the Relational Model? References: <000301be385e$84845960$8636bfa8@arabbit> Message-ID: <3691B0A5.D6A53EE2@prescod.net> Paul Butkiewicz wrote: > > But using XML for persistence in this case presents its own perils. XML is not optimized for update, retrieval, searching or anything else. It is optimized for interchange, interchange and interchange. So the question of the best persistence model for high-volume systems seems to me to boil down to a) "what data structure is fastest" and b) "what is the most convenient programatically." In other words, what data structures support business processes and with what sort of performance. I think that in the long run, flat text will lose out on both counts, but for now it is a good compromise. (anyone have any good arguments otherwise?) Object databases seem the obvious fit for convenience. Performance is harder. You could store a DOM or grove directly in an object database and retrieve it with no parsing overhead...but what about text searching? Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "In spite of everything I still believe that people are basically good at heart." - Anne Frank xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jan 5 17:52:57 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:14 2004 Subject: Internationalization and naming References: <4.0.1.19990104133100.00e19ed0@pop.hesketh.net> Message-ID: <3692515A.7F5489D0@locke.ccil.org> Simon St.Laurent wrote: > [In] XML [...] you can name your elements and attributes whatever > you like - but it seems likely to crop up again any time people and > organizations go to build document standards using XML. > > Will English vocabularies be used, or will other languages be used? [...] > This seems like something that the next generation of schemas could address > neatly, by providing room for something like a translation table, > identifying elements and their 'standard' equivalents. This strikes me as an ideal application of architectural forms (as implemented in XAF: see http://www.megginson.com/XAF). By specifying the desired standard form as an architecture, you allow the element types to be locally meaningful, while letting applications (XSL, validation, or whatever) to act) on architectural element types. XAF does the donkey work of reducing one to the other. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Jan 5 18:08:25 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:14 2004 Subject: Internationalization and naming In-Reply-To: <3692515A.7F5489D0@locke.ccil.org> References: <4.0.1.19990104133100.00e19ed0@pop.hesketh.net> Message-ID: <199901051807.NAA26057@hesketh.net> At 12:52 PM 1/5/99 -0500, John Cowan wrote: >This strikes me as an ideal application of architectural forms >(as implemented in XAF: see http://www.megginson.com/XAF). >By specifying the desired standard form as an architecture, >you allow the element types to be locally meaningful, while >letting applications (XSL, validation, or whatever) to act) >on architectural element types. XAF does the donkey work of >reducing one to the other. I definitely agree; my primary concern remains that architectural forms transformations will typically take place _after_ validation has already occurred, requiring developers to create complete translated DTDs rather than simpler tables of equivalent elements. In this, and in a significant number of situations like it, I suspect the XML spec's lack of a layered processing model is a hindrance. In other words, having a parser check basic document syntax and a validator check to see if the document structure corresponds to a schema would have made it easier to stick things in between the initial parse and the validation - like architectural forms transformations. Instead, we have parsers that do both syntax and structure checking and spit out results. This separation is something I hope to see come out of the upcoming W3C schema discussions, and is a promising aspect of XSchema (which layered itself on top of XML 1.0) as well. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Tue Jan 5 18:38:24 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:14 2004 Subject: XML-Data question Message-ID: <5BF896CAFE8DD111812400805F1991F708AAED0E@RED-MSG-08> Jeffrey E. Sussna asked "Has any further work taken place on XML Data? (How) does it relate to XSchema?" The Microsoft IE5 Technology Preview ships with an XML parser that supports the majority of the facilities described in the XML-Data proposal (http://www.w3.org/TR/1998/NOTE-XML-data-0105/). Key features it includes are (a) uses XML instance syntax, (b) datatypes, (c) open content model, (d) order-independent content model, (e) namespaces, (f) validation. Key features it omits are aliases, type extension and direct support of general foreign keys. See http://www.microsoft.com/sitebuilder/ for details. Regarding how XML-Data relates to XSchema, I have not worked actively with XML schemas for about six months, so don't have the knowledge to answer that question. Best regards, Andrew Layman Microsoft xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jan 5 19:40:06 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:14 2004 Subject: Why XML Over the Relational Model? References: <000301be385e$84845960$8636bfa8@arabbit> <3691B0A5.D6A53EE2@prescod.net> Message-ID: <36926A82.BC1AA4D4@locke.ccil.org> Paul Prescod wrote: > XML is not optimized for update, retrieval, searching or anything else. It > is optimized for interchange, interchange and interchange. Also for durability and durability (but perhaps not durability). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 5 20:18:14 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:14 2004 Subject: Reserved names and documentation Message-ID: <000201be38e8$00ac1bc0$5118a8c0@kuantech1.quokka.com> I understand that XML names starting in "xml" are reserved. My concern is how people find out what the defined reserved names are, without having to read every XML spec out there. I also have a related, larger concern that the XML universe will quickly become unmanageable. For example, to understand Microsoft's preview release of XML schemas, you need to understand XML Data and DCD. To understand DCD you have to understand RDF. And so on... All these ancillary specs are useful and worthwhile. It is clear that the XML language definition itself is necessary but not sufficient to do meaningful work. The danger is, though, that one will have to keep a pile of specs on one's desk in order to proceed. Perhaps this is no different than having to read several hundred pages of Toolbox Reference in order to write a Macintosh application. Nonetheless, I think it bears thought. Taken together, XML Data + RDF + ICE + WebDAV + whatever else represent a set of Web API's, with XML as the API definition language. Having worked with numerous large API's in the past (Smalltalk, Macintosh Toolbox, MacApp, Win32, etc.), I believe it's critical to try to make these Web API's as coherent and accessible as possible. I would like to encourage a meta-effort to examine and manage how all the generic (as opposed to vertical market) XML-based specs relate to one another. Jeff ----------------------------------------------------------------- Kuantech, Inc. http://www.kuantech.com Jeffrey E. Sussna, Principal jes@kuantech.com Distributed Content Architectures for Dynamic Online Applications ----------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 5 20:23:55 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:14 2004 Subject: FW: Why XML Over the Relational Model? Message-ID: <000301be38e8$d535e600$5118a8c0@kuantech1.quokka.com> >XML is not optimized for update, retrieval, searching or anything else. It >is optimized for interchange, interchange and interchange. So the question >of the best persistence model for high-volume systems seems to me to boil >down to a) "what data structure is fastest" and b) "what is the most >convenient programatically." In other words, what data structures support >business processes and with what sort of performance. Amen! Couldn't have said it better myself. Beware the temptation to think that "XML is all and all is XML". XML is a great standard interchange language. Java is a great portable applications language. Neither were intended to solve all problems. Remember that a standard mechanism for moving information between two points places NO restrictions on how the information is represented or managed within each point. There are thousands of man-years worth of effort and products in the persistence space, that should be leveraged, not replaced. Jeff Sussna xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bryan.cooper at veritas.com Tue Jan 5 21:21:04 1999 From: bryan.cooper at veritas.com (Bryan Cooper) Date: Mon Jun 7 17:07:14 2004 Subject: Reserved names and documentation In-Reply-To: <000201be38e8$00ac1bc0$5118a8c0@kuantech1.quokka.com> Message-ID: <199901052120.NAA29571@mailhub1.ncal.verio.com> I agree with this line of thinking. There's a lot going on but I've got deadlines to meet. I think this would be tough if you are trying to build a totally generic tool using XML since it means more and more flavors coming at you. Such a tool would be a moving target. For some of us, we are not trying to handle arbitrary XML, but instead have the luxury of using XML between different modules of our own projects. Right now, therefore, I am doing my project with plain XML and my own DTD as I don't see the other tools as far enough along to justify their approach. That is, I am on UNIX and using Python xmllib, plus another C based "ltxml" which provides faster xml searching within the various xml files generated by the project. So right off, I get 2 good xml tools into my project. BTW, I have already done some serious progress with just a few weeks of actual coding experience this way in Python.. My review of the other tools for RDF and any other project is that they aren't available yet for my project. One reason though I want to use XML now is so that at some point, I can incorporate those features into my project. Lets say I want later to use RDF because some tool is now really going to help me with RDF files. I can go back, update all the XML files I have into an appropriate RDF format, and the new tool will work. I would also have to update my program to handle parsing the changed RDF tags. While I am doing that, my old program and data files will keep chugging along. It may mean updating literally thousands of XML based files but hey, so what? It won't take that long, and it will work. (I may even put in RDF syntax now but ignore it...) I think XML is a good starting point for different projects because it is opening the door for tools that can all work from the same type of data. In that sense, it is equivalent to SQL as a method of data storage. For my current project, XML is a method of command storage, where I am creating commands , options, parameters, keywords, metadata all in XML. The type of user data I am working with would make RDF a natural choice in addition to the above, BUT it isn't ready yet. At 12:14 PM 1/5/99 -0800, Jeffrey E. Sussna wrote: >I understand that XML names starting in "xml" are reserved. My concern is how people find out what the defined reserved names are, without having to read every XML spec out there. I also have a related, larger concern that the XML universe will quickly become unmanageable. For example, to understand Microsoft's preview release of XML schemas, you need to understand XML Data and DCD. To understand DCD you have to understand RDF. And so on... All these ancillary specs are useful and worthwhile. It is clear that the XML language definition itself is necessary but not sufficient to do meaningful work. The danger is, though, that one will have to keep a pile of specs on one's desk in order to proceed. Perhaps this is no different than having to read several hundred pages of Toolbox Reference in order to write a Macintosh application. Nonetheless, I think it bears thought. Taken together, XML Data + RDF + ICE + WebDAV + whatever else represent a set of Web API's, with XML as the API definition language. Having worked with numerous large API's in the past (Smalltalk, Macintosh Toolbox, MacApp, Win32, etc.), I believe it's critical to try to make these Web API's as coherent and accessible as possible. I would like to encourage a meta-effort to examine and manage how all the generic (as opposed to vertical market) XML-based specs relate to one another. > >Jeff > >----------------------------------------------------------------- >Kuantech, Inc. http://www.kuantech.com >Jeffrey E. Sussna, Principal jes@kuantech.com > >Distributed Content Architectures for Dynamic Online Applications >----------------------------------------------------------------- > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > ...bryan F. Bryan Cooper 707 823 7324 VERITAS Software 707 321 3301 mobile Bryan.Cooper@veritas.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 5 21:28:13 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:14 2004 Subject: Reserved names and documentation In-Reply-To: <199901052120.NAA29571@mailhub1.ncal.verio.com> Message-ID: <000a01be38f1$cf7556c0$5118a8c0@kuantech1.quokka.com> >From a practical point of view, Bryan is spot on. I am making the same kinds of decisions myself. However, at some point the XML spec "family" will be mature. It would be a shame if that mature set of specs lacked coherency and was thus harder to use. Jeff -----Original Message----- From: Bryan Cooper [mailto:bryan.cooper@veritas.com] Sent: Tuesday, January 05, 1999 1:21 PM To: Jeffrey E. Sussna; 'XML-DEV' Subject: Re: Reserved names and documentation I agree with this line of thinking. There's a lot going on but I've got deadlines to meet. I think this would be tough if you are trying to build a totally generic tool using XML since it means more and more flavors coming at you. Such a tool would be a moving target. For some of us, we are not trying to handle arbitrary XML, but instead have the luxury of using XML between different modules of our own projects. Right now, therefore, I am doing my project with plain XML and my own DTD as I don't see the other tools as far enough along to justify their approach. [ snip ] xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Jan 5 21:52:49 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:15 2004 Subject: Reserved names and documentation In-Reply-To: <000a01be38f1$cf7556c0$5118a8c0@kuantech1.quokka.com> References: <199901052120.NAA29571@mailhub1.ncal.verio.com> Message-ID: <199901052152.QAA23454@hesketh.net> At 01:24 PM 1/5/99 -0800, Jeffrey E. Sussna wrote: >From a practical point of view, Bryan is spot on. I am making the same >kinds of decisions myself. However, at some point the XML spec "family" >will be mature. It would be a shame if that mature set of specs lacked >coherency and was thus harder to use. There are a lot of potential conflicts between assorted XML technologies, and rumor has it that the W3C is aware of them. Namespace prefixes hate validation. XLink provides services that seem to overlap with entities, no matter how much some insist that the don't, and the PI used for style sheets provides yet another example of connecting resources using URLs. XPointer is in some ways a query language. CSS and XSL are mutually incompatible tools that do a lot of the same things. Even in the XML 1.0 spec, valid and well-formed are pretty tightly locked in each other's embrace, making it difficult to separate the parts for a reasonable discussion or for a layered approach to parser development. I make my living these days explaining these issues, but I do keep wondering why they crop up so frequently. It may just be that it's a large project. I strongly hope that someone inside the W3C is watching for these issues and striving to keep the working groups from entering each other's turf. A 'lack of coherency' would certainly be a shame, and there are too many times when I see it. Of course, the specs are still immature, and the chaos does fill my pages quite rapidly, making my editors happy. We'll see... Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jan 5 21:56:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:15 2004 Subject: Why XML Over the Relational Model? References: <000301be385e$84845960$8636bfa8@arabbit> <3691B0A5.D6A53EE2@prescod.net> <36926A82.BC1AA4D4@locke.ccil.org> Message-ID: <36928729.D7849EB7@prescod.net> John Cowan wrote: > > Paul Prescod wrote: > > > XML is not optimized for update, retrieval, searching or anything else. It > > is optimized for interchange, interchange and interchange. > > Also for durability and durability (but perhaps not durability). Good point. Interchange across the time dimension is very important. People who use a relational or object database for their day-to-day work should definitely consider backing up a periodic XML dump, just as people who use XML day-to-day should consider how those other tools can help to make it updatable, retrievable, searchable, etc. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "In spite of everything I still believe that people are basically good at heart." - Anne Frank xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dkirsch at quintcom.com Tue Jan 5 22:04:20 1999 From: dkirsch at quintcom.com (dkirsch@quintcom.com) Date: Mon Jun 7 17:07:15 2004 Subject: Reserved names and documentation Message-ID: <882566F0.007BA57A.00@mercury.quintcom.com> So where would you see are the key points that need to be "codified" or placed into "mature specifications" versus those that can be left to the specification of the individual developer? Cheers, David K. "Jeffrey E. Sussna" on 01/05/99 01:24:42 PM Please respond to "Jeffrey E. Sussna" To: "'XML-DEV'" cc: "'Bryan Cooper'" (bcc: David Kirsch/QCI) Subject: RE: Reserved names and documentation >From a practical point of view, Bryan is spot on. I am making the same kinds of decisions myself. However, at some point the XML spec "family" will be mature. It would be a shame if that mature set of specs lacked coherency and was thus harder to use. Jeff -----Original Message----- From: Bryan Cooper [mailto:bryan.cooper@veritas.com] Sent: Tuesday, January 05, 1999 1:21 PM To: Jeffrey E. Sussna; 'XML-DEV' Subject: Re: Reserved names and documentation I agree with this line of thinking. There's a lot going on but I've got deadlines to meet. I think this would be tough if you are trying to build a totally generic tool using XML since it means more and more flavors coming at you. Such a tool would be a moving target. For some of us, we are not trying to handle arbitrary XML, but instead have the luxury of using XML between different modules of our own projects. Right now, therefore, I am doing my project with plain XML and my own DTD as I don't see the other tools as far enough along to justify their approach. [ snip ] xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Suli.Ding at geis.ge.com Tue Jan 5 22:56:24 1999 From: Suli.Ding at geis.ge.com (Ding, Suli (GEIS)) Date: Mon Jun 7 17:07:15 2004 Subject: text to XML conversion Message-ID: I updated my home page at http://www.geocities.com/SiliconValley/Platform/4871/ to show an example of converting a semicolon delimited file to XML. The test file is the one used by DataChannel for showing their XML generator. The test files are added to the zip file for Windows platform. Regards, Suli xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jan 6 00:27:11 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:15 2004 Subject: Reserved names and documentation Message-ID: <5BF896CAFE8DD111812400805F1991F708AAED20@RED-MSG-08> Simon St. Laurent wrote "Namespace prefixes hate validation." This is not true. There is nothing in namespaces per se that interferes with validation. It would be more accurate to say that work remains to better integrate DTDs and namespaces, and until that work is finished, if one wants to write a validatable document instance using namespaces, one must use exactly the prefixes written in the DTD. Whether integrating namespaces more fully with DTDs should be done by augmenting existing DTD syntax or by devising a new syntax is up to the currently-chartered "Schemas" effort. Best regards, Andrew Layman xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Jan 6 01:47:13 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:15 2004 Subject: Reserved names and documentation Message-ID: <3.0.32.19990105174446.00b8f480@pop.intergate.bc.ca> At 04:55 PM 1/5/99 -0500, Simon St.Laurent wrote: >There are a lot of potential conflicts between assorted XML technologies, >and rumor has it that the W3C is aware of them. There is at least an "XML Co-ordination" group whose job it is to worry about such things. Simon is right that the picture is pretty complicated. >Namespace prefixes hate >validation. Those who've heard my argument on this subject can tune out now. Here goes, again. Namespaces create two problems; an easy syntactic problem, and a hard design problem. The syntactic problem is that of validation, but there is a clean algorithmic solution: 1. You have a DTD that contains elements from different namespaces and you know what the URIs are for those namespaces. 2. You have a document that has tags from different namespaces, and you know what those namespaces are. 3. You want to validate the document against the DTD. 4. You make a list of all the namespace URIs that are in play via the DTD. For each you generate a unique prefix. 5. You preprocess the DTD, rewriting all the element & attribute declarations with the appropriate prefixes 6. You preprocess the instance, making all namespace prefixes explicit (no defaulting), declaring all the namespaces on the root element, and using the same set of prefixes you used in the DTD 7. You validate OK, this is a bit tedious but contains NO ROCKET SCIENCE. The syntactic problems of validating in the presence of namespaces are just not that hard. Now, on to the difficult problem: how do you go about making that DTD I mentioned in step 1, that has the combined elements? Right now we have little in the way of technology or automated procedures or even industry experience to aid us in designing that compound DTD in a good, clean, and efficient way. That's a hard problem and one that some of the schema proposals are feeling toward a solution for. But we're nowhere near knowing the answer. Thus, I have to reject Simon's contention that namespaces are anti-validation. It is true that *compound documents* pose big problems for document design in general and validation in particular. Compound documents, it is painfully obvious, are coming at us fast, and in high volume, so it behooves us to get our act together on document design. Namespaces, for the nonce, allow us to have compound documents without the elements falling over each other. But in and of themselves, they don't particularly impair validation. >XLink provides services that seem to overlap with entities, no >matter how much some insist that the don't Yup. Who insists there's no overlap? Obviously, since XLink is trying to be a general-purpose hypertext mechanism, and external entities have an obvious hypertext semantic, it would be surprising if there were no overlap. So much so that some have suggested that once we have hyperlinks we don't need entities any more. I doubt that, but it's a sane premise worth considering. But the overlap doesn't feel dangerous to me; what should we be worried about? >, and the PI used for style >sheets provides yet another example of connecting resources using URLs. That's evidently an interim patch made necessary by the imminence of the R5 XML-capable browsers... the right solution is a general-purpose packaging mechanism so you can bundle up an instance with pointers to (or direct inclusion of) the stylesheet(s) and schema(s) and scriptware and so on. But that's going to take some real work to build. >CSS and XSL are mutually >incompatible tools that do a lot of the same things. That's a real live problem all right; but at least everyone knows it exists. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bryan.cooper at veritas.com Wed Jan 6 02:33:04 1999 From: bryan.cooper at veritas.com (Bryan Cooper) Date: Mon Jun 7 17:07:15 2004 Subject: Reserved names and documentation In-Reply-To: <3.0.32.19990105174446.00b8f480@pop.intergate.bc.ca> Message-ID: <199901060232.SAA13207@mailhub1.ncal.verio.com> Assertion on: I personally feel namespaces as defined will implicitly REQUIRE everyone to explicitly tag each and every element which would be extra overhead and reduce the readability of the XML files. It also does not resolve your question about how to declare within the "primary" or "current" DTD that these "secondary" tags are allowed/disallowed. The problem appears to be that we have mixed, within the namespace redefinition of existing , a parser switch to another namespace while still parsing within the current namespace. Ouch! I think in general XML is best at making things EXPLICIT so this issue won't go away... /Assertion Suggestion On: A more explicit parser command tag like This is a push namespace event. enclosed can push other additional namespaces, and the parser would know to switch DTDs and pop off at each . For your problem, the primary DTD would only need to explicitly allow commands within specified , but would not need to declare anything within the since we are now in new namespace parsing territory. /Suggestion Analysis On: The idea is we need to send namespace to the parser so it can switch between multiple DTDs. I don't think combining DTDs is necessary or even desirable. I think that the DTD element containing secondary should then explicitly allow tags as a new XML type to support this kind of syntax. Once the occurs, we are in the secondary DTD which does NOT have to allow namespace switching for example. Rather, I think that XML should have EVENTs that are clearly designed for parser interaction and explicitly tagged inside the DTD. The primary DTD could then in fact declare which new namespace changes it allowed, or could allow any random namespace. We seem to have implicit namespace already occuring according to the namespace spec, I am just suggesting we make them explicit as a way to handle your DTD concerns AND to avoid everyone explicitly sticking namespace into every element. Rather, they could explicitly change just the namespace WHILE STILL PARSING WITHIN the primary/current namespace/DTD, and then let the secondary DTD do its job with the next, incoming . The secondary DTD does not even need to KNOW that it is within any namespace. Also, a new keyword like opens the door for some other parser directed possibilities. /2cents analysis Tell me if this makes any sense at all....just trying to help... >Now, on to the difficult problem: how do you go about making that >DTD I mentioned in step 1, that has the combined elements? Right now >we have little in the way of technology or automated procedures or even >industry experience to aid us in designing that compound DTD in a good, >clean, and efficient way. That's a hard problem and one that some >of the schema proposals are feeling toward a solution for. But we're >nowhere near knowing the answer. ...bryan F. Bryan Cooper 707 823 7324 VERITAS Software 707 321 3301 mobile Bryan.Cooper@veritas.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jan 6 03:13:33 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:15 2004 Subject: Namespaces hate validation! In-Reply-To: <3.0.32.19990105174446.00b8f480@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990105221336.00f603e4@pop.uunet.ca> At 08:46 PM 1/5/99 -0500, Tim Bray wrote: >At 04:55 PM 1/5/99 -0500, Simon St.Laurent wrote: >>Namespace prefixes hate validation. > >Those who've heard my argument on this subject can tune out now. Sadly, I don't feel that I can tune out on this one. In fact, >Here goes, again. Namespaces create two problems; an easy syntactic >problem, and a hard design problem. The syntactic problem is that >of validation, but there is a clean algorithmic solution: > >1. You have a DTD that contains elements from different namespaces > and you know what the URIs are for those namespaces. Everything that follows this point is predicated on the assumption that one can have such a DTD, but later Tim makes it clear that it is not currently feasible to design such a DTD. As Tim says, "we're nowhere near knowing the answer." >2. You have a document that has tags from different namespaces, and > you know what those namespaces are. >3. You want to validate the document against the DTD. >4. You make a list of all the namespace URIs that are in play via the > DTD. For each you generate a unique prefix. >5. You preprocess the DTD, rewriting all the element & attribute > declarations with the appropriate prefixes Using special care to take into account the non-XML notion of "global attributes". >6. You preprocess the instance, making all namespace prefixes > explicit (no defaulting), declaring all the namespaces on the root > element, and using the same set of prefixes you used in the DTD Of course, this will not work for instances that redeclare a namespace prefix with a different URI for the purposes of local scoping of namespaces. In that case, you have to declare namespaces on elements as you go. And, since you would have to inspect the entire document to determine whether local scoping of namespaces has been applied, you simply cannot count on Tim's algorithm for the general case. >7. You validate > >OK, this is a bit tedious but contains NO ROCKET SCIENCE. The >syntactic problems of validating in the presence of namespaces are >just not that hard. Well, tedious enough to make it unlikely that anyone will use validation on documents that utilize namespaces. It is hard. It is too hard. And for that reason, among others, Veo has vociferously opposed "Namespaces in XML". > >Now, on to the difficult problem: how do you go about making that >DTD I mentioned in step 1, that has the combined elements? Right now >we have little in the way of technology or automated procedures or even >industry experience to aid us in designing that compound DTD in a good, >clean, and efficient way. That's a hard problem and one that some >of the schema proposals are feeling toward a solution for. But we're >nowhere near knowing the answer. As a co-author of one of the schema submissions, I have to say that I do not see how to integrate "Namespaces in XML" -- as it is currently proposed -- with an XML Schema language. Perhaps someone will show me the error of my ways in the fullness of time, but I am skeptical. >Thus, I have to reject Simon's contention that namespaces are >anti-validation. It is true that *compound documents* pose big >problems for document design in general and validation in >particular. Compound documents, it is painfully obvious, are >coming at us fast, and in high volume, so it behooves us to get >our act together on document design. Namespaces, for the nonce, >allow us to have compound documents without the elements falling >over each other. But in and of themselves, they don't particularly >impair validation. No, they don't impair validation, they simply make it impractical to design document types that enable validation. I have never been able to make sense out of Tim arguments on this matter, and I still can't -- and it is not for lack of trying. "Namespaces in XML" hate validation. Shout it from the rooftops! Regards, Murray Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Wed Jan 6 04:30:14 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:07:15 2004 Subject: Reserved names and documentation References: <199901060232.SAA13207@mailhub1.ncal.verio.com> Message-ID: <3692E6B4.2744D4AC@allette.com.au> Bryan Cooper wrote: > > > > > This is a push namespace event. enclosed can push other > additional namespaces, and the parser would know to switch DTDs > and pop off at each . One problem would be that you lose context when you start parsing the fragments. For example, what if you just have a number of section-like elements in an event? How do you determine what the DOCTYPE element is, or whether they're occurring legally? The processor may not even be able to determine at what point of the DTD it should be initiating at. Even if you were able to pass this information to the processor, compound documents often aren't comprised of whole elements - for example, if you refer to legislation, you might just want two clauses to appear, though the parent element might be an entire Act. The only two ways that come quickly to mind would involve either padding the two clauses to make it look like an Act, or invoke a separate for each clause - an expensive workaround to avoid describing the structure more correctly. The truly inventive evil genius might even invoke a new event for every element, circumventing the requirement to adhere to that pesky DTD... if the elements originated from the same DTD, would you bother nesting them, or just put them in linearly? > The idea is we need to send namespace to > the parser so it can switch between multiple DTDs. I don't > think combining DTDs is necessary or even desirable. I don't know of anyone who would say that combining DTDs is desirable, but I do think it's necessary. The distinct lack of support for SUBDOC in SGML is strong evidence that the suspend-repurpose-resume approach is difficult for application designers and users alike. Imagine working in a word processor-like XML editor - can't put a element here? No problem, just start a new DOCTYPE. It's difficult enough to create a single DTD that discourages this approach, let alone compounding the problem by allowing multiple DOCTYPEs without providing satisfactory control over their occurrence. > Also, a new keyword like opens the door for some other > parser directed possibilities. That's a door I'll stay on this side of for the time being, thanks very much. :-) > Tell me if this makes any sense at all....just trying to help... My guess would be that the approach you describe would have been discussed by the WG and rejected for some of the reasons above, but of course we're still looking for the the DTD compounder... -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bryan.cooper at veritas.com Wed Jan 6 05:23:14 1999 From: bryan.cooper at veritas.com (Bryan Cooper) Date: Mon Jun 7 17:07:15 2004 Subject: Reserved names and documentation In-Reply-To: <3692E6B4.2744D4AC@allette.com.au> References: <199901060232.SAA13207@mailhub1.ncal.verio.com> Message-ID: <199901060522.VAA22608@mailhub1.ncal.verio.com> Marcus - thanx for the fast feedback. I am not proposing a complete solution but rather on top of the existing namespace proposal. I am also talking just at a general level of "does this tag allow ANY entry from namespace "newnamespace"? I am not trying to handle more delicate parsing within namespace. Apps would still be able to explicitly set namespace at each as currently proposed, but without the needed parsing clues for the primary DTD. Rather, I am saying this is an approach that would work for a number of types of XML documents. I believe merging DTDs will make XML namespace a big fat mess and defeat the purpose of namespace, since then the DTD just get bigger and bigger so why bother supporting multiple DTD anyway? For some purposes, telling the parser "Hey! Look! This is the same as "SUBDOC" so what is so wrong with supporting that for apps? I could go with in the main header, defining as the namespace encapsulation tag. The DTD would then need similar generic SUBDOCTYPE which equates XXX with valid namespace tags that it allows. Only the primary DTD would check that the namespace is valid, and not care whether XXX was the actual TAG used or YYY or whatever, just that the switched namespace had been placed within appropriate TAG. Again, I am starting just from the gross level where now the primary DTD can at least accept subdocs without necessarily having fine application level control within those subdocs. This would be a nice clean implementation and would allow the primary DTD to determine just which embedded namespaces it accepts (AND WHERE) by using a new keyword (or defined on the fly in each additional DOCTYPE as another suggestion ). In short, I don't see how the current proposal allows DTDs to reject embedded namespaces since there needs to be a way to communicate that rule to the parser in the primary DTD. Using a new keyword like is just one method, (or ) for the primary DTD elements... Then would be parsed by the primary DTD, and mean "change the namespace!"... I guess I am saying that there is a hierarchy to applications, where there really is at the "current" highest level, and it should allow that doctype to control subdoctype/namespace as requested by the huddled masses. We need a keyword to simplify the namespace switch within the DTD, not necessarily within the actual document as I am suggesting. Going totally granular on this may be necessary for some apps/DTDs, but what about alot of other apps where we just need to know the gross level namespace switch is about to occur? I have an application today where that would be helpful.. How do we allow/disallow that within the DTD today? Then let's drill down to the leaf node if people want/need such complicated DTDs. As to the committee deliberations, I won't go into the standard definition of "assume"... :-? I know that the current proposal makes a lot of sense, BUT it needs some tuning on this particular issue. At 03:29 PM 1/6/99 +1100, Marcus Carr wrote: >Bryan Cooper wrote: > >> >> >> >> >> This is a push namespace event. enclosed can push other >> additional namespaces, and the parser would know to switch DTDs >> and pop off at each . > >One problem would be that you lose context when you start parsing the fragments. For >example, what if you just have a number of section-like elements in an event? How do >you determine what the DOCTYPE element is, or whether they're occurring legally? The >processor may not even be able to determine at what point of the DTD it should be >initiating at. > >Even if you were able to pass this information to the processor, compound documents >often aren't comprised of whole elements - for example, if you refer to legislation, >you might just want two clauses to appear, though the parent element might be an >entire Act. The only two ways that come quickly to mind would involve either padding >the two clauses to make it look like an Act, or invoke a separate for each >clause - an expensive workaround to avoid describing the structure more correctly. The >truly inventive evil genius might even invoke a new event for every element, >circumventing the requirement to adhere to that pesky DTD... if the elements >originated from the same DTD, would you bother nesting them, or just put them in >linearly? > >> The idea is we need to send namespace to >> the parser so it can switch between multiple DTDs. I don't >> think combining DTDs is necessary or even desirable. > >I don't know of anyone who would say that combining DTDs is desirable, but I do think >it's necessary. The distinct lack of support for SUBDOC in SGML is strong evidence >that the suspend-repurpose-resume approach is difficult for application designers and >users alike. Imagine working in a word processor-like XML editor - can't put a > element here? No problem, just start a new DOCTYPE. It's difficult enough to >create a single DTD that discourages this approach, let alone compounding the problem >by allowing multiple DOCTYPEs without providing satisfactory control over their >occurrence. > >> Also, a new keyword like opens the door for some other >> parser directed possibilities. > >That's a door I'll stay on this side of for the time being, thanks very much. :-) > >> Tell me if this makes any sense at all....just trying to help... > >My guess would be that the approach you describe would have been discussed by the WG >and rejected for some of the reasons above, but of course we're still looking for the >the DTD compounder... > > >-- >Regards, > >Marcus Carr email: mrc@allette.com.au >___________________________________________________________________ >Allette Systems (Australia) www: http://www.allette.com.au >___________________________________________________________________ >"Everything should be made as simple as possible, but not simpler." > - Einstein > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > ...bryan F. Bryan Cooper 707 823 7324 VERITAS Software 707 321 3301 mobile Bryan.Cooper@veritas.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Wed Jan 6 10:20:54 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:07:15 2004 Subject: Namespaces hate validation! Message-ID: <01BE3965.CD8A0FD0@grappa.ito.tu-darmstadt.de> Murray Maloney wrote: > At 08:46 PM 1/5/99 -0500, Tim Bray wrote: > > >1. You have a DTD that contains elements from different namespaces > > and you know what the URIs are for those namespaces. > > Everything that follows this point is predicated on the > assumption that one can have such a DTD, but later Tim > makes it clear that it is not currently feasible to design > such a DTD. As Tim says, "we're nowhere near knowing the answer." I don't think Tim is saying that at all. Such a DTD is trivial to write. For example: Furthermore, it would not be difficult to design an editor that allowed people to combine DTDs. Such an editor would simply redefine elements as the user specified, writing the new element definitions to a new DTD and reusing the existing definitions. The only thing in Tim's algorithm that is currently unspecified is how to tell the preprocessor what the prefix-to-URL associations used by the DTD are. I think what Tim is saying is that it is non-trivial to automagically combine DTDs or in some sense to say that a given document validates against two or more different DTDs. As XML currently stands, this seems to be possible only through the liberal use of ANY in content models, which is a less-than-optimal solution. (I assume that the Contents=Open/Closed property in DCD is intended to address this further. When an element is declared as having open contents, it can contain child elements that are not declared in its content model. In other words, it allows schema designers to explicitly state where the content model can be altered/expanded. This is the same as ANY except #PCDATA is not allowed unless it was in the original content model. A further refinement would be to say that Contents=Open means that elements not declared in the current schema can occur as children. This would meet the needs of schema merging without allowing people to "violate" the cur rent schema.) > >5. You preprocess the DTD, rewriting all the element & attribute > > declarations with the appropriate prefixes > > Using special care to take into account the non-XML notion > of "global attributes". I don't understand this comment. Global attributes don't currently exist in XML, so how can a DTD even contain them? This comment makes sense only if you are using a schema language that supports global attributes, which doesn't apply in the case the algorithm addresses. > >6. You preprocess the instance, making all namespace prefixes > > explicit (no defaulting), declaring all the namespaces on the root > > element, and using the same set of prefixes you used in the DTD > > Of course, this will not work for instances that redeclare > a namespace prefix with a different URI for the purposes > of local scoping of namespaces. In that case, you have to > declare namespaces on elements as you go. And, since you > would have to inspect the entire document to determine > whether local scoping of namespaces has been applied, > you simply cannot count on Tim's algorithm for the general > case. If you are stating that the algorithm doesn't work, it does: Prefixes are mapped first to URIs, then to unique prefixes. Therefore, it doesn't matter if a prefix is reused in an instance -- at any given point in time, it maps to a unique URI, and thus to a unique prefix. If you are stating that the algorithm doesn't work because you have to inspect the entire document first, that's a circular argument. The algorithm clearly states that the document must be preprocessed, so you can't use that as an argument against it working. (Note that such preprocessing is necessary to use the algorithm with current parsers. This prefix substitution could be done at parse time by a specialized parser.) > > Well, tedious enough to make it unlikely that anyone will use > > validation on documents that utilize namespaces. It is hard. > > It is too hard. And for that reason, among others, Veo has > > vociferously opposed "Namespaces in XML". This might be true, although it is easy enough to write a tool that did the preprocessing necessary for this to work with the current batch of parsers. In the long run, these questions disappear anyway, as the current schema proposals can declare which namespace a given element or attribute belongs to, thus solving the problem of no namespace declarations in the DTD. > As a co-author of one of the schema submissions, I have to say > that I do not see how to integrate "Namespaces in XML" -- as > it is currently proposed -- with an XML Schema language. Perhaps > someone will show me the error of my ways in the fullness of time, > but I am skeptical. XSchema already does this. DCD almost does this, but is silent on how it associates namespace prefixes used in attribute values (such as the name of an element being declared) with URIs. The obvious solution to this -- to use namespace attributes -- is less than optimal. For example, the following would work: but isn't very user friendly. It would be better to allow the user to avoid prefixes altogether: Unfortunately, this isn't possible using namespace attributes, as it would require the user to declare the default namespace twice: In any case, it is certainly possible to integrate the current namespace proposal with a schema language, as XSchema shows. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Wed Jan 6 10:39:41 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:07:15 2004 Subject: XML-Data question Message-ID: <01BE3968.6E496B80@grappa.ito.tu-darmstadt.de> Andrew Layman wrote: > Jeffrey E. Sussna asked "Has any further work taken place on XML Data? (How) > does it relate to XSchema?" > > [answer to first question snipped] > > Regarding how XML-Data relates to XSchema, I have not worked actively with > XML schemas for about six months, so don't have the knowledge to answer that > question. XML Data is an ancestor of XSchema, as well as DCD and probably SOX. In my experience, code designed to use the basic parts of one schema language (element and attribute definitions, etc.) can be easily converted to use a different schema language. For example, I was able to quickly convert code that used XML-Data to use XSchema. This obviously becomes more difficult/impossible when the code exploits features of one schema language that don't occur in the other languages. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Wed Jan 6 12:45:42 1999 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:07:15 2004 Subject: Silfide XML Parser : VerifyError bug fixed Message-ID: <199901061244.NAA12081@chimay.loria.fr> Hi, I used to compile my java files with the JDK 1.1.7 compiler. For those of you who are running a Java Virtual Machine 1.2, you should have this kind of error message : java.lang.VerifyError: (class: fr/loria/xml/parser/ParserTokenManager, method: jjFillToken signature: ()Lfr/loria/xml/parser/Token;) Register 0 contains wrong type at fr.loria.xml.parser.XMLParser.(XMLParser.java) at fr.loria.xml.parser.XMLParser.(XMLParser.java) at fr.loria.xml.XDocument.load(XDocument.java) at fr.loria.xml.XDocument.load(XDocument.java) at fr.loria.xml.sax.SAXDriver.parse(SAXDriver.java) Exception in thread "main" It is because of the optimized java bytecode incompatibility between JDK 1.1.x and JDK 1.2. I have reported this bug to Sun developpers and their answer has been : "Do not use the option -O !". If you are using SXP with the JVM/JDK 1.2, you should download a new archive of the Java classes (without any bytecode optimization) from : http://www.loria.fr/projets/XSilfide/EN/sxp/download.html (with same version numbering) Sorry for all the inconvenience. Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jan 6 14:08:15 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:16 2004 Subject: Reserved names and documentation In-Reply-To: <3.0.32.19990105174446.00b8f480@pop.intergate.bc.ca> Message-ID: <199901061408.JAA15465@hesketh.net> At 05:46 PM 1/5/99 -0800, Tim Bray wrote: >There is at least an "XML Co-ordination" group whose job it is to worry >about such things. Simon is right that the picture is pretty complicated. I'd love to see a set of goals from the higher level group like the working groups below it have so successfully produced. Right now, the emperor himself is pretty invisible to the outside world. There's no broad statement of what the XML family of standards should look like when it reaches maturity (or puberty, even.) I think everyone on this list has their own, usually incompatible, vision of what XML should look like. A statement of what it will look like might give us something better to work with, introducing less complication in the long run. We've also got lots of specs and no clear order on how to process them. Do you parse the document first and validate it, then inspect it for links, then transform it, then format it? Or do you parse the document, transform it, validate it, inspect it for links, then format it? Or do you parse the document first and validate it, then transform it, then inspect it for links, then format it? And where would namespace processing fit in there, amongst the transformation (of the DTD?) or the validation? Yikes. Saying you can order these things any way you want is going to explode a lot of XML's interchangeability, damaging Paul Prescod's assertion that "[XML] is optimized for interchange, interchange and interchange." >>Namespace prefixes hate >>validation. > >[plausible but complex DTD transformation algorithm to accomodate >prefixes and namespaces] > >Thus, I have to reject Simon's contention that namespaces are >anti-validation. It is true that *compound documents* pose big >problems for document design in general and validation in >particular. Compound documents, it is painfully obvious, are >coming at us fast, and in high volume, so it behooves us to get >our act together on document design. Namespaces, for the nonce, >allow us to have compound documents without the elements falling >over each other. But in and of themselves, they don't particularly >impair validation. In and of themselves, they make validation far more difficult, requiring a transformation of DTDs for which there are no standard tools. Given that validation is built right into the parser in many implementations, it's kind of hard to slip in and fix the DTD after realizing that you've got a prefix change on your hands. Better parsers might be capable of doing this; I'd rather see layered processing, where one layer checks syntax, and another checks document structure. That way we could sneak in for DTD transformations and other weirdness. Unfortunately, there hasn't been a lot done in the XML 1.0 spec to accomodate or promote such a model. (The Lark/Larval implementation that Tim's built might allow such possibilities; I'll have to take a closer look.) I don't think too many people are actually going to try that algorithm, and namespaces are going to have to wait until schemas arrive that can handle them. (Schemas will also probably help with my layering issues described above.) >>XLink provides services that seem to overlap with entities, no >>matter how much some insist that the don't > >Yup. Who insists there's no overlap? Obviously, since XLink is >trying to be a general-purpose hypertext mechanism, and external >entities have an obvious hypertext semantic, it would be surprising >if there were no overlap. So much so that some have suggested that >once we have hyperlinks we don't need entities any more. >I doubt that, but it's a sane premise worth considering. But the >overlap doesn't feel dangerous to me; what should we be worried about? The overlap may not feel dangerous, but the very existence of an overlap does make people wonder - a lot. Having multiple ways to achieve similar goals using totally different syntax is usually not considered elegant. Elegance may not be a design goal for XML, but it certainly would help on the coherence issue. >>, and the PI used for style >>sheets provides yet another example of connecting resources using URLs. > >That's evidently an interim patch made necessary by the imminence >of the R5 XML-capable browsers... the right solution is a general-purpose >packaging mechanism so you can bundle up an instance with pointers to >(or direct inclusion of) the stylesheet(s) and schema(s) and scriptware >and so on. But that's going to take some real work to build. Glad to hear it's a temporary fix. I hope we don't see too many more of these temporary fixes. XLink should be able to help with this, when it finally arrives. >>CSS and XSL are mutually >>incompatible tools that do a lot of the same things. > >That's a real live problem all right; but at least everyone knows >it exists. -T. Everyone knows it exists, but it goes on... Coherence is important. XML has great potential, but it also has great potential to bury itself in complexity. (I think) David Megginson said a long time ago that XML would be doing well if every iteration of the spec was smaller and simpler. Unfortunately, that doesn't seem to be the direction XML is heading. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jan 6 14:43:48 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:16 2004 Subject: Regulating the XML Marketplace In-Reply-To: <199901061408.JAA15465@hesketh.net> References: <3.0.32.19990105174446.00b8f480@pop.intergate.bc.ca> <199901061408.JAA15465@hesketh.net> Message-ID: <13971.28990.313525.668125@localhost.localdomain> Simon St.Laurent writes: [about the highly secretive, smoke-filled XML Coordination group, aka The Syndicate] > I'd love to see a set of goals from the higher level group like the > working groups below it have so successfully produced. Right now, > the emperor himself is pretty invisible to the outside world. > There's no broad statement of what the XML family of standards > should look like when it reaches maturity (or puberty, even.) I > think everyone on this list has their own, usually incompatible, > vision of what XML should look like. A statement of what it will > look like might give us something better to work with, introducing > less complication in the long run. Actually, the problem is a little different. We all know what XML looks like -- it's described pretty clearly (modulo a few errata) in the XML 1.0 spec [1]. What we're waiting to find out is what applications that happen to use XML will look like. Somewhere out there, there's a yet-to-be-discovered magic dividing line between what the W3C should and shouldn't regulate -- clearly, core XML 1.0 syntax falls on the W3C side of the dividing line, and just as clearly, the source code for a specific XML parser falls on the other side. Beyond obvious cases, though, we have the classic problem of how to regulate a market without killing it. We could take the Old Labour/New Deal approach and nationalise everything, we could take the Margaret Thatcher approach and privatise everything, or we could try to be Tony Blairs and please/disappoint everyone a little without taking any firm positions. Right now, the W3C has decided (either formally or haphazardly) that the following are important enough, have general enough applicability, and/or fall well enough into the W3C's area of expertise that they should be regulated by the W3C itself (at least for now): - XML syntax, data model, schemas, etc. - standard linking and addressing facilities (XLink and XPointer) - standard stylesheet languages (CSS and XSL) - a standard XML format for metadata (RDF and specific initiatives built on top of it) - a standard XML format for browsers (HTML) - a standard tree-based API for use in browsers (DOM) On the other hand, the W3C has decided (either formally or haphazardly) that the following are not important enough, not general enough, or fall far enough outside of the W3C's area of expertise, that they should not be regulated by the W3C (at least not yet): - a standard event-based API (SAX) - specific XML document types for technical and academic documents (TEI, DocBook, etc.) - a standard XML format for e-commerce - a standard XML format for EDI - a standard XML format for database tables - a standard XML format for object serialisation For everything else, the W3C's first job is to decide where the line should be drawn, or, in other words, how much regulation is enough and how much is too much. In fact, the problem is probably unsolvable, but the discussion itself can be helpful All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jarle.stabell at dokpro.uio.no Wed Jan 6 15:06:00 1999 From: jarle.stabell at dokpro.uio.no (Jarle Stabell) Date: Mon Jun 7 17:07:16 2004 Subject: Reserved names and documentation Message-ID: <01BE398E.BD3B9350.jarle.stabell@dokpro.uio.no> Simon St.Laurent wrote (about entities and XLink overlap): > The overlap may not feel dangerous, but the very existence of an overlap > does make people wonder - a lot. Having multiple ways to achieve similar > goals using totally different syntax is usually not considered elegant. > Elegance may not be a design goal for XML, but it certainly would help on > the coherence issue. Personally I'd love to see entities disappear (except the "magic"/necessary ones), they make parsers harder to write (especially if one wants to make user-friendly tools (on syntax errors, the problematic text should be highlighted)). They also (AFAIK) ruin the "Desperate Perl Hacker" idea. I don't know how many parsers out there are able to do the following (via an application): 1. Load a document (with entities) 2. Operate on the document (via DOM). 3. Save it. *AND* keep the original entity structure intact? If one removed the entities and used DTD's with XML syntax, I think authoring tools would be much easier to implement, and probably easier to do the layering needed(?) for more conceptually advanced issues. Cheers, Jarle Stabell xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 15:49:30 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:16 2004 Subject: Reserved names and documentation References: <5BF896CAFE8DD111812400805F1991F708AAED20@RED-MSG-08> Message-ID: <369385CC.26B2BC17@locke.ccil.org> Andrew Layman wrote: > [I]f one wants to write a validatable document instance using > namespaces, one must use exactly the prefixes written in the DTD. And one must avoid exploiting local namespace scopes and default namespaces. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 16:13:22 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:16 2004 Subject: Namespaces hate validation! References: <3.0.1.32.19990105221336.00f603e4@pop.uunet.ca> Message-ID: <36938B7F.508D297E@locke.ccil.org> Murray Maloney wrote: > Everything that follows this point is predicated on the > assumption that one can have such a DTD, but later Tim > makes it clear that it is not currently feasible to design > such a DTD. Au contraire: we of DDML (formerly XSchema) *have* designed such a DTD. The DDML DTD uses two namespaces, DDML and IBTWSH (which latter does not use prefixes, in the name of HTML compatibility, but is a true namespace anyway). What we do not have is a *algorithmic* way of building such a DTD. I doubt we ever will, as *judgment* is required to decide when elements imported from other namespaces are to be allowed. Merging two DTDs intelligently is no easier (but no harder, IMHO) than designing content models in the first place: an "AI-complete" problem. > >5. You preprocess the DTD, rewriting all the element & attribute > > declarations with the appropriate prefixes > > Using special care to take into account the non-XML notion > of "global attributes". There is nothing particular about global attributes: from a purely XML 1.0 viewpoint, they are ordinary attributes that happen to have a ":" in their names. Their prefixes must be munged just like element prefixes. > >6. You preprocess the instance, making all namespace prefixes > > explicit (no defaulting), declaring all the namespaces on the root > > element, and using the same set of prefixes you used in the DTD > > Of course, this will not work for instances that redeclare > a namespace prefix with a different URI for the purposes > of local scoping of namespaces. In that case, you have to > declare namespaces on elements as you go. Not at all. With appropriate renamings of prefixes, you can move all nested prefixes out to the outermost element. For example: which uses two different namespaces with the prefix "foo", can be rewritten without loss of generality as: > [Y]ou would have to inspect the entire document to determine > whether local scoping of namespaces has been applied [...]. So you would. But nothing says Tim's algorithm can't be two-pass, as indeed it must be: one pass to scan for namespace declarations, and another pass to output the root element with all correctly munged declarations and then all elements and attributes with munged prefixes correctly applied. Given a tree API like the DOM, it is not necessary (though it may be preferable) to actually parse the instance twice. > Well, tedious enough to make it unlikely that anyone will use > validation on documents that utilize namespaces. It is hard. > It is too hard. It is hard until someone writes a tool to do it. I would do it now if I had an easy-to-use DTD analyzer in Java. > Murray Maloney, Esq. Phone: (905) 509-9120 > Muzmo Communication Inc. Fax: (905) 509-8637 > 671 Cowan Circle Email: murray@muzmo.com Hmm. Pity I can't list my address as "Maloney Square" for symmetry. :-) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed Jan 6 16:19:52 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:16 2004 Subject: Reserved names and documentation In-Reply-To: <369385CC.26B2BC17@locke.ccil.org> Message-ID: <000301be398f$df0b5140$d3228018@jabr.ne.mediaone.net> If this is indeed the case, as it appears to be, then namespaces have no real meaning outside of the xxx: prefix. namespaces become nothing more (or less :-) than a standard naming mechanism for tags. the namespace referenced urn is nothing more than an arbitrary statement of who is supposed to own the "xxx:" namespace prefix. the only solution (if one is needed) is to reserve use of ':' in element names and require conforming parsers to place elements in namespaces based upon [namespace]:[tagname] which would break the behavior of most current parsers. OTOH this would allow namespace prefix resolution to the specified urn. Jonathan Borden http://jabr.ne.mediaone.net > > > Andrew Layman wrote: > > > [I]f one wants to write a validatable document instance using > > namespaces, one must use exactly the prefixes written in the DTD. > > And one must avoid exploiting local namespace scopes and default > namespaces. > > -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RDaniel at DATAFUSION.net Wed Jan 6 16:52:41 1999 From: RDaniel at DATAFUSION.net (Ron Daniel) Date: Mon Jun 7 17:07:16 2004 Subject: Namespaces hate validation! Message-ID: <0D611E39F997D0119F9100A0C931315C2E0EC9@datafusionnt1> Murray Maloney said: > At 08:46 PM 1/5/99 -0500, Tim Bray wrote: > [Outline of Tim's procedure for validating in the presence of namespaces deleted] > >OK, this is a bit tedious but contains NO ROCKET SCIENCE. The > >syntactic problems of validating in the presence of namespaces are > >just not that hard. > > Well, tedious enough to make it unlikely that anyone will use > validation on documents that utilize namespaces. It is hard. > It is too hard. [Ron Daniel] Not all uses of namespaces are hard to validate. For example, assume I'm defining a file format and want to put Dublin Core descriptors in the header. I can keep the Dublin Core material in its own namespace. Developing such a DTD, and validating such files, is no harder if I use namespaces than if I don't. In fact, it may be slightly (but only slightly) easier since someone may have provided DTD fragments for the Dublin Core elements. It also enables other people's robots (if they are DC and namespace savvy) to harvest those files if they stumble across them. Now, I'm the first to admit that this is a LONG way from the dream of on-the-fly composition of compound documents. Its only an incremental step towards reuse. But it is a step. Ron Daniel Jr. DATAFUSION, Inc. 139 Townsend Street, Ste. 100 San Francisco, CA 94107 415.222.0100 fax 415.222.0150 rdaniel@datafusion.net http://www.datafusion.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jan 6 16:57:53 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:16 2004 Subject: Reserved names and documentation In-Reply-To: <000301be398f$df0b5140$d3228018@jabr.ne.mediaone.net> References: <369385CC.26B2BC17@locke.ccil.org> <000301be398f$df0b5140$d3228018@jabr.ne.mediaone.net> Message-ID: <13971.37748.173992.267730@localhost.localdomain> Borden, Jonathan writes: > If this is indeed the case, as it appears to be, then namespaces > have no real meaning outside of the xxx: prefix. namespaces become > nothing more (or less :-) than a standard naming mechanism for > tags. the namespace referenced urn is nothing more than an > arbitrary statement of who is supposed to own the "xxx:" namespace > prefix. Bingo! Or, to express it more generally, namespaces provide a convention for naming XML 1.0 elements and attributes in such a way that the names are globally-recognisable and globally-unique. This may seem like a small victory, but it enables me to do two things: 1. I can write code for handling a certain element type in *any* document, rather than just in documents of a specific type. If I know how to handle the element type http://www.w3.org/Profiles/voyager-strict a in HTML, then I know how to handle it in NITF as well. 2. I can allow other people to extend my document type without conflict, since their "name" element and my "name" element will be clearly distinguished. (Of course, I still need to establish handling rules: if I find an element type that I do not recognise, do I throw an error, skip the element and its descendants, or skip the element and process its descendants? In RDF, it's simple enough just to skip unknown properties, but in richer document types, that won't always work.) All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 6 17:11:03 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:16 2004 Subject: Reserved names and documentation References: <3.0.32.19990105174446.00b8f480@pop.intergate.bc.ca> Message-ID: <369399E9.A5A9A581@mecomnet.de> I posted a note back in December on the the related topic of "external dtd[s] and namespaces". (http://www.lists.ic.ac.uk/hypermail/xml-dev/9812/0276.html) The example shown there refutes the claim that namespaces (in themselves) places any restrictions on a processor's ability to validate a document. The only restriction, as noted by Mr Bray below (#1), is that the prefix - URI binding be known "within the dtd". In the example shown, I used (deprecated) processing instructions to this effect. In theory, it would be possible to do this entirely on the basis of declared default attribute values. I haven't (yet) implemented that. Tim Bray wrote: > [in response to the claim, that] > >Namespace prefixes hate > >validation. > > Those who've heard my argument on this subject can tune out now. > Here goes, again. Namespaces create two problems; an easy syntactic "namespaces" themselves create no problems. The difficulties arise with the limited prefix binding mechanism which the spec permits. The example shown in the cited note was the output of a processor which implments an algorithm similar to that which is described here. The algorithm is not original. It is that used in symbolic processing systems for decades to manage symbols. The problems discussed in this forum arise where one attempts to manages the qualified names as strings rather than as symbols. > problem, and a hard design problem. The syntactic problem is that > of validation, but there is a clean algorithmic solution: > > 1. You have a DTD that contains elements from different namespaces > and you know what the URIs are for those namespaces. As noted above, attribute defaults suffice for this purpose. If they are not available, then an alternative means of expression is necessary. A processing instruction suffices. There are issues about the scope / extent of such a binding, but those do not concern theoretical restrictions, just questions of interpretation. > 2. You have a document that has tags from different namespaces, and > you know what those namespaces are. This is specified in the proposed standard. > 3. You want to validate the document against the DTD. > 4. You make a list of all the namespace URIs that are in play via the > DTD. For each you generate a unique prefix. This is handled by creating named collections of symbols (known elsewhere as "packages") identifiying them "statically" with the uri and binding them "dynamically" to the respective prefix. Within the dtd, the scope of the prefix is not (yet) standardized, but there is no reason it couldn't be. The example shown is from a processor which establishes a dynamic binding within the doctype entity and within respective external entities, where the doctype comprises the external dtd. Other interpretations are possible. This scoping rule suffices, as it is both clear and effective. > 5. You preprocess the DTD, rewriting all the element & attribute > declarations with the appropriate prefixes This is handled by interning qualified names as symbols in the respective package. > 6. You preprocess the instance, making all namespace prefixes > explicit (no defaulting), declaring all the namespaces on the root > element, and using the same set of prefixes you used in the DTD This is handled the same was as 5. > 7. You validate Yes, and exactly as if there were no explicit qualifications. > > OK, this is a bit tedious but contains NO ROCKET SCIENCE. The It is neither rocket science, nor is it tedious. Lisp systems have been doing it for decades. > syntactic problems of validating in the presence of namespaces are > just not that hard. > > Now, on to the difficult problem: how do you go about making that > DTD I mentioned in step 1, that has the combined elements? Right now > we have little in the way of technology or automated procedures or even > industry experience to aid us in designing that compound DTD in a good, > clean, and efficient way. That's a hard problem and one that some > of the schema proposals are feeling toward a solution for. But we're > nowhere near knowing the answer. > This problem has two aspects. One is hard, but has nothing to do with namespaces. One does have to do with namespaces, but is neither hard, nor is one proceeding without "industry experience" when solving it in the context of document markup. The hard problem, that of combining element models, is independent of namespaces since it arises as a consequence of expressing relations (eg. "inheritance" or "subtyping") between element "types" and is independent of the presence of multiple namespaces. The problem which has to do with namespaces, that of establishing unambiguous names, is easy. (see above). xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 6 17:42:11 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:16 2004 Subject: Namespaces hate validation! References: <01BE3965.CD8A0FD0@grappa.ito.tu-darmstadt.de> Message-ID: <3693A135.9C0AD3AB@mecomnet.de> Ronald Bourret wrote: > ... > If you are stating that the algorithm doesn't work because you have to > inspect the entire document first, that's a circular argument. The > algorithm clearly states that the document must be preprocessed, so you > can't use that as an argument against it working. (Note that such > preprocessing is necessary to use the algorithm with current parsers. This > prefix substitution could be done at parse time by a specialized parser.) > this is the method used by the processor described earlier. (http://www.lists.ic.ac.uk/hypermail/xml-dev/9812/0276.html) > > > Well, tedious enough to make it unlikely that anyone will use > > > validation on documents that utilize namespaces. It is hard. > > > It is too hard. And for that reason, among others, Veo has > > > vociferously opposed "Namespaces in XML". > > This might be true, although it is easy enough to write a tool that did the > preprocessing necessary for this to work with the current batch of parsers. the trivial demonstration is the reserialization in the cited note. > In the long run, these questions disappear anyway, as the current schema > proposals can declare which namespace a given element or attribute belongs > to, thus solving the problem of no namespace declarations in the DTD. > schemas have many arguments in their favour, but are not strictly necessary in order to accomplish this. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 17:47:58 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:16 2004 Subject: Namespaces hate validation! References: Message-ID: <3693A198.30631C64@locke.ccil.org> In private mail, a correspondent asked me what DDML was. This is the new name for XSchema, just in case the XML Schema working group wants to use "XSchema" for their own product. It stands for Document Definition Markup Language. Also for Definitely Different Moisturizing Lotion (from Estee Lauder). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jan 6 18:05:13 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:16 2004 Subject: Namespaces hate validation! In-Reply-To: <01BE3965.CD8A0FD0@grappa.ito.tu-darmstadt.de> Message-ID: <3.0.1.32.19990106123952.00fd13c0@pop.uunet.ca> At 05:15 AM 1/6/99 -0500, Ronald Bourret wrote: >Murray Maloney wrote: > >> At 08:46 PM 1/5/99 -0500, Tim Bray wrote: >> >I think what Tim is saying is that it is non-trivial to automagically >combine DTDs or in some sense to say that a given document validates >against two or more different DTDs. As XML currently stands, this seems to >be possible only through the liberal use of ANY in content models, which is >a less-than-optimal solution. Easy enough to write a DTD that matches an instance. Just inspect the instance and generate a DTD that captures its models. The trick is to be able to write a DTD that encompasses a class of documents that might be validated by it. As I see it, Tim's algorithm is useful only if you are willing to write a new DTD for almost every document you get. > >(I assume that the Contents=Open/Closed property in DCD is intended to >address this further. When an element is declared as having open contents, >it can contain child elements that are not declared in its content model. > In other words, it allows schema designers to explicitly state where the >content model can be altered/expanded. This is the same as ANY except >#PCDATA is not allowed unless it was in the original content model. A >further refinement would be to say that Contents=Open means that elements >not declared in the current schema can occur as children. This would meet >the needs of schema merging without allowing people to "violate" the cur >rent schema.) Right. Well, content="open" tries to merge well-formedness with limited-validity. If that were an acceptable threshold for validity, then XML should have incorporated it. > >> >5. You preprocess the DTD, rewriting all the element & attribute >> > declarations with the appropriate prefixes >> >> Using special care to take into account the non-XML notion >> of "global attributes". > >I don't understand this comment. Global attributes don't currently exist >in XML, so how can a DTD even contain them? This comment makes sense only >if you are using a schema language that supports global attributes, which >doesn't apply in the case the algorithm addresses. Sorry, I was being facetious. Global attributes exist in "Namespaces in XML" but not in XML itself. Curious, no? My point is that "global attributes" as described in "Namespaces in XML" are a crock -- because there is no such thing as a global attribute "in XML". >> >6. You preprocess the instance, making all namespace prefixes >> > explicit (no defaulting), declaring all the namespaces on the root >> > element, and using the same set of prefixes you used in the DTD [...] >If you are stating that the algorithm doesn't work, it does: Prefixes are >mapped first to URIs, then to unique prefixes. Therefore, it doesn't >matter if a prefix is reused in an instance -- at any given point in time, >it maps to a unique URI, and thus to a unique prefix. Please re-read what Tim said: "...declaring all the namespaces on the root element" This assumes that all prefixes are unique. One cannot make such an assumption. Hence, this aspect at least does not work. >> > Well, tedious enough to make it unlikely that anyone will use >> > validation on documents that utilize namespaces. It is hard. >> > It is too hard. And for that reason, among others, Veo has >> > vociferously opposed "Namespaces in XML". > >This might be true, although it is easy enough to write a tool that did the >preprocessing necessary for this to work with the current batch of parsers. > In the long run, these questions disappear anyway, as the current schema >proposals can declare which namespace a given element or attribute belongs >to, thus solving the problem of no namespace declarations in the DTD. I dispute "easy enough". If that is true, then please show evidence. If someone would just send me the URL where I can find the listing of tools that automagically rewrites namespace-aware XML DTDs for me, then I will reconsider my opinion. :-{ I assert that those of us who consider such a tool easy to create are the ones who are least likely to actually write the tool. > >> As a co-author of one of the schema submissions, I have to say >> that I do not see how to integrate "Namespaces in XML" -- as >> it is currently proposed -- with an XML Schema language. Perhaps >> someone will show me the error of my ways in the fullness of time, >> but I am skeptical. > >XSchema already does this. Well, I just looked at XSchema again, and while it does include some facilities for namespace-awareness, it is not clear to me that it integrates "Namespaces in XML". In a fact, I have to challenge your assertion that XSchema integrates with "Namespaces in XML". Quoting from XSchema (4.3.2): The following XSchema structures cannot be converted to DTD structures because such structures do not exist: - More elements, AttDef and AttGroup elements that do not apply to a particular element, and Model and Enumeration elements nested directly beneath an XSchema element. - All id attributes, all attributes of the XSchema element except for prefix, all ns and ElementNS attributes, and the Root attribute of the ElementDecl element. - Nesting of schema information provided by nested XSchema elements. ------------ Please note that SOX also incorporates a namespace facility which encompasses elements, attributes, notations, entities, and processing instructions. Thus, it is not compatible with the "Namespaces in XML" proposal. > >DCD almost does this, but is silent on how it associates namespace prefixes >used in attribute values (such as the name of an element being declared) >with URIs. [...] So, DCD does not integrate with "Namespaces in XML". >In any case, it is certainly possible to integrate the current namespace >proposal with a schema language, as XSchema shows. XSchema shows no such thing as section 4.3.2 makes clear. Regards, Murray Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jan 6 18:05:40 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:17 2004 Subject: Namespaces hate validation! In-Reply-To: <36938B7F.508D297E@locke.ccil.org> References: <3.0.1.32.19990105221336.00f603e4@pop.uunet.ca> Message-ID: <3.0.1.32.19990106130340.00ff0574@pop.uunet.ca> At 11:12 AM 1/6/99 -0500, John Cowan wrote: >Murray Maloney wrote: > >> Everything that follows this point is predicated on the >> assumption that one can have such a DTD, but later Tim >> makes it clear that it is not currently feasible to design >> such a DTD. > >Au contraire: we of DDML (formerly XSchema) *have* designed such >a DTD. The DDML DTD uses two namespaces, DDML and IBTWSH (which >latter does not use prefixes, in the name of HTML compatibility, >but is a true namespace anyway). On what basis can you claim that IBTWSH is a *true namespace* while also stating that it does not use prefixes AND asserting that it is compatible with "Namespaces in XML"? Anyway, I was not saying that it is impossible to design a DTD that uses colons in the names of its elements and attributes. >What we do not have is a *algorithmic* way of building such a >DTD. I doubt we ever will, as *judgment* is required to decide >when elements imported from other namespaces are to be allowed. >Merging two DTDs intelligently is no easier (but no harder, IMHO) than >designing content models in the first place: an "AI-complete" problem. Well, based on my own experience and discussions with some of the world's most prolific and well-respected DTD designers, I have to say that it is a lot harder to design a DTD that combines two DTDs, especially if you are compelled to use "Namespaces in XML". Hopefully, one or more of my colleagues will amplify. >> >5. You preprocess the DTD, rewriting all the element & attribute >> > declarations with the appropriate prefixes >> >> Using special care to take into account the non-XML notion >> of "global attributes". > >There is nothing particular about global attributes: from a >purely XML 1.0 viewpoint, they are ordinary attributes that happen >to have a ":" in their names. Their prefixes must be munged >just like element prefixes. Too true. The point is that there is no such thing in XML as a "global attribute". Therefore, there should not be "global attributes" in "Namespaces in XML". But, to the extent that a global attribute can exist in an XML document -- according to "Namespaces in XML" -- Tim's algorithm should deal with them somehow. In other words, the algorithm is not complete in this respect (and others). >> >6. You preprocess the instance, making all namespace prefixes >> > explicit (no defaulting), declaring all the namespaces on the root >> > element, and using the same set of prefixes you used in the DTD >> >> Of course, this will not work for instances that redeclare >> a namespace prefix with a different URI for the purposes >> of local scoping of namespaces. In that case, you have to >> declare namespaces on elements as you go. > >Not at all. With appropriate renamings of prefixes, you can move >all nested prefixes out to the outermost element. Ok, so we never actually validate the received document instance. Instead, we end up validating a derived document. > >> [Y]ou would have to inspect the entire document to determine >> whether local scoping of namespaces has been applied [...]. > >So you would. But nothing says Tim's algorithm can't be two-pass, >as indeed it must be: one pass to scan for namespace declarations, >and another pass to output the root element with all correctly >munged declarations and then all elements and attributes with >munged prefixes correctly applied. Given a tree API like the >DOM, it is not necessary (though it may be preferable) to actually >parse the instance twice. So, I have to run several processes on the document that I am trying to validate before I actually get to test it against a DTD? And these processes, presumably, are guaranteed to produce a DTD against which the instance is valid, right? So I am never going to encounter a document that isn't valid -- ultimately -- within this process? What is the point in that? >> Well, tedious enough to make it unlikely that anyone will use >> validation on documents that utilize namespaces. It is hard. >> It is too hard. > >It is hard until someone writes a tool to do it. I would do it >now if I had an easy-to-use DTD analyzer in Java. So, perhaps we should not design facilities for which it is so hard to write tools -- especially when those facilities break compatibility with XML validity. Regards, Murray xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 18:27:07 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:17 2004 Subject: Namespaces hate validation! References: <3.0.1.32.19990105221336.00f603e4@pop.uunet.ca> <3.0.1.32.19990106130340.00ff0574@pop.uunet.ca> Message-ID: <3693AAD7.7220953C@locke.ccil.org> Murray Maloney wrote: > On what basis can you claim that IBTWSH is a *true namespace* > while also stating that it does not use prefixes AND asserting > that it is compatible with "Namespaces in XML"? By convention, the IBTWSH parts of documents use the namespace-default mechanism so that IBTWSH document fragments can be passed straight to HTML renderers. This is accomplished by giving the IBTWSH container element (whose element type depends on the enclosing DTD) an "xmlns" attribute with value "". > Well, based on my own experience and discussions with some of > the world's most prolific and well-respected DTD designers, > I have to say that it is a lot harder to design a DTD that > combines two DTDs, especially if you are compelled to use > "Namespaces in XML". So you think using a variant of the CALS table model in HTML, or the HTML 4.0 table model in xmlspec, made things harder, not easier, for the designer of those DTDs? > Too true. The point is that there is no such thing in XML > as a "global attribute". Therefore, there should not be > "global attributes" in "Namespaces in XML". Your reasoning is bad. 'There is no such thing as a namespace in XML 1.0; therefore there should be no namespaces in "Namespaces in XML"' would be equivalent. Global attributes are a conventional use of the legal character ":" in attribute names, that's all. > Tim's algorithm should > deal with them somehow. In other words, the algorithm is > not complete in this respect (and others). Tim's algorithm does deal with them. Prefixes on global attributes are handled just like prefixes on elements. It's the *absence* of a prefix that's handled differently for elements and attributes: for elements, an absent prefix means "use the current URI mapped to the null prefix"; for attributes, it means "use the URI of the current element". > Ok, so we never actually validate the received document instance. > Instead, we end up validating a derived document. Just so. We preprocess the DTD of the namespaced document, and we preprocess the instance, to create a derived DTD and a derived instance for which ordinary SGML/XML validation will work. (We also need some outside information to give us the prefix-to-URI map for the DTD.) I don't say this is clean, and I protested against it mightily. But it does *work*. > So, I have to run several processes on the document that > I am trying to validate before I actually get to test it > against a DTD? Well, one process on the document and another on the DTD. > And these processes, presumably, are guaranteed > to produce a DTD against which the instance is valid, right? Not at all. DTD conversion does not look at the instance, and instance conversion does not look at the DTD. The two derived entities are not joined together until the final (ordinary) validation is done, which may succeed or fail. The only thing necessary is to make sure that the two processes generate the same unique prefixes. This could be done, e.g., by generating a CRC of the URI, converting to hex, and using *that* as the prefix. The original prefixes appearing in the document are *ex hypothesi* worth nothing. > So I am never going to encounter a document that isn't valid > -- ultimately -- within this process? Not so. The final validation may fail for the same reasons any validation may fail. > What's the point of that? For one thing, a namespace-aware processor, given the derived instance, will treat it exactly as it would treat the original instance, provided that the processor does not depend on the presence or absence of "xmlns:*" or "xmlns" attributes in particular elements. IOW, the element types and attribute names will be resolved to the same (URI, localname) pairs. > So, perhaps we should not design facilities for which it is > so hard to write tools -- especially when those facilities > break compatibility with XML validity. It's not so hard; it's just that code to parse DTDs is currently embedded in full XML parsers, and I would like it to be broken out so that I can get access to DTD information. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamsden at us.ibm.com Wed Jan 6 18:30:10 1999 From: jamsden at us.ibm.com (jamsden@us.ibm.com) Date: Mon Jun 7 17:07:17 2004 Subject: Compound DTDs Message-ID: <852566F1.00656081.00@d54mta03.raleigh.ibm.com> Perhaps XSL style sheets can play a role in combining XML documents having similar semantics but different tag names and structure. Consider for example two XML documents that describe something about a particular e-business segment, but use a different DTD. One could write an XSL style sheet that translated each of these documents into a third document that contained the desired elements from both expressed in perhaps some new structure. The style sheet could change element and attribute names, restructure or re-order content, etc. Something similar could be applied to DTDs if they used XML syntax. Then style sheets could be used to handle the namespace problem as well as to merge the definitions from multiple DTDs into some new, composite DTD. This could remove some of the barriers that prevent common document languages from being developed, or allowing unavoidable variability between document languages in business segments. For example, a document language for health care might be used by the insurance industry in a manner quite different than it was originally intended. To require the developers of the health care document language to consider the requirements of other, future stakeholders may inhibit the development of a document language they can immediately leverage. By allowing variability and using XSL to translate documents to meet current needs, document language developers gain freedom and flexibility that comes from keeping things independent and separate, while document reuse is still enabled. These translator style sheets could be published as adjuncts to document languages to convert them to other document languages. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Jan 6 18:52:18 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:17 2004 Subject: Namespaces hate validation! Message-ID: <3.0.32.19990106105039.00a87e20@pop.intergate.bc.ca> At 12:39 PM 1/6/99 -0500, Murray Maloney wrote: >Easy enough to write a DTD that matches an instance. Just inspect >the instance and generate a DTD that captures its models. >The trick is to be able to write a DTD that encompasses >a class of documents that might be validated by it. Exactly. Of course, in historical practice, we kind of did this with well-known external entities such as %ISOLat1; and CALS tables and so on - this had two big problems: first, there was no way to ensure avoidance of name collisions, and second, there was no generally agreed upon way of resolving the PUBLIC identifiers. Namespaces would allow creation of a solution that would avoid both those problems. >As I see it, Tim's algorithm is useful only if you are >willing to write a new DTD for almost every document you get. Huh? Once you've written your compound DTD, the idea is that the algorithm uses it to validate documents that may or may not conform to it. Once the hard part - writing the compound DTD - is done, the algorithm does the rest, hands-off. >Right. Well, content="open" tries to merge well-formedness >with limited-validity. If that were an acceptable threshold >for validity, then XML should have incorporated it. No, because it's a new idea, and XML 1.0 was trying to crystallize practice that had been shown to work. Now we're trying to deal with the new problems of compound documents. >>I don't understand this comment. Global attributes don't currently exist >>in XML, so how can a DTD even contain them? This comment makes sense only >>if you are using a schema language that supports global attributes, which >>doesn't apply in the case the algorithm addresses. The algorithm does *not* depend on the concept of global attributes. The namespace draft introduces the concept, in a non-normative appendix, simply as a device to aid in explaining the mapping of element types and attribute names to URIs. >Global attributes exist in "Namespaces in XML" but not in XML itself. >Curious, no? My point is that "global attributes" as described in >"Namespaces in XML" are a crock -- because there is no such thing as >a global attribute "in XML". I'm missing your point. Yes, XML lacks global attributes. Why does this make the use of the term, as an explanatory device in a non-normative appendix, a crock? >Please re-read what Tim said: "...declaring all the namespaces on >the root element" Obviously my explanation wasn't simple enough. Suppose your instance contains all sorts of namespace defaulting. Suppose it also has a namespace URI "A" mapped to two different prefixes in different parts of the document, and suppose further it has a namespace URI "B" mapped, in a different part of the document, to one of the same prefixes that is used elsewhere for "A". All these cause validation problems. The algorithm goes through the document, builds a table, for every element & attribute, of its namespace (if any applies), makes one unique prefix for each URI that is used anywhere, inserts declarations for all those prefixes on the root element, than for each element and attribute that's in a namespace, puts the appropriate prefix on it. No more defaulting, the same namespace/prefix mappings used everywhere, everything explicit. Now you can validate. Sorry for not connecting the dots. Murray, this does work. >This assumes that all prefixes are unique. One cannot make such >an assumption. Hence, this aspect at least does not work. Yes, you can, after you've rewritten them. >I dispute "easy enough". If that is true, then please show evidence. >If someone would just send me the URL where I can find the listing >of tools that automagically rewrites namespace-aware XML DTDs for me, >then I will reconsider my opinion. :-{ Yep, while it's not conceptually hard, it's kinda practically hard right now because, as John Cowan et al point out, the existing XML processors tend not to expose the DTD structures enough to provide the info that you need (even though it's there in the document). >>> As a co-author of one of the schema submissions, I have to say >>> that I do not see how to integrate "Namespaces in XML" -- as >>> it is currently proposed -- with an XML Schema language. DCD was certainly 100% explicitly namespace-aware, and had facilities for including foreign-namespace elements in content models and attribute lists. You may disagree with aspects of that design, but a flat statement of "I do not see how to integrate namespaces with schemas" is not useful. >So, DCD does not integrate with "Namespaces in XML". DCD has one missing piece: the syntax for prefix/URI mapping. That was deliberate, because that ball was still in play when DCD was being written. This is not a credible technical objection. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 19:10:14 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:17 2004 Subject: Namespaces hate validation! References: <3.0.32.19990106105039.00a87e20@pop.intergate.bc.ca> Message-ID: <3693B4F9.A0A2E065@locke.ccil.org> Tim Bray wrote: [detailed description of instance algorithm snipped] > Now you can validate. > Sorry for not connecting the dots. Murray, this does work. Not quite. You must also rewrite the (compound) DTD to use the same prefixes as the rewritten instance, and you must have an oracle which can tell you how the prefixes in the DTD map to URIs, since the Namespaces PR does not tell you how to learn that. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 20:28:01 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:17 2004 Subject: Namespaces hate validation! References: <199901061954.LAA04234@mehitabel.eng.sun.com> Message-ID: <3693C735.AF25671@locke.ccil.org> Murray Altheim wrote: > Only on document instances that are already valid. If the instance is well-formed and namespace-compliant, then Tim's algorithm will work whether the instance is valid or not. > You complain about > Murray's faulty logic, but this whole concept of 'preprocessing' an > instance is so unclean as to be unusable. The whole reason for doing > validation is to determine that it's safe to perform processing. Safe to perform processing of certain kinds. Some processing requires only WFness, some requires validation, some requires validation and then further correctness checking. In this case, it is safe to change the prefixes on documents and move namespace-declaring attributes to the root element as long as the document is WF and namespace-correct. Indeed, the resulting instance is namespace-equivalent, in the sense that a namespace-aware processor that doesn't look at namespace declarations directly will not know the difference. > You > can't begin processing before you perform processing unless you've > already done some processing to determine that the processing you're > planning to do is going to be safe processing. True. > In other words, you can't > work on the derived product of an invalid instance. False. The instance can be invalid and still be processable by processes that expect only WFness, as is the case here. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 21:00:41 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:17 2004 Subject: Namespaces hate validation! References: <199901062048.MAA04257@mehitabel.eng.sun.com> Message-ID: <3693CEE4.173BAB0C@locke.ccil.org> Murray Altheim wrote: > The problem here is that documents that use multiple namespaces may not > be well-formed due to name clashes that might not occur otherwise if the > namespace prefixes were added [...]. I'm sorry, but this is incomprehensible to me. Can you give an example of what you mean? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 21:03:23 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:17 2004 Subject: Namespaces hate validation! References: <199901062048.MAA04257@mehitabel.eng.sun.com> Message-ID: <3693CF3A.4020B7C2@locke.ccil.org> A private correspondent has pointed out that my reference to CALS tables as the source of HTML tables is in error. I meant to refer to the IETF table model. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jan 6 21:54:06 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:17 2004 Subject: Reserved names and documentation Message-ID: <5BF896CAFE8DD111812400805F1991F708AAED26@RED-MSG-08> John Cowan wrote "And one must avoid exploiting local namespace scopes and default namespaces." John makes a good point about avoiding local scopes. Default namespaces are not a problem per se, however, since, in effect, the absence of a prefix is just like a specific prefix. The gist of John's comment is accurate, though: don't use local scopes, either for explicit or default prefixes. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jan 6 22:03:28 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:17 2004 Subject: Reserved names and documentation Message-ID: <5BF896CAFE8DD111812400805F1991F708AAED28@RED-MSG-08> Jonathan's statement below is an understandable error. My original mail was sent replying to a claim that namespaces and validation were incompatible. I pointed out that the two were perfectly compatible in principle, and that any limitations one might see are limitations of current DTD expressiveness. I then went on to mention that one could write an instance validatable against a current DTD using an unmodified, namespace-oblivious processor, but that you would have to recognize certain restrictions. Lacking that context, one might read the lines quoted from me at the end and conclude (wrongly) that those restrictions were intrinsic to namespaces. They are not. They are merely limits of the current state of DTDs. Others have pointed out either (a) algorithms for validating by modifying DTDs or (b) new forms of schema other than DTD that are capable--today--of supporting both validation and namespaces, with full flexibility. I hope this clears things up, Andrew -----Original Message----- From: Borden, Jonathan [mailto:jborden@mediaone.net] Sent: Wednesday, January 06, 1999 8:16 AM To: XML Dev Subject: RE: Reserved names and documentation If this is indeed the case, as it appears to be, then namespaces have no real meaning outside of the xxx: prefix. namespaces become nothing more (or less :-) than a standard naming mechanism for tags. the namespace referenced urn is nothing more than an arbitrary statement of who is supposed to own the "xxx:" namespace prefix. the only solution (if one is needed) is to reserve use of ':' in element names and require conforming parsers to place elements in namespaces based upon [namespace]:[tagname] which would break the behavior of most current parsers. OTOH this would allow namespace prefix resolution to the specified urn. Jonathan Borden http://jabr.ne.mediaone.net > > > Andrew Layman wrote: > > > [I]f one wants to write a validatable document instance using > > namespaces, one must use exactly the prefixes written in the DTD. > > And one must avoid exploiting local namespace scopes and default > namespaces. > > -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jan 6 22:08:58 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:17 2004 Subject: Compound DTDs Message-ID: <5BF896CAFE8DD111812400805F1991F708AAED29@RED-MSG-08> If I understand this, the author is saying that the kinds of mappings achievable with architectural forms can also be achieved with XSL. Is that correct? -----Original Message----- From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] Sent: Wednesday, January 06, 1999 7:21 AM To: Tim Bray Cc: xml-dev@ic.ac.uk Subject: Compound DTDs Perhaps XSL style sheets can play a role in combining XML documents having similar semantics but different tag names and structure. Consider for example two XML documents that describe something about a particular e-business segment, but use a different DTD. One could write an XSL style sheet that translated each of these documents into a third document that contained the desired elements from both expressed in perhaps some new structure. The style sheet could change element and attribute names, restructure or re-order content, etc. Something similar could be applied to DTDs if they used XML syntax. Then style sheets could be used to handle the namespace problem as well as to merge the definitions from multiple DTDs into some new, composite DTD. This could remove some of the barriers that prevent common document languages from being developed, or allowing unavoidable variability between document languages in business segments. For example, a document language for health care might be used by the insurance industry in a manner quite different than it was originally intended. To require the developers of the health care document language to consider the requirements of other, future stakeholders may inhibit the development of a document language they can immediately leverage. By allowing variability and using XSL to translate documents to meet current needs, document language developers gain freedom and flexibility that comes from keeping things independent and separate, while document reuse is still enabled. These translator style sheets could be published as adjuncts to document languages to convert them to other document languages. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jan 6 22:09:13 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:17 2004 Subject: Namespaces hate validation! In-Reply-To: <3.0.32.19990106105039.00a87e20@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990106170913.006e3fc4@pop.uunet.ca> At 01:51 PM 1/6/99 -0500, Tim Bray wrote: >At 12:39 PM 1/6/99 -0500, Murray Maloney wrote: >>Easy enough to write a DTD that matches an instance. Just inspect >>the instance and generate a DTD that captures its models. >>The trick is to be able to write a DTD that encompasses >>a class of documents that might be validated by it. > >Exactly. Of course, in historical practice, we kind of did this >with well-known external entities such as %ISOLat1; and CALS tables >and so on - this had two big problems: first, there was no way to >ensure avoidance of name collisions, and second, there was no >generally agreed upon way of resolving the PUBLIC identifiers. >Namespaces would allow creation of a solution that would avoid both >those problems. Two big problems. Problem 2. Well, I don't understand your point about the PUBLIC ids because XML relies on SYSTEM ids and not on PUBLIC ids. Besides, the SGML Open catalog specification handles PUBLIC ids. Problem 1. Name collision. We agree that this can be ameliorated by using prefixes. This introduces new big problems. Prefixes do not exist in flat "Namespace in XML" documents. That is, the namespace of an element or attribute may be the current default namespace, and any element can establish the default. Furthermore, the binding of a namespace prefix to URI can be locally scoped. Thus validation depends on the existence of a namespace-aware processor that can rewrite an XML document as an equivalent document with all namespaces declared on the root element and with no use of default namespaces or local scoping of prefixes. And, that processor is undefined and unimplemented. "Namespaces in XML" does not clearly define the relationship between itself and XML 1.0 validity. In technical specs, where one measure of friendliness toward a given topic is the sufficiency of coverage, I have to say that the absence of a clear definition of this relationship is tantamount to hate. ------------- >... Once you've written your compound DTD, the idea is that >the algorithm uses it to validate documents that may or may >not conform to it. Once the hard part - writing the compound >DTD - is done, the algorithm does the rest, hands-off. This I have to see. And when I see it, I may come to believe. But in the meantime, my skepticism is at perigee. Oh, by the way, what do you do about any entities you encounter? I mean, when I combine an HTML DTD with a graveyard DTD, how do I avoid name collision between general text entities? agrave, egrave, igrave, ograve, ugrave Now I assume that you will tell me that there is a *simple* algorithm for transforming the DTD and/or the instance to deal with name collisions. ------------- >DCD was certainly 100% explicitly namespace-aware, and had >facilities for including foreign-namespace elements in >content models and attribute lists. You may disagree with >aspects of that design, but a flat statement of "I do not see >how to integrate namespaces with schemas" is not useful. While I do disagree with certain aspects of the design of DCD, it is also true that SOX was informed by many of the other schema languages (DCD, XML-Data, XSchema, EXPRESS, XML DTDs). So, if I give the impression that I completely dislike DCD, please accept my apology. What I actually said was: >As a co-author of one of the schema submissions, I have to say >that I do not see how to integrate "Namespaces in XML" -- as >it is currently proposed -- with an XML Schema language. Perhaps >someone will show me the error of my ways in the fullness of time, >but I am skeptical. That statement was useful if only to encourage you and others to "show me the error of my ways." But so far I am not seeing thing much different. I do acknowledge that it is theoretically (and maybe even practically) possible to create processors that prepare a namespace-aware XML document for validation. But I have serious doubts about when such a processor will be standardized. I believe strongly in the "no harm, no foul" principle. That is, so long as a design characteristic or feature causes no harm to any other part of the system, then there is no reason to cry "Foul!". I find that the proposed "Namespaces in XML" is harmful to validation because it establishes a dependency on an un-defined, un-developed and non-standard class of XML processor. And it is harmful to XML schema languages by denying the use of name collision facilities for entities, notations and processing instructions. > >>So, DCD does not integrate with "Namespaces in XML". > >DCD has one missing piece: the syntax for prefix/URI mapping. That >was deliberate, because that ball was still in play when DCD was >being written. This is not a credible technical objection. -Tim Huh? Even XML DTDs can use prefixes without any help at all. Any schema language that does not have prefix/URI mapping, would seem to be incomplete with respect to "Namespaces in XML". The point is, there is not a single schema language in play that fully addresses its relationship to "Namespaces in XML". There are all kinds of questions that remain either unanswered or untried. Regards, Murray Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 22:23:33 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:17 2004 Subject: Compound DTDs References: <5BF896CAFE8DD111812400805F1991F708AAED29@RED-MSG-08> Message-ID: <3693E247.421D8116@locke.ccil.org> Andrew Layman wrote: > If I understand this, the author is saying that the kinds of mappings > achievable with architectural forms can also be achieved with XSL. Is that > correct? Tentatively yes. I have not made an exhaustive comparison, but I believe that an XSL stylesheet can do everything XAF at least can do (which is a subset of full architectural forms processing, notably because XAF has no concept of an architectural DTD). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 6 22:33:53 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:18 2004 Subject: Namespaces hate validation! References: <3.0.1.32.19990106170913.006e3fc4@pop.uunet.ca> Message-ID: <3693E4AF.6150DF16@locke.ccil.org> Murray Maloney wrote: > Thus validation depends on the existence of a namespace-aware > processor that can rewrite an XML document as an equivalent > document with all namespaces declared on the root element > and with no use of default namespaces or local scoping > of prefixes. > > And, that processor is undefined and unimplemented. I suppose eventually someone will have to MOV MOUTH, MONEY. But not me, not yet. > Oh, by the way, what do you do about any entities you encounter? > I mean, when I combine an HTML DTD with a graveyard DTD, > how do I avoid name collision between general text entities? > > agrave, egrave, igrave, ograve, ugrave > > Now I assume that you will tell me that there is a *simple* > algorithm for transforming the DTD and/or the instance to > deal with name collisions. Now don't mix up two different issues! There is *no* algorithm, and nobody claims there is, for merging DTDs automatically! Tim thinks one will eventually be found, about which *I* am deeply skeptical. The claim being made here is: Given: 1) a mixed-namespace DTD, and 2) a mixed-namespace instance (which is WF and namespace-compliant) that purports to conform to it, and 3) a source of information about the prefix-to-URI map(s) being used in the DTD, it is possible by preprocessing 1) the DTD (without the instance, and 2) the instance (without the DTD) to produce a modified (DTD, instance) pair which will validate using an ordinary XML validator if and only if the original (DTD, instance) pair would validate using a (nonexistent) namespace-aware validator, and the resulting modified instance will be namespace-equivalent to the original instance. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jan 6 23:26:04 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:18 2004 Subject: Architectural forms References: <5BF896CAFE8DD111812400805F1991F708AAED29@RED-MSG-08> Message-ID: <3693EC1F.CDE34C42@prescod.net> Andrew Layman wrote: > > If I understand this, the author is saying that the kinds of mappings > achievable with architectural forms can also be achieved with XSL. Is that > correct? This is more or less correct. XSL cannot implement the architectural form mechanism, but I believe that anything you would want to do with archforms could also be done with XSL -- for a particular DTD/archform pair. It would be nice if an XSL stylesheet *could* do XAF-level generic architectural form processing. Note, however, that architectural forms are completely declarative and can be implemented in a highly optimized fashion. The sorts of extensions that Microsoft has proposed for XSL (...) would completely destroy those features. Architectural mapping would, in general, be as reliable and high performance as ordinary software -- (not at all). Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Jan 7 01:03:43 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:07:18 2004 Subject: Why XML Over the Relational Model? References: <000301be385e$84845960$8636bfa8@arabbit> <3691B0A5.D6A53EE2@prescod.net> <36926A82.BC1AA4D4@locke.ccil.org> <36928729.D7849EB7@prescod.net> Message-ID: <36940751.C81@hiwaay.net> Paul Prescod wrote: > > Good point. Interchange across the time dimension is very important. > People who use a relational or object database for their day-to-day work > should definitely consider backing up a periodic XML dump, just as people > who use XML day-to-day should consider how those other tools can help to > make it updatable, retrievable, searchable, etc. Excellent thread. Excellent. All said then, we have pretty much the same answers we had in CALS: o Better interchange o Better lifecycle maintenance o Closer modeling to some real world structures such as *classical* hierarchical documents o Flexible modeling for non-classical structures (if there are any) o Ability to combine approaches both in the model and in the implementation I agree with all that has been said. During the SGML period, we eventually wrote that hybrid systems for enterprises were idea because of the way people tended to capture certain kinds of information (they like to write in topical based, top forward ways) and because we could keep on using these instead of asking authors to view the worlds as Forms. There were also the advantages that where authoring systems used DTDs to parameterize the user interface, it was very easy to *guide* authoring processes toward required content types, and it was very easy to read the file and determine what was intended (tough to do with a table that spans more than a page as anyone who has seen a dump of a relationally implemented version of MIL-D-87269 can attest to). The markup model using a DTD is a nice middle of the road/practically anyone can learn to write one schema. Relational modeling is certainly tighter given normalization, but it takes more effort. Those who do both (markup and relational modeling) probably do both better as a result. What I like about the tone of the answers to my question: 1. Developers do understand the issues and do understand that the underlying implementation affects most of the benefits, that is, benefits of OOP vs file. 2. Developers do understand the "horses for courses" approach and don't see everything in terms of XML. 3. Developers do understand the benefits of the lifecycle that markup can improve and do understand that exchange is a major plus. Good. Now, one additional benefit of markup as with any system that can use a schema is that the schema/DTD can be viewed as a contract/standard for information usage. Seeing the other thread about architectural forms, we should lookat the role of the schema/DTD in standards processes and artifacts. Many of us have done this and it isn't very hard to see the benefits. However, the introduction of architectural forms to SGML was never completed in the sense that the community applied them or became comfortable with them. Now that there will be alternative schema and design-DTDs such as SOX, we should consider these in terms of standards making. For example, the VRML NG effort is underway and there is a work item for creating a set of XML tags. I have brought this up before but I think it bears repeating. VRML 97 can be seen as a two layer specification. The first layer is node based and defines the properties of the entities as node properties. The second layer deals with the grammar as delivered (aka, the file format). I think it possible that the upper layer could be considered an architecture. If so, then isn't it possible to create standards from which other standards are derived by specifying, in this case, the property set as an architecture for Web3D applications from which the XML tag sets are derived? Therefore, 3DML, Chrome, etc. could have different tag sets, but be derived from the same architecture and therefore be playable in a compliant engine? However, looking at SOX, XML-DATA, etc and being reminded of the work done on the object-oriented MID version, I think it also possible that the same result could be achieved by these means as well given that in the end what is being considered is the fundamental property set which any application of the type must include. Given this, what approach is best for the making and maintenance of the standard? Note I am not asking about implementation, but in the context of creating and maintaining a standard over its lifecycle. Yes? No? Comments? len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbona18 at campus.mor.itesm.mx Thu Jan 7 05:23:41 1999 From: cbona18 at campus.mor.itesm.mx (Ing. Cesar Bonavides M.) Date: Mon Jun 7 17:07:18 2004 Subject: Just a doubt... In-Reply-To: Message-ID: Hi there! I'm new on all this SGML/XML stuff. I've been reading about XML but once I heard about XML-data. What's that?, what's better to learn, or is it exactly as plain XML?. As you can see I'm in a trouble, 'cause I've been reading a lot, but there's a lot of information, and sometimes I don't know where to start. To make it simple: I already read the XML, XLink, XPointer and XSL stuff, but that thing about XML-data and XML-schemas really did confuse me. Thanx in advance. (hope you understood my english) Cesar xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Thu Jan 7 06:08:41 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:07:18 2004 Subject: Compound DTDs References: <852566F1.00656081.00@d54mta03.raleigh.ibm.com> Message-ID: <36945D46.41420B87@allette.com.au> I feel that I must be missing something in this, but could someone explain how or whether compound documents can nest? When a fragment is embedded and a new DTD is created to support the structure, wouldn't the namespace of the document then refer to the newly created compound DTD? If so, you can't then embed the compound document into another document, can you? If you did, wouldn't you need to obtain the DTD that was used to create the fragment that was embedded in the first level of compounding? -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Thu Jan 7 09:39:35 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:07:18 2004 Subject: Just a doubt... Message-ID: <01BE3A29.2F6F8360@grappa.ito.tu-darmstadt.de> Cesar Bonavides M. wrote: > To make it simple: > I already read the XML, XLink, XPointer and XSL stuff, but that thing > about XML-data and XML-schemas really did confuse me. Currently, the legal format of an XML file is defined in a DTD. For example, the following DTD defines XML documents in which a Memo element contains one or more Paragraph elements and a Paragraph element contains parsed character data: XML schema languages are an attempt to replace DTDs. That is, they are XML languages used to defined other XML languages. For example, the DTD shown above can be defined in XML-Data as: There are two main reasons to do this. The first reason is that DTDs are restricted by the XML 1.0 requirement that XML be compatible with SGML. Thus, DTDs cannot be extended in ways that are incompatible with SGML DTDs. However, schema languages are not restricted and can therefore be extended in new ways, such as data typing of elements. The second reason is more practical in nature. Because many people write XML documents but few people write XML DTDs, many more tools and technologies are available for XML documents than for XML DTDs. Because schema languages use XML document syntax, they can use the tools and technologies designed for XML documents. As a simple example, suppose you are writing an XML editor and you want to use DTDs to control user input -- for example, if somebody is editing a memo that conforms to the above DTD, you want to be sure that the Memo element contains Paragraph elements but not other Memo elements. Because most XML parsers do not return DTD information to the application, you would need to write your own DTD parser. However, if your document schemas were defined using a schema language instead of DTDs, you could parse the schema documents using any available XML parser. There are currently four proposed schema languages: XML-Data: http://www.w3.org/TR/1998/NOTE-XML-data XSchema: http://www.simonstl.com/xschema/spec/xscspecv6.htm DCD: http://www.w3.org/TR/NOTE-dcd SOX: http://www.w3.org/TR/NOTE-SOX/ All of these languages are very similar at a base level -- defining elements and attributes and so on. They differ to some extent in the degree to which they replace DTDs; for example, some can define entities and some can't. They differ radically in the other capabilities they offer: XML-Data is the most ambitious and XSchema is the simplest. Eventually, all of these languages will be replaced by one currently being defined by the W3C. Since you are just starting out with XML, you might not need to worry about schema languages. If you are still interested, I suggest starting with XSchema, as I think it is the simplest (disclaimer: I am one of the authors and admittedly biased). A couple of other things to consider: (a) XML-Data is (I believe) no longer being worked on, but is used by the Microsoft parser as a way to expose DTD information. (b) You will probably want to convert any code you write to the W3C's schema language when it is published, so it might be safest to stick with the basics. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Thu Jan 7 10:45:52 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:07:18 2004 Subject: Namespaces hate validation! Message-ID: <01BE3A32.750B8E60@grappa.ito.tu-darmstadt.de> Murray Maloney wrote: > Well, I just looked at XSchema again, and while it does include > some facilities for namespace-awareness, it is not clear to me > that it integrates "Namespaces in XML". > > In a fact, I have to challenge your assertion that XSchema > integrates with "Namespaces in XML". Quoting from XSchema (4.3.2): > > The following XSchema structures cannot be converted > to DTD structures because such structures do not exist: > > [structures and other stuff snipped] > > >DCD almost does this, but is silent on how it associates namespace prefixes > >used in attribute values (such as the name of an element being declared) > >with URIs. > > So, DCD does not integrate with "Namespaces in XML". > > [snip] > > >In any case, it is certainly possible to integrate the current namespace > >proposal with a schema language, as XSchema shows. > > XSchema shows no such thing as section 4.3.2 makes clear. The impossibility of converting XSchema structures (even if they are rel ated to namespaces) to DTDs has nothing to do with namespace support in XSchema -- it has to do with converting XSchema documents to DTDs. XSchema and DCD (as soon as a prefix=>namespace URI associator is added) both completely support the current namespaces spec. That is, they provide enough namespace information that an application, parser, whatever, can look at a schema document and determine the namespace to which an element or attribute belongs. One important consequence of this is that the problem that started this entire discussion -- validating a namespace-using instance document against a DTD -- can be performed. That is, a namespace- and schema-aware parser (or namespace and schema layers on top of existing parsers) can take a document that uses namespaces and its associated schema document and validate that document against that schema. If this is not possible, then it is a bug in XSchema or DCD and needs to be fixed. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dalvim at yahoo.com Thu Jan 7 13:32:05 1999 From: dalvim at yahoo.com (mayes) Date: Mon Jun 7 17:07:18 2004 Subject: xml and servlets Message-ID: <19990107132707.20171.rocketmail@send1e.yahoomail.com> Has anyone done any kind of programming incorporating xml and servlets. Also I would like all you experts out there to recommend a book on xml.. Thanks Mayes ---John Cowan wrote: > > Murray Maloney wrote: > > > Thus validation depends on the existence of a namespace-aware > > processor that can rewrite an XML document as an equivalent > > document with all namespaces declared on the root element > > and with no use of default namespaces or local scoping > > of prefixes. > > > > And, that processor is undefined and unimplemented. > > I suppose eventually someone will have to MOV MOUTH, MONEY. > But not me, not yet. > > > Oh, by the way, what do you do about any entities you encounter? > > I mean, when I combine an HTML DTD with a graveyard DTD, > > how do I avoid name collision between general text entities? > > > > agrave, egrave, igrave, ograve, ugrave > > > > Now I assume that you will tell me that there is a *simple* > > algorithm for transforming the DTD and/or the instance to > > deal with name collisions. > > Now don't mix up two different issues! There is *no* algorithm, > and nobody claims there is, for merging DTDs automatically! > Tim thinks one will eventually be found, about which *I* am > deeply skeptical. > > The claim being made here is: > > Given: > > 1) a mixed-namespace DTD, and > 2) a mixed-namespace instance > (which is WF and namespace-compliant) > that purports to conform to it, and > 3) a source of information > about the prefix-to-URI map(s) being used in the DTD, > > it is possible by preprocessing > > 1) the DTD (without the instance, and > 2) the instance (without the DTD) > > to produce a modified (DTD, instance) pair which will validate > using an ordinary XML validator > > if and only if > > the original (DTD, instance) pair would validate > using a (nonexistent) namespace-aware validator, > > and the resulting modified instance > will be namespace-equivalent to the original instance. > > > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > You tollerday donsk? N. You tolkatiff scowegian? Nn. > You spigotty anglease? Nnn. You phonio saxo? Nnnn. > Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 7 15:29:56 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:18 2004 Subject: Regulating the XML Marketplace In-Reply-To: <13971.28990.313525.668125@localhost.localdomain> References: <199901061408.JAA15465@hesketh.net> <3.0.32.19990105174446.00b8f480@pop.intergate.bc.ca> <199901061408.JAA15465@hesketh.net> Message-ID: <199901071529.KAA26627@hesketh.net> At 09:42 AM 1/6/99 -0500, you wrote: >Simon St.Laurent writes: > > [about the highly secretive, smoke-filled XML Coordination group, aka > The Syndicate] > > > I'd love to see a set of goals from the higher level group like the > > working groups below it have so successfully produced. Right now, > > the emperor himself is pretty invisible to the outside world. > > There's no broad statement of what the XML family of standards > > should look like when it reaches maturity (or puberty, even.) I > > think everyone on this list has their own, usually incompatible, > > vision of what XML should look like. A statement of what it will > > look like might give us something better to work with, introducing > > less complication in the long run. > >Actually, the problem is a little different. We all know what XML >looks like -- it's described pretty clearly (modulo a few errata) in >the XML 1.0 spec [1]. What we're waiting to find out is what >applications that happen to use XML will look like. > >Somewhere out there, there's a yet-to-be-discovered magic dividing >line between what the W3C should and shouldn't regulate -- clearly, >core XML 1.0 syntax falls on the W3C side of the dividing line, and >just as clearly, the source code for a specific XML parser falls on >the other side. The problem that I'm describing isn't about where that dividing line is - the W3C seems to have decided that reasonably well enough for itself, though that's always contestable as well. The problem is that the W3C doesn't appear (to those of us outside the smoke-filled room) to be taking any initiative in regulating how its standards interact with each _other_. XML 1.0 is at least the foundation, though namespaces cause problems with much XML processing, as has been described repeatedly for the last 24 hours. Beyond that, however, it's not at all clear how XLink and XSL relate to each other, how transformation relates to validation, either traditional XML or using a schema, how XPointers and query languages will be similar or different, and why, and how to best deal with the 'incoherence' of the multiple specs - XML's usage of entities and notations, XLink's relationships of resources, and the xml-stylesheet PI's blunt grabbing of a URL-based resource with MIME type specified in the PI. This is a pretty ugly mess, and explaining it requires a lot of throwing your hands in the air and saying "that's the way it is". It may mean a lot more work for the W3C to clean it up, but it'll make for a far better standard in the long run. >Beyond obvious cases, though, we have the classic problem of how to >regulate a market without killing it. We could take the Old >Labour/New Deal approach and nationalise everything, we could take the >Margaret Thatcher approach and privatise everything, or we could try >to be Tony Blairs and please/disappoint everyone a little without >taking any firm positions. On the interactions between the specs, the W3C is definitely Tony Blair. I don't think it works as well in technology as in 'real-world' politics, but others may have different views. Also, remember the W3C is barely a 'regulator' by its own terms - specs are just 'recommendations'. I'd love to see a stronger W3C, but a much more open one, but I can't say I expect to see that. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 7 15:54:29 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:18 2004 Subject: xml and servlets In-Reply-To: <19990107132707.20171.rocketmail@send1e.yahoomail.com> Message-ID: <199901071554.KAA14996@hesketh.net> ZAt 05:27 AM 1/7/99 -0800, you wrote: > >Has anyone done any kind of programming incorporating xml and >servlets. Also I would like all you experts out there to recommend a >book on xml.. > >Thanks > >Mayes A book I co-authored, _Building XML Applications_, was supposed to be out last month, but will end up coming out sometime next month (hopefully), and includes a servlet XML processing example as well as a general discussion (and examples) of lots of Java tools and techniques for processing XML. Servlets seem like the right tool for a lot of server-side work, at least to my way of thinking, so hopefully we'll see more examples shortly. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Norbert at DataChannel.com Thu Jan 7 16:19:00 1999 From: Norbert at DataChannel.com (Norbert Mikula) Date: Mon Jun 7 17:07:18 2004 Subject: xml and servlets Message-ID: <8EAE75D3D142D211A45200A0C99B6023074809@ZEUS> I am using servlets in conjunction with the Microsoft/DataChannel parser (http://www.datachannel.com/xml_resources/developers/parser.shtml) I found it very powerful to be able to use XSL stylesheets (it is a combined XML parser and XSL stylesheet engine) while still being able to have a high level of control over the XML data through accessing it via the DOM and apply program logic - from within the servlet - that would be hard (if not impossible) with a pure stylesheet mechanism. ---------------------------------------------- Norbert H. Mikula Director of Architectural Services Norbert@DataChannel.com DataChannel, 155 108th Avenue NE Ste 400, Bellevue, WA 98004 Phone: 425.462.1999 Fax: 425.637.1192 http://www.datachannel.com > -----Original Message----- > From: Simon St.Laurent [mailto:simonstl@simonstl.com] > Sent: Thursday, January 07, 1999 7:57 AM > To: XML-Dev Mailing list > Subject: Re: xml and servlets > > > ZAt 05:27 AM 1/7/99 -0800, you wrote: > > > >Has anyone done any kind of programming incorporating xml and > >servlets. Also I would like all you experts out there to recommend a > >book on xml.. > > > >Thanks > > > >Mayes > > A book I co-authored, _Building XML Applications_, was > supposed to be out > last month, but will end up coming out sometime next month > (hopefully), and > includes a servlet XML processing example as well as a > general discussion > (and examples) of lots of Java tools and techniques for > processing XML. > > Servlets seem like the right tool for a lot of server-side > work, at least > to my way of thinking, so hopefully we'll see more examples shortly. > > Simon St.Laurent > XML: A Primer / Cookies > Sharing Bandwidth > Building XML Applications (February) > http://www.simonstl.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tallen at sonic.net Thu Jan 7 16:36:14 1999 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 17:07:18 2004 Subject: Compound DTDs Message-ID: <199901071635.IAA04581@bolt.sonic.net> My question is what Tim means by "compound document", a term I've used for a year and a half (see SGML 97 proceedings) to mean a document composed of parts, potentially in various formats, which may be SGML documents that are linked to as part of the content of an enframing document. CBL uses such compound documents. regards, Terry Terry Allen Veo Systems, Inc. Information Architect 2440 W. El Camino Real tallen[at]sonic.net Mountain View, Calif., 94040 Common Business Library - available at http://www.veosystems.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mdmahajan at yahoo.com Thu Jan 7 17:32:20 1999 From: mdmahajan at yahoo.com (Mohan Mahajan) Date: Mon Jun 7 17:07:18 2004 Subject: xml and servlets Message-ID: <19990107173058.1595.rocketmail@send101.yahoomail.com> I am working on XML with Java servlets using Datachannel XML parser. You may like to use 'Java Servlets' by Karl Moss and XML Applications from Wrox publishing. Thanks, Mohan Mahajan ---mayes wrote: > > > Has anyone done any kind of programming incorporating xml and > servlets. Also I would like all you experts out there to recommend a > book on xml.. > > Thanks > > Mayes > > > > ---John Cowan wrote: > > > > Murray Maloney wrote: > > > > > Thus validation depends on the existence of a namespace-aware > > > processor that can rewrite an XML document as an equivalent > > > document with all namespaces declared on the root element > > > and with no use of default namespaces or local scoping > > > of prefixes. > > > > > > And, that processor is undefined and unimplemented. > > > > I suppose eventually someone will have to MOV MOUTH, MONEY. > > But not me, not yet. > > > > > Oh, by the way, what do you do about any entities you encounter? > > > I mean, when I combine an HTML DTD with a graveyard DTD, > > > how do I avoid name collision between general text entities? > > > > > > agrave, egrave, igrave, ograve, ugrave > > > > > > Now I assume that you will tell me that there is a *simple* > > > algorithm for transforming the DTD and/or the instance to > > > deal with name collisions. > > > > Now don't mix up two different issues! There is *no* algorithm, > > and nobody claims there is, for merging DTDs automatically! > > Tim thinks one will eventually be found, about which *I* am > > deeply skeptical. > > > > The claim being made here is: > > > > Given: > > > > 1) a mixed-namespace DTD, and > > 2) a mixed-namespace instance > > (which is WF and namespace-compliant) > > that purports to conform to it, and > > 3) a source of information > > about the prefix-to-URI map(s) being used in the DTD, > > > > it is possible by preprocessing > > > > 1) the DTD (without the instance, and > > 2) the instance (without the DTD) > > > > to produce a modified (DTD, instance) pair which will validate > > using an ordinary XML validator > > > > if and only if > > > > the original (DTD, instance) pair would validate > > using a (nonexistent) namespace-aware validator, > > > > and the resulting modified instance > > will be namespace-equivalent to the original instance. > > > > > > > > -- > > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > > You tollerday donsk? N. You tolkatiff scowegian? Nn. > > You spigotty anglease? Nnn. You phonio saxo? Nnnn. > > Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) > > > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > > (un)subscribe xml-dev > > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > > subscribe xml-dev-digest > > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > > > > _________________________________________________________ > DO YOU YAHOO!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Jan 7 18:13:18 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:18 2004 Subject: Compound DTDs Message-ID: <3.0.32.19990107101049.00c1f100@pop.intergate.bc.ca> At 08:35 AM 1/7/99 -0800, Terry Allen wrote: >My question is what Tim means by "compound document" That's a good question. When someone from the traditional doc management biz, like Documentum, says "compound documents" they mean "we can deal with some number of atomic WP files as grouped into a logical document". Normally, when browbeating this kind of person, SGML/XML people have said "a compound document is one with internal structures, like SGML or XML". Now we're starting to see documents that are even more compound, where not only do we have internal structures, but the internal structures come from different problem domains and DTDs and information designers - this latter case is the one namespaces are trying to help with. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Thu Jan 7 18:13:29 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:19 2004 Subject: Status of XML-Data Message-ID: <5BF896CAFE8DD111812400805F1991F708AAED37@RED-MSG-08> The Microsoft IE5 "technology preview" contains a parser that supports the majority of the features and syntax described in the "XML-Data" paper, (http://www.w3.org/TR/1998/NOTE-XML-data-0105/). The parser supports datatypes, open content model, order-independent content model, namespaces, and validation. Naturally, there have been a few small changes in syntax over the intervening year. See http://www.microsoft.com/sitebuilder/ for details. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 7 19:13:42 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:19 2004 Subject: An XML Namespaces Alternative... Message-ID: <3695072D.DEC0B925@infinet.com> I like many other XML and XSL developers are very dissatisfied with the most recent "Namespaces in XML" working draft. However, some people it appears think that the current draft is the greatest thing since sliced bread. Anyways, I am one of the people who actually liked the old namespaces PI based proposal, mostly because it was simple and did the job in terms of what a namespace is. The current working draft though I dislike for several main reasons: (1) Namespace declarations are declared using attributes. This forces programmers to explicitly use namespaces or at least handle the namespace attributes even if they do not want to. Some applications may not give a hoot about namespaces, but will have a desire to parse documents that are namespace aware without using some namespaces aware XML Parser API or filter API. SAX for example is not namespace aware, so building some complicated inefficient filter to handle namespaces on top of SAX really defeats the purpose of SAX in the first place (a de-facto standard that is supported in just about every XML Parser package around). (2) Validating documents efficiently can be a problem with some uses of "Namespaces in XML". I don't want to reignite the giant thread on this that popped up several months ago on xml-dev regarding this particular issue, but there certainly is not anything close to a concensus on what to do with DTD validation and namespaces. Since I am probably one of the noisier people on this list regarding this namespaces issue, I suppose it would be a good idea to put up or shut up. Simply complaining and moaning about why I or someone else does not like namespaces in XML does not improve things at all though it does release personal frustration. I suppose the only thing I can do is post to these lists an idea (call it an alternative) that borrows some ideas from the previous proposal as well as the current working draft (I am posting to XSL List because namespaces are a very important part of XSL). I hope that the fact that I am not a well-known SGML developer with 10+ years of experience does not preclude me from trying to inject some life into an issue that currently plagues XML and all of its children. I hope my comments are taken objectively and I don't receive too many ad-hominem attacks which seem to be all too common in the programming world when talking about technical matters (I as pretty much everyone else is guilty of this from time to time). Fortunately, these two lists are some of the most polite technical discussion lists I have encountered so far. Now I have spent some serious time thinking about this issue as it will be likely be very important that XML has an easy to use namespaces standard for an app I have spent over a year and a half on that uses XML extensively for all sorts of things. I don't need to use XML, but I feel it is for the most part simple, standardized, and easy enough for end users to handle manually for such things like user profile data and init files. I think there is a pretty good concensus now among XML and XSL developers that XML needs a namespaces mechanism, just that there seems to be much disagreement about what the namespaces mechanism should be. For the most part, I have heard a lot of negative criticism, and then criticism of that criticism on the latest draft, but I have heard of few public alternatives, so here is my attempt at taking a stab at XML namespaces. ----------------------------------------------------------------------------------------------------- In the previous XML Namespaces proposal (WD-xml-names-19980327) processing instructions were used to declare globally applicable namespaces. The core objections to this approach from what I could garner on xml-dev was mostly that the historical use of processing instructions (processing instructions are supposed to be application specific) suggested that you use processing instructions for things which are not supposed to be core to the document and optionally ignored by applications. For lots of different reasons, I think that namespaces should be optionally ignored but mostly because for most XML applications, namespaces are not necessary at all (they complicate things for the end user no matter how you cut it). The other objection to the last draft was the argument that the pi approach with global namespaces had no concept of namespace defaulting. Namespace defaulting if done cleanly, I think would be a great utility to xml users. However, the current draft I don't think does things cleanly. The approach I have here has namespace defaulting (which still of course has some problems with validation), does not need to use attributes and should work more efficiently with SAX since you do not need to interate through all attributes in an element or look up an attribute in a map of attributes to see if a namespace declaration has been declared. Also you can undeclare a namespace which is something that the most recent namespaces draft cannot do. This proposal I think should obviate the need for the DOM to have any special interfaces to handle namespaces and make it much more attractive and efficient to use in XSL since all you need to do in an application which uses the DOM is something like: switch (node.getNodeType()) { case Node.PROCESSING_INSTRUCTION: { // Handle namespace processing here } default: { // Do something else } } rather than something like this which is a lot more inefficient: NamedNodeMap attributes = node.getAttributes(); int length = attributes.getLength(); Node attribute; for (int i = 0; i < length; i++) { attribute = attributes.item(i); if (attribute.getNodeName().startsWith("xmlns:")) { // This is a special namespace node so handle namespace processing here } } A basic SAX filter that any programmer could use for namespaces (or they could write their own) would be something like public void startElement(String name, org.xml.sax.AttributeList attributes) throws org.xml.sax.SAXException { int index = name.indexOf(":"); if (index == -1) { // Look up default namespace } else { findNamespace(name.substring(0, index)); } } public void endElement(String name) throws org.xml.sax.SAXException { int index = name.indexOf(":"); if (index == -1) { // Look up default namespace } else { findNamespace(name.substring(0, index)); } } public void characters(char ch[], int start, int length) throws org.xml.sax.SAXException {} public void ignorableWhitespace(char ch[], int start, int length) throws org.xml.sax.SAXException {} public void processingInstruction(String target, String data) throws org.xml.sax.SAXException { if (target.equals("xml:begin-ns")) { parseBeginNamespace(data); } else if (target.equals("xml:end-ns")) { parseEndNamespace(data); } } private void parseBeginNamespace(String data) { // Parse urn, name, and priority and // push namespace onto namespace stack and // remove the current namespace if it is a // sibling of this namespace } private void parseEndNamespace(String data) { // Parse name, and remove namespace with the // given name (ns pi's must be nested properly) } private Namespace findNamespace(String prefix) { // Continually peek at namespaces on the namespace stack until // one is found and return the urn associated with // that namespace } There are already SAX filters for the current namespaces proposal (I think John Cowan who lurks on xml-dev wrote one), but they are inefficient because for each element you effectively have to search all attributes to see if one of the attributes is a namespace attribute. This in the general case will eat a lot of CPU. The only real-world alternative I can see is to not use SAX and do all of this natively in the XML Parser (i.e. for each parsed attribute check it there to see if it is a namespace declaration). SAX is very successful so I see no reason why anyone will use "Namespaces in XML" unless it is forced down their throats in forthcoming sister XML drafts like XSL. Anyways, here is a sample XML file that for the most part shows the basic implementation of my namespaces idea. Most of this is pretty self-explantory however there are a few not so clear things here. One is the "super" attribute of a namespace processing instruction. This could be omitted, but I thought it might be useful for object-oriented applications which need to delegate (perhaps instead of "super" it should be "delegate") processing of a content type to some other component. In other words for: If an element type cannot be found in the namespace of "C" then it will delegate to the "A" namespace before throwing an error. This is just an idea that I think may help out object-oriented technologies so don't take it too seriously for the moment. You could even make it something like: Where you would have multiple delegates. For frameworks like Coins, this sort of feature may open up a whole lot of creative possibilities for dynamically assembled applications (I am not speaking from the seat of my pants here as I have an entire GUI based application I have written which has most of its GUI glued together dynamically using XML and Java). Who really knows, but I think it is an avenue of exploration. I have not really looked into the negatives of this "super" attribute idea too much so please don't beat me up too bad if I have seriously overlooked something here. Other ideas I have are global namespaces, priorities and lots of other things, but my goal here is that the W3C produce a simple, clear, proposal that my fox terrier could understand upon a first read (-: Namespaces should be simple, so we should keep what comprises namespaces simpl. All in all, I think this approach is much simpler to implement (especially in scripting languages like PERL) and much easier to use than what is currently drafted. Most importantly, it does not use attributes which is one of the number one annoyances of the current draft. Of course this is all just my opinion, so hopefully this will start a thread of serious debate on what sort of namespaces mechanism we the developers would like the W3C to implement instead of us folks critical about the latest namespaces draft just complaining about it. Of course if the W3C totally ignores the needs to the non-member developers, it will lose a lot of credibility and respect that any standards organizations holds dear. I doubt the W3C is the ivory tower so many people claim it to be, so I guess solving this namespaces problem in the next couple of months will be a major test. Regards, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Thu Jan 7 23:47:42 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:07:19 2004 Subject: Regulating the XML Marketplace In-Reply-To: <199901071529.KAA26627@hesketh.net> Message-ID: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Hi- Simon makes a lot of good points. I'm afraid that what we're seeing with XML is what Java would be without Sun or Linux would be without Linus. No one has yet emerged as the XML evangelist. I don't mean to take anything away from the people (on this list) that have helped make XML what it is. However, I don't think that there is going to be much cohesion among standards until someone like McNealy or Linus steps up and takes the stand. I believe that this is due, in part, to the fact that XML applications are still fairly esoteric. There is no "poster-child" application for XML. The popularization of the applet in 1996 was a huge step for Sun. The applets were totally inane, but that was beside the point. The applets attracted eyeballs. The minds and ears followed. Someone needs to come up with something clever with XML. It sounds difficult and improbable. But how many people who wrote virtual machines in college would have believed that the same essential technology would make people excited to play TIC TAC TOE?! A virual machine is no more or less esoteric than XML. Who is going to make it happen? Rob > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Simon St.Laurent > Sent: Thursday, January 07, 1999 7:29 AM > To: XML-Dev Mailing list > Subject: Re: Regulating the XML Marketplace > > > At 09:42 AM 1/6/99 -0500, you wrote: > >Simon St.Laurent writes: > > > > [about the highly secretive, smoke-filled XML Coordination group, aka > > The Syndicate] > > > > > I'd love to see a set of goals from the higher level group like the > > > working groups below it have so successfully produced. Right now, > > > the emperor himself is pretty invisible to the outside world. > > > There's no broad statement of what the XML family of standards > > > should look like when it reaches maturity (or puberty, even.) I > > > think everyone on this list has their own, usually incompatible, > > > vision of what XML should look like. A statement of what it will > > > look like might give us something better to work with, introducing > > > less complication in the long run. > > > >Actually, the problem is a little different. We all know what XML > >looks like -- it's described pretty clearly (modulo a few errata) in > >the XML 1.0 spec [1]. What we're waiting to find out is what > >applications that happen to use XML will look like. > > > >Somewhere out there, there's a yet-to-be-discovered magic dividing > >line between what the W3C should and shouldn't regulate -- clearly, > >core XML 1.0 syntax falls on the W3C side of the dividing line, and > >just as clearly, the source code for a specific XML parser falls on > >the other side. > > The problem that I'm describing isn't about where that dividing line is - > the W3C seems to have decided that reasonably well enough for itself, > though that's always contestable as well. The problem is that the W3C > doesn't appear (to those of us outside the smoke-filled room) to be taking > any initiative in regulating how its standards interact with each > _other_. > > XML 1.0 is at least the foundation, though namespaces cause problems with > much XML processing, as has been described repeatedly for the last 24 > hours. Beyond that, however, it's not at all clear how XLink and XSL > relate to each other, how transformation relates to validation, either > traditional XML or using a schema, how XPointers and query languages will > be similar or different, and why, and how to best deal with the > 'incoherence' of the multiple specs - XML's usage of entities and > notations, XLink's relationships of resources, and the xml-stylesheet PI's > blunt grabbing of a URL-based resource with MIME type specified in the PI. > > This is a pretty ugly mess, and explaining it requires a lot of throwing > your hands in the air and saying "that's the way it is". It may > mean a lot > more work for the W3C to clean it up, but it'll make for a far better > standard in the long run. > > >Beyond obvious cases, though, we have the classic problem of how to > >regulate a market without killing it. We could take the Old > >Labour/New Deal approach and nationalise everything, we could take the > >Margaret Thatcher approach and privatise everything, or we could try > >to be Tony Blairs and please/disappoint everyone a little without > >taking any firm positions. > > On the interactions between the specs, the W3C is definitely Tony > Blair. I > don't think it works as well in technology as in 'real-world' > politics, but > others may have different views. > > Also, remember the W3C is barely a 'regulator' by its own terms - > specs are > just 'recommendations'. I'd love to see a stronger W3C, but a much more > open one, but I can't say I expect to see that. > > Simon St.Laurent > XML: A Primer / Cookies > Sharing Bandwidth > Building XML Applications (February) > http://www.simonstl.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Fri Jan 8 00:04:09 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:19 2004 Subject: Regulating the XML Marketplace In-Reply-To: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <000401be3a99$f4124d40$5118a8c0@kuantech1.quokka.com> I partly agree, and partly disagree. Yes, XML needs a person and/or organization to guide its evolution. But I don't think it needs a killer app. Lots of cool stuff is already being done with XML. The analogy with Java is a good one. You have the language, then you have the JDK on top of the language. While the language has been completely stable, the JDK has gone through a somewhat painful evolution process from 1.0 to 1.1 to 2. Similary, the basic XML 1.0 spec is just fine (IMHO). It's the XDK, if you will, that needs help (again, IMHO). And, as I've said before on this mailing list, it's the XDK that lets people do meaningful work. Jeff -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Rob Schoening Sent: Thursday, January 07, 1999 3:48 PM To: Simon St.Laurent; XML-Dev Mailing list Subject: RE: Regulating the XML Marketplace Hi- Simon makes a lot of good points. I'm afraid that what we're seeing with XML is what Java would be without Sun or Linux would be without Linus. No one has yet emerged as the XML evangelist. I don't mean to take anything away from the people (on this list) that have helped make XML what it is. However, I don't think that there is going to be much cohesion among standards until someone like McNealy or Linus steps up and takes the stand. I believe that this is due, in part, to the fact that XML applications are still fairly esoteric. There is no "poster-child" application for XML. The popularization of the applet in 1996 was a huge step for Sun. The applets were totally inane, but that was beside the point. The applets attracted eyeballs. The minds and ears followed. Someone needs to come up with something clever with XML. It sounds difficult and improbable. But how many people who wrote virtual machines in college would have believed that the same essential technology would make people excited to play TIC TAC TOE?! A virual machine is no more or less esoteric than XML. Who is going to make it happen? Rob > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Simon St.Laurent > Sent: Thursday, January 07, 1999 7:29 AM > To: XML-Dev Mailing list > Subject: Re: Regulating the XML Marketplace > > > At 09:42 AM 1/6/99 -0500, you wrote: > >Simon St.Laurent writes: > > > > [about the highly secretive, smoke-filled XML Coordination group, aka > > The Syndicate] > > > > > I'd love to see a set of goals from the higher level group like the > > > working groups below it have so successfully produced. Right now, > > > the emperor himself is pretty invisible to the outside world. > > > There's no broad statement of what the XML family of standards > > > should look like when it reaches maturity (or puberty, even.) I > > > think everyone on this list has their own, usually incompatible, > > > vision of what XML should look like. A statement of what it will > > > look like might give us something better to work with, introducing > > > less complication in the long run. > > > >Actually, the problem is a little different. We all know what XML > >looks like -- it's described pretty clearly (modulo a few errata) in > >the XML 1.0 spec [1]. What we're waiting to find out is what > >applications that happen to use XML will look like. > > > >Somewhere out there, there's a yet-to-be-discovered magic dividing > >line between what the W3C should and shouldn't regulate -- clearly, > >core XML 1.0 syntax falls on the W3C side of the dividing line, and > >just as clearly, the source code for a specific XML parser falls on > >the other side. > > The problem that I'm describing isn't about where that dividing line is - > the W3C seems to have decided that reasonably well enough for itself, > though that's always contestable as well. The problem is that the W3C > doesn't appear (to those of us outside the smoke-filled room) to be taking > any initiative in regulating how its standards interact with each > _other_. > > XML 1.0 is at least the foundation, though namespaces cause problems with > much XML processing, as has been described repeatedly for the last 24 > hours. Beyond that, however, it's not at all clear how XLink and XSL > relate to each other, how transformation relates to validation, either > traditional XML or using a schema, how XPointers and query languages will > be similar or different, and why, and how to best deal with the > 'incoherence' of the multiple specs - XML's usage of entities and > notations, XLink's relationships of resources, and the xml-stylesheet PI's > blunt grabbing of a URL-based resource with MIME type specified in the PI. > > This is a pretty ugly mess, and explaining it requires a lot of throwing > your hands in the air and saying "that's the way it is". It may > mean a lot > more work for the W3C to clean it up, but it'll make for a far better > standard in the long run. > > >Beyond obvious cases, though, we have the classic problem of how to > >regulate a market without killing it. We could take the Old > >Labour/New Deal approach and nationalise everything, we could take the > >Margaret Thatcher approach and privatise everything, or we could try > >to be Tony Blairs and please/disappoint everyone a little without > >taking any firm positions. > > On the interactions between the specs, the W3C is definitely Tony > Blair. I > don't think it works as well in technology as in 'real-world' > politics, but > others may have different views. > > Also, remember the W3C is barely a 'regulator' by its own terms - > specs are > just 'recommendations'. I'd love to see a stronger W3C, but a much more > open one, but I can't say I expect to see that. > > Simon St.Laurent > XML: A Primer / Cookies > Sharing Bandwidth > Building XML Applications (February) > http://www.simonstl.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Fri Jan 8 01:14:49 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:07:19 2004 Subject: Regulating the XML Marketplace In-Reply-To: <000401be3a99$f4124d40$5118a8c0@kuantech1.quokka.com> Message-ID: <000001be3aa4$4220dc90$bda8b4d1@yak.ptld.uswest.net> The JDK evolution has been painful, but it has also been remarkably well staged. It would be nice to see some kind of XDK initiative that could unite the various standards and version them as a unit. If this doesn't happen the XML technology umbrella will evolve in fits and starts. If the W3C (or some related group) could produce a reference implementation of its interfaces, things might be a bit easier. Sun has done a good job with their Servlet API. They release the specification, then the java interfaces, then the Servlet SDK (w/reference implementation), and then a commercial implementation. 99% of the value added to the platform occurs when the SDK is released and developers can begin their prototypes without re-inventing the wheel. Unfortunately this stage is a bit hazy for the stuff coming out of the W3C. I agree that XML doesn't need a "killer app". I do think that it needs a "clever app"...something that resonates the possibilities of the technology. Rob > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Jeffrey E. Sussna > Sent: Thursday, January 07, 1999 4:01 PM > To: 'Rob Schoening'; 'Simon St.Laurent'; 'XML-Dev Mailing list' > Subject: RE: Regulating the XML Marketplace > > > I partly agree, and partly disagree. Yes, XML needs a person > and/or organization to guide its evolution. But I don't think it > needs a killer app. Lots of cool stuff is already being done with > XML. The analogy with Java is a good one. You have the language, > then you have the JDK on top of the language. While the language > has been completely stable, the JDK has gone through a somewhat > painful evolution process from 1.0 to 1.1 to 2. Similary, the > basic XML 1.0 spec is just fine (IMHO). It's the XDK, if you > will, that needs help (again, IMHO). And, as I've said before on > this mailing list, it's the XDK that lets people do meaningful work. > > Jeff > > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Rob Schoening > Sent: Thursday, January 07, 1999 3:48 PM > To: Simon St.Laurent; XML-Dev Mailing list > Subject: RE: Regulating the XML Marketplace > > > Hi- > > Simon makes a lot of good points. > > I'm afraid that what we're seeing with XML is what Java would be > without Sun > or Linux would be without Linus. No one has yet emerged as the XML > evangelist. I don't mean to take anything away from the people (on this > list) that have helped make XML what it is. However, I don't think that > there is going to be much cohesion among standards until someone like > McNealy or Linus steps up and takes the stand. > > I believe that this is due, in part, to the fact that XML applications are > still fairly esoteric. There is no "poster-child" application for XML. > The popularization of the applet in 1996 was a huge step for Sun. The > applets were totally inane, but that was beside the point. The applets > attracted eyeballs. The minds and ears followed. > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual > machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. > > Who is going to make it happen? > > Rob > > > -----Original Message----- > > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > > Simon St.Laurent > > Sent: Thursday, January 07, 1999 7:29 AM > > To: XML-Dev Mailing list > > Subject: Re: Regulating the XML Marketplace > > > > > > At 09:42 AM 1/6/99 -0500, you wrote: > > >Simon St.Laurent writes: > > > > > > [about the highly secretive, smoke-filled XML Coordination group, aka > > > The Syndicate] > > > > > > > I'd love to see a set of goals from the higher level group like the > > > > working groups below it have so successfully produced. Right now, > > > > the emperor himself is pretty invisible to the outside world. > > > > There's no broad statement of what the XML family of standards > > > > should look like when it reaches maturity (or puberty, even.) I > > > > think everyone on this list has their own, usually incompatible, > > > > vision of what XML should look like. A statement of what it will > > > > look like might give us something better to work with, introducing > > > > less complication in the long run. > > > > > >Actually, the problem is a little different. We all know what XML > > >looks like -- it's described pretty clearly (modulo a few errata) in > > >the XML 1.0 spec [1]. What we're waiting to find out is what > > >applications that happen to use XML will look like. > > > > > >Somewhere out there, there's a yet-to-be-discovered magic dividing > > >line between what the W3C should and shouldn't regulate -- clearly, > > >core XML 1.0 syntax falls on the W3C side of the dividing line, and > > >just as clearly, the source code for a specific XML parser falls on > > >the other side. > > > > The problem that I'm describing isn't about where that dividing > line is - > > the W3C seems to have decided that reasonably well enough for itself, > > though that's always contestable as well. The problem is that the W3C > > doesn't appear (to those of us outside the smoke-filled room) > to be taking > > any initiative in regulating how its standards interact with each > > _other_. > > > > XML 1.0 is at least the foundation, though namespaces cause > problems with > > much XML processing, as has been described repeatedly for the last 24 > > hours. Beyond that, however, it's not at all clear how XLink and XSL > > relate to each other, how transformation relates to validation, either > > traditional XML or using a schema, how XPointers and query > languages will > > be similar or different, and why, and how to best deal with the > > 'incoherence' of the multiple specs - XML's usage of entities and > > notations, XLink's relationships of resources, and the > xml-stylesheet PI's > > blunt grabbing of a URL-based resource with MIME type specified > in the PI. > > > > This is a pretty ugly mess, and explaining it requires a lot of throwing > > your hands in the air and saying "that's the way it is". It may > > mean a lot > > more work for the W3C to clean it up, but it'll make for a far better > > standard in the long run. > > > > >Beyond obvious cases, though, we have the classic problem of how to > > >regulate a market without killing it. We could take the Old > > >Labour/New Deal approach and nationalise everything, we could take the > > >Margaret Thatcher approach and privatise everything, or we could try > > >to be Tony Blairs and please/disappoint everyone a little without > > >taking any firm positions. > > > > On the interactions between the specs, the W3C is definitely Tony > > Blair. I > > don't think it works as well in technology as in 'real-world' > > politics, but > > others may have different views. > > > > Also, remember the W3C is barely a 'regulator' by its own terms - > > specs are > > just 'recommendations'. I'd love to see a stronger W3C, but a much more > > open one, but I can't say I expect to see that. > > > > Simon St.Laurent > > XML: A Primer / Cookies > > Sharing Bandwidth > > Building XML Applications (February) > > http://www.simonstl.com > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > > (un)subscribe xml-dev > > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > > following message; > > subscribe xml-dev-digest > > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gouders at spp.hpc.fujitsu.co.jp Fri Jan 8 01:23:51 1999 From: gouders at spp.hpc.fujitsu.co.jp (Dirk GOUDERS) Date: Mon Jun 7 17:07:19 2004 Subject: xml and servlets In-Reply-To: Your message of "Thu, 07 Jan 1999 10:57:02 EST." <199901071554.KAA14996@hesketh.net> Message-ID: <199901080123.KAA06650@dale.spp.hpc.fujitsu.co.jp> >Has anyone done any kind of programming incorporating xml and >servlets. Also I would like all you experts out there to recommend a >book on xml.. Nazmul Idris created a nice tutorial on XML and Java. In the first part of that tutorial an example using servlets is given: http://developerlife.com/xmljavatutorial1/ Dirk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From db at Eng.Sun.COM Fri Jan 8 03:46:49 1999 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:07:19 2004 Subject: xml and servlets References: <19990107132707.20171.rocketmail@send1e.yahoomail.com> Message-ID: <36957F5B.46F259A0@Eng.Sun.COM> mayes wrote: > > Has anyone done any kind of programming incorporating xml and > servlets. Certainly. Sun's package was used with servlets before it was used with Swing, in fact ... there are a lot of ways to do it. That package incorporates two rather different examples using servlets with XML. One is an XML validation service, the other does document messaging over HTTP(S) in much the same way that a workflow (e.g. Web Commerce) system would. The basic rule is that whenever you do server side web processing in Java, it'll be with a servlet. So if the server is dynamically generating some XML text to send to the client over HTTP, it'll be a servlet. Maybe the servlet is talking to some EJBs on the next tier(s) ... fine! I will encourage the use of any Java parser package that conforms to the SAX and DOM APIs ... especially Sun's! ;-) - Dave http://java.sun.com/xml xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amitr at abinfosys.com Fri Jan 8 09:17:17 1999 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:07:19 2004 Subject: Seeking advice on design of XML,DOM,XSchema based application Message-ID: <00df01be3ae7$b32ed5c0$0c01a8c0@vsnl.net.in> Hello, I have just completed the design of an XML based application which I have tried to explain below. I would be grateful if anyone would provide their comment/criticism on my approach before I begin my implementation phase. Given below is the AIM of the application described in 4 points labelled AIMN (N = 1 to 4). Intermingled with the AIMs is my design approach labelled MY DESIGN APPROACH TO AIMN SCENARIO The scenario in which my app. will operate is as follows :- I have a bunch of XML files along with their XSchema files on my web server. Each XML file has an associated XSchema file. Each of my clients will have my - XML based app. installed - A web browser with an inbuilt XMLDOM parser installed. The browser would have native XML support as well. For an XML file requested by any of my clients from their native XML browsers my client side app. will need to AIM1. Capture the served XML file AIM2. Emit a hierarchical tree control of the schema of served XML file (present in the .xsc file) in HTML format AIM3. Pass the emitted HTMLised tree control to browser for display MY DESIGN APPROACH TO AIM1-AIM3 - As far as capturing the reqested XML file data is concerned my app. will extract the XML DOM tree of the requested XML file from the DOMXML parser embedded in the client XML browser. - In order to emit a hierarchical tree control of the schema of the served XML file (present in the .xsc file) in HTML format, the app. will :- - Obtain the XSchema DOM tree - Invoke an XSL processor and pass it the XSchema DOM tree and XSL rules which will contain HTML templates to get the tree control HTML DOM tree output. - The XSL processor will output the tree control HTML DOM tree which my app. will then pass to the browser Let me illustrate my point with an example. Let's say I have a MyFile.xsc which is :- and it's instance MyFile.xml is :- Test-Data1 My app. would execute the following steps - XMLDOMtree = Extract-from-browser-XML-parser(MyFile.xml); - XSchemaDOMtree = Obtain-XSchema-DOM-tree(XMLDOMtree); - HTMLDOMtree = XSLProcessor(XSchemaDOMtree,XSLrules); - Pass the HTMLDOMtree to browser for display so that the browser output would be something like Root | | Ele1 On clicking a node of the tree control on the browser the user will be presented with the structure of the node (as in the XSchema) for him to fill in data + the following options :- - Make new instance of node - Get previous instance of node - Get next instance of node - Get parent instance of current instance - Get child instance of current instance For the MyFile.xsc and it's MyFile.xml instance file case 1 2 I would get a tree something like :- Root | Ele1 | | OnClick on Ele1 node would produce a form like | \/ _____________________________________ | Structure of Ele1 | | Content Type Value Current Instance | PCData 1 1 | List of Options | * Make new instance of node | * Get previous instance of node | * Get next instance of node | * Get parent instance of current instance | * Get child instance of current instance | |____________________________________ On clicking any of the above option, the client application will be invoked AIM4. My client app. on invocation by any of the above options is supposed to - query the XML instance data depending upon option clicked and - insert/retrieve the resulting XML, and - then emit the resultant XML as HTML. MY DESIGN APPROACH TO AIM4 Assuming that the user clicks on a tree node and then clicks on an option. The app. at this point already has - the XML DOM tree of the requested XML instance file - the XSchema DOM tree of the instance file - Depending upon option clicked the app. will query the the instance XML file's XML DOM tree and it will retrieve/insert the resulting XML DOM sub tree using the XML DOM API, - The resultant XML DOM sub tree will be given to the XSL processor along with the XSL rules to emit the resultant HTML DOM subtree. - The emitted HTML DOM subtree will be passed back to the browser for display. For the MyFile.xsc and it's MyFile.xml instance file case 1 2 Assuming the user has - selected the "Ele1" node and - got the options form - pressed the "get next instance of node" option on the form the client app. will need to query the the MyFile.xml XML DOM tree giving it the element name ("Ele1") and the action ("get-next-instance").The XML DOM tree will contain 1 2 My client app. on querying will remove the following XML tree fragment "2" This removed tree fragment will be converted to an HTML DOM tree using XSL and emitted out. In short my app. will execute the following steps :- - Ele1XMLDOMsubtree = Query("Ele1","Get-next-instance",XMLDOMtree) - HTMLDOMtree = XSLProcessor(Ele1XMLDOMsubtree,XSLrules); - Pass the HTMLDOMtree to browser for display where XMLDOMtree = The MyFile.xml XMLDOM tree The HTMLDOM tree that will be passed to the browser for the "2" XMLDOM tree fragment will be rendered as follows :- _____________________________________ | Structure of Ele1 | | Content Type Value Current Instance | PCData 2 2 | List of Options | * Make new instance of node | * Get previous instance of node | * Get next instance of node | * Get parent instance of current instance | * Get child instance of current instance | |____________________________________ On any furthur clicks on options above, the design approach to AIM4 would be followed and steps in that repeated. I hope I was able to make my design intention clear enough for comment. Thanks in advance for any replies, AMIT xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:19 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:19 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:20 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:21 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:21 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:21 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:21 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:21 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:21 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:21 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:21 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:22 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:22 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:22 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 12:45:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:22 2004 Subject: Regulating the XML Marketplace In-Reply-To: <3695F1DD.B271778F@prescod.net> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <199901081232.HAA12853@hesketh.net> At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done >with XML that could not be done with one of the dozens of proprietary, >hierarchically structured languages that preceded it. I find it very sad that people don't value plumbing, argue that infrastructure is fundamentally unexciting, and ignore the fact that without infrastructure improvements like plumbing itself, railroads, highways, and the Internet, we'd be in a very different place, one I don't think too many of us relish returning to. The builders of those improvements couldn't always see their results, but I don't think you'd have heard them saying that there was NOTHING new that you could do with their facilities. There are thousands, if not millions, of possibilities that XML enables. Yes, you can do all kinds of junk to data in any proprietary way that you like. You can have all the fun in the world processing data any way you want - but when it comes time to share that information, it ain't much good. Sharing is a difficult concept to sell in many ways. The Web did it very successfully for a while, with a limited set of applications, but while it was good at sharing information among users, its read-only approach, simple linking, broken syntax, and limited vocabulary have limited its capacity, and (to put it bluntly) the pipes are breaking. Not everyone can smell the sewage yet, which makes it harder to sell XML, but we need that plumbing. We need bigger, more stable pipes through which we can connect all that information cleanly. Successfully creating those systems will open the possibilities XML holds, making interchange easier, which opens up new fields in collaboration, information storage and retrieval, data processing, and a host of other fields. Of course you could do it another way, but don't we have enough damn closed boxes already? Instead of shutting down discussion by claiming that XML isn't good for anything new, why don't we try to expand it by figuring out how XML fits into the old and improves it significantly? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 12:09:53 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:22 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <3695F1DD.B271778F@prescod.net> Rob Schoening wrote: > > Someone needs to come up with something clever with XML. It sounds > difficult and improbable. But how many people who wrote virtual machines in > college would have believed that the same essential technology would make > people excited to play TIC TAC TOE?! A virual machine is no more or less > esoteric than XML. XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done with XML that could not be done with one of the dozens of proprietary, hierarchically structured languages that preceded it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The United Nations Declaration of Human Rights were be 50 years old on December 10, 1998. These are your fundamental rights: http://www.udhr.org/history/default.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From skshirsa at nortelnetworks.com Fri Jan 8 15:10:20 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:07:22 2004 Subject: Regulating the XML Marketplace Message-ID: <3.0.32.19990108093026.00687bd4@bl-mail2.corpeast.baynetworks.com> I agree that XML makes things lot simpler and cleaner than any other proprietary data exchange format. The biggest hurdle, I see for XML apps to pick up is uniform,inbuild XML Parsing (XDK) support across popular browsers. The present problem is to select one of the available XML parsers, make sure it works on the popular browsers and also the XML Parser jar file has to be served by the server which is a problem in particularly embedded systems environment. Shekhar Kshirsagar Nortel Networks. At 04:00 PM 1/7/99 -0800, you wrote: >I partly agree, and partly disagree. Yes, XML needs a person and/or organization to guide its evolution. But I don't think it needs a killer app. Lots of cool stuff is already being done with XML. The analogy with Java is a good one. You have the language, then you have the JDK on top of the language. While the language has been completely stable, the JDK has gone through a somewhat painful evolution process from 1.0 to 1.1 to 2. Similary, the basic XML 1.0 spec is just fine (IMHO). It's the XDK, if you will, that needs help (again, IMHO). And, as I've said before on this mailing list, it's the XDK that lets people do meaningful work. > >Jeff > >-----Original Message----- >From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of >Rob Schoening >Sent: Thursday, January 07, 1999 3:48 PM >To: Simon St.Laurent; XML-Dev Mailing list >Subject: RE: Regulating the XML Marketplace > > >Hi- > >Simon makes a lot of good points. > >I'm afraid that what we're seeing with XML is what Java would be without Sun >or Linux would be without Linus. No one has yet emerged as the XML >evangelist. I don't mean to take anything away from the people (on this >list) that have helped make XML what it is. However, I don't think that >there is going to be much cohesion among standards until someone like >McNealy or Linus steps up and takes the stand. > >I believe that this is due, in part, to the fact that XML applications are >still fairly esoteric. There is no "poster-child" application for XML. >The popularization of the applet in 1996 was a huge step for Sun. The >applets were totally inane, but that was beside the point. The applets >attracted eyeballs. The minds and ears followed. > >Someone needs to come up with something clever with XML. It sounds >difficult and improbable. But how many people who wrote virtual machines in >college would have believed that the same essential technology would make >people excited to play TIC TAC TOE?! A virual machine is no more or less >esoteric than XML. > >Who is going to make it happen? > >Rob > >> -----Original Message----- >> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of >> Simon St.Laurent >> Sent: Thursday, January 07, 1999 7:29 AM >> To: XML-Dev Mailing list >> Subject: Re: Regulating the XML Marketplace >> >> >> At 09:42 AM 1/6/99 -0500, you wrote: >> >Simon St.Laurent writes: >> > >> > [about the highly secretive, smoke-filled XML Coordination group, aka >> > The Syndicate] >> > >> > > I'd love to see a set of goals from the higher level group like the >> > > working groups below it have so successfully produced. Right now, >> > > the emperor himself is pretty invisible to the outside world. >> > > There's no broad statement of what the XML family of standards >> > > should look like when it reaches maturity (or puberty, even.) I >> > > think everyone on this list has their own, usually incompatible, >> > > vision of what XML should look like. A statement of what it will >> > > look like might give us something better to work with, introducing >> > > less complication in the long run. >> > >> >Actually, the problem is a little different. We all know what XML >> >looks like -- it's described pretty clearly (modulo a few errata) in >> >the XML 1.0 spec [1]. What we're waiting to find out is what >> >applications that happen to use XML will look like. >> > >> >Somewhere out there, there's a yet-to-be-discovered magic dividing >> >line between what the W3C should and shouldn't regulate -- clearly, >> >core XML 1.0 syntax falls on the W3C side of the dividing line, and >> >just as clearly, the source code for a specific XML parser falls on >> >the other side. >> >> The problem that I'm describing isn't about where that dividing line is - >> the W3C seems to have decided that reasonably well enough for itself, >> though that's always contestable as well. The problem is that the W3C >> doesn't appear (to those of us outside the smoke-filled room) to be taking >> any initiative in regulating how its standards interact with each >> _other_. >> >> XML 1.0 is at least the foundation, though namespaces cause problems with >> much XML processing, as has been described repeatedly for the last 24 >> hours. Beyond that, however, it's not at all clear how XLink and XSL >> relate to each other, how transformation relates to validation, either >> traditional XML or using a schema, how XPointers and query languages will >> be similar or different, and why, and how to best deal with the >> 'incoherence' of the multiple specs - XML's usage of entities and >> notations, XLink's relationships of resources, and the xml-stylesheet PI's >> blunt grabbing of a URL-based resource with MIME type specified in the PI. >> >> This is a pretty ugly mess, and explaining it requires a lot of throwing >> your hands in the air and saying "that's the way it is". It may >> mean a lot >> more work for the W3C to clean it up, but it'll make for a far better >> standard in the long run. >> >> >Beyond obvious cases, though, we have the classic problem of how to >> >regulate a market without killing it. We could take the Old >> >Labour/New Deal approach and nationalise everything, we could take the >> >Margaret Thatcher approach and privatise everything, or we could try >> >to be Tony Blairs and please/disappoint everyone a little without >> >taking any firm positions. >> >> On the interactions between the specs, the W3C is definitely Tony >> Blair. I >> don't think it works as well in technology as in 'real-world' >> politics, but >> others may have different views. >> >> Also, remember the W3C is barely a 'regulator' by its own terms - >> specs are >> just 'recommendations'. I'd love to see a stronger W3C, but a much more >> open one, but I can't say I expect to see that. >> >> Simon St.Laurent >> XML: A Primer / Cookies >> Sharing Bandwidth >> Building XML Applications (February) >> http://www.simonstl.com >> >> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >> (un)subscribe xml-dev >> To subscribe to the digests, mailto:majordomo@ic.ac.uk the >> following message; >> subscribe xml-dev-digest >> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) >> >> > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 8 15:12:09 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:23 2004 Subject: Regulating the XML Marketplace In-Reply-To: <199901081232.HAA12853@hesketh.net> Message-ID: <000e01be3b15$50ebb850$d3228018@jabr.ne.mediaone.net> Simon, 1) Its not that plumbing is unexiting and 2) Paul is just being honest. Linux and Java are in the same boat at XML in terms of the fact that their are different OS's and languages. Its not about the fact that something CAN be done, for example, I COULD go back to coding assembler, and I would be able to write programs, certainly SGML has been around for a while and has had mostly a supraset of XML's capabilities. The real issue is the ease of performing a task, and obtaining a momentum so that black boxes can become connected. Perhaps because XML is plumbing, it has been able to gain its own momentum. Who is the evangelist of the Web today? or of the Internet in general? or of E-mail? Certainly their are market leaders and visionaries but for truly important things, their importance can become self-evident. If I am building a house, the importance of installing plumbing is evident. Jonathan Borden http://jabr.ne.mediaone.net > > > At 05:54 AM 1/8/99 -0600, Paul Prescod wrote: > >XML is plumbing. Unlike Web-tac-toe, there is NOTHING that can be done > >with XML that could not be done with one of the dozens of proprietary, > >hierarchically structured languages that preceded it. > > I find it very sad that people don't value plumbing, argue that > infrastructure is fundamentally unexciting, and ignore the fact that > without infrastructure improvements like plumbing itself, railroads, > highways, and the Internet, we'd be in a very different place, one I don't > think too many of us relish returning to. The builders of those > improvements couldn't always see their results, but I don't think you'd > have heard them saying that there was NOTHING new that you could do with > their facilities. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Fri Jan 8 15:18:03 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:07:23 2004 Subject: XML in Electronic Commerce List Group Message-ID: <990108093354.31454@mail11.mitre.org.0> I have created a list group to discuss XML in Electronic Commerce. The purpose of the list group is to provide a forum for discussing how XML is and may be applied to EC. To subscribe send an email message to: listserv@mitre.org In the body of the message type: subscribe XML-EC-LIST Example: subscribe XML-EC-LIST John Doe See the following URL for more details: http://www.geocities.com/ResearchTriangle/ Facility/5136/XML-EC.html /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 8 15:24:01 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:23 2004 Subject: Reserved names and documentation In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAED28@RED-MSG-08> Message-ID: <001301be3b19$a0103330$d3228018@jabr.ne.mediaone.net> Andrew Layman wrote: comments inline. > > > Jonathan's statement below is an understandable error. My > original mail was > sent replying to a claim that namespaces and validation were incompatible. > I pointed out that the two were perfectly compatible in > principle, and that > any limitations one might see are limitations of current DTD > expressiveness. Perhaps this *is* the case, however the current DTD expressiveness *is* the standard. My statement is perhaps in error because I stated that there was one way to correct this, I should have wrote "At the exact instant I am writing this, I can see exactly one solution..." ;:-). > I then went on to mention that one could write an instance validatable > against a current DTD using an unmodified, namespace-oblivious processor, > but that you would have to recognize certain restrictions. We agree. > > Lacking that context, one might read the lines quoted from me at > the end and > conclude (wrongly) that those restrictions were intrinsic to namespaces. > They are not. They are merely limits of the current state of DTDs. The limits are intrinsic to the current state of affairs given the current standard and proposals. When we talk about 'validation' it is only reasonable that we talk about validation in terms of the current DTD. This is how I define the term 'validation' in the context of XML. One measure of the suitability of a new proposal, (in this case namespaces), it its ability to layer onto existing standards, e.g. XML 1.0 which includes DTD's. If we have to keep ripping apart existing standards to define new features everything gets horribly chaotic, people implement subsets that they arbitrarily choose and whole standard in general gets weakened. > > Others have pointed out either (a) algorithms for validating by modifying > DTDs or (b) new forms of schema other than DTD that are capable--today--of > supporting both validation and namespaces, with full flexibility. > The jist of my statement was that namespaces are the first part of a two part naming system for elements. Do you argee with this? or if not what the meaning of a namespace? Jon > > If this is indeed the case, as it appears to be, then namespaces have no > real meaning outside of the xxx: prefix. namespaces become > nothing more (or > less :-) than a standard naming mechanism for tags. the namespace > referenced > urn is nothing more than an arbitrary statement of who is supposed to own > the "xxx:" namespace prefix. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 15:52:48 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:23 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> <199901081232.HAA12853@hesketh.net> Message-ID: <36961B59.6461FAD6@prescod.net> [someone sent me an email to say that they got six of my last post... did anyone else have that problem?] "Simon St.Laurent" wrote: > ... > There are thousands, if not millions, of possibilities that XML enables. This is where we disagree. I don't think you can name even one. XML does not enable new applications in the sense that Java made Tic-Tac-Toe possible. XML just makes them more affordable by sharing development and R&D costs through standardized interchange. It is no coincidence that for most of the new XML-based languages being created there was a non-XML equivalent before. I'm not saying that XML is not exciting. I'm saying that there is no killer app or even "really cool demo." There will never be a demo of XML-based technology that is substantially more interesting than that same demo based on legacy or proprietary formats. Word will not instantly become more fun and exciting to use when it exports XML. Furthermore, Microsoft has built support for Word so deeply into the operating system that it will take years for XML to be as "standard" there. > Yes, you can do all kinds of junk to data in any proprietary way that you > like. You can have all the fun in the world processing data any way you > want - but when it comes time to share that information, it ain't much good. Data is shared in proprietary or legacy formats every day! We are carrying on this email conversation entirely without XML's help. If the email protocols were being invented today, they might use XML, and maybe the files would be a little easier to parse. But the email program would not do anything significantly different. (sociological factors are hard to predict...maybe if we used XML mail the idea of formatted email text would have caught on earlier and more forcefully...I'm speaking of technical factors, not sociological ones) > Of course you could do it another way, but don't we have enough damn closed > boxes already? Being non-XML is not the same as being a closed box. The first standard meta-syntax is probably the Lisp S-expression. Over several years of considering it, the only technical advantage I can come up with for XML is: "easier to type and read." That's a significant advantage, but not one that is going to lead us to a killer app or demo. > Instead of shutting down discussion by claiming that XML > isn't good for anything new, why don't we try to expand it by figuring out > how XML fits into the old and improves it significantly? Because XML alone won't improve anything significantly. At best it can save money. Perhaps it depends on what definition of XML we are using. Do we include all of the new standards that use XML syntax? Even the ones that were under development before XML existed? Extended linking can allow new applications, but extended linking predates XML and SGML. You can do extended linking with S-expressions. RDF was under development under various names before it was encoded in XML syntax. XSL is a little different. As far as I know, it is the only standardized declarative tree transformation language. It IS something new under the sun. [Rob Schoening] > I believe that this is due, in part, to the fact that XML applications > are still fairly esoteric. [unlike Java]... The applets attracted > eyeballs. The minds and ears followed. XML itself is only a serious money saver. That may not be cool enough to sustain the current hype, but I don't see that as a problem. The hype is inherently unsustainable and not useful anyhow. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "I want to give beauty pageants the respectability they deserve." - Brooke Ross, Miss Canada International xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 15:59:36 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:23 2004 Subject: Regulating the XML Marketplace In-Reply-To: <000e01be3b15$50ebb850$d3228018@jabr.ne.mediaone.net> References: <199901081232.HAA12853@hesketh.net> Message-ID: <199901081558.KAA25616@hesketh.net> [I'm hoping the XML-Dev mailer won't send this out repeatedly like it did my last posting. If it does, many apologies, and apologies for the last one.] At 09:43 AM 1/8/99 -0500, Jonathan Borden wrote: > 1) Its not that plumbing is unexiting and 2) Paul is just being >honest. Paul's honesty is fine; it's the dismissal of XML's potential that I find extraordinarily disturbing from someone so close to the standard. Calling XML plumbing is good - provided you follow up by saying that plumbing is useful, indeed critically important, not by saying that it does 'NOTHING' new. >Linux and Java are in the same boat at XML in terms of the fact that their >are different OS's and languages. Its not about the fact that something CAN >be done, for example, I COULD go back to coding assembler, and I would be >able to write programs, certainly SGML has been around for a while and has >had mostly a supraset of XML's capabilities. The real issue is the ease of >performing a task, and obtaining a momentum so that black boxes can become >connected. Linux is a great general-purpose platform, on which you can run Java, a great general-purpose multiplatform-capable OOP language, which you can use to process XML documents efficiently. If I really wanted, I could run Windows, and use programs written with Microsoft C++ that only work with files in proprietary formats. At present, the latter is definitely easier for most tasks, if frustrating in its own way. That doesn't make the Linux/Java/XML combination any less compelling - but we do need to make clear the differences between Linux and Windows, Java and C++ (and other contenders), and XML and proprietary formats instead of just throwing our hands in the air and proclaiming it all the same thing. > Perhaps because XML is plumbing, it has been able to gain its own momentum. >Who is the evangelist of the Web today? or of the Internet in general? or of >E-mail? Certainly their are market leaders and visionaries but for truly >important things, their importance can become self-evident. There are no formal 'Web evangelists', though Tim Berners-Lee is about the closest thing we've got. I proposed creating an organized group of XML evangelists at the beginning of last year, and got virtually no support. Unfortunately, I don't yet think it's clear that XML's importance is anywhere near self-evident, and its initial goal of 'SGML on the Web' seems pretty clearly forgotten. Programmers and database developers have certainly jumped on it, so it does seem to be finding a home, but I wouldn't call its importance self-evident yet. > If I am building a house, the importance of installing plumbing is >evident. It is now, but it wasn't when plumbing first came out. My grandparents sold a lake cottage in the 50's rather than bring it up to a new building code by installing indoor plumbing. Didn't seem worth the cost or the hassle to them, and the new owners got to do it, whether they wanted to or not. Plumbing is important, enabling, and prevents us from having to live in a sewer. Getting the components in order is an important first step; a second step is encouraging people to use this plumbing so we can all work on the same system, instead of thousands of separate systems. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Fri Jan 8 16:04:17 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:07:23 2004 Subject: Multiple postings (was Regulating the XML Marketplace) Message-ID: <01BE3B27.F1540010@grappa.ito.tu-darmstadt.de> Paul Prescod wrote: > [someone sent me an email to say that they got six of my last post... > did anyone else have that problem?] I got multiple postings of both your last post and Simon's last post, so it's probably not your software's fault. Whatever the cause, it seems to have stopped -- I didn't get multiple postings of later posts. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri Jan 8 16:07:19 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:23 2004 Subject: Regulating the XML Marketplace Message-ID: <5F052F2A01FBD11184F00008C7A4A800011369ED@eukbant101.ericsson.se> > -----Original Message----- > From: Paul Prescod [SMTP:paul@prescod.net] > > [someone sent me an email to say that they got six of my last post... > did anyone else have that problem?] > The strange thing is I also got 7 of Simon's replies, but everything since has been fine. Quite ironic that you mention parsing e-mail below, when I bet this is the fault of our exchange gateway... > "Simon St.Laurent" wrote: > > ... > > There are thousands, if not millions, of possibilities that XML enables. > > This is where we disagree. I don't think you can name even one. XML does > not enable new applications in the sense that Java made Tic-Tac-Toe > possible. XML just makes them more affordable by sharing development and > R&D costs through standardized interchange. It is no coincidence that for > most of the new XML-based languages being created there was a non-XML > equivalent before. > I think the problem is that XML on the web (specifically in the browser) isn't there yet. For example, prior to Java it was also possible to do Tic-Tac-Toe (or "Noughts and Crosses" as we call it in England) as a Plugin, and you could do the legwork of doing 2 plugins if you wanted to support both IE and Netscape. Java changed that. What XML in the browser will give us is this sort of benefit (and I don't mean WriteOnceRunEverywhere) - it will reduce the amount of code needed to do things like search product catalogues, import external data, etc. Yes, it's still plumbing in a way, the difference might just be in time to market though. Got XML, got XSL - you can display it. This is a whole lot simpler than a backend connected to a database that creates HTML. Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Fri Jan 8 16:13:56 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:07:23 2004 Subject: Regulating the XML Marketplace In-Reply-To: <199901081558.KAA25616@hesketh.net> References: <000e01be3b15$50ebb850$d3228018@jabr.ne.mediaone.net> <199901081232.HAA12853@hesketh.net> Message-ID: <3.0.5.32.19990108081424.00ae0eb0@scripting.com> I want to briefly add my two cents here. XML is about compatibility and working together. Paul is 100 percent right. No killer apps. The most exciting thing I ever see is deployment of interesting open documented XML apps. The specs mean nothing until something gets deployed. An example, I learned yesterday that DreamWeaver supports a plug-in archictecture that's XML-DOM based. What does this mean? I have no idea! But I'll learn about it because it's deployed in an app that lots of people use. It's what you do that isn't XML that gives your offering juice, if it's connected to XML. That and how many and what kinds of people use it. Just my opinion, of course. Dave At 10:59 AM 1/8/99 -0500, you wrote: >[I'm hoping the XML-Dev mailer won't send this out repeatedly like it did >my last posting. If it does, many apologies, and apologies for the last one.] > >At 09:43 AM 1/8/99 -0500, Jonathan Borden wrote: >> 1) Its not that plumbing is unexiting and 2) Paul is just being >>honest. > >Paul's honesty is fine; it's the dismissal of XML's potential that I find >extraordinarily disturbing from someone so close to the standard. Calling >XML plumbing is good - provided you follow up by saying that plumbing is >useful, indeed critically important, not by saying that it does 'NOTHING' new. > >>Linux and Java are in the same boat at XML in terms of the fact that their >>are different OS's and languages. Its not about the fact that something CAN >>be done, for example, I COULD go back to coding assembler, and I would be >>able to write programs, certainly SGML has been around for a while and has >>had mostly a supraset of XML's capabilities. The real issue is the ease of >>performing a task, and obtaining a momentum so that black boxes can become >>connected. > >Linux is a great general-purpose platform, on which you can run Java, a >great general-purpose multiplatform-capable OOP language, which you can use >to process XML documents efficiently. If I really wanted, I could run >Windows, and use programs written with Microsoft C++ that only work with >files in proprietary formats. At present, the latter is definitely easier >for most tasks, if frustrating in its own way. That doesn't make the >Linux/Java/XML combination any less compelling - but we do need to make >clear the differences between Linux and Windows, Java and C++ (and other >contenders), and XML and proprietary formats instead of just throwing our >hands in the air and proclaiming it all the same thing. > >> Perhaps because XML is plumbing, it has been able to gain its own momentum. >>Who is the evangelist of the Web today? or of the Internet in general? or of >>E-mail? Certainly their are market leaders and visionaries but for truly >>important things, their importance can become self-evident. > >There are no formal 'Web evangelists', though Tim Berners-Lee is about the >closest thing we've got. I proposed creating an organized group of XML >evangelists at the beginning of last year, and got virtually no support. > >Unfortunately, I don't yet think it's clear that XML's importance is >anywhere near self-evident, and its initial goal of 'SGML on the Web' seems >pretty clearly forgotten. Programmers and database developers have >certainly jumped on it, so it does seem to be finding a home, but I >wouldn't call its importance self-evident yet. > >> If I am building a house, the importance of installing plumbing is >>evident. > >It is now, but it wasn't when plumbing first came out. My grandparents >sold a lake cottage in the 50's rather than bring it up to a new building >code by installing indoor plumbing. Didn't seem worth the cost or the >hassle to them, and the new owners got to do it, whether they wanted to or >not. > >Plumbing is important, enabling, and prevents us from having to live in a >sewer. Getting the components in order is an important first step; a >second step is encouraging people to use this plumbing so we can all work >on the same system, instead of thousands of separate systems. > >Simon St.Laurent >XML: A Primer / Cookies >Sharing Bandwidth >Building XML Applications (March) >http://www.simonstl.com > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > ----------------------------- http://www.scriptingnews.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mark at conveyor.com Fri Jan 8 16:18:34 1999 From: mark at conveyor.com (Mark Baker) Date: Mon Jun 7 17:07:23 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> <199901081232.HAA12853@hesketh.net> <36961B59.6461FAD6@prescod.net> Message-ID: <36963038.246813BD@beduin.com> Paul Prescod wrote: > There will never be a demo of > XML-based technology that is substantially more interesting than that same > demo based on legacy or proprietary formats. Could this be because you're thinking of a demo on a standalone PC rather than one executed over a network? How about any app that works between tens or hundreds of partnered companies over the Net? Say a supply chain management "system", where no single vendor/supplier has the same software as anybody else - it could all be proprietary - but they all talk XML (and agree on DTDs, or just specific tags & semantics, etc..). The true value of XML, IMHO, is in its potential to become ubiquitous. MB -- Mark Baker, Personal Apps Lead Sun Microsystems Inc. Ottawa, Ontario, CANADA. http://java.sun.com/products/personalapps xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Fri Jan 8 16:23:40 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:07:24 2004 Subject: Chinese pages now available Message-ID: <005a01be3b23$25f30410$51f96d8c@NT.JELLIFFE.COM.AU> The Chinese pages on the "Chinese XML Now!" site are now online. The Chinese FAQ, terminology and test pages are available in Chinese. The files are available in UTF-8 and Big5, with GB2312 to come. The site is (fingers crossed) all HTML-in-XML, using voyager, so you can use the site as general XML test pages too. http://www.ascc.net/xml/ We are currently working on a project which will put up to 100 meg of Chinese text online in XML (TEI) and perhaps with some kind of Xpointer linkability, too. The site is still aimed at Western developers, but will gradually move to catering to Chinese developers after products support Chinese better. We have had pretty good response from many developers so far. If you want to test your product, a good file to use is http://www.ascc.net/xml/test/wfall/utf-8/test13.xml which has almost all the Chinese tests rolled into a single file, with guiding comments. Please feel free to add this file to your test suites: if you handle this file correctly, your product is probably acceptable for international markets, as far as its XML IO is concerned. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Fri Jan 8 16:27:16 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace Message-ID: <01BE3B2A.DC4B7330@grappa.ito.tu-darmstadt.de> Paul Prescod wrote: > Because XML alone won't improve anything significantly. At best it can > save money. I suppose this depends on whether "XML" means strictly the language (in which case I agree) or the use of the language (in which case I disagree strongly). Personally, I think it's meaningless to separate the two. For example, the Internet existed before the Web did and I suspect everything that is possible over the Web today was possible before it existed -- we could just as well have FTP'ed SGML files back and forth. The Web made Web-like stuff easy, it caught the public's imagination, and off we went. Similarly, we can probably do everything that is possible with XML without XML, but that's largely irrelevant. We live in a world filled with humans -- not exactly the most rational species ever to roam the earth -- and discussing technology without discussing ease of use, marketing strategies, development costs, fad factors, and so on is a waste of time if you're t rying to figure out where the future lies. I think XML has a great chance to change the world in the same way the Web did simply because it gives us a standard data transport that is likely to be widely accepted. And that acceptance is likely to inspire a whole lot of applications that are possible today, but aren't being written for all of the human, not technical, reasons. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.S.Brothers at EMCIns.Com Fri Jan 8 16:32:16 1999 From: Michael.S.Brothers at EMCIns.Com (Michael S. Brothers) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace In-Reply-To: <5F052F2A01FBD11184F00008C7A4A800011369ED@eukbant101.ericsson.se> Message-ID: Hello, I am not a developer, but a manager/philosopher (sounds more high-falutin' than it is) interested in new tools to enhance web-based commerce. I therefor welcome this recent discussion in lieu of the highly technical ones that have dominated the last few weeks. Paul, Simon, Matthew et al. all have some extremely good points. The key one to me is that 'flash' is not what's at stake here. I think Paul is saying that flash is necessary to get people excited about using a new tool, otherwise the idea becomes diluted and everyone goes their own merry way. From what I can tell, XML is possibly (possibly) the gateway toward better standardization of Web-commerce (write all the cool stuff you want, you still gotta pay the bills). If apps are easier to write in XML, and thus cheaper, all the better. If XML-based apps increase on the woeful capability of HTML to do web-commerce, exchange information, and facilitate translation and storage of generated data into legacy systems via the Internet, hoorah. Sell that to the people who will actually make the decisions on what to buy and people will get very excited about XML and the apps it helps to develop. The electronic marketplace and information clearinghouse in place today is a jumble of value-added networks, proprietary systems, incompatible protocols, yada yada yada. XML might not be THE answer to clean it all up, but it does appear to be a good move in that direction. Michael S. Brothers Michael.S.Brothers@EMCIns.com 515-362-7473 "I like different foods. Ham, bacon, pork chops." "But Dad, those all come from the same animal." "Yesss, Lisa. A wonderful, magical animal." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 16:39:08 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace In-Reply-To: <36963038.246813BD@beduin.com> References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> <199901081232.HAA12853@hesketh.net> <36961B59.6461FAD6@prescod.net> Message-ID: <199901081636.LAA25738@hesketh.net> At 11:20 AM 1/8/99 -0500, Mark Baker wrote: >The true value of XML, IMHO, is in its potential to become ubiquitous. Precisely. The ability for a thousand different applications to share identical plumbing is a significant step forward, not something to be sniffed at by jaded experts. This isn't just for the bean counters - XML means that people can finally start sharing data without everyone needing to have precisely the same set of tools. Sharing a format like this can reduce costs across the board, not to mention aggravation. Reducing costs makes it possible to create much grander applications and move into new fields. XML is an excellent fit for component-based development, allowing people to use each other's work instead of having to reinvent the wheel constantly. Less need for reinvention means more time for real work. I'm at work building tools and documents I hope will contribute to this movement, and I hope others are as well. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From skshirsa at nortelnetworks.com Fri Jan 8 16:51:55 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace Message-ID: <3.0.32.19990108114816.006f144c@bl-mail2.corpeast.baynetworks.com> I agree with Matt. I think way of exchanging structure information on Web in an interoperable way - XML or something else, is the need of today and tomorrow. The earlier standards for data exchange didn't become popular may be because enough initiative was not there to support those standards in the Web environments. XML is not great but most importantantly it's simple and so widespread support of XML seems to be feasible in near future. Eventually XSL will allow easy & flexible display of of XML data in the browsers. I see lot of opportunity for XML based applications once the Web browsers have a stabilized support for XML/XSL/DOM. May not be just XML, but XML + XSL + DOM support within popular browsers is definitely exciting and opens lot of opportunities for killer apps. Shekhar Kshirsagar Nortel Networks. At 05:04 PM 1/8/99 +0100, Matthew Sergeant (EML) wrote: > I think the problem is that XML on the web (specifically in the >browser) isn't there yet. For example, prior to Java it was also possible to >do Tic-Tac-Toe (or "Noughts and Crosses" as we call it in England) as a >Plugin, and you could do the legwork of doing 2 plugins if you wanted to >support both IE and Netscape. Java changed that. What XML in the browser >will give us is this sort of benefit (and I don't mean >WriteOnceRunEverywhere) - it will reduce the amount of code needed to do >things like search product catalogues, import external data, etc. Yes, it's >still plumbing in a way, the difference might just be in time to market >though. Got XML, got XSL - you can display it. This is a whole lot simpler >than a backend connected to a database that creates HTML. > > Matt. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Fri Jan 8 16:53:45 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace In-Reply-To: <199901081636.LAA25738@hesketh.net> References: <36963038.246813BD@beduin.com> <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> <199901081232.HAA12853@hesketh.net> <36961B59.6461FAD6@prescod.net> Message-ID: <3.0.5.32.19990108085245.00ae22d0@scripting.com> >The true value of XML, IMHO, is in its potential to become ubiquitous. Precisely. The ability for a thousand different applications to share identical plumbing is a significant step forward, not something to be sniffed at by jaded experts. --- That's where this whole thing gets hung up, IMHO, in the breathless self-importance. I've seen this over and over, in communities that thought that what they were doing is so cool that all they had to do is believe it would be huge and it would be. General Magic, Newton, Java come to mind. There have been many others. (OpenDoc, HyperCard, integrated software, object oriented programming, hey what about "push"). You're not necessarily involved in writing the Constitution or the Magna Carta. This stuff could easily all turn out to be irrelevant. Realistically right now it *is* irrelevant. Only if we start focusing on deploying apps that break down walls can it become relevant. Let's get some practical benefits delivered to end users and be more prosaic and realistic and entrepreneurial about what we're doing here. ----------------------------- http://www.scriptingnews.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From begeddov at jfinity.com Fri Jan 8 17:13:02 1999 From: begeddov at jfinity.com (Gabe Beged-Dov) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace Message-ID: <004901be3b29$fc9a9680$160016c0@jfinity1> >At 11:20 AM 1/8/99 -0500, Mark Baker wrote: >>The true value of XML, IMHO, is in its potential to become ubiquitous. > >Precisely. The ability for a thousand different applications to share >identical plumbing is a significant step forward, not something to be >sniffed at by jaded experts. > >This isn't just for the bean counters - XML means that people can finally >start sharing data without everyone needing to have precisely the same set >of tools. Sharing a format like this can reduce costs across the board, >not to mention aggravation. I want to focus on what I see is the key one for XML. XML as an interchange format, and the various XDK (XML development kits), __potentially__ lower the barrier to entry of application development. This is especially true if the application is part of a deployment environment that is made up of loosely coupled applications. One critical requirement for XML and XDK is that they be good framework citizens. This means supporting both layered architectures and peer architectures. As Simon has mentioned in several postings, there are some significant problems with the current crop of XML specifications and XDK offerrings in the area of layering and peer functionality. An example of layering problems are the coupling of well-formedness and validation in both the specs and the tools. An example of peer problems is the multiple ways to point at something (entity, XPointer, idref). All of these problems are addressable by creating monolithic specs and XDK that dictate a certain configuration of layering and peer services. At some point though, this catches up with you. This was one of the main reasons I created XArc (www.jfinity.com/xarc). I thought there should be a simple low level linking construct on top of which higher level services like XLink and RDF were layered. But I guess that would be too easy :-) Gabe Beged-Dov xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From JEROME.YUROW at hq.doe.gov Fri Jan 8 17:18:54 1999 From: JEROME.YUROW at hq.doe.gov (JEROME.YUROW@hq.doe.gov) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace Message-ID: All this talk about finding a "killer ap" or even a "clever ap" for XML has me puzzled. The most obvious "killer ap" for XML is as a medium for business-to-business electronic data interchange (EDI) and systems integration for the rest of us, i.e. the small to medium size businesses of the world. Sure the AT&T's and other large corporations have their proprietary networks and software for doing EDI, but XML enables the vast, rest of the world to use both a publicly available, i.e. inexpensive, network and to acquire, if not create its own, software at a price much lower than anything the established EDI software vendors are asking. This is clearly revolutionary and threatening to the "EDI establishment." For evidence, just root around the web site, for example, of the Data Interchange Standards Association (DISA), www.disa.org. Check out their membership list and see what kind of attention they're giving to this newfangled "XML technology". There are two companies that I have found that appear to be in the forefront of the XML-EDI revolution (and perhaps others can find more): WebMethods (www.webmethods.com) and Datachannel (www.datachannel.com). xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 17:42:27 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace References: <000501be3a98$1a0d45b0$bda8b4d1@yak.ptld.uswest.net> <199901081232.HAA12853@hesketh.net> <36961B59.6461FAD6@prescod.net> <36963038.246813BD@beduin.com> Message-ID: <3696416C.7952F913@prescod.net> Mark Baker wrote: > > How about any app that works between tens or hundreds of partnered companies over > the Net? Say a supply chain management "system", where no single vendor/supplier > has the same software as anybody else - it could all be proprietary - but they all > talk XML (and agree on DTDs, or just specific tags & semantics, etc..). They do the same thing with EDIFACT. It's just that it is more expensive (another pre-XML specification). It is also less flexible, but that is because EDIFACT's ideas are very old, not because its syntax could not be made flexible. > The true value of XML, IMHO, is in its potential to become ubiquitous. Right. Ubiquity saves money. Saving money is a Good Thing. It allows you to spend money on doing more interesting stuff. Please recall that the genesis of this thread was in the call for XML evangelism, an XML killer app etc. Cool plumbing doesn't need evangelism (rah! rah! Unicode!). And it defies killer apps. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "I want to give beauty pageants the respectability they deserve." - Brooke Ross, Miss Canada International xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 8 17:45:13 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace References: <199901081232.HAA12853@hesketh.net> <199901081558.KAA25616@hesketh.net> Message-ID: <36963E79.C8A92E03@prescod.net> "Simon St.Laurent" wrote: > > Paul's honesty is fine; it's the dismissal of XML's potential that I find > extraordinarily disturbing from someone so close to the standard. Calling > XML plumbing is good - provided you follow up by saying that plumbing is > useful, indeed critically important, not by saying that it does 'NOTHING' new. "Nothing new" and "critically important" are not contradictory statements. Mac users dismiss Windows 9X's user interface as derivative. Unix users dismiss NT's connectivity similarly. Still, the deployment of these OLD technologies on millions of desktops is pretty exciting. I think that our real disagreement is not on technology or potential. We disagree on marketing. Five years ago I would have been very annoyed had I read someone speaking of SGML that way. After all, the "world" had not yet caught on to SGML's potential and to me, promoting it was a moral necessity. The world was wasting huge amounts of money translating between incompatible formats and it wasn't going to stop doing that if SGML users went around trumpetting its flaws. When XML came along, I stopped promoting SGML, XML or generic markup. It doesn't need promoting. The meme is out there. It has caught hold. It is the leader in various data interchange fields. It can only be displaced by something better. So now I don't feel any need to sugar coat the fact that XML doesn't allow anything new, it just saves time and money. Once again, I do think that XSL does allow some new stuff, so there *is* cool stuff you can demo: but the demo watchers won't know or care if the input is XML or Lisp s-expressions or Python pickles. > There are no formal 'Web evangelists', though Tim Berners-Lee is about the > closest thing we've got. I proposed creating an organized group of XML > evangelists at the beginning of last year, and got virtually no support. That's because saving money does not need to be evangelized! It's the *one* thing that sells itself! In many of XML's markets (unlike many of SGML's markets) the move to XML actually saves money in the short, medium and long terms. Traditionally SGML has only saved money in the long term. I am going to go so far as to claim that XML evangelism works AGAINST connectivity and productivity. Because of the hype we rush out specifications without properly aligning them ("data model? no time. do it later.") and standardize ideas that have not been proven in the field yet. If XML was less of a high-profile standard, we could go back now and make some tweaks based on experience.We are also reinventing wheels because few people want to take the time to research existing technologies (i.e. is OQL an XML query language? If not, how not? If so, do we need XQL) When the XML hype goes away (approx 2 years from now) we will be able to take a more careful, deliberative approach to standards-based data interchange. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "I want to give beauty pageants the respectability they deserve." - Brooke Ross, Miss Canada International xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bryan.cooper at veritas.com Fri Jan 8 18:25:38 1999 From: bryan.cooper at veritas.com (Bryan Cooper) Date: Mon Jun 7 17:07:24 2004 Subject: XML in the Marketplace (was Regulating) In-Reply-To: Message-ID: <199901081825.KAA21513@mailhub1.ncal.verio.com> One thing is that EDI has been around for quite a while, has vendors who make money from it, have apps including many legacy apps that support it, etc. etc. Alot of the commercial space can use EDI over the internet for example, but often EDI is run through private networks such as manufacturer ordering parts for inventory. To get them to use XML or EDI inside XML won't make much sense unless theres' additional functionality. Or, over next say 5 years XML will start to replace EDI in some of these shops, but they'll still need to support EDI since alot of smaller shops won't/can't replace their inventory software due to cost issues. To get vendors or app people in a specific technology sector, like EDI, to start using XML faster or more extensively is not an easy thing. What often happens is they'll say "we support XML" in the sense that they have a EDI/XML conversion utility. That's a good first step, but it MAY become the only step for XML. Killer apps have the ability to solve an existing problem or demonstrate some advanced approach AND have the additional psychological ability to get vendors (like EDI vendors) to review their level of committment to that technology. XML is clearly in need of three things: 1) Products that use existing XML standard 2) Products that promote their use of XML to solve problems. 3) People who promote #1 and #2 One thing that can be done easily is for the XML web site to easily allow vendors using embedded XML in their products to be found there. a page setup with a group of subpages based on product category could start showing the universe at large just how many products are using XML at some level. a simple form would allow people to insert their web sites into that list...there may be alot more XML apps there than people realize. At 12:02 PM 1/8/99 -0500, JEROME.YUROW@hq.doe.gov wrote: > All this talk about finding a "killer ap" or even a "clever ap" for > XML has me puzzled. The most obvious "killer ap" for XML is as a > medium for business-to-business electronic data interchange (EDI) and > systems integration for the rest of us, i.e. the small to medium size > businesses of the world. Sure the AT&T's and other large corporations > have their proprietary networks and software for doing EDI, but XML > enables the vast, rest of the world to use both a publicly available, > i.e. inexpensive, network and to acquire, if not create its own, > software at a price much lower than anything the established EDI > software vendors are asking. This is clearly revolutionary and > threatening to the "EDI establishment." For evidence, just root > around the web site, for example, of the Data Interchange Standards > Association (DISA), www.disa.org. Check out their membership list and > see what kind of attention they're giving to this newfangled "XML > technology". > > There are two companies that I have found that appear to be in the > forefront of the XML-EDI revolution (and perhaps others can find > more): WebMethods (www.webmethods.com) and Datachannel > (www.datachannel.com). > ...bryan F. Bryan Cooper 707 823 7324 VERITAS Software 707 321 3301 mobile Bryan.Cooper@veritas.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 8 18:56:55 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:24 2004 Subject: Regulating the XML Marketplace In-Reply-To: <36963E79.C8A92E03@prescod.net> References: <199901081232.HAA12853@hesketh.net> <199901081558.KAA25616@hesketh.net> Message-ID: <199901081856.NAA12245@hesketh.net> At 11:20 AM 1/8/99 -0600, Paul Prescod wrote: >I think that our real disagreement is not on technology or potential. We >disagree on marketing. [...] >When XML came along, I stopped promoting SGML, XML or generic markup. It >doesn't need promoting. The meme is out there. It has caught hold. It is >the leader in various data interchange fields. It can only be displaced by >something better. So now I don't feel any need to sugar coat the fact that >XML doesn't allow anything new, it just saves time and money. Then say that it saves time and money, don't just mutter about how nothing is new. Saving time and money sells itself... doing NOTHING sells NOTHING. >I am going to go so far as to claim that XML evangelism works AGAINST >connectivity and productivity. Because of the hype we rush out >specifications without properly aligning them ("data model? no time. do it >later.") and standardize ideas that have not been proven in the field yet. >If XML was less of a high-profile standard, we could go back now and make >some tweaks based on experience.We are also reinventing wheels because few >people want to take the time to research existing technologies (i.e. is >OQL an XML query language? If not, how not? If so, do we need XQL) > >When the XML hype goes away (approx 2 years from now) we will be able to >take a more careful, deliberative approach to standards-based data >interchange. When XML is better understood by a wiser and _significantly_ larger community we might be able to take a more careful, deliberative approach to examine how XML fits in the world or doesn't. If you don't expand that community, you're going to have the same 30 people in the same room talking about how a more careful, deliberative approach can do a better job of the same old thing. Like it or not, this community needs to be expanded. The meme may be contagious enough to survive, but it's not infected enough people and organizations in a strong enough way for it to grow without a significant push. Is there anyone in the XML community who really isn't too busy? Couldn't use some help getting projects out the door? If you don't grow the user community, don't expect the meme to develop. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sat Jan 9 15:55:40 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:25 2004 Subject: Seeking SAX filters Message-ID: <199901091555.KAA07004@hesketh.net> I'm trying to build a list of filters available for SAX, the Simple API for XML. Right now, I have: David Megginson's XAF. John Cowan's ParserFilter abstract class, his NamespaceFilter, and his InheritanceFilter. James Clark's XT XSL tree construction implementation My own XLinkFilter and LocationFilter. Anyone else out there? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gberthet at netcom.com Sun Jan 10 08:02:10 1999 From: gberthet at netcom.com (Gerard Berthet) Date: Mon Jun 7 17:07:25 2004 Subject: subscribe xml-dev gberthet@netcom.com Message-ID: <002a01be3c6f$8242b9c0$0c00a8c0@dell450> subscribe xml-dev gberthet@netcom.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rick at activated.com Sun Jan 10 12:52:58 1999 From: rick at activated.com (Rick Ross) Date: Mon Jun 7 17:07:25 2004 Subject: [ANN] Activated XSL Servlet Demo Online Message-ID: <3698A29E.5C3099AF@activated.com> Activated Intelligence has put a modest demo page online for AXSL - the Activated XSL Processor. Not too many people have had a chance to see XML and XSL in real world scenarios yet, so we thought it might be worthwhile to show how we use it to drive the Java Lobby website. The demo page is: http://www.javalobby.org/axsl.html Enjoy! Rick Ross Activated Intelligence ----- Unite for Java - Join the Java Lobby now! http://www.javalobby.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sblackbu at erols.com Sun Jan 10 13:14:42 1999 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:07:25 2004 Subject: [ANN] WFC 38 is out (and a question) Message-ID: <003601be3c9b$1d03fa70$01010101@sammy> I just published release 38 of my freeware Win32 Foundation Classes (WFC) library. The XML classes have had several bugs fixed as well as adding new functionality. You can now control how strict or sloppy the parser is. While doing this work, I came across a situation that I don't believe is covered in the specification. Consider the following snippet:

Text

More Text

Less Text

Is this valid XML? " More Text " is orphaned. In WFC, I force the document to always have an XML declaration as the root node whether or not one appeared in the original data stream. All of these orphaned text segments are children of the root node. http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Jan 10 13:55:08 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:25 2004 Subject: Seeking 'DOM filters' Message-ID: <199901101354.IAA16672@hesketh.net> As long as I'm looking around for SAX filters (see my previous post), I thought I might also look around for generic DOM processors - software that takes a DOM tree (from any parser, not just one implementation), and does something to it or with it, and gives it back to the application. I'm not sure what to call this - DOM filter doesn't sound quite right - but it seems like there should be processors out there like this. If anyone has something, let me know. Thanks to those who sent SAX filter references, and more are always welcome. Thanks! Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Sun Jan 10 17:05:31 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:25 2004 Subject: [ANN] WFC 38 is out (and a question) Message-ID: <001901be3cbb$bad7ac40$0300000a@othniel.cygnus.uwa.edu.au> -----Original Message----- From: Samuel R. Blackburn >While doing this work, I came across a situation that I don't believe is >covered in the specification. Consider the following snippet: > >

Text

More Text

Less Text

> >Is this valid XML? " More Text " is orphaned. For a start, I'm not sure you mean "valid". Remember that validity requires a DTD. So assuming you really mean "is this well-formed XML" the answer is no. Production [1] makes it clear that there must be a single root, or document element. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Associate Researcher, Electronic Commerce Network Curtin University of Technology, Perth, Western Australia Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sun Jan 10 18:44:03 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:25 2004 Subject: [ANN] WFC 38 is out (and a question) In-Reply-To: <003601be3c9b$1d03fa70$01010101@sammy> Message-ID: <000001be3cc8$b2ef1010$d3228018@jabr.ne.mediaone.net> This fragment appears to be a valid, well-formed HTML document but not a valid nor well formed XML document. HTML, which has an SGML DTD, allows both the HTML and BODY tags to be optional. Under XML optional tags are not provided for. Hence, the normalized HTML document derived from the stream is:

Text

More Text

Less Text

which is also well formed XML. Jonathan Borden http://jabr.ne.mediaone.net ... Consider the following snippet: > >

Text

More Text

Less Text

> > Is this valid XML? " More Text " is orphaned. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sun Jan 10 18:47:21 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:25 2004 Subject: Seeking 'DOM filters' In-Reply-To: <199901101354.IAA16672@hesketh.net> Message-ID: <000101be3cc9$123ec830$d3228018@jabr.ne.mediaone.net> Does an XSL or DSSSL transformation count? Jonathan Borden http://jabr.ne.mediaone.net > > As long as I'm looking around for SAX filters (see my previous post), I > thought I might also look around for generic DOM processors - > software that > takes a DOM tree (from any parser, not just one implementation), and does > something to it or with it, and gives it back to the application. > > I'm not sure what to call this - DOM filter doesn't sound quite > right - but > it seems like there should be processors out there like this. > > If anyone has something, let me know. Thanks to those who sent SAX filter > references, and more are always welcome. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Jan 10 19:15:04 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:25 2004 Subject: Seeking 'DOM filters' In-Reply-To: <000101be3cc9$123ec830$d3228018@jabr.ne.mediaone.net> References: <199901101354.IAA16672@hesketh.net> Message-ID: <199901101914.OAA02983@hesketh.net> At 01:43 PM 1/10/99 -0500, Jonathan Borden wrote: >Does an XSL or DSSSL transformation count? Provided it takes its input as a standard DOM tree, and returns its output as a standard DOM tree, without relying on parser-specific implementations outside the W3C DOM spec, I'd be happy to include it. Most likely, given the DOM spec, it would be written in Java, but I'd be willing to mention and examine DOM implementations in JavaScript or other languages. (Yes, I realize that trees are a little stranger to 'filter' than events.) Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Sun Jan 10 19:30:05 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:07:25 2004 Subject: [ANN] WFC 38 is out (and a question) Message-ID: <000901be3ccf$74279300$22acdccf@ix.netcom.com> >

Text

More Text

Less Text

> Is this valid XML? " More Text " is orphaned It depends on your DTD, if the root element allows PCDATA then it is perfectly valid. frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) ----- Original Message ----- From: Samuel R. Blackburn To: Sent: Sunday, January 10, 1999 8:14 AM Subject: [ANN] WFC 38 is out (and a question) >I just published release 38 of my freeware Win32 Foundation Classes (WFC) >library. The XML classes have had several bugs fixed as well as adding new >functionality. You can now control how strict or sloppy the parser is. > >While doing this work, I came across a situation that I don't believe is >covered in the specification. Consider the following snippet: > >

Text

More Text

Less Text

> >Is this valid XML? " More Text " is orphaned. > >In WFC, I force the document to always have an XML declaration >as the root node whether or not one appeared in the original data >stream. All of these orphaned text segments are children of the >root node. > >http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Sun Jan 10 20:22:54 1999 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:07:25 2004 Subject: Regulating the XML Marketplace Message-ID: <199901102018.MAA10693@boethius.eng.sun.com> > [about the highly secretive, smoke-filled XML Coordination group, aka > The Syndicate] FYI, the Coordination Group just schedules meetings, manages formal communications among working groups, and takes care of other administrivia; it doesn't make policy. But the point about secrecy is well taken. The W3C didn't start out as a standards organization but as a consortium for the development of advanced technology. Its confidentiality rules (which for many of us working within the structure are a source of considerable annoyance) have historically been justified by the fact that the members of the consortia often reveal product plans in the course of designing the recommendations. Personally, I believe that the W3C will have to evolve toward a more open way of doing business if it's going to continue to function as a standards body, but for the present all the participants are bound by stringent contractual agreements to maintain confidentiality. That's just a legal reality that we have to live with right now. The good news is that the basic direction of each project is determined by the requirements it is attempting to meet and, within the XML activity at least, we have recently adopted a process that makes those requirements public early in the life cycle of each project, invites public discussion of those requirements in archived mailing lists, and requires the requirements to be reviewed periodically. One of the XML WGs, the XML Fragment WG, has already published its requirements; see http://www.w3.org/TR/NOTE-XML-FRAG-REQ This is a preview of what you will see coming from the other XML WGs. Schedules slip around a bit, especially in the WGs with the most complicated problems to solve, but all of the remaining XML WGs are currently on schedules that will result in publication of their requirements documents some time in February if all goes well. The first review period following initial publication of the requirements documents will last about a month. Participation in the public discussions of these requirements on the mailing lists that will be set up for this purpose offers the best opportunity for input to the W3C design process as presently constituted. It will be interesting to see how many people take advantage of it. Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems 901 San Antonio Road, MPK17-101, Palo Alto, California 94303 ISO/IEC JTC1/SC34::NCITS V1::OASIS:: Chair, W3C XML Coordination Group ---------------------------------------------------------------------- You regard it much too much as a matter of course that one can tell anything to anyone. -- Wittgenstein ---------------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Sun Jan 10 22:37:33 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:25 2004 Subject: Seeking SAX filters In-Reply-To: <199901091555.KAA07004@hesketh.net> References: <199901091555.KAA07004@hesketh.net> Message-ID: * Simon St.Laurent | | I'm trying to build a list of filters available for SAX, the Simple | API for XML. | | [...list deleted...] | | Anyone else out there? Geir Ove Gr?nmos xmlarch is a SAX filter for the Python version of SAX. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Sun Jan 10 22:42:58 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:25 2004 Subject: [ANN] WFC 38 is out (and a question) In-Reply-To: <000001be3cc8$b2ef1010$d3228018@jabr.ne.mediaone.net> References: <000001be3cc8$b2ef1010$d3228018@jabr.ne.mediaone.net> Message-ID: * Samuel R. Blackburn | |

Text

More Text

Less Text

| | Is this valid XML? " More Text " is orphaned. * Jonathan Borden | | This fragment appears to be a valid, well-formed HTML document but | not a valid nor well formed XML document. It is not a valid HTML document, simply because it has no DOCTYPE declaration. This makes it impossible for an SGML parser to infer the document element type as well as the omitted tags. Wqell-formed does not apply to HTML, although the newest SGML TC has some terms that are more or less equivalent (although finer-grained) with well-formed. | HTML, which has an SGML DTD, allows both the HTML and BODY tags to | be optional. It does, but TITLE is required (and missing in this document). So even with a DOCTYPE this would still be invalid. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gberthet at netcom.com Mon Jan 11 01:41:42 1999 From: gberthet at netcom.com (Gerard Berthet) Date: Mon Jun 7 17:07:25 2004 Subject: Regulating the XML Marketplace Message-ID: <015b01be3d03$6f6c0920$0c00a8c0@dell450> Easy it is, indeed! But the real business benefits will be in the low life-cycle cost for app vendors to interoperate with other third-party apps. Clearly, there is tremendous information to be shared across heterogeneous apps. For example, how many apps have the same person name in their database? the same equipment identifier (IP address) in their database? First, because so many apps duplicate the same information, add developers would benefit tremendously from extracting the data from a single recognized data provider (ERP app and SNMP platform respectively, in the examples above). That done, the app vendor can then focus on adding real value to its app. XML makes this data exchange possible, but as was pointed out, this is not revolutionary. The biggest value XML brings is that, in the past, an app vendor was very reluctant to support other vendor-proprietary APIs to support such data exchange, not because it was not feasible, but because it was cost-prohibitive. Imagine an application having to interoperate with one or more app, each app having a couple of releases in the market, each release on several UNIX flavors & versions and MS platforms. A great deal of development resources had to be allocated just to maintain the status-quo, constantly catching up with the latest release. This model was fundamentally broken. With XML, interoperability is simpler for both data producers and consumers, and needs only to be implemented once for all apps and platforms, clearly relieving valuable development resources to add real value to the app and eventually to the end-user, killer app or not. That is, in my opinion, how XML will gain ground. Regards, Gerard -----Original Message----- From: Shekhar Kshirsagar To: xml-dev@ic.ac.uk Date: Friday, January 08, 1999 8:52 AM Subject: RE: Regulating the XML Marketplace >I agree with Matt. >I think way of exchanging structure information on Web in an interoperable >way - >XML or something else, is the need of today and tomorrow. > >The earlier standards for data exchange didn't become popular may be >because enough >initiative was not there to support those standards in the Web environments. >XML is not great but most importantantly it's simple and so widespread >support of XML >seems to be feasible in near future. > >Eventually XSL will allow easy & flexible display of of XML data in the >browsers. >I see lot of opportunity for XML based applications once the Web browsers >have a >stabilized support for XML/XSL/DOM. > >May not be just XML, but XML + XSL + DOM support within popular browsers is >definitely exciting and opens lot of opportunities for killer apps. > >Shekhar Kshirsagar >Nortel Networks. > >At 05:04 PM 1/8/99 +0100, Matthew Sergeant (EML) wrote: >> I think the problem is that XML on the web (specifically in the >>browser) isn't there yet. For example, prior to Java it was also possible to >>do Tic-Tac-Toe (or "Noughts and Crosses" as we call it in England) as a >>Plugin, and you could do the legwork of doing 2 plugins if you wanted to >>support both IE and Netscape. Java changed that. What XML in the browser >>will give us is this sort of benefit (and I don't mean >>WriteOnceRunEverywhere) - it will reduce the amount of code needed to do >>things like search product catalogues, import external data, etc. Yes, it's >>still plumbing in a way, the difference might just be in time to market >>though. Got XML, got XSL - you can display it. This is a whole lot simpler >>than a backend connected to a database that creates HTML. >> >> Matt. >> > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Mon Jan 11 02:26:20 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:07:25 2004 Subject: expat 1.0.2 Message-ID: <36995046.37F7123A@jclark.com> Expat 1.0.2 is now avaiable. See http://www.jclark.com/xml/expat.html This release fixes one rather nasty bug that was discovered in 1.0.1. There's also a new test release in ftp://ftp.jclark.com/pub/test/expat.zip which also includes this bug fix. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From vivi at odi.com Mon Jan 11 02:56:56 1999 From: vivi at odi.com (Vittorio Viarengo) Date: Mon Jun 7 17:07:25 2004 Subject: Free Beta for XML Data Server Message-ID: <000c01be3d0d$9342f2a0$0b1403c6@pc-vivi.odi.com> All, I know you want to stay up to date on the latest XML products and technologies, so I thought you'd be interested in knowing that there is a free beta version of Object Design's eXcelon XML data server available on our Web site (http://www.objectdesign.com). eXcelon is a high performance, highly scalable XML data server. It's used to build enterprise XML Web applications and can be used with existing data sources as a middle-tier application cache or in stand-alone mode as a back-end data source. Key features include: - Support for XML and DOM - Support for SQL - In-memory distributed XML database - Comprehensive tool suite Unlike relational-based approach, eXcelon fully leverages XML flexibility and extensibility by storing XML in its native format. You can find the free eXcelon beta under the "shortcut" menu the Object Design home page. Please feel free to contact me if you would like additional information regarding eXcelon. I hope you find this useful Sorry for the intrusion Regards Vittorio xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Mon Jan 11 10:29:36 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:07:26 2004 Subject: Schema software Message-ID: <01BE3D54.D4485550@grappa.ito.tu-darmstadt.de> What publicly available software uses the XML schema languages (XSchema, DCD, SOX, XML-Data)? I am curious about general schema tools, such as converters and validators, and software that uses a schema language, such as parsers and editors. The only software I am aware of is: * JUMBO: uses XSchema to drive editing * Microsoft/DataChannel parser: uses XML-Data to expose DTD information -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hassan.hussein at zurich.com Mon Jan 11 11:11:50 1999 From: hassan.hussein at zurich.com (hassan.hussein@zurich.com) Date: Mon Jun 7 17:07:26 2004 Subject: No subject Message-ID: I am working on a solution to convert a text file to valid XML. I have created the DTD and the XML document but when I try to display the XML file in the browser (IE5 beta) then the browser displays the whole XML file including tags. Does anyone know where I am getting wrong. I am new to the XML field. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From vivi at odi.com Mon Jan 11 13:09:10 1999 From: vivi at odi.com (Vittorio Viarengo) Date: Mon Jun 7 17:07:26 2004 Subject: Free Beta for XML Data Server - correction - Message-ID: <003501be3d63$057ce380$0b1403c6@pc-vivi.odi.com> All, --- Correction --- eXcelon support XQL and not SQL as I stated in my previous message. Sorry for that... Regards Vittorio Vittorio xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From skshirsa at nortelnetworks.com Mon Jan 11 13:18:10 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:07:26 2004 Subject: Message-ID: <3.0.32.19990111080234.006c3d08@bl-mail2.corpeast.baynetworks.com> You need to have XSL Style sheet attached to the XML document to display the XML document in the format you need. If you don't specify XSL, the browser by default displays the XML document in tree structure. Thanks, Shekhar Kshirsagar Nortel Networks At 10:16 AM 1/11/99 +0000, hassan.hussein@zurich.com wrote: > > >I am working on a solution to convert a text file to valid XML. I have created >the DTD and the XML document but when I try to display the XML file in the >browser (IE5 beta) then the browser displays the whole XML file including tags. >Does anyone know where I am getting wrong. I am new to the XML field. > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mynzito at sinectis.com.ar Mon Jan 11 15:44:17 1999 From: mynzito at sinectis.com.ar (N. y M. Zito) Date: Mon Jun 7 17:07:26 2004 Subject: Regulating the XML Marketplace Message-ID: <3.0.6.32.19990111123714.0079e100@pop.sinectis.com.ar> 1. XML and appls interconection The point mentioned by Gerard Berthet is, in my opinion, the biggest inmediate achievable benefit of XML. That is: interoperation between appls. As an appls. developer I have usually faced the problems he mentioned. I work in Laboratory Info. Systems, where we usually have to parse ASCII reports generated by lab. instruments to transfer the extracted data to the lab system. There are hundreds of instrument providers (and instruments), each with their own formats. This is an area where using XML may be of incredible benefit. It would be very simple for the instrument providers to just generate one additional XML report. One remaining problem is that, if you need to connect two appls from different providers, you still have to deal with the different data models in each appl. This requires the transformation of one XML doc (generated with appl #1) to other XML doc (readable by appl #2). I don't clearly see how this can be solved in a standard way: Can this be done using XSL ? Is there some other way of doing it ? 2. XML Migration paths I think the point we should raise is: How can be begin using XML and obtaining benefits from it's use in appls development, while XML and it's associated technologies are still evolving and there are still a lot of open questions (namespaces, XML Data, Xlink, compounding documents, etc...) ? What can be use NOW, and what will have to wait till it's mature ? I here briefly describe the lines we have taken in this direction (maybe this experience is of some help for anyone else). This may or may not be a solution, as this is an open question (even for myself): Aside from Web development, we have found XML to be of help in developing client-server appls (not Web appls). Request messages are XML docs, as well as the response messages, and so XML is used as a way of implementing a RPC or distributed objects mechanism. I have seen a Note to the W3C where this has been already proposed. Although some can say that CORBA has already solved this problem, developing in CORBA (or DCOM) is much more difficult and error prone (using the C++ mappings). Previously we were using CORBA, and I can testify this. We have been using XML (and our own little parsers) in our appls to support this type of client-server interaction with success. We have observed little performance penalties compared to using CORBA. Some benefits we observed: Client and server can run in different platforms, no CORBA runtimes or fees (just a little TCP/IP library for managing the client-server connections), much easier installation and deployment, VERY lightweight, much easier development (and less training for new developers), very simple to change the server interface definitions. Although CORBA should have solved this problem, developing in CORBA (or DCOM) is much more difficult and error prone (using the C++ mappings). previously we were using CORBA, and I can testify this. We have been using XML (and our own little parsers) in our appls to support this type of client-server interaction with success. This can be viewed as a specialized browser, one that implements the user interface our appls require, without the performance penalty of supporting complex user interface development in a browser with the current tools (Java and JavaScript). I can say that developing such a client application that interacts with a XML server in this way is really not difficult. When the Web browsers (in some future time) are ready for true XML-XSL support and higher degrees of interaction, it will be very easy to migrate our current appls to them (only the client side needs to be migrated, the appl. servers should remain nearly untouched: they already generate XML responses). The big point here is that we can begin using XML and getting it's benefits NOW, while we let XML and it's associated technologies mature and define clear ways to arquitecture our appls. Hope this can help. Mario A. Zito xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From JEROME.YUROW at hq.doe.gov Mon Jan 11 15:59:15 1999 From: JEROME.YUROW at hq.doe.gov (JEROME.YUROW@hq.doe.gov) Date: Mon Jun 7 17:07:26 2004 Subject: [ANN] WFC 38 is out (and a question) Message-ID: * Samuel R. Blackburn | |

Text

More Text

Less Text

| | Is this valid XML? " More Text " is orphaned. I received the above question at two locations. (1) my office, this morning, via lotus cc:mail (text only) and (2) my home, over the weekend, (America Online 4.0). When I read it at home. The example did not display the tags, it appeared as a mini-web page something like the following: ================================================================ Text (in heading-1 font size) More text (in font size smaller than heading-2 font size) Less text (in heading-2 font size) ==================================================================== So the rest of the message was a complete mystery to me, because I couldn't see the tags! (For some reason, I couldn't get my mouse to display the source code either.) When I read it at the office everything became clear, because the whole message was in plain text and the html labels were visible. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jan 11 19:08:13 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:26 2004 Subject: Extender characters, Production 89 of XML 1.0 References: <9901111553.AA27198@unicode.org> Message-ID: <369A4C06.53E1D52D@locke.ccil.org> Elliotte Rusty Harold wrote: > In XML ["extender"] > characters can be used anywhere a base character or ideographic > character can be used. This is not quite true, because extenders are not name-start characters in either XML or Unicode. > However I have been unable to find in the Unicode book or Web site any > definition of what makes a character an extender. Can anyone clue me in on > why some Unicode characters have the extender property while others don't? > What's the logic behind this grouping of characters across languages? Roughly (and unofficially) speaking, an extender is something that isn't a letter or combining mark but often appears embedded in words. For example, one may use L plus MIDDLE DOT as a compatibility equivalent of L WITH MIDDLE DOT in writing Catalan, and we do not want a Catalan name to break into two names at the MIDDLE DOT. (The dot is used to distinguish two successive Ls, written with a dot, from the unitary Catalan letter "ll", written without a dot.) Extenders are enumerated (but not explained) in Section 5.14 of the Unicode Standard. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pchen at CSUA.Berkeley.EDU Mon Jan 11 22:21:38 1999 From: pchen at CSUA.Berkeley.EDU (Philip Chen) Date: Mon Jun 7 17:07:26 2004 Subject: parsing XML into DOM Message-ID: <199901112221.OAA09449@soda.CSUA.Berkeley.EDU> Does anyone know where I can find a parser which parses XML into DOM format? Please copy me via email. Thanks in advance. Philip xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 12 00:47:58 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:26 2004 Subject: XML standards coherency and so forth Message-ID: <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> I have been thinking more about the issue of coherency between XML-based standards. I think I may have hit upon both the problem and the solution. I think we may be missing the very point of XML. XML is a data representation language. Having represented a domain in an interoperable manner, you can then apply any number of applications to that domain. At least some of the W3 efforts, on the other hand, seem more focused on applications than domains. For example: WebDAV, DRP, and ICE all need to operate on hierarchies of assets. But they all think about and represent those hierarchies differently. It is easy to imagine a system that wants to apply distributed authoring, replication, and content syndication to the same set of content. Why not start with a common representation for that content, then let the apps expose different sets of operations on top of it? I think such an approach would go a long way towards adding coherency between the various specs under development. Jeff ----------------------------------------------------------------- Kuantech, Inc. http://www.kuantech.com Jeffrey E. Sussna, Principal jes@kuantech.com Distributed Content Architectures for Dynamic Online Applications ----------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Maneesha.Jain at Ebay.Sun.COM Tue Jan 12 01:09:25 1999 From: Maneesha.Jain at Ebay.Sun.COM (Maneesha.Jain) Date: Mon Jun 7 17:07:26 2004 Subject: Tools to create dtds Message-ID: Hi, I understand there are tools to generate XML documents. Are there any tools available for creating and managing DTDs ? Regards Maneesha xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Maneesha.Jain at Ebay.Sun.COM Tue Jan 12 01:09:37 1999 From: Maneesha.Jain at Ebay.Sun.COM (Maneesha.Jain) Date: Mon Jun 7 17:07:26 2004 Subject: Tools to create dtds Message-ID: Hi, I understand there are tools to generate XML documents. Are there any tools available for creating and managing DTDs ? Regards Maneesha xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 12 01:16:45 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:26 2004 Subject: XML standards coherency and so forth In-Reply-To: <199901120108.RAA12982@mehitabel.eng.sun.com> Message-ID: <001b01be3dc8$adb92c60$5118a8c0@kuantech1.quokka.com> The DOM represents the structure of a single document. I am talking about the structure of a hierarchy of documents. Jeff -----Original Message----- From: Murray Altheim [mailto:altheim@mehitabel.eng.Sun.COM] Sent: Monday, January 11, 1999 5:09 PM To: jes@kuantech.com Subject: Re: XML standards coherency and so forth I believe that is what the DOM aims to accomplish. Murray xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Tue Jan 12 01:54:58 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:07:26 2004 Subject: Regulating the XML Marketplace References: <199901081232.HAA12853@hesketh.net> <199901081558.KAA25616@hesketh.net> <36963E79.C8A92E03@prescod.net> Message-ID: <369AAAD6.4D96@hiwaay.net> Paul Prescod wrote: > > In many of XML's markets (unlike many of > SGML's markets) the move to XML actually saves money in the short, medium > and long terms. Traditionally SGML has only saved money in the long term. Basically right. SGML and SGML systems: o Were typically expensive to acquire and set up. Lack of cheap tools (until SGMLS, IADS, etc.), lack of expertise (little training in the universities, mostly fueled by high-dollar aerospace/DoD efforts, homegrown, fed by the kindness of strangers). o Mired in the print technology of the time and forced to compete with WYSIWYG systems. Saying markup could support objects was once considered a statement of *magic* and taken almost as seriously. Goldfarb and Rubinsky had to defend the idea that SGML could even support real hypertext. The fights between the PostScript/LaTex and SGML communities were legends and some are still happening. See comp-text-sgml. o Forced down odd paths of development by requirements of the standards process that demanded any attempts to look at markup as an application of programming be disregarded. o Subject to the misguided rants of the HTML community that declared it "too hard, too obtuse, too syntactically strange" (see TimBL) and so it goes. XML is in a much better position to make the benefits of markup more profitable. Will a killer app emerge? Folks, that is like Elvis: largely a context issue for a certain time when a certain realization takes hold. Mosaic was not a great development to those of us who already had SGML-based, DTD-aware, stylesheet driven hypertext in 1992. It wasn't. When you remember just how few people did (check out the prices of hypertext browsers and authoring tools then), then the idea that a lot of folks already understand XML (they don't) is self-defeating. Still, I don't think it necessary to evangelize XML as much as it is necessary to get the language communities currently designing their next generation of languages and applications to use it. XML's successful emergence will not come as the result of a killer app, but when a set of DIFFERENT XML applications interoperate, share information, and enable an enterprise to be more competitive. That has been the goal for over fifteen years and you are much closer today to realizing it than ever. Target the companies that have: o Data with long lifecycles (Still the biggest payoff) o Lots of little data pockets (aka, islands of automation) o The requirement to dynamically create JIT documents o The requirement to share those documents across organizational boundaries without requiring *economic bullpens* (see contractually bound communications and delivery of data) The good news is the quiet revolution has been won and the emerging evolution has begun. This isn't about new ideas. This is about cost-effective, sustainable implementations. Like SGML at its best, an XML application is successful when invisible. So, Paul is right; the secret is not the demonstration of XML. It is the application of XML. Y'all really need to decide what to do about architectures. They are critical. Base enabling applications would surely help clean up the standards and that is a big favor to the next generation of software developers. Ask me about the problems of the FedsPostCALS: very little change in the data delivery and maintenance nightmares. Real drag on the economy, that one. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Tue Jan 12 01:57:32 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:07:26 2004 Subject: Tools to create dtds References: Message-ID: <369AAB2F.47F7@hiwaay.net> Maneesha.Jain wrote: > > Hi, > > I understand there are tools to generate XML documents. Are there any tools > available for creating and managing DTDs ? Several. I recommend Near and Far. It is a very solid product having had several versions of development now. Len Bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jan 12 02:06:21 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:07:26 2004 Subject: XML standards coherency and so forth Message-ID: <004301be3dd0$5d8239a0$49f96d8c@NT.JELLIFFE.COM.AU> From: Jeffrey E. Sussna > XML is a data representation language. Well, XML is really a data *labelling* language (i.e. markup). By taking care of syntax, it exposes the difficult problem: how to go from mere labels to specific representation. > Why not start with a common representation for that content, then let the apps expose > different sets of operations on top of it? I think such an approach would go a long way > towards adding coherency between the various specs under development. I think you are right: apart from RDF in its limited domain, there is no movement in XML/SGML similar to the "pattern movement" in OO programming: a movement trying to extract the fundamental structural patterns in markup which can be used in any application. Architectural forms and namespaces give mechanisms for making it easier to use this approach, but they have not found archetypes. My book (XML & SGML Cookbook) is the only attempt I know to move towards a pattern-based way of marking up documents; Dave Megginson's "Structuring XML Documents" has a tacet awareness of the possibility of patterns too. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From JeremyP at clbooks.com Tue Jan 12 02:18:19 1999 From: JeremyP at clbooks.com (Jeremy Pascual) Date: Mon Jun 7 17:07:26 2004 Subject: xml and distributed data Message-ID: <073841B11720D2119E6200104B2474FB010C46D5@CLBEXCHANGE.cbooks.com> hi, i'm new to the list and xml... i would like to find out more info on using xml to transfer data between sites. any suggestions would be greatly appreciated. =) thanks, jeremy --------------------------------------------- jeremy pascual computerliteracy (bookshops+online) http://www.clbooks.com Corporate Office 1308 orleans drive sunnyvale, ca 94089 email: jeremyp@clbooks.com phone: 408 541-2020 x170 fax1: 408-752-9919 (Better Choice) fax2: 408-752-9917 --------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Tue Jan 12 03:00:59 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:07:26 2004 Subject: XML standards coherency and so forth In-Reply-To: <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> (jes@kuantech.com) References: <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> Message-ID: <199901120253.UAA10246@bruno.techno.com> [Jeff Sussna:] > I have been thinking more about the issue of coherency between > XML-based standards. I think I may have hit upon both the problem and > the solution. I think we may be missing the very point of XML. XML is > a data representation language. Having represented a domain in an > interoperable manner, you can then apply any number of applications to > that domain. At least some of the W3 efforts, on the other hand, seem > more focused on applications than domains. For example: > > WebDAV, DRP, and ICE all need to operate on hierarchies of assets. But > they all think about and represent those hierarchies differently. It > is easy to imagine a system that wants to apply distributed authoring, > replication, and content syndication to the same set of content. Why > not start with a common representation for that content, then let the > apps expose different sets of operations on top of it? I think such an > approach would go a long way towards adding coherency between the > various specs under development. Coherency between the specs under development will, I think, ultimately require a single powerful paradigm, such as the paradigms afforded by architectural forms, groves, and property sets, that can handle the specification requirements of all of the XML-based standards. I have often ranted in favor of higher and higher levels of abstraction, and I remain unshakably convinced of the technical merit of abstracting one's way to general solutions, and of the absolute merit of general solutions. But it will not be easy to put any such an all-encompassing paradigm in place, especially after the fact of standardizing mutually incompatible ways of doing things. I recently was reminded of a wise saying attributed to an acquaintance who works at Microsoft: "Whenever we go to a higher level of abstraction, we lose 90% of the audience." The marketplace does not necessarily respond either to technical merit or to absolute merit. It can't respond to what it doesn't understand, and surprisingly few people grasp the overall problem of information management in ways that encompass the combination of problem domains that, in the aggregate, account for the bulk of the market. The doctor can't always get the patient to take the necessary medicine, either. But the patient will be back when he reaches the next level of discomfort, and maybe then he'll be persuadable to have the major operation he really needs. Someone recently said to me that a lot of the uproar in XML standards efforts is attributable to the tendency of relational-database people to see everything in terms of relational databases and tuples, versus the tendency of the dyed-in-the-wool document-systems people and ODBMS people to see everything in object oriented terms, despite the fact that RDBMSs are where the people, the capital, the expertise, and the installed base of high-scale systems are. There's probably a grain of truth in this observation: that everybody sees what they know how to see and what they can afford to see, and that this is the reason why there is a lack of vision-consensus. It's very challenging to think globally when a billion-dollar opportunity may be slipping through your fingers, while pointy-headed people dither contentiously about technical details that have no great relevance to that billion-dollar opportunity. Even if civilization as a whole could save trillions of dollars in lost productivity by getting those details right in the first place. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Tue Jan 12 04:41:03 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:26 2004 Subject: XML standards coherency and so forth In-Reply-To: <199901120253.UAA10246@bruno.techno.com> Message-ID: <000001be3de5$40efb910$d3228018@jabr.ne.mediaone.net> ... It's very challenging to think > globally when a billion-dollar opportunity may be slipping through > your fingers, while pointy-headed people dither contentiously about > technical details that have no great relevance to that billion-dollar > opportunity. Even if civilization as a whole could save trillions of > dollars in lost productivity by getting those details right in the > first place. I'm sorry ... exactly which billion dollar opportunity is slipping through whose fingers :-) This is true, take for example healthcare (which IMHO is the killer XML app). The U.S. spends in aggregate $ 1.5 or so Trillion/year. Estimates are that 20-40% is due to overhead, inefficiency, waste etc. (i.e. *not* being spent on actual health care). The problem is that its no one individual, or organization's problem. Its always someone elses problem. Unless there is a very specific benefit to improving efficiency there's no incentive to do the hard work to make it happen. So... each and every one on this list has to take a stand and refuse medical care from any organization which doesn;t maintain and transmit its records in XML ... Jonathan Borden http://jabr.ne.mediaone.net > > -Steve > > -- > Steven R. Newcomb, President, TechnoTeacher, Inc. > srn@techno.com http://www.techno.com ftp.techno.com > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Tue Jan 12 07:55:25 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:27 2004 Subject: XML standards coherency and so forth In-Reply-To: <199901120253.UAA10246@bruno.techno.com> References: <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> Message-ID: <3.0.1.32.19990111235816.00976c90@mail.accessone.com> I've been following this thread, and had some questions and observations. Excuse me if they're naive. Firstly, the idea of xml needing a "killer app". I thought xml _is_ the killer app? It sure seems to be being adopted as fast of or in advance of released standards for a lot of different products (Ms Word's adoptation of xml in it's next release comes to mind as a non-web product). Secondly, this notion of cohesion of standards. This I tend to agree on. They all seem to be a bit out of focus with respect to each other - thinking primarily about xml vs. xsl. I also keep in mind that xml as the killer app for sgml is something in the neighborhood of 2 years old and the actual spec (xml) is just coming up on it's first birthday. Third, about patterns etc. Um... isn't a dtd a pattern for a collection/class of documents that adhere to that dtd if they are valid instances of it? I recall when rdms' where the ugly step children due to the overhead their use entailed and a lack of understanding of their benefits etc. Now they are the entrenched majority trying to fend off the next inovation and maintain the status quo. Deja vu all over again. Now, permit me to digress a bit. Having been studying and working with xml for the last 18 months or so, it seems to me this market is coming together very slowly. There are not yet any decent (at least not inexpensive) tools out for the average consumer-programmer that seem worth a darn. I implemented a small xml application for a commercial product, and we where unable to find usable off the shelf tools at any (reasonable) cost. Ditto for commercial C++ drop in parsing tools. Sincerely, Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Tue Jan 12 10:25:01 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:07:27 2004 Subject: XML standards coherency and so forth In-Reply-To: <3.0.1.32.19990111235816.00976c90@mail.accessone.com> Message-ID: <000001be3e15$d5073fd0$bda8b4d1@yak.ptld.uswest.net> > Excuse me if they're naive. Not at all. > Firstly, the idea of xml needing a "killer app". I thought xml _is_ the > killer app? To the minds of the people reading this list, it probably is. But the subscription to this list isn't a good cross section of *any* population! ;-) XML is certainly the enabling technology for a lot of potential "killer" information systems. Unfortunately, it is applicable to so many different problem domains that it lacks the punch of a killer app. The story of Visicalc is that when shown to the computer geeks, they said "computers can already do that" and when shown to accountants, they said "this is it!" Now it seems that the roles are reversed. The geeks are saying about XML, "this is it!" and the rest of the world is saying "computers can already do that." I believe that Java would have followed the same path were it not for the gratuitous applets that served no practical purpose whatsoever. Without the applet, the world would have said "computers can already do that...and 10 times faster to boot". But once you play tic tac toe on a web page, it is patently obvious that "computers *couldn't* already do that." >It sure seems to be being adopted as fast of or in advance of > released standards for a lot of different products (Ms Word's > adoptation of > xml in it's next release comes to mind as a non-web product). This is, IMHO, a really big deal. I've seen various figures that report 80% of corporate data resides on the filesystem of Windows desktops in the form of Excel and Word documents. The number of people that spend 40 hour weeks creating such documents only to have them printed and filed away in the departmental closet is staggering. What is more staggering is that this is fantastic information that is completely inaccessible to almost anyone except those who generated the data. It doesn't surprise me one bit that MS is pursuing XML as hard as they are. If that data were less opaque, the value of the MS products would rise significantly. If cubicle farms could be mined for data, that would place XML in the "this is it" category. > Third, about patterns etc. Um... isn't a dtd a pattern for a > collection/class of documents that adhere to that dtd if they are valid > instances of it? Yes, but there is no convenient way to apply logic to these collections. Set-building among collections of XML documents is very difficult. Set-building is the mainstay of corporate information systems: reports reports reports. XQL isn't much help either. It's great for extracting information from a few large documents. But it doesn't do much good for sifting through enormous numbers of small documents. That's great for SGML-ish applications, but for lightweight documents that represent transactions, the utility is wasted. > I recall when rdms' where the ugly step children due to the overhead their > use entailed and a lack of understanding of their benefits etc. Now they > are the entrenched majority trying to fend off the next inovation and > maintain the status quo. Deja vu all over again. Is there a clear "threat" to the RDBMs? OO databases are maturing, but they suffer from the same problem as I mentioned previously: reporting! Set processing is very difficult since the stored objects are opaque. OODBMS are great for the OO programmer, but not so for the CIO. I can't imagine any system that can process sets of documents that wasn't (at the lowest levels) a set-theoretic RDBMS. (Please, prove me wrong!!) I'm really interested to see Oracle's forthcoming XML support. If XML was a neo-first-class datatype for a RDBMS, I can see fantastic things to come. But if the XML data is stored as a blob and run through a parser to and fro, it will be a complete bust. I'm not holding my breath just yet. > > Now, permit me to digress a bit. Having been studying and working with xml > for the last 18 months or so, it seems to me this market is > coming together > very slowly. There are not yet any decent (at least not inexpensive) tools > out for the average consumer-programmer that seem worth a darn. I > implemented a small xml application for a commercial product, and we where > unable to find usable off the shelf tools at any (reasonable) cost. Ditto > for commercial C++ drop in parsing tools. I agree and I also understand that this is the responsibility of the people and organizations represented on this list. Or perhaps we need an xml-app-dev list??? Or some kind of grass-roots organization that can affect some kind of change.... Rob Schoening xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andreas_berg at usa.net Tue Jan 12 10:34:07 1999 From: andreas_berg at usa.net (Andreas Berg) Date: Mon Jun 7 17:07:27 2004 Subject: Word DOC to XML Converter Message-ID: <19990112103123.1910.qmail@www0x.netaddress.usa.net> Hi there, I am searching for a converter from Word documents to XML. Unfortunatly I have no time to wait for Office 2000..... Is there something like this available? Andreas. ____________________________________________________________________ Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From acmuller at human.toyogakuen-u.ac.jp Tue Jan 12 11:15:27 1999 From: acmuller at human.toyogakuen-u.ac.jp (Charles Muller) Date: Mon Jun 7 17:07:27 2004 Subject: Sample XML/DTD/XSL Message-ID: <00b001be3e1c$fea6c020$77ab89d2@dellxps300> Friends, There have occasionally been requests on this list from people completely new to XML, for samples of XML files, DTDs, XSL files etc. I have been compiling two lexicons for a number of years, extensive CJK (Chinese-Japanese-Korean) to-English references that have been on my web site since 1995 in HTML format. These have been stored during this time in a quasi-SGML-TEI structured text format. I have recently finished fully converting these to XML and validating them, and have gotten them set up so that they are browsable with the MSIE 5 beta. The format is extremely rudimentary, with little styling and no XLinking, but they are nonetheless viewable with a major browser (a major step!), so those who are constructing their first DTDs and XSL files might be able to benefit from some of the code to start their own basic documents. [Note: At this point, the Dictionary of East Asian Buddhist Terms is more highly developed than the dictionary of East Asian Literary Terms, so please pay greater attention to the former than the latter] For any of the XML pros out there who have a moment to take a look at this material, I would appreciate any advice on implementing other functions that are supported by MSIE5b2 that I may not know about. The HTML files are also still available on the same site, so you can see what it is *supposed* to look like, eventually. Of course you need CJK font support to see the East Asian characters, but the bulk of the dictionary is English text. I have uploaded just twenty of the 214 data files for the time being. These will be upgraded regularly according to advancements in browser support and the growth of my grasp on XML. Eventually this XML version should fully supercede the HTML version. The resource is located at: http://www.human.toyogakuen-u.ac.jp/~acmuller/dicts Regards, Charles Muller ---------------------------------- Toyo Gakuen University 1660 Hiregasaki, Nagareyama-shi, Chiba 270-0161 Japan Resource for East Asian Language and Thought http://www.human.toyogakuen-u.ac.jp/~acmuller xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Pasqualino Tue Jan 12 11:21:32 1999 From: Pasqualino (Pasqualino) Date: Mon Jun 7 17:07:27 2004 Subject: KQML Message-ID: <369B3048.DA5FE32@kamus.it> Is anyone aware of XML mappings of KQML ? Thanks -- Pasqualino "Titto" Assini The Data Archive - University of Essex, UK xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jan 12 11:37:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:27 2004 Subject: xml and distributed data References: <073841B11720D2119E6200104B2474FB010C46D5@CLBEXCHANGE.cbooks.com> Message-ID: <369B3228.73CD4F0B@prescod.net> Jeremy Pascual wrote: > > hi, > > i'm new to the list and xml... i would like to find out more info on using > xml to transfer data between sites. any suggestions would be greatly > appreciated. =) WDDX: http://www.oasis-open.org/cover/wddx.html XML-RPC: http://www.scripting.com/davenet/98/07/xmlrpcfornewbies.html -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "I want to give beauty pageants the respectability they deserve." - Brooke Ross, Miss Canada International xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jan 12 12:23:39 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:27 2004 Subject: XML standards coherency and so forth References: <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> <3.0.1.32.19990111235816.00976c90@mail.accessone.com> Message-ID: <369B1DA3.EC721AE2@prescod.net> David LeBlanc wrote: > > Now, permit me to digress a bit. Having been studying and working with xml > for the last 18 months or so, it seems to me this market is coming together > very slowly. There are not yet any decent (at least not inexpensive) tools > out for the average consumer-programmer that seem worth a darn. I > implemented a small xml application for a commercial product, and we where > unable to find usable off the shelf tools at any (reasonable) cost. Ditto > for commercial C++ drop in parsing tools. In what sense are the Netscape supported (but not written) "expat" and the Microsoft supported (but not written) msxml not "commercial C++ drop in parsing tools?" Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "I want to give beauty pageants the respectability they deserve." - Brooke Ross, Miss Canada International xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jan 12 12:23:41 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:27 2004 Subject: XML standards coherency and so forth References: <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> <3.0.1.32.19990111235816.00976c90@mail.accessone.com> Message-ID: <369B1DA3.EC721AE2@prescod.net> David LeBlanc wrote: > > Now, permit me to digress a bit. Having been studying and working with xml > for the last 18 months or so, it seems to me this market is coming together > very slowly. There are not yet any decent (at least not inexpensive) tools > out for the average consumer-programmer that seem worth a darn. I > implemented a small xml application for a commercial product, and we where > unable to find usable off the shelf tools at any (reasonable) cost. Ditto > for commercial C++ drop in parsing tools. In what sense are the Netscape supported (but not written) "expat" and the Microsoft supported (but noX-Mozilla-Status: 0009commercial C++ drop in parsing tools?" Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "I want to give beauty pageants the respectability they deserve." - Brooke Ross, Miss Canada International xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Adrian.Griffith at tma.osd.mil Tue Jan 12 13:08:17 1999 From: Adrian.Griffith at tma.osd.mil (Griffith, Adrian, CON, OASD(HA)/TMA) Date: Mon Jun 7 17:07:27 2004 Subject: XML standards coherency and so forth Message-ID: it is happening: Microsoft, IBM get XML to users http://www.zdnet.com/pcweek/stories/news/0,4153,383815,00.html unfortunately, xml is not going to live a sexy life. it will become the data format of choice for distributed systems, objects, and the web. hopefully the users of microsoft products have been filling out the "properties" form when saving a document. combine that with an xml based search engine and viola, the data at cubicle XX is available. of course a xml based search engine, capable of viewing information in "context" of the query ... > ---------- > From: Rob Schoening[SMTP:rschoening@unforgettable.com] > Sent: Tuesday, January 12, 1999 5:25 AM > To: David LeBlanc; xml-dev@ic.ac.uk > Subject: RE: XML standards coherency and so forth > > > > Excuse me if they're naive. > > Not at all. > > > Firstly, the idea of xml needing a "killer app". I thought xml _is_ the > > killer app? > > To the minds of the people reading this list, it probably is. But the > subscription to this list isn't a good cross section of *any* population! > ;-) > > XML is certainly the enabling technology for a lot of potential "killer" > information systems. Unfortunately, it is applicable to so many different > problem domains that it lacks the punch of a killer app. The story of > Visicalc is that when shown to the computer geeks, they said "computers > can > already do that" and when shown to accountants, they said "this is it!" > Now > it seems that the roles are reversed. The geeks are saying about XML, > "this > is it!" and the rest of the world is saying "computers can already do > that." > I believe that Java would have followed the same path were it not for the > gratuitous applets that served no practical purpose whatsoever. Without > the > applet, the world would have said "computers can already do that...and 10 > times faster to boot". But once you play tic tac toe on a web page, it is > patently obvious that "computers *couldn't* already do that." > > > >It sure seems to be being adopted as fast of or in advance of > > released standards for a lot of different products (Ms Word's > > adoptation of > > xml in it's next release comes to mind as a non-web product). > > This is, IMHO, a really big deal. I've seen various figures that report > 80% > of corporate data resides on the filesystem of Windows desktops in the > form > of Excel and Word documents. The number of people that spend 40 hour > weeks > creating such documents only to have them printed and filed away in the > departmental closet is staggering. What is more staggering is that this > is > fantastic information that is completely inaccessible to almost anyone > except those who generated the data. It doesn't surprise me one bit that > MS > is pursuing XML as hard as they are. If that data were less opaque, the > value of the MS products would rise significantly. If cubicle farms could > be mined for data, that would place XML in the "this is it" category. > > > Third, about patterns etc. Um... isn't a dtd a pattern for a > > collection/class of documents that adhere to that dtd if they are valid > > instances of it? > > Yes, but there is no convenient way to apply logic to these collections. > Set-building among collections of XML documents is very difficult. > Set-building is the mainstay of corporate information systems: reports > reports reports. XQL isn't much help either. It's great for extracting > information from a few large documents. But it doesn't do much good for > sifting through enormous numbers of small documents. That's great for > SGML-ish applications, but for lightweight documents that represent > transactions, the utility is wasted. > > > I recall when rdms' where the ugly step children due to the overhead > their > > use entailed and a lack of understanding of their benefits etc. Now they > > are the entrenched majority trying to fend off the next inovation and > > maintain the status quo. Deja vu all over again. > > Is there a clear "threat" to the RDBMs? OO databases are maturing, but > they > suffer from the same problem as I mentioned previously: reporting! Set > processing is very difficult since the stored objects are opaque. OODBMS > are > great for the OO programmer, but not so for the CIO. I can't imagine any > system that can process sets of documents that wasn't (at the lowest > levels) > a set-theoretic RDBMS. (Please, prove me wrong!!) I'm really interested > to > see Oracle's forthcoming XML support. If XML was a neo-first-class > datatype > for a RDBMS, I can see fantastic things to come. But if the XML data is > stored as a blob and run through a parser to and fro, it will be a > complete > bust. I'm not holding my breath just yet. > > > > > Now, permit me to digress a bit. Having been studying and working with > xml > > for the last 18 months or so, it seems to me this market is > > coming together > > very slowly. There are not yet any decent (at least not inexpensive) > tools > > out for the average consumer-programmer that seem worth a darn. I > > implemented a small xml application for a commercial product, and we > where > > unable to find usable off the shelf tools at any (reasonable) cost. > Ditto > > for commercial C++ drop in parsing tools. > > I agree and I also understand that this is the responsibility of the > people > and organizations represented on this list. Or perhaps we need an > xml-app-dev list??? Or some kind of grass-roots organization that can > affect some kind of change.... > > > Rob Schoening > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From acmuller at human.toyogakuen-u.ac.jp Tue Jan 12 14:53:47 1999 From: acmuller at human.toyogakuen-u.ac.jp (Charles Muller) Date: Mon Jun 7 17:07:27 2004 Subject: Sample XML lexicon files Message-ID: <001201be3e3b$804d6160$69ab89d2@dellxps300> It has been pointed out to me that some of the sample XML files I offered in an earlier post are too large to open up effectively across the network. I will remedy this by uploading some "sample.zip" packs--but it will be several hours before I am on a server terminal. Please check back later. Regards, Charles Muller Toyo Gakuen University 1660 Hiregasaki, Nagareyama-shi, Chiba 270-0161 Japan Resources for East Asian Language and Thought http://www.human.toyogakuen-u.ac.jp/~acmuller xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From THILL at imf.org Tue Jan 12 15:33:15 1999 From: THILL at imf.org (Hill, Terence) Date: Mon Jun 7 17:07:27 2004 Subject: Word DOC to XML Converter Message-ID: <9D18C8AEF80CD21198D10008C7FAE61518EE0B@mlnt5s.imf.org> Why not try ADVENT in the UK, the makers of the 3B2 composition engine. By the way, what information is available to suggest that Office 2000 will produce XML? > -----Original Message----- > From: Andreas Berg [SMTP:andreas_berg@usa.net] > Sent: Tuesday, January 12, 1999 6:31 AM > To: xml-dev@ic.ac.uk > Subject: Word DOC to XML Converter > > > Hi there, > > I am searching for a converter from Word documents to XML. Unfortunatly I > have > no time to wait for Office 2000..... Is there something like this > available? > > Andreas. > > > ____________________________________________________________________ > Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From acp at CAM.ORG Tue Jan 12 16:02:02 1999 From: acp at CAM.ORG (Andre-Claude Potvin) Date: Mon Jun 7 17:07:27 2004 Subject: Word DOC to XML Converter In-Reply-To: <9D18C8AEF80CD21198D10008C7FAE61518EE0B@mlnt5s.imf.org> Message-ID: See http://www.microsoft.com/presspass/press/1998/oct98/xmlcappr.htm where it says: "Microsoft Office 2000, elevates HTML to a companion file format and uses XML to store additional document information. By using XML in this way, Office 2000 users can save documents as Web pages and then later return these documents to their original Office state for editing." So it's going to be a very limited use of XML. But at least it should respect W3C standards. Andre-Claude Potvin Journalist & Web site developer Montreal, Canada On Tue, 12 Jan 1999, Hill, Terence wrote: > Why not try ADVENT in the UK, the makers of the 3B2 composition engine. By > the way, what information is available to suggest that Office 2000 will > produce XML? > > > -----Original Message----- > > From: Andreas Berg [SMTP:andreas_berg@usa.net] > > Sent: Tuesday, January 12, 1999 6:31 AM > > To: xml-dev@ic.ac.uk > > Subject: Word DOC to XML Converter > > > > > > Hi there, > > > > I am searching for a converter from Word documents to XML. Unfortunatly I > > have > > no time to wait for Office 2000..... Is there something like this > > available? > > > > Andreas. > > > > > > ____________________________________________________________________ > > Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > > (un)subscribe xml-dev > > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > > message; > > subscribe xml-dev-digest > > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > --- Andr?-Claude POTVIN Sp?cialiste, Internet et NTIC Journaliste, Memento http://www.cam.org/ http://www.memento.com/ --- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Tue Jan 12 16:11:36 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:07:28 2004 Subject: 7 Questions on DCDs Message-ID: <990112111050.13698@mail11.mitre.org.0> (1) Will a DCD have a DOCTYPE declaration, or is that a thing of the past? (2) XML instance documents will specify the the DCD it is conforming to using namespaces, rather the using the DOCTYPE declaration? i.e., instead of: ... it will be: where in BookCatalogue.dcd I must have: DCD to define a Book Catalog file://localhost/xml-course/xml-part1/BookCatalog ue.dcd ... (3) Will it make sense to validate a DCD? If so, how? Should a DCD document reference the DCD namespace (to enable validation) e.g., ... (4) The examples in the DCD spec use the RDF namespace (e.g., RDF:Order) but no where is a namespace declaration shown. Should there be a namespace declaration for the RDF prefix? i.e., ... (5) It is not clear to me how to define an attribute whose datatype is an enumeration and is required. In DTD it is specified as: I am guessing that in DCD it is specified as: autobiography non-fiction fiction ... (6) What's the difference between an ElementDef with Content="Open" versus an ElementDef with Model="Any"? They seem to mean the same thing. i.e., ... versus ... (7) Can somebody explain this external entity example: Where did this copyrightNotice thing come from? Thanks. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Jan 12 16:23:45 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:28 2004 Subject: Word DOC to XML Converter Message-ID: <3.0.32.19990112081924.00b16410@pop.intergate.bc.ca> At 11:01 AM 1/12/99 -0500, Andre-Claude Potvin wrote: >So it's going to be a very limited use of XML. But at least it should >respect W3C standards. There are lots of Office2K betas around; have a look and see what you think. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jabuss at cessna.textron.com Tue Jan 12 17:19:35 1999 From: jabuss at cessna.textron.com (Buss, Jason A) Date: Mon Jun 7 17:07:28 2004 Subject: Into the fray... Message-ID: Hello to everyone. I just subscribed to this mailing list over the last couple of days and it appears I have walked into a very interesting discussion. I just thought I would share a few things with everyone regarding the impressions and hopes that I have for XML. I could be considered a relative newcomer to XML. I have been working with SGML for the last 7 months or so, as part of a team that was formed to implement an SGML publishing system for our company. The team went through some reorganization, and I sort of got in at the tail end, implementation side of things, as most of the research, conceptualizing, and development had already been completed. Basically, I learned SGML by working with various public tools as well as the commercial software we ordered, and the internet. There just isn't a whole lot out there other than the materials generated by the individuals and organizations committed to SGML Basically, we did evaluation after evaluation of commercial software, decided on a publishing package from a very respected vendor. Showed it to our technical writers, and watched them turn on us. The lack of real information that came from the team to the publishing group only helped to exacerbate the feelings of paranoia and helplessness from writers. They were terrified that we were going to force everyone to learn programming. I have, over time and vendor improvements, shown most people that this is not the case. Most people hear "metalanguage", but think "language". I am no programmer by any stretch of the imagination. I was a technical writer and illustrator before being coaxed into SGML publishing. I was put off by the whole thing until I took a really close look at it. And that brings me to a real sore spot that I think would love to see addressed when people write white papers and abstracts to explain XML for the rest of us. The concept of SGML (and XML) is no challenge for most people to grasp, but the majority of published texts are so weighted down that most technical writers come away either crushed or confused. Many of them need to see it applied before they can fully grasp the application (particularly the syntax). I personally had to read almost ten white papers before I came away with everything I needed to get the whole picture. I know there are some people who are in the process of building SGML publishing systems who are terrified because as the information and resources for XML increases, the information and resources for SGML has trailed off somewhat. A lot of people, for whatever reason, have missed the XML/SGML connection, and are worried that SGML will fall out of favor, and not have the support it once had. And hopefully, something, or someone, will bring XML to the forefront of public awareness. Be it a well-branded vendor such as Microsoft (I am personally banking on Netscape/Sun/IBM; AOL stands to gain hand over fist from XML implementation), or the next Gates or Andressen or someone who can really push XML not only into the office for production, but into the home for delivery. Even the beginning web surfers quickly understand that it is HTML and Java applets that make all this information visible within their browser. Many people pick up on the concepts and syntax of HTML from there, going on to create their own documents/pages, but the ones who choose not to still understand the benefit of HTML. XML would probably be most likely to succeed if it has the groundswell of support or at least understanding of benefit from the public at large as it becomes implemented. Unfortunatlely, I can ask 20 people familiar with HTML, and maybe two of them have heard of XML. Almost none of them understand that HTML is a doctype of SGML. There needs to be a really simple, straightforward PR blitz aimed not only at publishers and document managers, but at webmasters and the general public. It is very commendable of Microsoft to embrace XML like they have, but it seems most of their papers are geared towards the industry, and promises XML support in their products, as opposed to informing the general public of the benefits to be gained from XML. People clamored for a way to share, transmit, and display information in an inexpensive, easy-to use format that could be accessible to anyone or everyone, Hence HTML, and the internet. Customer-driven solution. Now the challenge is to convince everyone who is comfortable with HTML that XML will better serve their needs and offer them the most benefit. Industry-driven solution. Like I said before, I have recently entered the area of metadata, but I have gone through most of the resources I could, and unless I am missing some things along the way, this seems to be where some additional focus could be used; explanation of benefit as well as concept and use. And to bring the introduction of application up to speed with the introduction of information and concept. BTW, has anyone noticed the variance of how techmedia has perceived XML? I have seen articles that say XML is the direct replacement for HTML, while I have seen others that say XML is a compliment to HTML, and HTML will never really be phased out at this point. With this in mind, I got a somewhat panicked phone call from someone who came across the W3C draft for rewriting HTML 4.0 as an XML application recently. I was able to dispel his alarm, but the concern was somewhat understandable. Any comments?? Jason A. Buss Single Engine Technical Publications Cessna Aircraft Co. jabuss@cessna.textron.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Tue Jan 12 17:31:13 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:07:28 2004 Subject: Sneaking up on writers (was Into the fray...) In-Reply-To: Message-ID: <3.0.5.32.19990112093158.00940990@scripting.com> We've been working on this! Here's the solution. Come up with an editorial system where people write the initial versions of their texts with a plain text editor, whatever they like best. As it enters the publishing database, create an XML wrapper for it, automatically assigning default values for all the tags, since none were specified by the author. Then, when the piece is to be edited, either by the original author or another member of the team, give them the XML text, with the tags. They figure out what's expected of them, and when they see the original copy under the tag, the lightbulbs go on. It's the sneaky way to get XML into the hands of writers. They get it. Dave At 11:15 AM 1/12/99 -0600, Buss, Jason A wrote: >Hello to everyone. > >I just subscribed to this mailing list over the last couple of days and it >appears I have walked into a very interesting discussion. > >I just thought I would share a few things with everyone regarding the >impressions and hopes that I have for XML. > >I could be considered a relative newcomer to XML. I have been working with >SGML for the last 7 months or so, as part of a team that was formed to >implement an SGML publishing system for our company. The team went through >some reorganization, and I sort of got in at the tail end, implementation >side of things, as most of the research, conceptualizing, and development >had already been completed. Basically, I learned SGML by working with >various public tools as well as the commercial software we ordered, and the >internet. There just isn't a whole lot out there other than the materials >generated by the individuals and organizations committed to SGML > >Basically, we did evaluation after evaluation of commercial software, >decided on a publishing package from a very respected vendor. Showed it to >our technical writers, and watched them turn on us. The lack of real >information that came from the team to the publishing group only helped to >exacerbate the feelings of paranoia and helplessness from writers. They >were terrified that we were going to force everyone to learn programming. I >have, over time and vendor improvements, shown most people that this is not >the case. Most people hear "metalanguage", but think "language". > >I am no programmer by any stretch of the imagination. I was a technical >writer and illustrator before being coaxed into SGML publishing. I was put >off by the whole thing until I took a really close look at it. And that >brings me to a real sore spot that I think would love to see addressed when >people write white papers and abstracts to explain XML for the rest of us. >The concept of SGML (and XML) is no challenge for most people to grasp, but >the majority of published texts are so weighted down that most technical >writers come away either crushed or confused. Many of them need to see it >applied before they can fully grasp the application (particularly the >syntax). I personally had to read almost ten white papers before I came >away with everything I needed to get the whole picture. > >I know there are some people who are in the process of building SGML >publishing systems who are terrified because as the information and >resources for XML increases, the information and resources for SGML has >trailed off somewhat. A lot of people, for whatever reason, have missed the >XML/SGML connection, and are worried that SGML will fall out of favor, and >not have the support it once had. > >And hopefully, something, or someone, will bring XML to the forefront of >public awareness. Be it a well-branded vendor such as Microsoft (I am >personally banking on Netscape/Sun/IBM; AOL stands to gain hand over fist >from XML implementation), or the next Gates or Andressen or someone who can >really push XML not only into the office for production, but into the home >for delivery. Even the beginning web surfers quickly understand that it is >HTML and Java applets that make all this information visible within their >browser. Many people pick up on the concepts and syntax of HTML from there, >going on to create their own documents/pages, but the ones who choose not to >still understand the benefit of HTML. XML would probably be most likely to >succeed if it has the groundswell of support or at least understanding of >benefit from the public at large as it becomes implemented. Unfortunatlely, >I can ask 20 people familiar with HTML, and maybe two of them have heard of >XML. Almost none of them understand that HTML is a doctype of SGML. There >needs to be a really simple, straightforward PR blitz aimed not only at >publishers and document managers, but at webmasters and the general public. >It is very commendable of Microsoft to embrace XML like they have, but it >seems most of their papers are geared towards the industry, and promises XML >support in their products, as opposed to informing the general public of the >benefits to be gained from XML. People clamored for a way to share, >transmit, and display information in an inexpensive, easy-to use format that >could be accessible to anyone or everyone, Hence HTML, and the internet. >Customer-driven solution. Now the challenge is to convince everyone who is >comfortable with HTML that XML will better serve their needs and offer them >the most benefit. Industry-driven solution. > >Like I said before, I have recently entered the area of metadata, but I have >gone through most of the resources I could, and unless I am missing some >things along the way, this seems to be where some additional focus could be >used; explanation of benefit as well as concept and use. And to bring the >introduction of application up to speed with the introduction of information >and concept. > >BTW, has anyone noticed the variance of how techmedia has perceived XML? I >have seen articles that say XML is the direct replacement for HTML, while I >have seen others that say XML is a compliment to HTML, and HTML will never >really be phased out at this point. With this in mind, I got a somewhat >panicked phone call from someone who came across the W3C draft for rewriting >HTML 4.0 as an XML application recently. I was able to dispel his alarm, >but the concern was somewhat understandable. Any comments?? > >Jason A. Buss >Single Engine Technical Publications >Cessna Aircraft Co. >jabuss@cessna.textron.com > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > ----------------------------- http://www.scriptingnews.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ti64877 at imcnam.sbi.com Tue Jan 12 17:40:38 1999 From: ti64877 at imcnam.sbi.com (Ingargiola, Tito) Date: Mon Jun 7 17:07:28 2004 Subject: DOM & CORBA Message-ID: <3994C79D0211D211A99F00805FE6DEE249BF4C@exchny15.corp.smb.com> Hi, I imagine I'm missing something a bit obvious... I'm confused by the differences between the IDL definitions (http://www.w3.org/TR/REC-DOM-Level-1/idl-definitions.html) and the Java Language Binding (http://www.w3.org/TR/REC-DOM-Level-1/java-language-binding.html) provided along with the DOM spec. It seems to me that running any corba2.2-compliant idl-to-java compiler ought to generate the latter from the former (as well as a slew of stubs, skeletons and helper files). This doesn't seem possible, though, as the IDL definitions define different attributes/methods than the Java language binding. Example: /// from org-w3c-dom/Attr.idl interface Attr : Node { readonly attribute DOMString name; readonly attribute boolean specified; attribute DOMString value; }; /// from org.w3c.dom.Attr.java (comments removed) package org.w3c.dom; public interface Attr extends Node { public String getName(); public boolean getSpecified(); public String getValue(); public void setValue(String value); } The idl and java certainly resemble each other, but one couldn't expect an IDL compiler to get the one from the other without some help. By way of example, the idltojava compiler for JDK1.2 generates the following: /// from org-w3c-dom (comments and attributes from Node.idl removed) package org_w3c_dom; public interface Attr extends org.omg.CORBA.Object, org_w3c_dom.Node { short[] name(); boolean specified(); short[] value(); void value(short[] arg); } Both of the DOM-specified interfaces -- Attr.java and Attr.idl -- make sense; the java file should be based on public methods (the "atomic design element" in java), while the IDL version uses attributes for efficiency (do I really want to hit the network to find out an attribute's name or value? -- not likely!). However, I'm missing how they're meant to be used together... Is anybody using DOM objects in a CORBA environment? How are you dealing with this "mis-match"? What am I missing here? Many thanks for any help! Regards, Tito. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From johnm at magnet.com Tue Jan 12 18:04:36 1999 From: johnm at magnet.com (John Mitchell) Date: Mon Jun 7 17:07:28 2004 Subject: Sneaking up on writers (was Into the fray...) In-Reply-To: <3.0.5.32.19990112093158.00940990@scripting.com> Message-ID: On Tue, 12 Jan 1999, Dave Winer wrote: > We've been working on this! > > Here's the solution. Come up with an editorial system where people write > the initial versions of their texts with a plain text editor, whatever they > like best. As it enters the publishing database, create an XML wrapper for > it, automatically assigning default values for all the tags, since none > were specified by the author. Digital Creations has come up with a variation of this. It's a text format which is both human-readable and easily converted to HTML/XML/whatever. Things like *italic* and **bold** are supported, indenting, numbered/bulleted items, example code, etc. check: http://www.digicool.com/jim/python/StructuredText.html - j xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmcdonou at library.berkeley.edu Tue Jan 12 18:08:33 1999 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:07:28 2004 Subject: KQML In-Reply-To: <369B3048.DA5FE32@kamus.it> Message-ID: <3.0.5.32.19990112094816.009a3860@library.berkeley.edu> At 11:21 AM 1/12/1999 +0000, Pasqualino \\"Titto\\" Assini wrote: >Is anyone aware of XML mappings of KQML ? > Not exactly, but Scott Moore (samoore@umich.edu), a professor at Univ. of Michigan, developed an XML-based language, FLBC (Formal Language for Business Communication) and was working on translating KQML's standard performatives into it. He presented some of the work at a workshop at the Haas school here at Berkeley last year. You can find a short paper describing his work at: http://www.haas.berkeley.edu/~citm/cec/papers/moore/Moore.html with details on his views on KQML and how he thinks FLBC corrects some of KQML's deficiencies. I believe the Multimedia Research Group at the University of Southampton was also working on an XML-based performative language that borrowed heavily from KQML and ACL. I think Prof. Hugh Davis at U. Southampton (hcd@ecs.soton.ac.uk) was heading up that effort. Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......) Library Systems Office, 386 Doe, U.C. Berkeley | \ * * / Berkeley, CA 94720-6000 (510) 642-5168 | \ <> / "Well, it looks easy enough...." | \ -- / SGNORMPF!!! -- From the Famous Last Words file | |||| xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From april at syclo.com Tue Jan 12 18:29:19 1999 From: april at syclo.com (David S. April) Date: Mon Jun 7 17:07:28 2004 Subject: XML book - opinions Message-ID: <3.0.1.32.19990112122702.00e7ba88@quake.xnet.com> I have been trying to fulfill my obligation in the Small Computer book club and build up my XML reference library at the same time. I have been waiting for additional XML titles to show up in their catalog. Yesterday I saw a listing for "XML in Plain English" by Sandra E. Eddy. Any opinions on this book? FYI - I would like to get Simon's books (especially "XML - A Primer" which is a great intro to DTDs) through this book club but they don't carry them. Thanks in advance. Dave -- David S. April Syclo LLC april@syclo.com 101 Lions Dr - Suite 118 (847) 842-0320 Barrington, IL 60010 http://www.soasoas.com/april/ "Paradise is exactly like where you are right now, only much, much *better*." - Laurie Anderson xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 12 19:42:20 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:28 2004 Subject: A practical question about attributes Message-ID: <000301be3e63$1975fd80$5118a8c0@kuantech1.quokka.com> Folks, Having started a heavily philosophical thread about coherent standards, I want to ask a much more practical question. I am designing an XML schema for use in an environment that is extremely bandwidth sensitive. I can gain significant size reductions by representing things as attributes rather than sub-elements. Here is an example: 25Q15 57 bytes as opposed to 36 bytes Here's the question: does anyone know of any gotchas in using attributes instead of elements? Parsing issues, etc.? TIA, Jeff ----------------------------------------------------------------- Kuantech, Inc. http://www.kuantech.com Jeffrey E. Sussna, Principal jes@kuantech.com Distributed Content Architectures for Dynamic Online Applications ----------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jan 12 20:02:59 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:28 2004 Subject: A practical question about attributes References: <000301be3e63$1975fd80$5118a8c0@kuantech1.quokka.com> Message-ID: <369BAA43.1129137C@locke.ccil.org> Jeffrey E. Sussna wrote: > Having started a heavily philosophical thread about coherent > standards, I want to ask a much more practical question. That's what you think! Attributes vs. elements is about as "philosophical" than coherent standards. > Here's the question: does anyone know of any gotchas in using > attributes instead of elements? Parsing issues, etc.? See http://www.oasis-open.org/cover/elementsAndAttrs.html , the canonical location for best-practices on this vexed point. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jabuss at cessna.textron.com Tue Jan 12 20:15:07 1999 From: jabuss at cessna.textron.com (Buss, Jason A) Date: Mon Jun 7 17:07:28 2004 Subject: Sneaking up on writers (was Into the fray...) Message-ID: Actually, this solution is one of the proposed ideas for bringing our legacy data into our SGML publishing system. Once we really get to sit down with the writer and try out the software with them and walk them through it, they are surprised at the ease of authoring. The idea I was trying to convey is that normally you don't switch a publishing group to an all new concept of creating documents without giving them heads-up, information, some time to learn and understand before springing the new software on them. All the resources and materials I can find on the subjects seem to fill most writers (and myself, originally) with a mixture of loathing and abject terror. What I am suggesting for the folks who are developing XML standards and apps is creating documentation and books/papers/tutorials that are friendly to the non/unprogrammer. To ease them into the concept and syntax of XML without making them confused or stupefied by technical jargon or allusions to various programming languages/techniques. Something they can read through, absorb, then pick up a more technical, in-depth book or paper, and really have an understanding of what is being offered. When you start with intensely technical materials, you find yourself going round and round with various materials, reviewing the same ideas and concepts, looking for the one that is presented in a manner that finally causes the epiphany. Thanks for everyone's input, Jason A. Buss Single Engine Technical Publications Cessna Aircraft Co. jabuss@cessna.textron.com "I don't have your solution, but I do admire your problem..." > -----Original Message----- > From: Dave Winer [SMTP:dave@userland.com] > Sent: Tuesday, January 12, 1999 11:32 AM > To: xml-dev@ic.ac.uk > Subject: Sneaking up on writers (was Into the fray...) > > We've been working on this! > > Here's the solution. Come up with an editorial system where people write > the initial versions of their texts with a plain text editor, whatever > they > like best. As it enters the publishing database, create an XML wrapper for > it, automatically assigning default values for all the tags, since none > were specified by the author. > > Then, when the piece is to be edited, either by the original author or > another member of the team, give them the XML text, with the tags. > > They figure out what's expected of them, and when they see the original > copy under the tag, the lightbulbs go on. It's the sneaky way to > get > XML into the hands of writers. They get it. > > Dave > > > At 11:15 AM 1/12/99 -0600, Buss, Jason A wrote: > >Hello to everyone. > > > >I just subscribed to this mailing list over the last couple of days and > it > >appears I have walked into a very interesting discussion. > > > >I just thought I would share a few things with everyone regarding the > >impressions and hopes that I have for XML. > > > >I could be considered a relative newcomer to XML. I have been working > with > >SGML for the last 7 months or so, as part of a team that was formed to > >implement an SGML publishing system for our company. The team went > through > >some reorganization, and I sort of got in at the tail end, implementation > >side of things, as most of the research, conceptualizing, and development > >had already been completed. Basically, I learned SGML by working with > >various public tools as well as the commercial software we ordered, and > the > >internet. There just isn't a whole lot out there other than the > materials > >generated by the individuals and organizations committed to SGML > > > >Basically, we did evaluation after evaluation of commercial software, > >decided on a publishing package from a very respected vendor. Showed it > to > >our technical writers, and watched them turn on us. The lack of real > >information that came from the team to the publishing group only helped > to > >exacerbate the feelings of paranoia and helplessness from writers. They > >were terrified that we were going to force everyone to learn programming. > I > >have, over time and vendor improvements, shown most people that this is > not > >the case. Most people hear "metalanguage", but think "language". > > > >I am no programmer by any stretch of the imagination. I was a technical > >writer and illustrator before being coaxed into SGML publishing. I was > put > >off by the whole thing until I took a really close look at it. And that > >brings me to a real sore spot that I think would love to see addressed > when > >people write white papers and abstracts to explain XML for the rest of > us. > >The concept of SGML (and XML) is no challenge for most people to grasp, > but > >the majority of published texts are so weighted down that most technical > >writers come away either crushed or confused. Many of them need to see > it > >applied before they can fully grasp the application (particularly the > >syntax). I personally had to read almost ten white papers before I came > >away with everything I needed to get the whole picture. > > > >I know there are some people who are in the process of building SGML > >publishing systems who are terrified because as the information and > >resources for XML increases, the information and resources for SGML has > >trailed off somewhat. A lot of people, for whatever reason, have missed > the > >XML/SGML connection, and are worried that SGML will fall out of favor, > and > >not have the support it once had. > > > >And hopefully, something, or someone, will bring XML to the forefront of > >public awareness. Be it a well-branded vendor such as Microsoft (I am > >personally banking on Netscape/Sun/IBM; AOL stands to gain hand over > fist > >from XML implementation), or the next Gates or Andressen or someone who > can > >really push XML not only into the office for production, but into the > home > >for delivery. Even the beginning web surfers quickly understand that it > is > >HTML and Java applets that make all this information visible within their > >browser. Many people pick up on the concepts and syntax of HTML from > there, > >going on to create their own documents/pages, but the ones who choose not > to > >still understand the benefit of HTML. XML would probably be most likely > to > >succeed if it has the groundswell of support or at least understanding of > >benefit from the public at large as it becomes implemented. > Unfortunatlely, > >I can ask 20 people familiar with HTML, and maybe two of them have heard > of > >XML. Almost none of them understand that HTML is a doctype of SGML. > There > >needs to be a really simple, straightforward PR blitz aimed not only at > >publishers and document managers, but at webmasters and the general > public. > >It is very commendable of Microsoft to embrace XML like they have, but it > >seems most of their papers are geared towards the industry, and promises > XML > >support in their products, as opposed to informing the general public of > the > >benefits to be gained from XML. People clamored for a way to share, > >transmit, and display information in an inexpensive, easy-to use format > that > >could be accessible to anyone or everyone, Hence HTML, and the internet. > >Customer-driven solution. Now the challenge is to convince everyone who > is > >comfortable with HTML that XML will better serve their needs and offer > them > >the most benefit. Industry-driven solution. > > > >Like I said before, I have recently entered the area of metadata, but I > have > >gone through most of the resources I could, and unless I am missing some > >things along the way, this seems to be where some additional focus could > be > >used; explanation of benefit as well as concept and use. And to bring > the > >introduction of application up to speed with the introduction of > information > >and concept. > > > >BTW, has anyone noticed the variance of how techmedia has perceived XML? > I > >have seen articles that say XML is the direct replacement for HTML, while > I > >have seen others that say XML is a compliment to HTML, and HTML will > never > >really be phased out at this point. With this in mind, I got a somewhat > >panicked phone call from someone who came across the W3C draft for > rewriting > >HTML 4.0 as an XML application recently. I was able to dispel his alarm, > >but the concern was somewhat understandable. Any comments?? > > > >Jason A. Buss > >Single Engine Technical Publications > >Cessna Aircraft Co. > >jabuss@cessna.textron.com > > > > > > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > >(un)subscribe xml-dev > >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > >subscribe xml-dev-digest > >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > > > > ----------------------------- > http://www.scriptingnews.com/ > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Tue Jan 12 20:23:06 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:28 2004 Subject: A practical question about attributes In-Reply-To: <000301be3e63$1975fd80$5118a8c0@kuantech1.quokka.com> Message-ID: <3.0.1.32.19990112152311.01005410@pop.uunet.ca> A practical answer. Use attributes where you can and it suits you to do so. Don't use attributes if you are concerned that you may want to use structured values in a later version. Don't use attributes if you need to allow element markup within the value for any reason. At 02:38 PM 1/12/99 -0500, Jeffrey E. Sussna wrote: >Folks, > >Having started a heavily philosophical thread about coherent standards, I want to ask a much more practical question. I am designing an XML schema for use in an environment that is extremely bandwidth sensitive. I can gain significant size reductions by representing things as attributes rather than sub-elements. Here is an example: > >25Q15 > >57 bytes > >as opposed to > > > >36 bytes > >Here's the question: does anyone know of any gotchas in using attributes instead of elements? Parsing issues, etc.? > >TIA, >Jeff > >----------------------------------------------------------------- >Kuantech, Inc. http://www.kuantech.com >Jeffrey E. Sussna, Principal jes@kuantech.com > >Distributed Content Architectures for Dynamic Online Applications >----------------------------------------------------------------- > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Jan 12 20:26:40 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:28 2004 Subject: A practical question about attributes Message-ID: <3.0.32.19990112122401.00a44da0@pop.intergate.bc.ca> At 11:38 AM 1/12/99 -0800, Jeffrey E. Sussna wrote: >Folks, > >I can gain significant size reductions by representing things as attributes >rather than sub-elements. Here is an example: In general, I'd say it's a bad practice to warp your design out of shape in order to save bytes; LZ compression does a better job anyhow. >25Q15 > Let's take a closer look, at "25" vs id='25'. In this case, you're only saving 4 chars. Attributes carry 3 characters of overhead: equals and two quotation marks, beyond the name. If the length of the name is N, then elements carry N + 5 (end tag, <, >, ). So the saving is N+2 chars, where N is the length of the name. Work it out. >Here's the question: does anyone know of any gotchas in using attributes >instead of elements? Parsing issues, etc.? Yeah, they can't repeat, they can't have internal structure, they can't contain external entities, they have no defined order. But perhaps these aren't material in your application. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Tue Jan 12 21:15:54 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:29 2004 Subject: XML standards coherency and so forth In-Reply-To: <369B1DA3.EC721AE2@prescod.net> References: <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> <001a01be3dc4$bb8e44a0$5118a8c0@kuantech1.quokka.com> <3.0.1.32.19990111235816.00976c90@mail.accessone.com> Message-ID: <3.0.1.32.19990112113959.01205b80@mail.accessone.com> In the time frame we where evaluating tools, Microsoft's (at the time written by Microsoft - or at least available from their site) parser was not a candidate since it was written in Java. I didn't know about James Clark's expat at the time, nor so far as I know is it a commercial product being distributed under the Mozilla license. If java, instead of C/C++, had been an option, I would have opted for the IBM parser which had just gone "open source" royalty free license. We even tried using SP, but the Ms Mac compiler (the product had to be cross-platform for both windows and mac) became very pathalogical when compiling SP. Each and every one of the source files became a 500kb (really!) object file. We also tried an acedemic package from Europe - enough said. We eventually went with the WFC XML classes which imho was very sub-optimal since I would have preferred a validating parser. So far as I know, there is still not a commercially available (pure) XML validating parser written in C/C++. Dave LeBlanc At 04:02 AM 1/12/99 -0600, Paul Prescod wrote: >David LeBlanc wrote: >> >> Now, permit me to digress a bit. Having been studying and working with xml >> for the last 18 months or so, it seems to me this market is coming together >> very slowly. There are not yet any decent (at least not inexpensive) tools >> out for the average consumer-programmer that seem worth a darn. I >> implemented a small xml application for a commercial product, and we where >> unable to find usable off the shelf tools at any (reasonable) cost. Ditto >> for commercial C++ drop in parsing tools. > >In what sense are the Netscape supported (but not written) "expat" and the >Microsoft supported (but not written) msxml not "commercial C++ drop in >parsing tools?" > > Paul Prescod - ISOGEN Consulting Engineer speaking for only himself > http://itrc.uwaterloo.ca/~papresco > >"I want to give beauty pageants the respectability they deserve." > - Brooke Ross, Miss Canada International > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Tue Jan 12 21:17:03 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:29 2004 Subject: Word DOC to XML Converter In-Reply-To: <3.0.32.19990112081924.00b16410@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990112114641.01206c70@mail.accessone.com> FWIW, Ms has announced that Jan 31st is the last day they will accept orders for the Office 2K betas. For $20 you get at least a half a dozen cds. Dave LeBlanc At 08:22 AM 1/12/99 -0800, Tim Bray wrote: >At 11:01 AM 1/12/99 -0500, Andre-Claude Potvin wrote: >>So it's going to be a very limited use of XML. But at least it should >>respect W3C standards. > >There are lots of Office2K betas around; have a look and see what you >think. -Tim > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Tue Jan 12 21:31:21 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:07:29 2004 Subject: Word DOC to XML Converter References: <19990112103123.1910.qmail@www0x.netaddress.usa.net> Message-ID: <369BCD11.7A41B6E8@allette.com.au> Andreas Berg wrote: > I am searching for a converter from Word documents to XML. Unfortunatly I have > no time to wait for Office 2000..... Is there something like this available? Have a look at Rick Geimer's site (http://www.sesha.com/omlette/rtf2xml/) - he has written one in OmniMark that will run on the free version (OMLE). It works very nicely. As an aside, don't hold your breath waiting for support from Word in Office 2000 - I've been looking at a beta this week and it appears to store the document in straight HTML. The only thing that looks vaguely like XML is the document properties section and some formatting information, all embedded in comments. This redefinition of RTF into angle brackets is IMHO far less satisfactory than the software referred to above. The index in the Word documentation doesn't even include an entry for XML; I rank the XML support as virtually nil. -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 12 21:36:34 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:29 2004 Subject: XML standards coherency and so forth In-Reply-To: <004301be3dd0$5d8239a0$49f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <000601be3e73$289ea7c0$5118a8c0@kuantech1.quokka.com> I don't think I'm actually talking about "patterns" here in the OO sense of the word. I simply mean that there are multiple specs that all need to deal with file system hierarchies (DRP, ICE, WebDAV) and all do it in a different way. If we instead wrote a spec for representing a file system hierarchy, and perhaps a delta against that hierarchy, then we could build specs on top of that for versioning, authoring, replication, syndication, and so forth. Jeff -----Original Message----- From: Rick Jelliffe [mailto:ricko@allette.com.au] Sent: Monday, January 11, 1999 6:08 PM To: Jeffrey E. Sussna; 'XML-DEV' Subject: Re: XML standards coherency and so forth From: Jeffrey E. Sussna > XML is a data representation language. Well, XML is really a data *labelling* language (i.e. markup). By taking care of syntax, it exposes the difficult problem: how to go from mere labels to specific representation. > Why not start with a common representation for that content, then let the apps expose > different sets of operations on top of it? I think such an approach would go a long way > towards adding coherency between the various specs under development. I think you are right: apart from RDF in its limited domain, there is no movement in XML/SGML similar to the "pattern movement" in OO programming: a movement trying to extract the fundamental structural patterns in markup which can be used in any application. Architectural forms and namespaces give mechanisms for making it easier to use this approach, but they have not found archetypes. My book (XML & SGML Cookbook) is the only attempt I know to move towards a pattern-based way of marking up documents; Dave Megginson's "Structuring XML Documents" has a tacet awareness of the possibility of patterns too. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From JEROME.YUROW at hq.doe.gov Tue Jan 12 22:09:36 1999 From: JEROME.YUROW at hq.doe.gov (JEROME.YUROW@hq.doe.gov) Date: Mon Jun 7 17:07:29 2004 Subject: A practical question about attributes Message-ID: John Cowan suggests checking out the web site: http://www.oasis-open.org/cover/elementsAndAttrs.html So I did and got the message: "Not Found The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Tue Jan 12 22:25:15 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:29 2004 Subject: A practical question about attributes Message-ID: <5BF896CAFE8DD111812400805F1991F708AAED97@RED-MSG-08> Let's add one more (consequent) restriction on attributes: Because they cannot contain structure, the versioning story is harder. You cannot simply add some more subelements. -----Original Message----- From: Tim Bray [mailto:tbray@textuality.com] Sent: Tuesday, January 12, 1999 12:24 PM To: Jeffrey E. Sussna; 'XML-DEV' Subject: Re: A practical question about attributes At 11:38 AM 1/12/99 -0800, Jeffrey E. Sussna wrote: >Folks, > >I can gain significant size reductions by representing things as attributes >rather than sub-elements. Here is an example: In general, I'd say it's a bad practice to warp your design out of shape in order to save bytes; LZ compression does a better job anyhow. >25Q15 > Let's take a closer look, at "25" vs id='25'. In this case, you're only saving 4 chars. Attributes carry 3 characters of overhead: equals and two quotation marks, beyond the name. If the length of the name is N, then elements carry N + 5 (end tag, <, >, ). So the saving is N+2 chars, where N is the length of the name. Work it out. >Here's the question: does anyone know of any gotchas in using attributes >instead of elements? Parsing issues, etc.? Yeah, they can't repeat, they can't have internal structure, they can't contain external entities, they have no defined order. But perhaps these aren't material in your application. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jan 12 23:11:03 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:07:29 2004 Subject: A practical question about attributes In-Reply-To: <3.0.32.19990112122401.00a44da0@pop.intergate.bc.ca> Message-ID: <000101be3e80$57e34240$5118a8c0@kuantech1.quokka.com> In general I try not to warp my designs to save bytes; in this case, however, I'm on the edge of being able to justify using XML as opposed to a hardwired data format, for performance reasons. However, it turns out Tim is absolutely right. I generated some sample data using elements and then using attributes. Uncompressed, the file sizes in bytes were 8341 (elements), 5041 (attributes). After being zipped, though, the sizes were 1085 (elements), 989 (attributes). Assuming I can do the zip and unzip within the timing constraints (I'm pretty sure I can), then I think XML in general and the elements approach in particular will work. Thanks Tim! Jeff -----Original Message----- From: Tim Bray [mailto:tbray@textuality.com] Sent: Tuesday, January 12, 1999 12:24 PM To: Jeffrey E. Sussna; 'XML-DEV' Subject: Re: A practical question about attributes At 11:38 AM 1/12/99 -0800, Jeffrey E. Sussna wrote: >Folks, > >I can gain significant size reductions by representing things as attributes >rather than sub-elements. Here is an example: In general, I'd say it's a bad practice to warp your design out of shape in order to save bytes; LZ compression does a better job anyhow. >25Q15 > Let's take a closer look, at "25" vs id='25'. In this case, you're only saving 4 chars. Attributes carry 3 characters of overhead: equals and two quotation marks, beyond the name. If the length of the name is N, then elements carry N + 5 (end tag, <, >, ). So the saving is N+2 chars, where N is the length of the name. Work it out. >Here's the question: does anyone know of any gotchas in using attributes >instead of elements? Parsing issues, etc.? Yeah, they can't repeat, they can't have internal structure, they can't contain external entities, they have no defined order. But perhaps these aren't material in your application. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Tue Jan 12 23:47:45 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:07:29 2004 Subject: A practical question about attributes Message-ID: <000301be3e85$aed63940$25aedccf@ix.netcom.com> Pros:Use attributes when you want to enforce content, and you dont want the values to appear on the 'print out'. Cons:you cant use external entiies in attributes, you can't repeat them, and they have no fixed order. Use elements when the content is designed to be read. As far as the DOM is concerned, an element list is indexed and automatically updated, an attribute list is not. As far as I can see from reviewing the discussions over the last ten years (about 50% for and 50% against attributes) the rest is religion! Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) ----- Original Message ----- From: Jeffrey E. Sussna To: 'XML-DEV' Sent: Tuesday, January 12, 1999 2:38 PM Subject: A practical question about attributes >Folks, > >Having started a heavily philosophical thread about coherent standards, I want to ask a much more practical question. I am designing an XML schema for use in an environment that is extremely bandwidth sensitive. I can gain significant size reductions by representing things as attributes rather than sub-elements. Here is an example: > >25Q15 > >57 bytes > >as opposed to > > > >36 bytes > >Here's the question: does anyone know of any gotchas in using attributes instead of elements? Parsing issues, etc.? > >TIA, >Jeff > >----------------------------------------------------------------- >Kuantech, Inc. http://www.kuantech.com >Jeffrey E. Sussna, Principal jes@kuantech.com > >Distributed Content Architectures for Dynamic Online Applications >----------------------------------------------------------------- > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Jan 13 01:19:21 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:29 2004 Subject: MDSAX, an open framework for processing multiple document types Message-ID: <005501be3e92$438cc980$c9a8a8c0@thing2> MDSAX is a set of tools for organizing, managing, and directing sophisticated SAX (the Simple API for XML) processing of XML documents. Using MDSAX, developers can create clean entryways for documents, making it easier to create applications that work with multiple document types and can support some of the more sophisticated features of XML processing, like namespaces, XLink linking, XSL transformations, and architectural forms. MDSAX is distributed under the BSD license, and contributions are invited (and will be credited.) MDSAX is still very much under development and would benefit from your participation. Documentation is now available: http://www.jxml.com/mdsax/mdsaxintro.html Full source is available: http://www.jxml.com/download.html License: http://www.jxml.com/License.txt Bill la Forge xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shinichiro.hamada at toshiba.co.jp Wed Jan 13 04:46:11 1999 From: shinichiro.hamada at toshiba.co.jp (=?iso-2022-jp?B?GyRCSU1FRBsoQiAbJEI/LTBsTzobKEI=?=) Date: Mon Jun 7 17:07:29 2004 Subject: How 2 output tags att with XSL Message-ID: <007301be3eaf$708adc20$db247385@hoge.ssel.toshiba.co.jp> Hello. I am studying XML and XSL with IE5. And I wrote a simple sample with them like as following. ** xml file ** hoge1 hoge1.gif hoge2/param> hoge2.gif ** xsl file **
above xsl file is written for convert input xml file to a table structure, but i have no idea to embed given image filename from xml into the "src" attribute's value of "image" tag. If anyone knows how to do, please give me any advice. Thank you in advance. -- Shinichiro HAMADA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Wed Jan 13 07:42:34 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:29 2004 Subject: XML - NG Message-ID: <3.0.1.32.19990205234524.00916390@mail.accessone.com> (standing well away from the opening as he opens Pandora's box) Is there any group working or thinking about an XML 2.0 spec? Is XMLDev an appropriate place to talk about such a thing? Reading "Structuring XML" by David Megginson, I keep seeing things mentioned that are in SGML that I wonder why they got left out of XML. They don't appear to add undesired complexity to things and they do look like they would add to the power and flexibility of the notation. At a minimum, a couple of things i'd like to see are CDATA element content and CDATA attribute content. Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Wed Jan 13 08:04:54 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:29 2004 Subject: XML - NG Message-ID: <029701be3ecb$a0f449c0$0300000a@othniel.cygnus.uwa.edu.au> >Is there any group working or thinking about an XML 2.0 spec? Is XMLDev an >appropriate place to talk about such a thing? Have a look at http://www.w3.org/XML/Activity.html (section entitled "Current Situation") to see what is being worked on at the moment. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Associate Researcher, Electronic Commerce Network Curtin University of Technology, Perth, Western Australia Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Wed Jan 13 08:08:41 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:29 2004 Subject: XML - NG In-Reply-To: <029701be3ecb$a0f449c0$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <3.0.1.32.19990206001116.009ef690@mail.accessone.com> Yes, I had already looked there and that was one thing that prompted my mail. Sincerely, Dave LeBlanc At 04:06 PM 1/13/99 +0800, James Tauber wrote: >>Is there any group working or thinking about an XML 2.0 spec? Is XMLDev an >>appropriate place to talk about such a thing? > >Have a look at http://www.w3.org/XML/Activity.html (section entitled >"Current Situation") to see what is being worked on at the moment. > >James >-- >James Tauber / jtauber@jtauber.com / www.jtauber.com >Associate Researcher, Electronic Commerce Network >Curtin University of Technology, Perth, Western Australia > >Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Wed Jan 13 08:18:29 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:30 2004 Subject: XML - NG Message-ID: <02ad01be3ecd$94694fa0$0300000a@othniel.cygnus.uwa.edu.au> What changes did you want to see from XML 1.0? James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fiona_campbell at england.com Wed Jan 13 09:35:24 1999 From: fiona_campbell at england.com (Fiona Campbell) Date: Mon Jun 7 17:07:30 2004 Subject: (No Subject) Message-ID: Subscribe xml-dev Fiona Campbell __________________________________________________________________ Get your own free England E-mail address at http://www.england.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Wed Jan 13 09:55:01 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:30 2004 Subject: ANN: HTML Form to XML module Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136A14@eukbant101.ericsson.se> Although this is a perl module, I hope others will see the usefulness of this, and perhaps it can become a standard. I've created a module that is a subclass of CGI.pm which takes HTML Form output and generates XML. The aim of this module is to be able to generate _arbitrary_ XML, not a standard (read: less useful) DTD. In order to be able to do this the form element names use a standard naming convention, based around XSL/XQL. For example, the following form elements: will create the following XML:
val1
The benefit of this naming scheme is it should be possible (this has been demonstrated) to use an XQL processor to read in XML, and create these form values directly, this way you can have an XML editor in your browser with very little work. The module also has limited (although much more planned) support for ignoring form elements, using a namespace xmlcgi:ignore, so that you can use them for things other than generating XML. I'm very interested in feedback on this module, although I realise that most people here are not primarily Perl developers. I also have a much more extensive white paper available on this module, and more complex documentation is available in the archive should anyone require that. Find it temporarily at: http://www.fastnetltd.ndirect.co.uk/Perl/CGI-ToXML-0.03.tar.gz Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ R+++ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 13 12:03:17 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:30 2004 Subject: 7 Questions on DCDs References: <990112111050.13698@mail11.mitre.org.0> Message-ID: <369C8C6B.358CC3E@mecomnet.de> I missed any ansers to these, but would hope the answer to (2) is "no". To do it this way would conflate the identity of names with the rules for structure. This would be a bad idea. For example, it would permit well formed constructs in which that it would be impossible to determine the element declaration until its attributes have been parsed. Is this really necessary? Roger L. Costello wrote: > ... > of the past? > > (2) XML instance documents will specify the the DCD it is > conforming to using namespaces, rather the using the DOCTYPE > declaration? > > i.e., instead of: > > > "file://localhost/xml-course/xml-part1/BookCatalogue.dtd"> > > ... > > > it will be: > > > > > where in BookCatalogue.dcd I must have: > > > > DCD to define a Book Catalog > file://localhost/xml-course/xml-part1/BookCatalog > ue.dcd > > ... > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pchiang at bellatlantic.net Wed Jan 13 14:38:48 1999 From: pchiang at bellatlantic.net (pchiang@bellatlantic.net) Date: Mon Jun 7 17:07:30 2004 Subject: New XML EDI Tool ready for download Message-ID: <199901131438.JAA20169@smtp-out1.bellatlantic.net> Redix International Inc. recently announces a new XML/EDI tool that converts any file (EDI or proprietary) to XML. The tool gives you ability to define your own interface between your application software and XML formats, regardless of whether your application format is EDI based or proprietary. Besides Any-to-XML, some other features of the XML/EDI Authoring Tool include: -- Validate input data/file (loop structure, data type, etc) before constructing XML -- Extract code definitions from EDI standard -- User defined document type -- User defined tag name -- Wizard approach to help you build your conversion criteria -- GUI to help you maintain your message definitions and conversion criteria Several examples are provided in this tool. These include X12, EDIFACT, HIPAA (Health Insurance Portability and Accountability Act of 1996), Oracle ERP, and SAP. We also provide a tutorial that guides you through the steps to interface with the XML/EDI Authoring Tool. If interested, please visit http://www.redix.com. Thanks, Pen Chiang Redix International Inc. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gkholman at CraneSoftwrights.com Wed Jan 13 15:05:12 1999 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Mon Jun 7 17:07:30 2004 Subject: XML in Electronic Commerce List Group (RETRY 3) Message-ID: At 99/01/08 11:24 -0800, I wrote: >At 99/01/08 09:33 -0500, Roger L. Costello wrote: >>I have created a list group to discuss XML in Electronic Commerce. The >>purpose of the list group is to provide a forum for discussing how XML is >>and may be applied to EC. > >How would you compare your new list to: > > http://www.geocities.com/WallStreet/Floor/5815/mail1.htm > >... whose charter is: > > http://www.geocities.com/WallStreet/Floor/5815/charter.htm > >Though the focus is EDI, I see generic issues of EC are discussed (which is interesting since I'm no EC expert myself), and when people bring up generic topics of EC on this list, the discussion attracts (apparent) experts proffering their opinion. > >So many lists ... so little time .... > >............... Ken -- G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Training: http://www.CraneSoftwrights.com/x/schedule.htm Resources: http://www.CraneSoftwrights.com/x/resources.htm Shareware: http://www.CraneSoftwrights.com/x/shareware.htm Next XSL Training (see training link): WWW8 - 1999-05-11 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gkholman at CraneSoftwrights.com Wed Jan 13 15:05:16 1999 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Mon Jun 7 17:07:30 2004 Subject: How 2 output tags att with XSL (RETRY) Message-ID: At 99/01/13 13:44 +0900, Shinichiro HAMADA wrote: >I am studying XML and XSL with IE5. And I wrote a simple sample with them >like as following. >... >above xsl file is written for convert input xml file to a table structure, >but i have no idea to embed given image filename from xml into the "src" >attribute's value of "image" tag. > >If anyone knows how to do, please give me any advice. The example below illustrates an approach to this. The way I've written "test.xml" below is directly viewable with IE5b2, since it includes the link to the stylesheet. I hope this helps. ............. Ken T:\FTEMP>type test.xml hoge1 hoge1.gif hoge2 hoge2.gif T:\FTEMP>type test.msxsl
T:\FTEMP>call msxsl test.xml test.msxsl test.htm T:\FTEMP>type test.htm
hoge1
hoge2
T:\FTEMP> -- G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Training: http://www.CraneSoftwrights.com/x/schedule.htm Resources: http://www.CraneSoftwrights.com/x/resources.htm Shareware: http://www.CraneSoftwrights.com/x/shareware.htm Next XSL Training (see training link): WWW8 - 1999-05-11 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 13 15:09:03 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:30 2004 Subject: XML - NG References: <3.0.1.32.19990205234524.00916390@mail.accessone.com> Message-ID: <369CB69A.F082AC53@locke.ccil.org> David LeBlanc scripsit: > At a minimum, a couple of things i'd like to see are CDATA element content CDATA element content is Evil and Rude. The only reason to have it is to avoid using <s. Yet it doesn't do what you really want, because it is terminated by *any* ETAGO ("" brackets. > and CDATA attribute content. XML *has* CDATA attributes. What are you thinking of here? OTOH I have now been convinced that leaving out data attributes was a regrettable loss, although they can be sort of simulated by ordinary attributes that just happen to go with the unparsed entity. (Essentially, they are attributes attached directly to an unparsed entity; i.e. for a picture, the height and width of the picture.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jond at wrox.com Wed Jan 13 15:22:21 1999 From: jond at wrox.com (Jon Duckett) Date: Mon Jun 7 17:07:30 2004 Subject: Word DOC to XML Converter Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C17B7E5@WROX3> To clarify how XML is used in Office 2000, I have posted an article on the subject on the Wrox web developer site... http://webdev.wrox.co.uk/resources/articles/ It will form part of a new XML section of our site that we are developing at the moment. Hope this helps. Jon Duckett Wrox Press Programmer to Programmer(TM) www.wrox.com jond@wrox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Wed Jan 13 15:34:56 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:07:30 2004 Subject: Message-ID: <012201be3f0a$4de68b50$3cf96d8c@NT.JELLIFFE.COM.AU> 1) make sure the file has a .xml extension 2) make sure the file is valid. Download XML Notepad from Microsoft: it is not a validator, but it gives some error messages, and it is simple install. 3) do you have an XML header PI at the very top of your file? Is it lower case? 4) check how IE5 beta has displayed your file: is it in multiple colours and with little + and - buttons on the left side? If this is so, then you are looking at the default stylesheet for XML, and not just the text file. Rick Jelliffe -----Original Message----- From: hassan.hussein@zurich.com To: xml-dev@ic.ac.uk Date: Monday, 11 January 1999 22:24 > > >I am working on a solution to convert a text file to valid XML. I have created >the DTD and the XML document but when I try to display the XML file in the >browser (IE5 beta) then the browser displays the whole XML file including tags. >Does anyone know where I am getting wrong. I am new to the XML field. > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dante at mstirling.gsfc.nasa.gov Wed Jan 13 16:14:22 1999 From: dante at mstirling.gsfc.nasa.gov (Dante Lee) Date: Mon Jun 7 17:07:30 2004 Subject: XSL Message-ID: Can anyone give me a working example of an XSL document that IE 5.0 will support? Dante M. Lee Code 588 NASA/GSFC Greenbelt MD 20771 Voice = 301-521-1077 Bldg = 23 Rm = W415 Email = dante@mstirling.gsfc.nasa.gov dante4@hotmail.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nikita.ogievetsky at csfb.com Wed Jan 13 17:40:19 1999 From: nikita.ogievetsky at csfb.com (Ogievetsky, Nikita) Date: Mon Jun 7 17:07:30 2004 Subject: XML standards coherency and so forth Message-ID: <9C998CDFE027D211B61300A0C9CF9AB44246BB@SNYC11309> >Andreas Berg wrote: > I am searching for a converter from Word documents to XML. Unfortunatly >I have > no time to wait for Office 2000..... Is there something like this available? In the MS Word go to / menu, select "Save as HTML document". It will create a well formed XML file: HTML with all elements having start and end tags. (Just remember to exhume the - sorry for bad joke). Nikita Ogievetsky. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nikita.ogievetsky at csfb.com Wed Jan 13 17:55:52 1999 From: nikita.ogievetsky at csfb.com (Ogievetsky, Nikita) Date: Mon Jun 7 17:07:30 2004 Subject: Word DOC to XML Converter Message-ID: <9C998CDFE027D211B61300A0C9CF9AB44246BC@SNYC11309> >Andreas Berg wrote: > I am searching for a converter from Word documents to XML. Unfortunatly >I have > no time to wait for Office 2000..... Is there something like this available? In the MS Word go to / menu, select "Save as HTML document". It will create a well formed XML file: HTML with all elements having start and end tags. Apply XSL if you want tag name or attributes changed. (Just remember to exhume the - sorry for bad joke). Nikita Ogievetsky. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Jan 13 18:02:14 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:30 2004 Subject: XML - NG Message-ID: <001801be3f1e$5b3dd420$c9a8a8c0@thing2> From: John Cowan >XML *has* CDATA attributes. What are you thinking of here? And here I thought you could not include &'s in attribute data. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From CRAMIREZ at sag.es Wed Jan 13 18:08:14 1999 From: CRAMIREZ at sag.es (Carlos Ramirez Palacin) Date: Mon Jun 7 17:07:30 2004 Subject: Additional declarations included directly in xml document Message-ID: Hello, I have a problem with the additional declarations in a xml document. If I include the element pp declaration in my xml document ]> From cowan at locke.ccil.org Wed Jan 13 18:12:21 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:30 2004 Subject: XML - NG References: <001801be3f1e$5b3dd420$c9a8a8c0@thing2> Message-ID: <369CE171.255BCC84@locke.ccil.org> Bill la Forge wrote: > And here I thought you could not include &'s in attribute data. You can't. Nor <'s either. But CDATA in "CDATA attribute" does not mean the same thing as in "CDATA element content", which does not mean the same as in "CDATA section". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jan 13 18:23:21 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:30 2004 Subject: XML - NG In-Reply-To: <001801be3f1e$5b3dd420$c9a8a8c0@thing2> References: <001801be3f1e$5b3dd420$c9a8a8c0@thing2> Message-ID: <13980.58230.652819.707827@localhost.localdomain> Bill la Forge writes: > From: John Cowan > > >XML *has* CDATA attributes. What are you thinking of here? > > And here I thought you could not include &'s in attribute data. That's not what a CDATA attribute means in SGML or XML -- the terminology is admittedly confusing, but for attributes CDATA means "not a token", while for content it means "restricted delimiter recognition". Neither XML nor SGML allows literal '&' in an attribute value (except that SGML has bizarre delimiter-in-context rules that allow you to use literal '&' and '<' sometimes). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jan 13 18:23:27 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:30 2004 Subject: XML - NG In-Reply-To: <369CE171.255BCC84@locke.ccil.org> References: <001801be3f1e$5b3dd420$c9a8a8c0@thing2> Message-ID: <199901131822.NAA20536@hesketh.net> At 01:09 PM 1/13/99 -0500, John Cowan wrote: >Bill la Forge wrote: > >> And here I thought you could not include &'s in attribute data. > >You can't. Nor <'s either. But CDATA in "CDATA attribute" does not >mean the same thing as in "CDATA element content", which does not >mean the same as in "CDATA section". Which suggests that at some point a colossal renaming scheme is in order. Maybe the XML spec itself needs namespaces; just imagine: element:CDATA - for CDATA element content attribute:CDATA - for CDATA attributes section:CDATA - for CDATA marked sections No, it wouldn't work well that way, but it would certainly be interesting... Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmcdonou at library.berkeley.edu Wed Jan 13 18:33:22 1999 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:07:31 2004 Subject: XML In WordPerfect Message-ID: <3.0.5.32.19990113102824.011458b0@library.berkeley.edu> I saw this in the most recent edition of Computer Currents (http://www.thelearningcenter.com/computercurrents/): "Corel is making noise about changes to all four programs. Quattro Pro will let you handle bigger worksheets, save or open files directly to HTML, and edit files simultaneously with other users. Corel Presentations will give you more control over the setup and layout of Internet slide shows; you'll also be able to apply special effects like brightness and contrast. The interface on CorelCentral has been redesigned and an alarm clock has been added. As for WordPerfect, version 9 will offer XML and SGML editing features, including tree views of your document...." Has anyone played with/seen betas of WordPerfect Office 2000, and if so, any comments on the XML support therein? Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......) Library Systems Office, 386 Doe, U.C. Berkeley | \ * * / Berkeley, CA 94720-6000 (510) 642-5168 | \ <> / "Well, it looks easy enough...." | \ -- / SGNORMPF!!! -- From the Famous Last Words file | |||| xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gkholman at CraneSoftwrights.com Wed Jan 13 18:36:47 1999 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Mon Jun 7 17:07:31 2004 Subject: XSL In-Reply-To: Message-ID: At 99/01/13 12:00 -0500, Dante Lee wrote: >Can anyone give me a working example of an XSL document that IE 5.0 will >support? > > > Dante M. Lee Code 588 > NASA/GSFC Greenbelt MD 20771 > Voice = 301-521-1077 Bldg = 23 Rm = W415 > Email = dante@mstirling.gsfc.nasa.gov > dante4@hotmail.com This would have been better posted to: http://www.mulberrytech.com/xsl/xsl-list Here is an example XSL script ... save it in a directory and name the file "card.msxsl": ==============================8<-------------------------------- <xsl:value-of select="/card/name"/>

()

mailto:

Building: Room:
==============================8<-------------------------------- Here is an example XML file, save it in the same directory: ==============================8<-------------------------------- Dante M. Lee 588 301-521-1077 NASA/GSFC Greenbelt MD 20771 23 W415 dante@mstirling.gsfc.nasa.gov dante4@hotmail.com ==============================8<-------------------------------- If you use IE5b2, then directly viewing the XML file will style it for rendering. I hope this helps. ...... Ken -- G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Training: http://www.CraneSoftwrights.com/x/schedule.htm Resources: http://www.CraneSoftwrights.com/x/resources.htm Shareware: http://www.CraneSoftwrights.com/x/shareware.htm Next XSL Training (see training link): WWW8 - 1999-05-11 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 13 18:44:29 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:31 2004 Subject: XML - NG References: <001801be3f1e$5b3dd420$c9a8a8c0@thing2> <199901131822.NAA20536@hesketh.net> Message-ID: <369CE963.63F91C40@locke.ccil.org> Simon St.Laurent wrote: > >You can't. Nor <'s either. But CDATA in "CDATA attribute" does not > >mean the same thing as in "CDATA element content", which does not > >mean the same as in "CDATA section". > > Which suggests that at some point a colossal renaming scheme is in order. Aaaaak! One Great Renaming was enough! But at least in XML the term "CDATA" has only 2 meanings, rather than the 5 meanings of full SGML.... -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jan 13 18:52:04 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:31 2004 Subject: A practical question about attributes Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEDA3@RED-MSG-08> Something else to think about is that most modems contain compression software, so what looks like a wordy XML file will be sent as far fewer bytes. -----Original Message----- From: Jeffrey E. Sussna [mailto:jes@kuantech.com] Sent: Tuesday, January 12, 1999 3:08 PM To: 'Tim Bray'; 'XML-DEV' Subject: RE: A practical question about attributes In general I try not to warp my designs to save bytes; in this case, however, I'm on the edge of being able to justify using XML as opposed to a hardwired data format, for performance reasons. However, it turns out Tim is absolutely right. I generated some sample data using elements and then using attributes. Uncompressed, the file sizes in bytes were 8341 (elements), 5041 (attributes). After being zipped, though, the sizes were 1085 (elements), 989 (attributes). Assuming I can do the zip and unzip within the timing constraints (I'm pretty sure I can), then I think XML in general and the elements approach in particular will work. Thanks Tim! Jeff -----Original Message----- From: Tim Bray [mailto:tbray@textuality.com] Sent: Tuesday, January 12, 1999 12:24 PM To: Jeffrey E. Sussna; 'XML-DEV' Subject: Re: A practical question about attributes At 11:38 AM 1/12/99 -0800, Jeffrey E. Sussna wrote: >Folks, > >I can gain significant size reductions by representing things as attributes >rather than sub-elements. Here is an example: In general, I'd say it's a bad practice to warp your design out of shape in order to save bytes; LZ compression does a better job anyhow. >25Q15 > Let's take a closer look, at "25" vs id='25'. In this case, you're only saving 4 chars. Attributes carry 3 characters of overhead: equals and two quotation marks, beyond the name. If the length of the name is N, then elements carry N + 5 (end tag, <, >, ). So the saving is N+2 chars, where N is the length of the name. Work it out. >Here's the question: does anyone know of any gotchas in using attributes >instead of elements? Parsing issues, etc.? Yeah, they can't repeat, they can't have internal structure, they can't contain external entities, they have no defined order. But perhaps these aren't material in your application. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jan 13 19:01:25 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. Message-ID: <199901131901.OAA21238@hesketh.net> With all the focus on 'vertical' applications of XML, I'm a bit concerned that the opportunity to standardize some key horizontal elements may be past. Names, dates, and currency are typical items that are used in an enormous number of applications but are represented differently all over the world. XML seems like a useful tool for addressing these complexities, if only because of the ease with which its contents can be transformed into whatever format you want. MathML has addressed the complexities of mathematical notation - is there any similar movement for NameML, DateML, or CurrencyML? Or are we going to be stuck with 50 different formats for each of those? Just curious. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 13 19:36:19 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. References: <199901131901.OAA21238@hesketh.net> Message-ID: <369CF59E.D100F078@locke.ccil.org> Simon St.Laurent wrote: > [I]s there any similar movement for NameML, DateML, > or CurrencyML? Or are we going to be stuck with 50 different formats for > each of those? For all of these, we need architectures rather than markup languages per se, because applications may need more than one name, date, or money amount. The format of dates is nicely specified by a profile of ISO 8601, http://www.w3.org/TR/NOTE-datetime-970915.html , which is a W3 Note. So one convention would be to make any element that has a "date" attribute with that value (or some simpler one preferably) has mixed content in that format. Similar tricks can be played with the other two cases. As for the actual content, a name element should have the name as its content, and a "surname" attribute to indicate the thing to sort on, search for, e.g. Simon St. Laurent This is the most culturally neutral form. The term "surname" comes from X.500 Person, and is admitted to be a bit misleading. Bits about last name, first name, etc. are very culture specific. For currencies there are two items(*), the 3-letter ISO 4217 currency code (see http://www.indigo.ie/egt/standards/iso4217-en.html) and the amount expressed as a decimal fraction (with the international decimal point ",", please, not the North American full stop). I would recommend the currency code as an attribute and the value as element content, but there is a case to be made for representing them both as attributes and a properly formatted version (like "$32.45" for USD or "32$45" for PTE or "\u20AC32.45" for XEU). (*) Now that "data" is a mass noun, we need a new plural for "datum". One datum, two datums? Bletch. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Wed Jan 13 19:59:36 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:07:31 2004 Subject: Web XML application Message-ID: <000701be3f2f$1c198580$34aedccf@ix.netcom.com> Hi, I posted today a prototype of a web application that uses XML on the Client side. It makes use of Jon Bosak's Shakespeare XML files to build an application the can index, search and filter the files. It is a proto type and rather clunky. The only draw back is that as it makes heavy use of the W3 DOM you will need the IE5 beta to run it. It can be found at www.hypermedic.com/style follow the hyperlink to the demo. I would be grateful for feed back and suggestions. I hope to get an application up on the server side in the next week or so, so that anyone can view it. Regards, Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jan 13 20:08:10 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. In-Reply-To: <369CF59E.D100F078@locke.ccil.org> References: <199901131901.OAA21238@hesketh.net> Message-ID: <199901132007.PAA22900@hesketh.net> At 02:35 PM 1/13/99 -0500, John Cowan wrote: >> [I]s there any similar movement for NameML, DateML, >> or CurrencyML? Or are we going to be stuck with 50 different formats for >> each of those? > >For all of these, we need architectures rather than markup languages >per se, because applications may need more than one name, date, >or money amount. Applications will indeed need more than one name, date, or money amount - but will they need the information in multiple formats within the same document? Or would they rather get all names in a NameML format, all dates in a DateML format, and all currency in a CurrencyML format? Implementing these as architectures is fine with me, if you want to spare the odd element - but seeing them formally defined is most important. (And since XSL doesn't seem to support architectural forms, explaining the architectural approach itself to newcomers will be fun.) >The format of dates is nicely specified by a profile of ISO 8601, >http://www.w3.org/TR/NOTE-datetime-970915.html , which is a W3 Note. >So one convention would be to make any element that has a >"date" attribute with that value (or some simpler one preferably) >has mixed content in that format. Similar tricks can be played >with the other two cases. This is possible, certainly - I'd like to see something more formal, more thoroughly XML. Dates at least may be covered as a data type by a schema of some sort, which could then point to that NOTE without much difficulty. >As for the actual content, a name element should have the name >as its content, and a "surname" attribute to indicate the thing >to sort on, search for, e.g. > > Simon St. Laurent > >This is the most culturally neutral form. The term "surname" comes >from X.500 Person, and is admitted to be a bit misleading. >Bits about last name, first name, etc. are very culture specific. I spend a lot of time in my books apologizing about name formatting - first name and surname don't make sense in too many contexts. Family Name usually means something, unless you're in Iceland, and even there it's a mix. I'd really like to see something hammered out more formally. >For currencies there are two items(*), the 3-letter ISO 4217 currency >code (see http://www.indigo.ie/egt/standards/iso4217-en.html) >and the amount expressed as a decimal fraction (with the >international decimal point ",", please, not the North American >full stop). > >I would recommend the currency code as an attribute >and the value as element content, but there is a case to be made >for representing them both as attributes and a properly formatted >version (like "$32.45" for USD or "32$45" for PTE or >"\u20AC32.45" for XEU). This sounds promising - I could probably even learn to pronounce , as point given some practice - but again, we need to get this made some kind of standard that people can find and use. These seem like issues outside of the W3C's oversight - maybe they belong at ISO, or maybe someone else should take a look. Maybe the W3C's i18n folks could look at it. Leaving this information to chance seems like a good way to create enormous frustration in the long run, reducing the touted 'lowered costs' of XML as more and more incompatible formats describing similar things arise. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Wed Jan 13 20:40:41 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. In-Reply-To: <199901132007.PAA22900@hesketh.net> References: <369CF59E.D100F078@locke.ccil.org> <199901131901.OAA21238@hesketh.net> Message-ID: <3.0.1.32.19990206123956.01292410@mail.accessone.com> How does xsl not support architectural forms? As described in David Megginson's book, they are just a formalism for attaching attributes to elements which have meaning only for the architecture processor. Dave LeBlanc At 03:10 PM 1/13/99 -0500, Simon St.Laurent wrote: >Applications will indeed need more than one name, date, or money amount - >but will they need the information in multiple formats within the same >document? Or would they rather get all names in a NameML format, all dates >in a DateML format, and all currency in a CurrencyML format? Implementing >these as architectures is fine with me, if you want to spare the odd >element - but seeing them formally defined is most important. > >(And since XSL doesn't seem to support architectural forms, explaining the >architectural approach itself to newcomers will be fun.) > >Simon St.Laurent >XML: A Primer / Cookies >Sharing Bandwidth >Building XML Applications (March) >http://www.simonstl.com > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Wed Jan 13 20:40:42 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. In-Reply-To: <199901131901.OAA21238@hesketh.net> Message-ID: <3.0.1.32.19990206123428.01290730@mail.accessone.com> How about a novel idea: use the ISO standards for those things where they exist. I'm pretty sure there's an ISO standard for dates for example. Dave LeBlanc At 02:01 PM 1/13/99 -0500, Simon St.Laurent wrote: >With all the focus on 'vertical' applications of XML, I'm a bit concerned >that the opportunity to standardize some key horizontal elements may be >past. Names, dates, and currency are typical items that are used in an >enormous number of applications but are represented differently all over >the world. > >XML seems like a useful tool for addressing these complexities, if only >because of the ease with which its contents can be transformed into >whatever format you want. MathML has addressed the complexities of >mathematical notation - is there any similar movement for NameML, DateML, >or CurrencyML? Or are we going to be stuck with 50 different formats for >each of those? > >Just curious. > >Simon St.Laurent >XML: A Primer / Cookies >Sharing Bandwidth >Building XML Applications (March) >http://www.simonstl.com > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jan 13 20:49:35 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. In-Reply-To: <3.0.1.32.19990206123428.01290730@mail.accessone.com> References: <199901131901.OAA21238@hesketh.net> Message-ID: <199901132048.PAA23648@hesketh.net> At 12:34 PM 2/6/99 -0800, David LeBlanc wrote: >How about a novel idea: use the ISO standards for those things where they >exist. I'm pretty sure there's an ISO standard for dates for example. The problem isn't that there are no standards for dates - there certainly is an ISO date standard (8601) - but that there is no standard for representing dates in XML. Where does the date go in an element? Should it be a single string in an attribute, in element content, broken into year/month/day, or something else creative? Dates are the easiest because they have been thoroughly serialized (by the ISO and others) and because schemas are likely to reference them. Names and currency are both more complicated, as are other 'basic' things like phone numbers and (especially) addresses. If someone's really standardized these items, especially if they've done it in XML, I'd love to know. X.500's done some on the directory information front, but I haven't seen much call for using that framework in XML. Maybe we'll go that way. Who knows? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jan 13 21:10:29 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. In-Reply-To: <3.0.1.32.19990206123956.01292410@mail.accessone.com> References: <199901132007.PAA22900@hesketh.net> <369CF59E.D100F078@locke.ccil.org> <199901131901.OAA21238@hesketh.net> Message-ID: <199901132110.QAA24045@hesketh.net> David LeBlanc wrote: >How does xsl not support architectural forms? As described in David >Megginson's book, they are just a formalism for attaching attributes to >elements which have meaning only for the architecture processor. Paul Prescod wrote (on January 6th): >Andrew Layman wrote: >> >> If I understand this, the author is saying that the kinds of mappings >> achievable with architectural forms can also be achieved with XSL. Is that >> correct? > >This is more or less correct. XSL cannot implement the architectural form >mechanism, but I believe that anything you would want to do with archforms >could also be done with XSL -- for a particular DTD/archform pair. It >would be nice if an XSL stylesheet *could* do XAF-level generic >architectural form processing. > >Note, however, that architectural forms are completely declarative and can >be implemented in a highly optimized fashion. The sorts of extensions that >Microsoft has proposed for XSL (...) would completely destroy >those features. Architectural mapping would, in general, be as reliable >and high performance as ordinary software -- (not at all). I read this as saying the XSL doesn't do architectural forms directly - you'd have to write a stylesheet per DTD to do the transformation, rather than just saying 'go', which means that "yes, you can do it - but it isn't easy or pretty". Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jan 13 21:13:41 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEDAF@RED-MSG-08> The idea to build on existing standards is a good one. As Simon says below, there are standards for dates (e.g. ISO 8601) and a number of other notations. Some of the issues raised here are being addressed in the XML "datatypes" effort. One key thing to keep in mind is the distinction between a datatype in the sense of a notation (e.g. ISO 8601) versus structured element content, which is more a matter of standard element types, and is an area in which Namespaces should help people construct and organize standard libraries of element types. -----Original Message----- From: Simon St.Laurent [mailto:simonstl@simonstl.com] Sent: Wednesday, January 13, 1999 12:51 PM To: XML-Dev Mailing list Subject: Re: Names, Dates, Etc. At 12:34 PM 2/6/99 -0800, David LeBlanc wrote: >How about a novel idea: use the ISO standards for those things where they >exist. I'm pretty sure there's an ISO standard for dates for example. The problem isn't that there are no standards for dates - there certainly is an ISO date standard (8601) - but that there is no standard for representing dates in XML. Where does the date go in an element? Should it be a single string in an attribute, in element content, broken into year/month/day, or something else creative? Dates are the easiest because they have been thoroughly serialized (by the ISO and others) and because schemas are likely to reference them. Names and currency are both more complicated, as are other 'basic' things like phone numbers and (especially) addresses. If someone's really standardized these items, especially if they've done it in XML, I'd love to know. X.500's done some on the directory information front, but I haven't seen much call for using that framework in XML. Maybe we'll go that way. Who knows? Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 13 21:18:35 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:31 2004 Subject: Names, Dates, Etc. References: <199901131901.OAA21238@hesketh.net> <199901132007.PAA22900@hesketh.net> Message-ID: <369D0D58.BC2EAFE@locke.ccil.org> Simon St.Laurent scripsit: > Applications will indeed need more than one name, date, or money amount - > but will they need the information in multiple formats within the same > document? Or would they rather get all names in a NameML format, all dates > in a DateML format, and all currency in a CurrencyML format? Sure. My point was that the comparison with HTML or MathML is ill-founded, because those have fixed element types. We do not want a fixed element type "Date" analogous to "H2" or "over". > Implementing > these as architectures is fine with me, if you want to spare the odd > element - but seeing them formally defined is most important. You don't have to understand architectures to understand a specific application of them, any more than you have to understand SGML to understand an application of SGML (like, say, HTML). In particular, XLink is an architecture, but this fact is not mentioned in the XLink documents. > This is possible, certainly - I'd like to see something more formal, more > thoroughly XML. Date parsing is very simple and well-understood, so IMHO it is not worth using sub-elements. > >This is the most culturally neutral form. The term "surname" comes > >from X.500 Person, and is admitted to be a bit misleading. > >Bits about last name, first name, etc. are very culture specific. > > I spend a lot of time in my books apologizing about name formatting - first > name and surname don't make sense in too many contexts. Family Name > usually means something, unless you're in Iceland, and even there it's a > mix. In Iceland, "surname" would typically be the first name, since that's what they sort on. > I'd really like to see something hammered out more formally. The X.500 folks have done an unbelievable amount of work on these issues, especially in the Person schema, and it would be silly to reinvent that wheel. > This sounds promising - I could probably even learn to pronounce , as point > given some practice - but again, we need to get this made some kind of > standard that people can find and use. Agreed. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jan 13 21:39:22 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:32 2004 Subject: Names, Dates, Etc. In-Reply-To: <3.0.1.32.19990206123428.01290730@mail.accessone.com> References: <199901131901.OAA21238@hesketh.net> Message-ID: <3.0.1.32.19990113163519.00f2d5fc@pop.uunet.ca> At 03:34 PM 2/6/99 -0500, David LeBlanc wrote: >How about a novel idea: use the ISO standards for those things where they >exist. I'm pretty sure there's an ISO standard for dates for example. > >Dave LeBlanc That is exactly what we did in SOX, with a tip of the hat to the W3C "Date and Time" NOTE. Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Savage.Ron.RS at bhp.com.au Wed Jan 13 22:22:27 1999 From: Savage.Ron.RS at bhp.com.au (Savage, Ron RS) Date: Mon Jun 7 17:07:32 2004 Subject: FW: Names, Dates, Etc. Message-ID: <199901132220.JAA26820@gossamer.itmel.bhp.com.au> BTW: There is an Australian Standard with a name something like Geographic Locations, for eg postal addresses. Presumably there is an ISO equivalent. Just what XML needs to stop feature creep. Ron Savage Work (preferred): Savage.Ron.RS@bhp.com.au Home: rpsavage@ozemail.com.au http://www.ozemail.com.au/~rpsavage > ---------- > From: Murray Maloney[SMTP:murray@muzmo.com] > Reply To: Murray Maloney > Sent: Thursday, 14 January 1999 8:35 > To: XML-Dev Mailing list > Subject: Re: Names, Dates, Etc. > > At 03:34 PM 2/6/99 -0500, David LeBlanc wrote: > >How about a novel idea: use the ISO standards for those things where they > >exist. I'm pretty sure there's an ISO standard for dates for example. > > > >Dave LeBlanc > > That is exactly what we did in SOX, with a tip of the hat > to the W3C "Date and Time" NOTE. > > > Murray Maloney, Esq. Phone: (905) 509-9120 > Muzmo Communication Inc. Fax: (905) 509-8637 > 671 Cowan Circle Email: murray@muzmo.com > Pickering, Ontario Email: murray@yuri.org > Canada, L1W 3K6 > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tony.stewart at rivcom.com Wed Jan 13 23:01:16 1999 From: tony.stewart at rivcom.com (Tony Stewart) Date: Mon Jun 7 17:07:32 2004 Subject: Word DOC to XML Converter Message-ID: Nikita: Sorry, this trick doesn't quite work. Depending on the document you'll need to do a bunch of manual cleanup or write a script to take care of it. (Among other things, the SIZE attribute values are all unquoted.) OTOH "Save as HTML" does get you a good way down the road and gives you something you can work with. Whether the result is useful XML or not is another question. Regards, Tony tony.stewart@rivcom.com -----Original Message----- From: Ogievetsky, Nikita [mailto:nikita.ogievetsky@csfb.com] Sent: Wednesday, January 13, 1999 12:53 PM To: 'xml-dev@ic.ac.uk' Subject: RE: Word DOC to XML Converter >Andreas Berg wrote: > I am searching for a converter from Word documents to XML. Unfortunatly >I have > no time to wait for Office 2000..... Is there something like this available? In the MS Word go to / menu, select "Save as HTML document". It will create a well formed XML file: HTML with all elements having start and end tags. Apply XSL if you want tag name or attributes changed. (Just remember to exhume the - sorry for bad joke). Nikita Ogievetsky. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Jan 14 00:06:37 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:07:32 2004 Subject: A practical question about attributes References: <5BF896CAFE8DD111812400805F1991F708AAEDA3@RED-MSG-08> Message-ID: <369D3468.5BFD@hiwaay.net> Andrew Layman wrote: > > Something else to think about is that most modems contain compression > software, so what looks like a wordy XML file will be sent as far fewer > bytes. > That was the VRML answer too during the VRML 97 design effor, Andrew, and darned if everyone is still not trying to find ways to make the files smaller. Apparently, every byte is sacred. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Jan 14 00:09:08 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:07:32 2004 Subject: Names, Dates, Etc. References: <199901131901.OAA21238@hesketh.net> <369CF59E.D100F078@locke.ccil.org> Message-ID: <369D34F4.308E@hiwaay.net> John Cowan wrote: > > Simon St.Laurent wrote: > > > [I]s there any similar movement for NameML, DateML, > > or CurrencyML? Or are we going to be stuck with 50 different formats for > > each of those? > > For all of these, we need architectures rather than markup languages > per se, because applications may need more than one name, date, > or money amount. Glad to see that answer. The VRML NG discussion is creating a set of element types that directly correspond to the primitive datatypes required by the language. Hopefully, the concept of using such a DTD as an architecture will catch on. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Thu Jan 14 00:11:08 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:32 2004 Subject: A practical question about attributes Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEDBA@RED-MSG-08> Sure. Size is undoubtably important in many cases. In some circumstances, however, it may be a reasonable trade-off to allow a modem to compress a file rather than spending server cycles on a generic compression such as GZIP. -----Original Message----- From: len bullard [mailto:cbullard@hiwaay.net] Sent: Wednesday, January 13, 1999 4:04 PM To: Andrew Layman Cc: 'XML-DEV' Subject: Re: A practical question about attributes Andrew Layman wrote: > > Something else to think about is that most modems contain compression > software, so what looks like a wordy XML file will be sent as far fewer > bytes. > That was the VRML answer too during the VRML 97 design effor, Andrew, and darned if everyone is still not trying to find ways to make the files smaller. Apparently, every byte is sacred. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Steven_DeRose at Brown.edu Thu Jan 14 00:28:56 1999 From: Steven_DeRose at Brown.edu (Steve DeRose) Date: Mon Jun 7 17:07:32 2004 Subject: XML - NG In-Reply-To: <3.0.1.32.19990205234524.00916390@mail.accessone.com> Message-ID: At 3:45 AM -0400 2/6/99, David LeBlanc wrote: >At a minimum, a couple of things i'd like to see are CDATA element content >and CDATA attribute content. CDATA element content was one of the most-hated features of SGML (mainly because of the rules about how they end). But more importantly, adding it would remove one of the most important advantages (to my mind) of XML: you could no longer correctly parse a document without the DTD -- since you'd never know whether that "<" you just found was a delimiter or data. I discuss this at length in The SGML FAQ Book, along with the rationale that ultimately underlies many of XML's other choices (probably should have put "XML" in the title, since most of it talks about XML motivation anyway). As for CDATA attributes, I thought we had those. Now, "CDATA" for attributes doesn't mean "entities aren't recognized" in them -- but it doesn't mean that in SGML either. So if that's what you were hoping for, there's no way to get it without pitching the nice property that XML is an SGML subset -- SGML has no way to suppress delimiter recognition in attributes (except perhaps the MS[IOS]CHAR function characters, which I have never seen used, and doubt most SGML implementations actually implement). Just my $0.02. Steve Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd Chief Scientist, Scholarly Technology Group, and Adjunct Associate Professor, Brown University; Chief Scientist, Inso Corporation xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Thu Jan 14 01:21:52 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:32 2004 Subject: XML - NG In-Reply-To: References: <3.0.1.32.19990205234524.00916390@mail.accessone.com> Message-ID: <3.0.1.32.19990206170901.01271ec0@mail.accessone.com> Ok, I see I misspoke myself out of not understanding some things that have been pointed out about the various meanings of CDATA. I never whould have realized (well, not anytime soon), that attribute CDATA wasn't the same as other types of CDATA. Thanks. What I would like is a content type (call it UPDATA), that has a distinct start and stop tag ( ..... ) that is entirely unparsed. This would be useful for content that has lots of significant characters.. like xml itself. In fact, I was thinking that it could be .... , but I now realize that there's a lot of freight attached to that character combination :-). It seems blechy to have to declare content PCDATA and then do the <[CDATA[ ... ]]> thing in the document. It forces the author of a document rather then the designer of a document class to be responsible for "escaping" content. Dave LeBlanc At 07:27 PM 1/13/99 -0400, Steve DeRose wrote: >At 3:45 AM -0400 2/6/99, David LeBlanc wrote: >>At a minimum, a couple of things i'd like to see are CDATA element content >>and CDATA attribute content. > >CDATA element content was one of the most-hated features of SGML (mainly >because of the rules about how they end). But more importantly, adding it >would remove one of the most important advantages (to my mind) of XML: you >could no longer correctly parse a document without the DTD -- since you'd >never know whether that "<" you just found was a delimiter or data. I >discuss this at length in The SGML FAQ Book, along with the rationale that >ultimately underlies many of XML's other choices (probably should have put >"XML" in the title, since most of it talks about XML motivation anyway). > >As for CDATA attributes, I thought we had those. Now, "CDATA" for >attributes doesn't mean "entities aren't recognized" in them -- but it >doesn't mean that in SGML either. So if that's what you were hoping for, >there's no way to get it without pitching the nice property that XML is an >SGML subset -- SGML has no way to suppress delimiter recognition in >attributes (except perhaps the MS[IOS]CHAR function characters, which I >have never seen used, and doubt most SGML implementations actually >implement). > >Just my $0.02. > >Steve > > >Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd >Chief Scientist, Scholarly Technology Group, and > Adjunct Associate Professor, Brown University; >Chief Scientist, Inso Corporation > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Thu Jan 14 01:28:52 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:32 2004 Subject: XSL and Architectural Forms. Message-ID: <3.0.1.32.19990206173015.0120c830@mail.accessone.com> I split this out from names, dates etc. because it seems worthy of discussion on it's own merits. Firstly, as I understand Arch. forms, they are the declaration of some entities which have the effect of attaching one or more DTDs or DTD fragments that defines a set of attributes that can be added to various elements. Does using arch. forms prevent attaching an xsl style sheet? Is there any reason an xsl template can't have attributes? Is there any point to this? It seems to me that, as someone already pointed out, that a lot of the avalanche of proposals pending at the W3C are either DTDs or Arch. forms - many of which really don't have any place at the W3C if it weren't that the proposers where trying to have their idea of what's best cast into a W3C recommendation. (I'm not including XSL in this category!) Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Thu Jan 14 03:23:04 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:07:32 2004 Subject: Tools to create dtds Message-ID: <49092BAEAC84D2119B0600805FD40F9F120BC6@MDYNYCMSX1> >I understand there are tools to generate XML documents. Are there any tools >available for creating and managing DTDs ? Earl Hood's perlSGML is a collection of perl scripts, many of which are very handy when building, documenting, and maintaining DTDs. While you need perl installed, you don't need to know any perl to use them. I believe they even work with perl 4. They work fine with XML DTDs. Bob DuCharme www.snee.com/bob see www.snee.com/bob/xmlann for "XML: The Annotated Specification" from Prentice Hall. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tgraham at mulberrytech.com Thu Jan 14 04:04:55 1999 From: tgraham at mulberrytech.com (Tony Graham) Date: Mon Jun 7 17:07:32 2004 Subject: Tools to create dtds In-Reply-To: <49092BAEAC84D2119B0600805FD40F9F120BC6@MDYNYCMSX1> References: <49092BAEAC84D2119B0600805FD40F9F120BC6@MDYNYCMSX1> Message-ID: At 13 Jan 1999 14:33 -0500, DuCharme, Robert wrote: > >I understand there are tools to generate XML documents. Are there any > tools > >available for creating and managing DTDs ? My Emacs mode for creating and editing DTDs is available at http://www.mulberrytech.com/tdtd/ Regards, Tony Graham ====================================================================== Tony Graham mailto:tgraham@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9632 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Thu Jan 14 09:37:08 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:07:32 2004 Subject: XML - NG In-Reply-To: References: <3.0.1.32.19990205234524.00916390@mail.accessone.com> Message-ID: <3.0.6.32.19990114092904.00c55090@gpo.iol.ie> [Steve Dr Rose] >As for CDATA attributes, I thought we had those. Now, "CDATA" for >attributes doesn't mean "entities aren't recognized" in them -- but it >doesn't mean that in SGML either. So if that's what you were hoping for, >there's no way to get it without pitching the nice property that XML is an >SGML subset If XML is truly a subset of SGML, how come nsgmls - a paragon of SGML compliance - is not fully XML compliant? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From CRAMIREZ at sag.es Thu Jan 14 10:48:51 1999 From: CRAMIREZ at sag.es (Carlos Ramirez Palacin) Date: Mon Jun 7 17:07:32 2004 Subject: Additional declarations included directly in xml document Message-ID: Hello, I have a problem with the additional declarations in a xml document. If I include the element pp declaration in my xml document Where could be appear the element pp? In any place within the xml document? Between and ? At the same level that ? ]> From shinichiro.hamada at toshiba.co.jp Thu Jan 14 11:32:31 1999 From: shinichiro.hamada at toshiba.co.jp (=?iso-8859-1?B?lWyTYyCQTIjqmFk=?=) Date: Mon Jun 7 17:07:32 2004 Subject: How 2 output tags att with XSL Message-ID: <004601be3fb1$3b2cb6e0$db247385@hoge.ssel.toshiba.co.jp> Thank you for your kind advices. I succeeded with your way. BTW, you seemed to use "call msxsl" dos command for debugging xsl behavior. I don't know it. I want to debug xsl too, i don't have that command. Where can i get it? >T:\FTEMP>call msxsl test.xml test.msxsl test.htm >T:\FTEMP>type test.htm -- Shinichiro HAMADA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andreas_berg at usa.net Thu Jan 14 12:13:57 1999 From: andreas_berg at usa.net (Andreas Berg) Date: Mon Jun 7 17:07:32 2004 Subject: Entity handling in DOM Message-ID: <19990114120822.18925.qmail@www0q.netaddress.usa.net> I just did some DOM programming with IBM's XML4J. I experienced that if there is a general entity in the XML document the parser doesn't expand it and instead just provides an EntityReference node. The DOM standard says the parser "may" expand entities. I wondered what is the sense of not expanding? How do other parsers handle this? BTW, why is there a difference between general entities and parameter entities? To my (very naive) understanding entities are a kind of text replacement and should be handled transparently. Could please someone help me understand??? Thanks, Andreas. ____________________________________________________________________ Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gkholman at CraneSoftwrights.com Thu Jan 14 15:07:29 1999 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Mon Jun 7 17:07:32 2004 Subject: How 2 output tags att with XSL In-Reply-To: <004601be3fb1$3b2cb6e0$db247385@hoge.ssel.toshiba.co.jp> Message-ID: At 99/01/14 20:30 +0900, ?l?c ?L???YqmFk= wrote: >BTW, you seemed to use "call msxsl" dos command for debugging xsl behavior. >I don't know it. I want to debug xsl too, i don't have that command. Where >can i get it? > >>T:\FTEMP>call msxsl test.xml test.msxsl test.htm >>T:\FTEMP>type test.htm There was a 5-line script posted on the XSL list as follows: var data = WScript.CreateObject("Microsoft.XMLDOM"); var style = WScript.CreateObject("Microsoft.XMLDOM"); data.load(WScript.Arguments(0)); style.load(WScript.Arguments(1)); WScript.Echo( data.transformNode( style.documentElement )); There is a command line environment for scripting called the Windows Scripting Host available at: http://www.microsoft.com/management/wsh.htm I created a batch file that takes the same arguments as XT: source, style and destination: cscript //nologo p:\misc\js\xslproc.js %1 %2 >%3 This mimics what I use when I use XT, a batch file following James' invocation requirements: call xsl infile.xml instyle.xsl outfile.??? ... and when I want to debug something with MSXSL, I use: call msxsl infile.xml instyle.msxsl outfile.htm Personally, I distinguish my files by different extensions for each of the implementations of XSL. I hope this helps. ........... Ken -- G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Training: http://www.CraneSoftwrights.com/x/schedule.htm Resources: http://www.CraneSoftwrights.com/x/resources.htm Shareware: http://www.CraneSoftwrights.com/x/shareware.htm Next XSL Training (see training link): WWW8 - 1999-05-11 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wperry at fiduciary.com Thu Jan 14 16:03:34 1999 From: wperry at fiduciary.com (W. E. Perry) Date: Mon Jun 7 17:07:33 2004 Subject: Process vs. Markup (was Names, Dates, Etc.) References: <199901131901.OAA21238@hesketh.net> <369CF59E.D100F078@locke.ccil.org> Message-ID: <369E153C.ADB0594A@fiduciary.com> John Cowan wrote: > For all of these, we need architectures rather than markup languages > per se, because applications may need more than one name, date, > or money amount. This discussion now has nowhere to go without first sorting out the various stages of markup and processing. XML is being promoted--aggressively--as freedom for every Web author to express each nuance of personal epistemology by creating new tags, by following individual preferences in attributes vs. elements, and by constructing uniquely rococo subelement structures. That is the promise which has lured the customers in from the HTML world (the masses are not coming to XML from SGML). Namespaces somewhat codified the low rumblings there had always been that, someday, potential chaos would have to be tempered by agreed tagsets of industry- or discipline-wide scope. But XML is becoming a mass-market phenomenon because the fixed tagset(s) of HTML hit a wall, and the frustrated refugees are flocking to the most appealing possible promise: define your own markup. John Cowan is undoubtedly sincere when he declares > We do not want a fixed element type "Date" analogous to "H2" or "over". > Nevertheless, if the 'problem' is to be solved with markup alone, fixed element types are precisely what will eventually result. We speak of markup--the XML Recommendation describes markup and prescribes the most basic handling of it--but the builders of XML processors are the true audience for this philosophizing and these rules of markup. Parsers, of course, provide only the first stage of processing. The discussion of names, dates, etc. illustrates precisely the sort of processing which will have to be done and which we, as the xml-dev's, will presumably have to build. In the first place, I do not believe that we can simply withdraw, or even substantially limit, the perceived freedom to create tags and then to apply instance markup following personal inclination. In my evangelical experience, this is the one salient characteristic which draws every newcomer to XML. On the other hand, there are only a limited, and more-or-less easily enumerated, number of processes which can be performed on dates, or names, or other such classes of data. These processes are not only suitable for standardization, but ripe for it. Where this leaves us is with the need for an intermediate layer, not only to map between idiosyncratic markup and standardized process, but specifically to strip out the 'presentational'--including the inherently cultural--leaving only the 'ontological', which may be easily processed. This intermediate layer may well be a species of architectural forms, but it is predicated on a need for processing, not just for declarative markup. Notice, too, that our 'styling' mechanism must perform a mirror-image operation on the output of these standard processes. Dates submitted in one 'cultural' form, mixing presentational elements with their ontology, must be stripped in order that we may perform date arithmetic, but their subsequent presentation requires the reintroduction of cultural conventions--perhaps from a different culture than those which were originally stripped away. Some sense of how many layers of such cultural information must be stripped, and then re-introduced by degrees, is apparent in John Cowan's example of the sort order of Icelandic names. The details of that example imply that at least some standard name-handling processes must manipulate data sufficiently stripped that it requires the re-introduction of cultural data in order to establish a (presentational) sort order, even if that sort is only to facilitate the further handling of the data by another standard process. Walter Perry xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From acmuller at human.toyogakuen-u.ac.jp Thu Jan 14 16:24:39 1999 From: acmuller at human.toyogakuen-u.ac.jp (Charles Muller) Date: Mon Jun 7 17:07:33 2004 Subject: XSL examples Message-ID: <00ac01be3fda$7ee4d920$67ab89d2@dellxps300> >>Can anyone give me a working example of an XSL document that IE 5.0 will >>support? Please see http://www.human.toyogakuen-u.ac.jp/~acmuller/dicts/xmlbdict/data The XSL/XML/DTD listed there is currently working on my Win98 system with IE5B2 Regards, Charles Muller Toyo Gakuen University 1660 Hiregasaki, Nagareyama-shi, Chiba 270-0161 Japan Resources for East Asian Language and Thought http://www.human.toyogakuen-u.ac.jp/~acmuller xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nikita.ogievetsky at csfb.com Thu Jan 14 17:29:56 1999 From: nikita.ogievetsky at csfb.com (Ogievetsky, Nikita) Date: Mon Jun 7 17:07:33 2004 Subject: XML - NG Message-ID: <9C998CDFE027D211B61300A0C9CF9AB44246C1@SNYC11309> If we just could supply XML text element with datatype attribute, something like... && - equivalent to CDATA within element but easier to read. I would even declare it in DTD for some elements. For example for those holding URL. Nikita Ogievetsky >From: David LeBlanc >Date: Sat, 06 Feb 1999 17:09:01 -0800 >Subject: Re: XML - NG >Ok, I see I misspoke myself out of not understanding some things that have >been pointed out about the various meanings of CDATA. I never whould have >realized (well, not anytime soon), that attribute CDATA wasn't the same as >other types of CDATA. Thanks. > >What I would like is a content type (call it UPDATA), that has a distinct >start and stop tag ( ..... ) that is entirely unparsed. >This would be useful for content that has lots of significant characters.. >like xml itself. In fact, I was thinking that it could be .... >, but I now realize that there's a lot of freight attached to that >character combination :-). > >It seems blechy to have to declare content PCDATA and then do the <[CDATA[ >... ]]> thing in the document. It forces the author of a document rather >then the designer of a document class to be responsible for "escaping" >content. > >Dave LeBlanc > >At 07:27 PM 1/13/99 -0400, Steve DeRose wrote: >>At 3:45 AM -0400 2/6/99, David LeBlanc wrote: >>>At a minimum, a couple of things i'd like to see are CDATA element content >>>and CDATA attribute content. >> >>CDATA element content was one of the most-hated features of SGML (mainly >>because of the rules about how they end). But more importantly, adding it >>would remove one of the most important advantages (to my mind) of XML: you >>could no longer correctly parse a document without the DTD -- since you'd >>never know whether that "<" you just found was a delimiter or data. I >>discuss this at length in The SGML FAQ Book, along with the rationale that >>ultimately underlies many of XML's other choices (probably should have put >>"XML" in the title, since most of it talks about XML motivation anyway). >> >>As for CDATA attributes, I thought we had those. Now, "CDATA" for >>attributes doesn't mean "entities aren't recognized" in them -- but it >>doesn't mean that in SGML either. So if that's what you were hoping for, >>there's no way to get it without pitching the nice property that XML is an >>SGML subset -- SGML has no way to suppress delimiter recognition in >>attributes (except perhaps the MS[IOS]CHAR function characters, which I >>have never seen used, and doubt most SGML implementations actually >>implement). >> >>Just my $0.02. >> >>Steve >> >> >>Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd >>Chief Scientist, Scholarly Technology Group, and >> Adjunct Associate Professor, Brown University; >>Chief Scientist, Inso Corporation >> >> >> >>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >>(un)subscribe xml-dev >>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >>subscribe xml-dev-digest >>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) >> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 14 17:47:28 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:33 2004 Subject: XML - NG References: <3.0.1.32.19990205234524.00916390@mail.accessone.com> <3.0.6.32.19990114092904.00c55090@gpo.iol.ie> Message-ID: <369E2D89.C156BFF1@locke.ccil.org> Sean Mc Grath wrote: > If XML is truly a subset of SGML, how come nsgmls - a paragon of SGML > compliance - > is not fully XML compliant? nsgmls, IMHO, fails to report some erroneous XML as erroneous. It processes all correct XML correctly. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jan 14 17:50:27 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:07:33 2004 Subject: XML - NG In-Reply-To: <3.0.1.32.19990206170901.01271ec0@mail.accessone.com> (message from David LeBlanc on Sat, 06 Feb 1999 17:09:01 -0800) Message-ID: <199901141746.MAA29269@ruby.ora.com> > Date: Sat, 06 Feb 1999 17:09:01 -0800 > From: David LeBlanc > > What I would like is a content type (call it UPDATA), that has a > distinct start and stop tag ( ..... ) that is > entirely unparsed. This would be useful for content that has lots > of significant characters.. like xml itself. In fact, I was > thinking that it could be .... , but I now realize > that there's a lot of freight attached to that character combination > :-). > > It seems blechy to have to declare content PCDATA and then do the > <[CDATA[ ... ]]> thing in the document. It forces the author of a > document rather then the designer of a document class to be > responsible for "escaping" content. Your proposal uses a fixed element type. What's the difference between a fixed element type ... and a fixed string ? Why is requiring the author to insert an element less onerous than requiring the author to insert a CDATA marked section? If you want to allow *different* elements to be "UPDATA", then you have a situation where reading or not reading the DTD results in radically different interpretations of data, violating a major goal of the XML effort. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Jan 14 17:54:02 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:33 2004 Subject: XML - NG Message-ID: <3.0.32.19990114094721.00c76600@pop.intergate.bc.ca> At 01:09 PM 1/13/99 -0500, John Cowan wrote: >> And here I thought you could not include &'s in attribute data. > >You can't. Nor <'s either. But CDATA in "CDATA attribute" does not >mean the same thing as in "CDATA element content", which does not >mean the same as in "CDATA section". Urgh. John is right. Inherited from SGML. Sigh. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Jan 14 17:55:19 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:33 2004 Subject: XML - NG Message-ID: <3.0.32.19990114094354.00bbce80@pop.intergate.bc.ca> At 11:45 PM 2/5/99 -0800, David LeBlanc wrote: >Is there any group working or thinking about an XML 2.0 spec? Is XMLDev an >appropriate place to talk about such a thing? Nobody's working on it right now. You can talk about it anywhere. >At a minimum, a couple of things i'd like to see are CDATA element content >and CDATA attribute content. We have CDATA attribute content. CDATA element content is B.A.D. (broken as designed) in SGML because it terminates with the first Message-ID: <369E300A.4F84600E@locke.ccil.org> Andreas Berg wrote: > BTW, why is there a difference between general entities and parameter > entities? Probably so that entities useful for DTD-construction purposes don't leak into actual document instances. DOM questions should go to www-dom@w3.org . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 14 18:05:41 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:33 2004 Subject: Process vs. Markup (was Names, Dates, Etc.) References: <199901131901.OAA21238@hesketh.net> <369CF59E.D100F078@locke.ccil.org> <369E153C.ADB0594A@fiduciary.com> Message-ID: <369E31A4.5D10DDB4@locke.ccil.org> W. E. Perry wrote: > Some sense of how many > layers of such cultural information must be stripped, and then re-introduced by > degrees, is apparent in John Cowan's example of the sort order of Icelandic > names. Just so, though I would characterize it as "the Icelandic sort order of names". The difference is subtle-but-profound: Icelanders may expect to see even non-Icelandic names sorted this way, whereas non-Icelanders may expect to see even Icelandic names sorted otherwise. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 14 18:07:50 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:33 2004 Subject: XML media types revisited Message-ID: <199901141806.NAA07944@hesketh.net> I'm pondering the fairly thorny issue of MIME types and XML, and I'm really wondering if the approach of RFC 2376 is a good idea. Apart from dealing with an enormous number of possible complications regarding character sets, RFC 2376 (available at ftp://ftp.isi.edu/in-notes/rfc2376.txt) defines the text/xml and application/xml media types. I'm concerned that treating XML as a subtype isn't really appropriate to the nature of XML. XML isn't a subtype of text or application - it's really a type on which other applications can be built. Perhaps if media types had three levels - type/subtype/furthersubtype - text/xml and application/xml might make more sense to me. Which makes more sense? application/xml + sorting out DOCTYPE or xml/cml, xml/mathml, xml/xmi I don't expect the IETF to change this anytime soon, but it does seem like something that could stand improvement. XML isn't really a text format - Tim Bray used to say, it's a replacement for ASCII. I'm inclined to agree with him here, and think that maybe XML deserves to be placed on the same footing as ASCII, not underneath it. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jan 14 18:12:04 1999 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:07:33 2004 Subject: LISTRIVIA [was Re: XML - NG] In-Reply-To: <9C998CDFE027D211B61300A0C9CF9AB44246C1@SNYC11309> Message-ID: <3.0.1.16.19990114191023.08474f7e@pop3.demon.co.uk> At 12:26 14/01/99 -0500, [an XML-DEVer] wrote: [A short message] followed by about 30 times more quoted material. I haven't posted LISTRIVIA recently, so just to let those of you new to the list: - please do not quote material without thinking. A good posting quotes paragraphs from previous posters and intersperses them with high-quality comment. I cannot easily think of examples where quoted material should exceed the real posting. - please do not attach any documents. This includes HTML generated from certain mailers. Attachments: - foul up the mailer - increase my personal phone bill (yup!, I really have to pay to read about XML) - make some people annoyed. In general XML-DEV is for developers of XML. We're not heavy about what is posted but in general it's not appropriate to ask newbie questions about XML itself (see http://www.oasis-open.org/cover and http://www.ucc.ie/xml). There are also several other forums (comp.text.xml and XML-L). A particular feature of XML-DEV is the collaborative development of resources (programs, APIs, specifications, protocols, examples, etc.) If you have something to contribute, don't feel shy. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jarle.stabell at dokpro.uio.no Thu Jan 14 18:36:14 1999 From: jarle.stabell at dokpro.uio.no (Jarle Stabell) Date: Mon Jun 7 17:07:33 2004 Subject: XML - NG Message-ID: <01BE3FF5.92A978B0.jarle.stabell@dokpro.uio.no> Ogievetsky, Nikita wrote: > If we just could supply XML text element with datatype attribute, > something like... > && > - equivalent to CDATA within element but easier to read. It would be very confusing (IMHO) if the value of a rather innocent looking attribute decided how the parser should handle the parsing of the element, I think it would be much better if the start tag had a special marker somewhere, f.i "*" as in. && But, this is only day-dreaming of course... Cheers, Jarle xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 14 18:47:00 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:33 2004 Subject: XML media types revisited References: <199901141806.NAA07944@hesketh.net> Message-ID: <369E3B86.92111611@locke.ccil.org> Simon St.Laurent wrote: > I'm pondering the fairly thorny issue of MIME types and XML, and I'm really > wondering if the approach of RFC 2376 is a good idea. Apart from dealing > with an enormous number of possible complications regarding character sets, > RFC 2376 (available at ftp://ftp.isi.edu/in-notes/rfc2376.txt) defines the > text/xml and application/xml media types. I think it's worth pointing out that these are merely *generic* media types for XML: application/xml for any XML whatsoever, and text/xml for XML that meets the relatively lenient requirements of the "text" top-level type (basically, that the content makes sense as plain text and is not full of Base-64 rubbish, or the like, and that line breaks are represented as CR-LF). Specific applications of XML can and should be registered as distinct media types, possibly under other top-level types: an XML-based representation of music might be registered as "audio/musicml" in the expectation that some audio players might be able to play it. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 14 18:56:56 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:33 2004 Subject: Big Day for Namespaces, Styles Message-ID: <199901141856.NAA09018@hesketh.net> 'Namespaces in XML' is now a W3C recommendation: http://www.w3.org/TR/REC-xml-names/ At the same time, 'Associating Stylesheets With XML Documents' is now a Proposed Recommendation: http://www.w3.org/TR/PR-xml-stylesheet Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 14 19:03:57 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:34 2004 Subject: XML media types revisited In-Reply-To: <369E3B86.92111611@locke.ccil.org> References: <199901141806.NAA07944@hesketh.net> Message-ID: <199901141903.OAA09191@hesketh.net> At 01:46 PM 1/14/99 -0500, John Cowan wrote: >Specific applications of XML can and should be registered as distinct >media types, possibly under other top-level types: an XML-based >representation of music might be registered as "audio/musicml" >in the expectation that some audio players might be able to >play it. I agree that applications of XML can and should be registered as distinct media sub-types, but still think that XML itself makes as much (and possibly more) sense as a top-level type than text or application for most applications. While audio/musicml might make sense, it doesn't necessarily exclude xml/musicml. I'm not convinced that application/x-cml makes as much sense as xml/x-cml. An initial type of xml would significantly broaden the usability of generic xml applications, much as the initial type of text broadens the usability of generic text applications. (And there aren't any generic 'application' applications that I'm aware of.) Maybe I'll go poke around the IETF some more, when I have time. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jarle.stabell at dokpro.uio.no Thu Jan 14 19:22:18 1999 From: jarle.stabell at dokpro.uio.no (Jarle Stabell) Date: Mon Jun 7 17:07:34 2004 Subject: XSchema suggestion/wish: Parameter entity (or SGML DTD inclusions/exclusions?) "equivalent" Message-ID: <01BE3FFB.FCBDC930.jarle.stabell@dokpro.uio.no> The company I work for is building an XML tool where we need an easy to learn schema language, which needs to be extensible in the way described below. XSchema would suit us well if it had an extension "equivalent" to this. ---------------- DTD Design: ---------------- When (experienced) people design DTD's, they use "tricks/idioms" like the below (taken from John Covan's IBTWSH DTD http://www.ccil.org/~cowan/XML/ibtwsh.dtd ): ---------------- ---------------- We would like to be able to use the same idiom, but within XML instance syntax, f.i. like the following: ...etc... Now we need the equivalent to: F.i. like:                   We assume we could also need an element type to be available inside definitions (for set substraction), but DTD design gurus probably can tell whether this is needed or not. We would like "subschemas" to be able to extend (or substract) elementsets defined in base-/superschemas, ie changing also the part of the [total] schema defined in the baseschema. (The calculations of the extensions of the elementsets shouldn't be done before all the schemas have been read) This "set algebra" is perhaps not so "semantically pretty" as some inheritance mechanisms, but is IMHO quite easy to use/understand. --------- Example: --------- Assume you have a schema named BaseSchema (which someone else "owns", meaning it would bring you ugly maintaince problems if you change it in any way), which has an ElementSet named 'formattingtags' (used in a lot of mixed content elements). You would like to be able to extend this set with , and element types. You should be allowed to define a schema which "includes/inherits" BaseSchema, and "redefines/extends" the set 'formattingtags' to also include , and . Something like: ...mechanism to include baseschema...                   ...same for 'warning' and 'tip'... Advanced schema languages would be useful for DTD/schema designers even without any XML parser knowing that particular schema language, because authoring tools could automatically translate the advanced schemas into the simpler ones. Directly authoring big/complex XSchemas seems highly problematic without extensions like this one. Cheers, Jarle Stabell Digital Logikk AS xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jan 14 19:58:14 1999 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:07:34 2004 Subject: ANN: HTML Form to XML module In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136A14@eukbant101.ericss on.se> Message-ID: <3.0.1.16.19990114192641.4b97656e@pop3.demon.co.uk> At 10:52 13/01/99 +0100, Matthew Sergeant (EML) wrote: >Although this is a perl module, I hope others will see the usefulness of >this, and perhaps it can become a standard. Please don't feel embarrassed (if you were) about perl :-). I have recently started using perl (for CGI XML stuff) and am very impressed by the professionalism of the material produced, and the speed with which it has been developed. For those who may not know there is a perl-xml mailing list and I recently sent greetings from XML-DEV. As some of us remember, a classic protagonist in XML was the DPH or "Desperate Perl Hacker". The quality of the perl modules (XML::DOM, XML::Parser) should mean that a perl hacker never (or hardly ever) has to hack a perl parser themselves. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jan 14 19:58:16 1999 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:07:34 2004 Subject: XML - NG In-Reply-To: <029701be3ecb$a0f449c0$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <3.0.1.16.19990114192135.4c871a20@pop3.demon.co.uk> At 16:06 13/01/99 +0800, [...] wrote: >>Is there any group working or thinking about an XML 2.0 spec? Is XMLDev an >>appropriate place to talk about such a thing? It's marginal. In favour is that XML-DEV is a good breeding ground for ideas. Against is that this is formally a W3C activity and that it's easy to spend a lot of discussion getting nowhere. In the past I have tended to discourage such discussions, but I have deliberately let things run a bit more freely over the last 2 months or so. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Curt.Arnold at hyprotech.com Thu Jan 14 20:15:21 1999 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:07:34 2004 Subject: FW: XSchema suggestion/wish: Parameter entity (or SGML DTD inclus ions/exclusions?) "equivalent" Message-ID: <61DAD58E8F4ED211AC8400A0C9B468730121BE@THOR> Several features in XSchema were designed to allow reuse of attribute groups and element groups in subsequent releases, but are laying dormant since it was decided not to use a linking pattern that might conflict with XLink. From: Jarle Stabell [mailto:jarle.stabell@dokpro.uio.no] >>The company I work for is building an XML tool where we need an easy to >>learn schema language, which needs to be extensible in the way described >>below. >>XSchema would suit us well if it had an extension "equivalent" to this. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Ed at dega.com Thu Jan 14 20:58:05 1999 From: Ed at dega.com (Ed Howland) Date: Mon Jun 7 17:07:34 2004 Subject: XSchema and DTDs Message-ID: <30649320C177D111ADEC00A024E9F297169EF4@exchange-server.dega.com> I don't understand why there is both DTD and XSchema. Will XSchema eventually replace DTD or will both be used interchangeably? So far I only know of one XML parser that understands both: IE5b2. Are there more? Any open source parsers? Is MS's implementation compliant with the XSchema std? Why I want to know. I'm developing two independant XML languages: XRL (eXtensible Revision Language) for interchange of source code control like information on the web, and an XML <-> APAA (Automotive Parts Aftermarket Associate) mapping to exchange car parts catalog information in a biz2biz eCommerce setting. So for both of these I need to create a DTD or an XSchema. Which one would be more long term? Or do I need to do both. On the last point, can't XSL format a XSchema into DTD? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Ed at dega.com Thu Jan 14 21:01:52 1999 From: Ed at dega.com (Ed Howland) Date: Mon Jun 7 17:07:34 2004 Subject: XSchema and SOX. Message-ID: <30649320C177D111ADEC00A024E9F297169EF5@exchange-server.dega.com> Does anybody have the W3 spec/proposal paper for XSchema? I found something about SOX (Schema for Object-oriented XML) which seems even better than what I have read so far (MS web site about IE5b2) about XSchema. What is the status of these? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Thu Jan 14 21:24:51 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:34 2004 Subject: XSchema and DTDs Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEDCC@RED-MSG-08> Ed Howland says that IE5b2 supports DTDs and XSchema. I think that is not quite true. IE5b2 supports DTDs and a large subset of XML-Data (http://www.w3.org/TR/1998/NOTE-XML-data-0105/) as schema formats. Regarding his question on which one (DTD or XML-Data) schema you should create now, that depends on the features you need. Regarding what is the long-term plan, the XML Activity has a chartered working group to investigate and possibly recommend new schema formats. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Curt.Arnold at hyprotech.com Thu Jan 14 21:29:27 1999 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:07:34 2004 Subject: XSchema and SOX. Message-ID: <61DAD58E8F4ED211AC8400A0C9B468730121BF@THOR> >>Does anybody have the W3 spec/proposal paper for XSchema? I found something >>about SOX (Schema for Object-oriented XML) which seems even better than what >>I have read so far (MS web site about IE5b2) about XSchema. What is the >>status of these? XSchema, XML-Data, DCD and SOX are all proposal for XML-based representation of schema information. XSchema was a product of this list and has no W3C status. The other three have been submitted to the W3C as a note. Hopefully all four are being considered in a W3C working group on XML schemas and an unified standard will emerge. XSchema is available at http://purl.oclc.org/NET/xschema. You might want to check http://www.oasis-open.org/cover/xml.html#xml-XSchema for more background on XSchema, DCD etc. Currently, the Microsoft IE5 parser supports something in between XML-Data and DCD, but has no support for XSchema (that I know of). I think most people that are using the XML-based schema languages are using them as a higher-level language for schema generation and then converting them down to the universally recognized DTD. Just like a C++ and Delphi parser would result in the univerally understood Intel-byte code :). Myself, I'm using a DCD variant that I have enhanced with documentation elements and am building DTD's and HTMLHelp documentation from a unified source. Until the W3C working group gets further in its progress, I think that translation down to DTD's is required. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 14 21:43:17 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:34 2004 Subject: Big Day for Namespaces, Styles References: <199901141856.NAA09018@hesketh.net> Message-ID: <369E64D7.2458FE55@infinet.com> "Simon St.Laurent" wrote: > 'Namespaces in XML' is now a W3C recommendation: > > http://www.w3.org/TR/REC-xml-names/ This is a very, very, very sad day for the XML Community which will be remembered for eons as the day XML complicated itself to the point where it is virtually unusable by the masses, at least as far as namespaces is concerned. Right now for a number of XML related projects I am working on, I am pondering whether or not to: (1) Ignore namespaces altogether and never mention the phrase "Namespaces in XML" in the words I speak. (2) Roll my own proprietary namespaces implementation (I really don't like this option but just about anything can be better than what we currently have). (3) Look into something like David Megginson's XAF to do what I need for now and the future. (4) Get by without any namespaces mechanism as I have so far to date. For technologies like XSL where you will have web-site designers who don't have CS degrees from fancy-shmancy institutions, "Namespaces in XML" will be a bigger travesty as transformation of XSL is complicated enough already. The W3C Namespaces WG could of done a much better job if they tried harder and did not fall into the groupthink model that appears to have driven this draft from the beginning. These are my own personal opinions. I don't mean to be rude or disrespectful to the WG and editors of this draft, but I really don't know of any other forum where I can publicly display my deep frustration and disappointment with this WG recommendation that us developers are expected to use and implement in our software products as some sort of "standard". Namespaces plain and simple are inefficient to process, sloppy (making namespace declarations through the use of attributes), and most importantly too complicated for the end-user IMVVVVVVVHO. In the future, the W3C will need to get more non-programmers like web-site developers developing these specs cause they will in the end be the ones who will be using XSL, XML, and all of the related technologies the most. When us programmers write specs that are too complicated for mere mortals to understand at first glance, then we are only spewing out useless text to glorify ourselves and each other. When will the W3C get the point that end-users matter. Sincerely, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Thu Jan 14 21:52:04 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:34 2004 Subject: XSchema and SOX. In-Reply-To: <61DAD58E8F4ED211AC8400A0C9B468730121BF@THOR> Message-ID: <3.0.1.32.19990114164512.00ee1790@pop.uunet.ca> At 04:27 PM 1/14/99 -0500, Arnold, Curt wrote: >XSchema, XML-Data, DCD and SOX are all proposal for XML-based representation >of schema information. XSchema was a product of this list and has no W3C >status. The other three have been submitted to the W3C as a note. >Hopefully all four are being considered in a W3C working group on XML >schemas and an unified standard will emerge. I think that I can safely assure you all that all of these specs will be considered by members of the working group. Regards, Murray xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Curt.Arnold at hyprotech.com Thu Jan 14 21:55:55 1999 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:07:34 2004 Subject: Microsoft XML chat tomorrow Message-ID: <61DAD58E8F4ED211AC8400A0C9B468730121C1@THOR> >From Microsoft's Developer Chat page (http://msdn.microsoft.com/developer/chat/default.htm) > Friday, January 15th, 9-10 a.m. (PST) 5-6 p.m. (GMT) Join Program Managers > from Microsoft's XML team for a chat about Microsoft's XML support. Topics > will include Microsoft's XML parser, the XML DOM, XSL, and XML-Schemas. > MSDN Online Chat MSJ > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Jan 14 22:00:13 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:34 2004 Subject: Big Day for Namespaces, Styles Message-ID: <3.0.32.19990114135802.00be2da0@pop.intergate.bc.ca> At 04:42 PM 1/14/99 -0500, Tyler Baker wrote: >The W3C Namespaces WG could of done a much better job if they tried harder and >did not fall into the groupthink model that appears to have driven this draft >from the beginning. Well, namespaces may be a horrible terrible thing as Tyler says, but I can assure everyone that they are not a result of group-think. I'm no standards veteran, but I can tell you that the process of designing the namespace spec was the longest, toughest, most contentious, most complex work ever done in the sphere of the XML activity. If I told you how many person-months were burned up in producing this puppy, you wouldn't believe me. Not a surprise. Phil Karlton, one of the smartest programmers I ever met, said "there are only two hard problems in Computer Science: cache invalidation and naming things". If anyone ever proposes XML-based cache invalidation, watch me run the other way. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Thu Jan 14 22:58:58 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:07:34 2004 Subject: Exploring Allaire's WDDX.. In-Reply-To: <30649320C177D111ADEC00A024E9F297169EF4@exchange-server.deg a.com> Message-ID: <3.0.5.32.19990114150023.00b93db0@scripting.com> I've been doing an exploration of Allaire's WDDX object serialization format, and put up this website for the Frontier community, and it just occurred to me that since WDDX is a flavor of XML, that the people on the xml-dev list might be interested. http://nirvana.userland.com/wddx/ Dave PS: Happy Birthday to namespaces! ----------------------------- http://www.scriptingnews.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Thu Jan 14 23:35:59 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:07:34 2004 Subject: Big Day for Namespaces, Styles In-Reply-To: <369E64D7.2458FE55@infinet.com> (message from Tyler Baker on Thu, 14 Jan 1999 16:42:47 -0500) References: <199901141856.NAA09018@hesketh.net> <369E64D7.2458FE55@infinet.com> Message-ID: <199901142335.RAA01230@bruno.techno.com> [Tyler Baker:] > For technologies like XSL where you will have web-site designers who > don't have CS degrees from fancy-shmancy institutions, "Namespaces > in XML" will be a bigger travesty as transformation of XSL is > complicated enough already. It's wrong to suppose that information management is easy. It's not. Information technology only makes the easy parts easier by making the hard parts harder. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Thu Jan 14 23:52:42 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:07:34 2004 Subject: XML media types revisited In-Reply-To: <199901141806.NAA07944@hesketh.net> Message-ID: <4.1.19990115104411.00bd5360@steptwo.com.au> At 04:08 15/01/1999 , Simon wrote: | Which makes more sense? | | application/xml + sorting out DOCTYPE | | or | | xml/cml, xml/mathml, xml/xmi | | I don't expect the IETF to change this anytime soon, but it does seem like | something that could stand improvement. XML isn't really a text format - | Tim Bray used to say, it's a replacement for ASCII. I'm inclined to agree | with him here, and think that maybe XML deserves to be placed on the same | footing as ASCII, not underneath it. Maybe I'm overlooking the obvious, but: What distinguishes cml, MathML, etc from any other DTD? ie, if we are looking at xml/mathml, why shouldn't I expect to have: xml/myml xml/theirml xml/everyonesml That is, if we are using the MIME type to distinguish between DTDs, won't we need a type for _every_ DTD that could be used for interchange? J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 15 00:00:04 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:34 2004 Subject: XML media types revisited In-Reply-To: <4.1.19990115104411.00bd5360@steptwo.com.au> References: <199901141806.NAA07944@hesketh.net> Message-ID: <199901142359.SAA19362@hesketh.net> At 10:49 AM 1/15/99 +1000, James Robertson wrote: >Maybe I'm overlooking the obvious, but: > >What distinguishes cml, MathML, etc from any other >DTD? > >ie, if we are looking at xml/mathml, why shouldn't >I expect to have: > > xml/myml > xml/theirml > xml/everyonesml > >That is, if we are using the MIME type to distinguish >between DTDs, won't we need a type for _every_ DTD >that could be used for interchange? That's fine by me, except that it would need to be: xml/x-myml xml/x-theirml xml/x-everyonesml (or xml/everyonesml if 'everyonesml' was a registered subtype.) Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Fri Jan 15 00:29:25 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:07:35 2004 Subject: XML media types revisited In-Reply-To: <199901142359.SAA19362@hesketh.net> References: <4.1.19990115104411.00bd5360@steptwo.com.au> <199901141806.NAA07944@hesketh.net> Message-ID: <4.1.19990115112029.00be63d0@steptwo.com.au> At 10:02 15/01/1999 , Simon St.Laurent wrote: | At 10:49 AM 1/15/99 +1000, James Robertson wrote: | >Maybe I'm overlooking the obvious, but: | > | >What distinguishes cml, MathML, etc from any other | >DTD? | > | >ie, if we are looking at xml/mathml, why shouldn't | >I expect to have: | > | > xml/myml | > xml/theirml | > xml/everyonesml | > | >That is, if we are using the MIME type to distinguish | >between DTDs, won't we need a type for _every_ DTD | >that could be used for interchange? | | That's fine by me, except that it would need to be: | xml/x-myml | xml/x-theirml | xml/x-everyonesml (or xml/everyonesml if 'everyonesml' was a registered | subtype.) OK, that's fine. But to rephrase my question: Who decides which DTDs have sufficient merit/useage/stability/etc to warrant a registered subtype? It seems unrealistic to expect IETF to make those sort of decisions. Or, to rephrase again: If I write a new DTD for (say) classifying house bricks, to be used in the building industry, and I go to to the IETF, and say: Give me a registered subtype! What should they do and say? Cheers, J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 15 00:45:43 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:35 2004 Subject: XML media types revisited In-Reply-To: <4.1.19990115112029.00be63d0@steptwo.com.au> References: <199901142359.SAA19362@hesketh.net> <4.1.19990115104411.00bd5360@steptwo.com.au> <199901141806.NAA07944@hesketh.net> Message-ID: <199901150045.TAA20072@hesketh.net> At 11:26 AM 1/15/99 +1000, James Robertson wrote: >Who decides which DTDs have sufficient merit/useage/stability/etc >to warrant a registered subtype? > >It seems unrealistic to expect IETF to make those sort >of decisions. > >Or, to rephrase again: > >If I write a new DTD for (say) classifying house bricks, >to be used in the building industry, and I go to to the >IETF, and say: > > Give me a registered subtype! > >What should they do and say? Same as they do for everyone else. See: ftp://ftp.isi.edu/in-notes/rfc1590.txt for details, unless it's been revised since. It doesn't look too painful. Looking through my Netscape settings, it seems like the x- types are used without too much concern. Unless you hit a naming conflict, registration doesn't really matter. It doesn't seem like a large problem. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tscola at research.att.com Fri Jan 15 01:05:57 1999 From: tscola at research.att.com (Tom Scola) Date: Mon Jun 7 17:07:35 2004 Subject: XML media types revisited In-Reply-To: <199901150045.TAA20072@hesketh.net> Message-ID: On Thu, 14 Jan 1999, Simon St.Laurent wrote: > Same as they do for everyone else. See: > ftp://ftp.isi.edu/in-notes/rfc1590.txt > > for details, unless it's been revised since. It doesn't look too painful. rfc2048 is the (substantially) revised version. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 04:04:23 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:35 2004 Subject: XML media types revisited In-Reply-To: <199901150045.TAA20072@hesketh.net> Message-ID: <001b01be403b$961b9230$d3228018@jabr.ne.mediaone.net> Simon, et al., On the other hand, the fact that DTD's exist obviates the need for xml MIME subtypes. text/xml is sufficiently expressive, and when not text/xxx will do. I mean its text/html, not sgml/html. The fact is, xml is text plain and simple. Jonathan Borden JABR Technology Corp. http://jabr.ne.mediaone.net > > At 11:26 AM 1/15/99 +1000, James Robertson wrote: > >Who decides which DTDs have sufficient merit/useage/stability/etc > >to warrant a registered subtype? > > > >It seems unrealistic to expect IETF to make those sort > >of decisions. > > > >Or, to rephrase again: > > > >If I write a new DTD for (say) classifying house bricks, > >to be used in the building industry, and I go to to the > >IETF, and say: > > > > Give me a registered subtype! > > > >What should they do and say? > > Same as they do for everyone else. See: > ftp://ftp.isi.edu/in-notes/rfc1590.txt > > for details, unless it's been revised since. It doesn't look too painful. > > Looking through my Netscape settings, it seems like the x- types are used > without too much concern. Unless you hit a naming conflict, registration > doesn't really matter. It doesn't seem like a large problem. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Fri Jan 15 04:11:36 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:35 2004 Subject: XML - NG In-Reply-To: <199901141746.MAA29269@ruby.ora.com> References: <3.0.1.32.19990206170901.01271ec0@mail.accessone.com> Message-ID: <3.0.1.32.19990114194401.0091a6d0@mail.accessone.com> I was making a distinction between the author (writer) of a document conforming to some DTD and the designer of the DTD that the author was using. I hadn't considered the situation where a DTD was not present argh! I didn't know that CDATA content was broken in SGML and thus inherited by XML. Dave LeBlanc At 12:46 PM 1/14/99 -0500, Chris Maden wrote: >> Date: Sat, 06 Feb 1999 17:09:01 -0800 >> From: David LeBlanc >> >> What I would like is a content type (call it UPDATA), that has a >> distinct start and stop tag ( ..... ) that is >> entirely unparsed. This would be useful for content that has lots >> of significant characters.. like xml itself. In fact, I was >> thinking that it could be .... , but I now realize >> that there's a lot of freight attached to that character combination >> :-). >> >> It seems blechy to have to declare content PCDATA and then do the >> <[CDATA[ ... ]]> thing in the document. It forces the author of a >> document rather then the designer of a document class to be >> responsible for "escaping" content. > >Your proposal uses a fixed element type. What's the difference >between a fixed element type ... and a fixed string >? Why is requiring the author to insert an >element less onerous than requiring the author to insert a CDATA >marked section? > >If you want to allow *different* elements to be "UPDATA", then you >have a situation where reading or not reading the DTD results in >radically different interpretations of data, violating a major goal of >the XML effort. > >-Chris >-- > >"http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 >90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Fri Jan 15 04:11:39 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:35 2004 Subject: XML media types revisited In-Reply-To: <199901141806.NAA07944@hesketh.net> Message-ID: <3.0.1.32.19990114195819.0091bd10@mail.accessone.com> Hi; I don't agree with the idea that XML is a replacement for ASCII. ASCII is just one means of encoding character data; EBCDIC and Unicode are others (encoding in the sense of assigning a code to a character glyph). To me, "text" does not imply the underlying represtentation/encoding. In fact, although XML is based on Unicode, there are no technical reasons that I know of why XML could not be represtented in EBCDIC or ASCII (aside from standard compliance). Neither does "application" imply C, C++, Java or whatever else. In fact, I wonder if "application/xml" is appropriate at all - does "application/RTF" or "application/TROFF" make sense? Sincerely, Dave LeBlanc At 01:08 PM 1/14/99 -0500, Simon St.Laurent wrote: >I don't expect the IETF to change this anytime soon, but it does seem like >something that could stand improvement. XML isn't really a text format - >Tim Bray used to say, it's a replacement for ASCII. I'm inclined to agree >with him here, and think that maybe XML deserves to be placed on the same >footing as ASCII, not underneath it. > >Simon St.Laurent >XML: A Primer / Cookies >Sharing Bandwidth >Building XML Applications (March) >http://www.simonstl.com > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Jan 15 04:58:27 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:35 2004 Subject: Big Day for Namespaces, Styles References: <199901141856.NAA09018@hesketh.net> <369E64D7.2458FE55@infinet.com> <199901142335.RAA01230@bruno.techno.com> Message-ID: <369ECAD3.23B9E0B2@infinet.com> "Steven R. Newcomb" wrote: > [Tyler Baker:] > > > For technologies like XSL where you will have web-site designers who > > don't have CS degrees from fancy-shmancy institutions, "Namespaces > > in XML" will be a bigger travesty as transformation of XSL is > > complicated enough already. > > It's wrong to suppose that information management is easy. It's not. > Information technology only makes the easy parts easier by making the > hard parts harder. There is a difference between easy and understandable. I am one of the folks that feels information management can always be made easier; "Namespaces in XML" I feel makes things harder overall. True genius is being able to make complex things simple so it is very hard for me to understand how "Namespaces in XML" got to be the way it is considering the editors and WG members are all well-respected, intelligent people. Sometimes smart people get lazy in trying to build solutions that the next generation of programmers and developers can first understand and then build upon. I think that "Namespaces in XML" totally ignores the very important goal of making XML an architecture that the next generation can understand and build upon. A fellow student of mine back in my college days was peeved about the advent of Java because he said that it was a dummied down language and that only C should be allowed because only the gifted can use it. I guess he was one of the folks that felt that the programming world should only be reachable by people insane enough to live off of mountain dew for years on end and have no life other than coding. Though I personally sometimes reflect that stereotype, most people are not as dedicated as I or most of the posters to this list and may not enjoy programming at all, but do it just to put food on the table for their family. I respect those people and when you make their life harder, you will be making your own life harder because they will not use the tools you develop and they may even deem you a geek. And worst of all, they will opt for mediocre solutions like Visual Basic because even though it is ugly, it is easy for the mere mortal to understand. In the end you die childless at age 40 from a heart attack (you can't live off pop and cheetos forever) with only your glorified ego to let you rest in piece as the medics pound on your chest doing CPR. Pretty depressing isn't it. Well so is "Namespaces in XML". Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri Jan 15 12:13:50 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:35 2004 Subject: Names, Dates, Etc. Message-ID: <93CB64052F94D211BC5D0010A8001331068E68@WWMESS3> > >For all of these, we need architectures rather than markup languages > >per se, because applications may need more than one name, date, > >or money amount. I've actually hit this in a recent project which is using all three of these data types. I have to say I got myself a bit confused; in traditional data modelling we distinguish between the property name (e.g. recipient) and the domain (e.g. personalName), and I wasn't at all sure which of these to use as the XML element name, especially when the element had sub-structure. I guess architectural forms would have helped here, but they aren't mainstream XML. I toyed with double nesting (e.g. Fred but this seems horribly clumsy. I also thought of using a fixed attribute (dataType="personalName") in the DTD, but I don't particularly like fixed attributes e.g. because they vanish when you use a non-validating parser. In the end I just used the property name () and left the data type as implicit, something the receiving application is expected to know. Anyone have any better ideas? Mike Kay PS: I decided not to tag the substructure of dates and currency in XML, so currency appears just as GBP123.45, and dates as 1999-01-13. I tried XML substructures at one stage but the troops rebelled. Incidentally, I don't think "," as a decimal separator is any more international than ".", unless you use "international" in the U.S. sense of "not American". What you should really be using is a "middle dot"... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri Jan 15 12:13:58 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:35 2004 Subject: XML - NG Message-ID: <93CB64052F94D211BC5D0010A8001331068E67@WWMESS3> > If XML is truly a subset of SGML, how come nsgmls - a paragon of SGML > compliance - is not fully XML compliant? The XML standard defines conformance rules for "XML documents" and "XML processors". The following statements are both true (I believe): - every compliant XML document is a compliant SGML document - no compliant SGML processor is a compliant XML processor For example, a compliant XML processor is required to reject documents that are not valid XML, even though they may be valid SGML. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joel at softopt.co.uk Fri Jan 15 13:19:02 1999 From: joel at softopt.co.uk (Joel Rosi-Schwartz) Date: Mon Jun 7 17:07:35 2004 Subject: Existing XSL processors References: Message-ID: <369F3F5E.EA17CB49@softopt.co.uk> I am also new to XML/XSL and one of the first cofusions I had to sort out was the "missing" piece of visual output processing software, be it on screen or paper. It just seemed so "obvious" to me that this "should" be there, that for a couple of weeks I kep thinking that I was missing something in the way it all came together and worked. Finally I figured out that no it is just not there yet as any kind of standard (official or de facto) means of implementing it. It would be really useful, in my opinion, if this was rectified (at least on the Java front) with a formating engine class library that easily processed XML+DTD+XLS into an AWT display and common (read PS + RTF + TeX + PDF, etc) output. I am aware that parts of this is being addressed with technology such as James Tauber's FOP, but a more comprehensive solution under an Open Software Licence would certainly be nice. hmm....I didn't start this note with this intention, but I guess what I am really getting down to is asking if there is interest among the members of this list to take this on. Regards, Joel anette.engel@crpht.lu wrote: > Hi Guy, > > Thanks for your answer. Unfortunately I am not only dealing with displaying > documents in a browser , but also with printout. Apart from that there are > still > browsers which don't support XML and XSL at all. > > Cheers > Anette > > Guy_Murphy@dialog.com on 01/14/99 03:22:49 PM > > Please respond to xsl-list@mulberrytech.com > > To: xsl-list@mulberrytech.com > cc: (bcc: Anette Engel/crmm) > Subject: Re: Existing XSL processors > > Hi Anette. > The second part is pretty much up to the browsers. You can output pretty > much aything you want (as long as it's well formed) as long as your target > browser will support it, and render it. At the moment that leaves us pretty > much with HTML and/or XML w/CSS. The second part is more an issue of agreed > output than anything. > There might be a proof of concept browser/application out there somewhere > that supports formatting object as per the current XSL spec, but not in > wide circulation. Anybody seen such a beast? > Cheers > Guy. > > xsl-list@mulberrytech.com on 01/14/99 07:22:51 PM > To: xsl-list@mulberrytech.com > cc: (bcc: Guy Murphy/UK/MAID) > Subject: Existing XSL processors > > Reading the XSL Draft of the w3 consortium it is said: > "XSL is a lnaguage for expressing stylsheets. It consists of two parts: > 1. a language for transforming XML documents, and > 2. an XML vocabulary for specifiying formatting semantics" > So far I had a look at XSL engines which implement the first part. > Is there by any chance a XSL engine, which implements > the second part too? > Regards > Anette > anette.engel@crpht.lu > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Fri Jan 15 14:03:11 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:07:35 2004 Subject: What is a namespace ... really? Message-ID: <990115090135.15469@mail11.mitre.org.0> I thought I knew what a namespace was ... but now I think perhaps I don't. Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I define some elements, attributes, entities, etc. I define the relationships between the elements, attributes, etc. I place BookCatalogue.dtd in a directory: file://localhost/xml-course/xml-part1/BookCatalogue.dtd Is this a namespace? That is, is the file itself (BookCatalogue.dtd) a namespace? In all the examples that I see in the namespace spec they don't refer to a specific file. Instead, they refer to "some place", such as: http://www.w3.org/TR/HTML/ So, perhaps the "directory" that BookCatalogue.dtd resides in is the namespace? i.e., file://localhost/xml-course/xml-part1/ I thought I knew the way, now I don't. Help me find my way again. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 14:16:43 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:35 2004 Subject: What is a namespace ... really? In-Reply-To: <990115090135.15469@mail11.mitre.org.0> References: <990115090135.15469@mail11.mitre.org.0> Message-ID: <13983.19260.449920.371632@localhost.localdomain> Roger L. Costello writes: > I thought I knew what a namespace was ... but now I think perhaps I > don't. It's simpler than you think. > Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I > define some elements, attributes, entities, etc. I define the > relationships between the elements, attributes, etc. I place > BookCatalogue.dtd in a directory: > > file://localhost/xml-course/xml-part1/BookCatalogue.dtd > > Is this a namespace? It's a namespace URI (in this case, a URL). > That is, is the file itself (BookCatalogue.dtd) a namespace? No -- it's irrelevant as far as the current namespaces REC is concerned. > In all the examples that I see in the namespace spec they don't > refer to a specific file. Instead, they refer to "some place", > such as: > > http://www.w3.org/TR/HTML/ Not a place, just a unique URI. The URI doesn't actually have to work (a URI that throws up a 404 is just fine). > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > namespace? i.e., > > file://localhost/xml-course/xml-part1/ No. > I thought I knew the way, now I don't. Help me find my way again. A namespace is very similar to a package name in Java -- it's just a way of disambiguating names. Consider package com.megginson.xml; class XMLNamespace { // [...] } This does not guarantee that if you enter the URL http://xml.megginson.com/ into Netscape, something will happen; however, by virtue of the fact that my company owns the megginson.com domain, I can guarantee that no one else can (or should) be able to use this package name, so there is no chance of my classes getting confused with someone else's. Likewise, consider Megginson Technologies Ltd. +1 613 722 8770 This does not guarantee that if you enter the URL http://www.megginson.com/ns/phone into Netscape, something useful will happen; however, by virtue of the fact that my company owns the megginson.com domain, I can guarantee that no one else can (or should) be able to use this namespace URI, so there is no chance of my element type names getting confused with someone else's. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 14:47:49 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:35 2004 Subject: What is a namespace ... really? In-Reply-To: <13983.19260.449920.371632@localhost.localdomain> Message-ID: <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> This is the *current* state of affairs. There are people who also believe that in the future the namespace concept is to be extended to incorporate Schema definition. That is, when a namespace URN points to a Schema definition, the Schema may, can or will be enforced in the same way that a DTD is enforced by a validating parser and a > > Roger L. Costello writes: > > > I thought I knew what a namespace was ... but now I think perhaps I > > don't. > > It's simpler than you think. > ... > > > That is, is the file itself (BookCatalogue.dtd) a namespace? > > No -- it's irrelevant as far as the current namespaces REC is > concerned. > > > In all the examples that I see in the namespace spec they don't > > refer to a specific file. Instead, they refer to "some place", > > such as: > > > > http://www.w3.org/TR/HTML/ > > Not a place, just a unique URI. The URI doesn't actually have to work > (a URI that throws up a 404 is just fine). > > > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > > namespace? i.e., > > > > file://localhost/xml-course/xml-part1/ > > No. > > > I thought I knew the way, now I don't. Help me find my way again. > > A namespace is very similar to a package name in Java -- it's just a > way of disambiguating names. Consider > > package com.megginson.xml; > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:49:48 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:35 2004 Subject: Names, Dates, Etc. References: <93CB64052F94D211BC5D0010A8001331068E68@WWMESS3> Message-ID: <369F5519.134613E3@locke.ccil.org> Michael.Kay@icl.com wrote: > Incidentally, I don't think "," as a decimal separator is any more > international than ".", unless you use "international" in the U.S. sense of > "not American". What you should really be using is a "middle dot"... There is an ISO spec for this, but I'm having no luck finding it. It explicitly says that , is the international decimal point, but that . may be substituted in North America. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:53:16 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:35 2004 Subject: XML - NG References: <93CB64052F94D211BC5D0010A8001331068E67@WWMESS3> Message-ID: <369F54C7.1B2568E1@locke.ccil.org> Michael.Kay@icl.com wrote: > For example, a compliant XML processor is required to reject documents that > are not valid XML, even though they may be valid SGML. For "valid" read "well-formed". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:54:28 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:36 2004 Subject: What is a namespace ... really? References: <990115090135.15469@mail11.mitre.org.0> Message-ID: <369F55F0.E18CA735@locke.ccil.org> Roger L. Costello wrote: > Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I define some > elements, attributes, entities, etc. I define the relationships between > the elements, attributes, etc. I place BookCatalogue.dtd in a directory: > > file://localhost/xml-course/xml-part1/BookCatalogue.dtd > > Is this a namespace? That is, is the file itself (BookCatalogue.dtd) a > namespace? No, not as such. To have a namespace, you must define attributes *in the document* that have the form xmlns:prefix='some URI' where "some URI" is intended to remain stable. > In all the examples that I see in the namespace spec they don't refer to a > specific file. Instead, they refer to "some place", such as: > > http://www.w3.org/TR/HTML/ > > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > namespace? i.e., It can be used as such if you decide to do so. Or you can refer to the DTD itself as the namespace name. Or any URL you want; the URL does not have to refer to anything in particular. > file://localhost/xml-course/xml-part1/ This wouldn't be so useful, because it means different things on different hosts. But again, the URI is just used as a thing to compare to determine if two namespaces are the same or different. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 15:10:59 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:36 2004 Subject: What is a namespace ... really? In-Reply-To: <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> References: <13983.19260.449920.371632@localhost.localdomain> <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> Message-ID: <13983.22028.629794.586609@localhost.localdomain> Borden, Jonathan writes: > This is the *current* state of affairs. There are people who also > believe that in the future the namespace concept is to be extended > to incorporate Schema definition. That is, when a namespace URN > points to a Schema definition, the Schema may, can or will be > enforced in the same way that a DTD is enforced by a validating > parser and a Message-ID: <369F5BA2.36856834@locke.ccil.org> David LeBlanc wrote: > I don't agree with the idea that XML is a replacement for ASCII. Figuratively, not literally. The idea is that XML is meant to become the (near)ubiquitous way of expressing structured text or data, just as plain ASCII is the (near)ubiquitous way of expressing plain text or data. (But not forever: Unicode plain text rulz!) > [T]here are no technical reasons that I > know of why XML could not be represtented in EBCDIC or ASCII (aside from > standard compliance). Indeed, it is perfectly standards-compliant to have EBCDIC XML documents, as long as they begin with the characters " Neither does "application" imply C, C++, Java or whatever else. In fact, I > wonder if "application/xml" is appropriate at all - does "application/RTF" > or "application/TROFF" make sense? Yes, very much so. Troff source can and should be specified as "application/x-troff" and could be registered as "application/troff" if anyone wanted to bother. But "text/x-troff" would be reasonable too, since much troff source can reasonably read as plain text. RTF source is usually too *busy* to be read as plain text, though. Anent the "application" top-level type, RFC 2046 saith: # [...T]ypically either uninterpreted binary data or information to be # processed by an application. [... E]xpected uses for "application" # include spreadsheets, data for mail-based scheduling systems, and # languages for "active" (computational) messaging, and word # processing formats that are not directly readable. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 15 15:30:10 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:36 2004 Subject: XML media types revisited References: <199901141806.NAA07944@hesketh.net> Message-ID: <369F5B37.F9501C54@prescod.net> "Simon St.Laurent" wrote: > > I don't expect the IETF to change this anytime soon, but it does seem like > something that could stand improvement. XML isn't really a text format - > Tim Bray used to say, it's a replacement for ASCII. I think that Tim meant to say that it is *analogous* to ASCII. It sure isn't a replacement for Unicode or ASCII in any sense. There are going to be many places in the Web information system where ASCII and Unicode are used without XML. The most reasonable way to handle this would be to allow mime types to have arbitrary levels. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 15 15:53:44 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:36 2004 Subject: XML media types revisited In-Reply-To: <369F5B37.F9501C54@prescod.net> References: <199901141806.NAA07944@hesketh.net> Message-ID: <199901151553.KAA31113@hesketh.net> At 09:13 AM 1/15/99 -0600, Paul Prescod wrote: >There are going to >be many places in the Web information system where ASCII and Unicode are >used without XML. The most reasonable way to handle this would be to allow >mime types to have arbitrary levels. Of course plain text will still survive; I'm hardly proposing abolishing text or application as top-level types. I'm just saying that XML is a top-level type itself. Your arbitrary level proposal is quite reasonable, though I suspect that that would require considerably more development (through the full IETF process) than just adding a new top-level type. Intriguing possibility, though... Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 16:09:37 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:36 2004 Subject: What is a namespace ... really? In-Reply-To: <13983.22028.629794.586609@localhost.localdomain> Message-ID: <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> David, My mind is still out on this topic. I've had a look at Microsoft's XML Schema stuff in IE5 b2 however, and currently when the namespace uri starts with "urn:" the namespace behaves as you desire. When the namespace uri begins with another prefix, the implication is that this points to a schema definition. I don't see a problem with this one-to-one relationship, after all, a namespace *is* defined by a uri, so... and I don't immediately see why this precludes inclusion of elemements from different namespaces. I think the idea is that if a namespace is defined by a uri, it may inherit a meaning associated with that uri, for example, suppose the uri was a .DTD, would this cause a problem or work any less well than a DTD which defines a default namespace and is specified in a > > Borden, Jonathan writes: > > > This is the *current* state of affairs. There are people who also > > believe that in the future the namespace concept is to be extended > > to incorporate Schema definition. That is, when a namespace URN > > points to a Schema definition, the Schema may, can or will be > > enforced in the same way that a DTD is enforced by a validating > > parser and a > Ack! No! Please don't hardcode a one-to-one relationship between > schemas and namespaces. > > A single schema could define structures using elements and attributes > from more than one namespace, and elements and attributes from a > single namespace can be used and structured in many different ways. > > SGML people handle this problem in a fairly clumsy way by using public > identifiers for indirection and then swapping entity catalogues at > different stages of production. We can do better if do what a > database designer does for many-to-many relationships: add separate > associations between the namespace and the schema. > > The alternative would be to rely on HTTP content negotiation to get > the kind of schema you want, and that is a pretty grim prospect > (especially for people with web sites hosted by large ISPs who really > aren't going to let them fiddle with the web server). > > > All the best, > > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 16:20:10 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:36 2004 Subject: XML media types revisited In-Reply-To: <199901151553.KAA31113@hesketh.net> Message-ID: <002701be40a2$57314940$d3228018@jabr.ne.mediaone.net> Simon, It's not that its otherwise a bad idea (it is an excellent idea). the problem is that adding a top level MIME type requires changes to tons of MIME aware code. This is why I always use text/xml as opposed to application/xml because the "application" top level is quite frequently used to denote 8 bit character data or binary data types which need to be base64 encoded for SMTP transport whereas "text" data is 7bit (UNICODE aside :-) and is appropriately transfered as content-type: 7bit or quoted-printable. On the other hand, my MIME code takes special care when it sees the text/xml content-type (not that this should sway the IETF :-)) not that these assumptions are valid, its just that they exist. Jonathan Borden http://jabr.ne.mediaone.net > > Of course plain text will still survive; I'm hardly proposing abolishing > text or application as top-level types. I'm just saying that XML is a > top-level type itself. > > Your arbitrary level proposal is quite reasonable, though I suspect that > that would require considerably more development (through the full IETF > process) than just adding a new top-level type. > > Intriguing possibility, though... > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 16:26:02 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:36 2004 Subject: XML media types revisited References: <199901141806.NAA07944@hesketh.net> <199901151553.KAA31113@hesketh.net> Message-ID: <369F6BE6.4F288EC@locke.ccil.org> Simon St.Laurent wrote: > Your arbitrary level proposal is quite reasonable, though I suspect that > that would require considerably more development (through the full IETF > process) than just adding a new top-level type. Either way requires a standards-track RFC. The trouble is that XML just isn't a content type analogous to "text", "video", "image", "audio", "model", etc: it's a format, or rather a metaformat. Content-types are supposed to be named based on what they are good for, rather than what the details of the internal format are. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Fri Jan 15 16:33:31 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:07:36 2004 Subject: Summary of XML schema languages Message-ID: <01BE40AC.477539D0@grappa.ito.tu-darmstadt.de> I recently gave a presentation on XML schema languages. Due to the recent questions about these on XML-Dev, I've annotated my slides and made them available on the Web. A majority of my audience didn't know XML, so the presentation starts with a brief description of XML. It then discusses why you might want XML schema languages, their basic syntax, and what the major differences between the four existing languages (XSchema, DCD, SOX, and XML-Data) are. It ends with a summary of what I think a schema language should have today and what languages I think you should use for what purpose. You can find the presentation at: HTML: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/xmlsch emas/index.htm PowerPoint: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/xmlsch emas/XMLSchemas.ppt Warning: The notes are a bit rough and sometimes rather opinionated. Feel free to send me comments and complaints. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Jan 15 16:49:31 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:36 2004 Subject: Existing XSL processors Message-ID: <021e01be40a7$39916aa0$0300000a@othniel.cygnus.uwa.edu.au> >output. I am aware that parts of this is being addressed with technology such >as James Tauber's FOP, but a more comprehensive solution under an Open Software >Licence would certainly be nice. I intend both for FOP to both become more comprehensive and for it to be placed under an Open Software Licence. James (who deliberated over the cross-posting :-) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 16:54:56 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:36 2004 Subject: What is a namespace ... really? In-Reply-To: <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> References: <13983.22028.629794.586609@localhost.localdomain> <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> Message-ID: <13983.28566.71365.447556@localhost.localdomain> Borden, Jonathan writes: > I don't see a problem with this one-to-one relationship, after all, > a namespace *is* defined by a uri, so... and I don't immediately > see why this precludes inclusion of elemements from different > namespaces. What if I want to create a schema specifying that (for my set of documents) an html:p element may contain a tei:foreign element, or a docbook:Trademark element in addition to the regular HTML elements? What if I want to create a schema specifying that (for my set of documents) an html:p element may *not* contain an html:font element? It doesn't make sense to have to create a new and different namespace for either of these -- I'm still using the individual elements in mostly the same way. I could, of course, use some kind of inheritance scheme, but I don't think the world will buy anything that requires retrieving 5 or 10 schemas from different servers just to figure out that an html:a element is from the HTML namespace. > I think the idea is that if a namespace is defined by a uri, it may > inherit a meaning associated with that uri, for example, suppose > the uri was a .DTD, would this cause a problem or work any less > well than a DTD which defines a default namespace and is specified > in a David Megginson wrote: > What if I want to create a schema specifying that (for my set of > documents) an html:p element may contain a tei:foreign element, or a > docbook:Trademark element in addition to the regular HTML elements? > > What if I want to create a schema specifying that (for my set of > documents) an html:p element may *not* contain an html:font element? > > It doesn't make sense to have to create a new and different namespace > for either of these -- I'm still using the individual elements in > mostly the same way. I think you do need to create a new namespace for these. Each would give you multiple definitions of the same variable within the same namespace, which makes no more sense for XML than it does for a programming language. Note that an inheritance scheme might work, but the new element would exist in your namespace, not the one the supertype inhabits. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 18:12:55 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:36 2004 Subject: What is a namespace ... really? References: <01BE40B1.CD3BA5E0@grappa.ito.tu-darmstadt.de> Message-ID: <369F8504.8DE98BAC@locke.ccil.org> Ronald Bourret wrote: > I think you do need to create a new namespace for these. Each would give > you multiple definitions of the same variable within the same namespace, > which makes no more sense for XML than it does for a programming language. I don't agree with you, at least taking "namespace" in the sense of the Rec. Namespaces are just lists of names (one for elements, one for global attributes, one for each element containing its local attributes). Nothing can be inferred about the proper use of a name from the mere fact of its appearance in a namespace. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Clark.Cooper at corporate.ge.com Fri Jan 15 18:16:36 1999 From: Clark.Cooper at corporate.ge.com (Cooper, Clark (CORP, Consultant)) Date: Mon Jun 7 17:07:36 2004 Subject: Namespace PR Message-ID: <014CB98EB81ED011B3E900805FE2D47A04F74AFF@X01SCHCORPGE> I couldn't find it in the old Note and I can't find it in the new P.R.: How are namespaces for qualified names in declarations declared, since they are outside the scope of any element? Productions 13 through 18 show that we can use qualified names in the declarations but what do their prefixes mean there? For instance: ]> In the body of the document, there is no ambiguity since the uses of the qualified name is in scope. But in the internal subset, what namespace does "a:where" belong to? If this is an error, what section of the recommendation has this violated? Clark Cooper Logic Technologies,Inc cccooper@ltionline.com (518) 388-7690 650 Franklin St., Suite 304 coopercc@netheaven.com Schenectady, NY 12305 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 18:23:16 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:36 2004 Subject: Namespace PR In-Reply-To: <014CB98EB81ED011B3E900805FE2D47A04F74AFF@X01SCHCORPGE> References: <014CB98EB81ED011B3E900805FE2D47A04F74AFF@X01SCHCORPGE> Message-ID: <13983.34471.882046.615436@localhost.localdomain> Cooper, Clark (CORP, Consultant) writes: > I couldn't find it in the old Note and I can't find it in the new > P.R.: > > How are namespaces for qualified names in declarations declared, > since they are outside the scope of any element? They are outside the scope of the Namespaces REC altogether -- DTDs define the structure of the surface document. DTDs and namespaces can work together on the same element structure, but right now, they don't know anything about each other. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Fri Jan 15 18:27:13 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:07:37 2004 Subject: What is a namespace ... really? Message-ID: <990115132421.15469@mail11.mitre.org.0> I have been closely monitoring (with great interest!) all the discussion arising from my question on what is a namespace. It seems that people have differing ideas on what it is. I would like to try to summarize the points of view, and add my own two cents. (1) A namespace is just a URI. It references some domain. It is simply there to tell an application/processor what domain the associated XML elements hail from. (2) A namespace is a URI to a DTD. It references a domain and also a DTD within the domain. In addition to telling an application/parser what domain the associated XML elements hail from, with this namespace declaration a validating parser could validate that portion of your XML document against the DTD at that URI. So, with point-of-view (2) this is a valid namespace declaration: and this is not a valid namespace declaration: because there is no referenced DTD at that domain. Is this a fair assessment of the points of view? My two cents: What is the purpose of namespaces? It is my understanding that the purpose of namespaces is twofold: (a) Disambiguation. e.g., if BookCatalogue is defined in another DTD that you are using then namespaces allow you to distinguish BookCatalogue in DTD A from Bookcatalogue in DTD B (b) Reuse/validation. e.g., if you declare that BookCatalogue comes from a DTD in some domain then conceivably a parser could validate that portion of the XML document. Who's right? What is "truth"? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Maneesha.Jain at Ebay.Sun.COM Fri Jan 15 18:32:53 1999 From: Maneesha.Jain at Ebay.Sun.COM (Maneesha Jain) Date: Mon Jun 7 17:07:37 2004 Subject: Any tools for DCD/SOX on UNIX Message-ID: <199901151829.KAA28545@hsnwk02h.EBay.Sun.COM> Hi, Are there any tools/library/browsers available for DCD/SOX/XML-Data for UNIX systems ? Thanks Maneesha xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Fri Jan 15 18:41:34 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:07:37 2004 Subject: What is a namespace ... really? In-Reply-To: <990115132421.15469@mail11.mitre.org.0> (costello@mail11.mitre.org) Message-ID: <199901151839.NAA29182@ruby.ora.com> > I have been closely monitoring (with great interest!) all the > discussion arising from my question on what is a namespace. It > seems that people have differing ideas on what it is. I would like > to try to summarize the points of view, and add my own two cents. It may be just that I'm in camp (1), but I think the spec falls apart if you treat the namespace URI as anything other than a magic cookie. That is, this namespace is the same as that namespace iff their URIs are identical. The files at two different URIs may be the same, but that does not make the namespaces identical; the same URI may return a randomly selected collection of Keats's works to each request, but two namespaces using it are the same URI. In XSL, a pattern matches an element if the URI of the pattern's element's namespace in the stylesheet matches the URI of the element's namespace in the document, and if the rest of the element type matches exactly. This allows styling of documents with namespaces; processing with special-purpose applets could be handled similarly. No further comparison can meaningfully be made in any reliable way; it requires further definition from the WG, which may well not be forthcoming. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Jan 15 18:46:32 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:37 2004 Subject: What is a namespace ... really? Message-ID: <027c01be40b7$35365aa0$0300000a@othniel.cygnus.uwa.edu.au> >(1) A namespace is just a URI. It references some domain. It is simply >there to tell an application/processor what domain the associated XML >elements hail from. Well, it doesn't even need to be the domain the elements hail from, just a URI that no one else would use for different elements. Universal uniqueness (is that a tautology) is what namespaces are all about. If I developed my own elements, I might use the URI http://www.jtauber.com/ If I want to use your elements but there is nothing obvious to use for a namespace, I might use http://www.jtauber.com/costello/ I can be fairly sure that it's unique (who else would use my domain). There doesn't even have to be a resource at that URI. >(2) A namespace is a URI to a DTD. No. It doesn't have to be at all (although it *could* be and a URI for a DTD is as good a URI as any and better than most) James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Fri Jan 15 19:05:12 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:37 2004 Subject: What is a namespace ... really? In-Reply-To: <13983.28566.71365.447556@localhost.localdomain> References: <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> <13983.22028.629794.586609@localhost.localdomain> <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> Message-ID: <3.0.1.32.19990115135649.00f6c6ec@pop.uunet.ca> At 11:52 AM 1/15/99 -0500, david@megginson.com wrote: >Borden, Jonathan writes: > > > I don't see a problem with this one-to-one relationship, after all, > > a namespace *is* defined by a uri, so... and I don't immediately > > see why this precludes inclusion of elemements from different > > namespaces. > >What if I want to create a schema specifying that (for my set of >documents) an html:p element may contain a tei:foreign element, or a >docbook:Trademark element in addition to the regular HTML elements? Well, if you intend to modify the content spec of an element from a namespace over which you have no control or authority, you might have a problem. Seems to be the same problem that you have if you try to modify a "final" class. That's not to say that the XML Schema work will not offer a way to do so. > >What if I want to create a schema specifying that (for my set of >documents) an html:p element may *not* contain an html:font element? Again, same problem. But neither of these example address the question that was raised by Jonathan. > >It doesn't make sense to have to create a new and different namespace >for either of these -- I'm still using the individual elements in >mostly the same way. I might make sense to be *allowed* to create a new *schema* for both of these examples. The effect of doing so would be to create a new namespace (see SOX). >I could, of course, use some kind of inheritance >scheme, but I don't think the world will buy anything that requires >retrieving 5 or 10 schemas from different servers just to figure out >that an html:a element is from the HTML namespace. I don't think that we know yet what the world will or will not buy (notwithstanding ridicyulous PE ratios). > > > I think the idea is that if a namespace is defined by a uri, it may > > inherit a meaning associated with that uri, for example, suppose > > the uri was a .DTD, would this cause a problem or work any less > > well than a DTD which defines a default namespace and is specified > > in a >It would cause about the same set of problems as DOCTYPE (perhaps >worse with datatyping and other niceties) -- that's why we need to get >away from it. Of course, David's opinion is his own. Although it may be shared by others in the community, I hope that his opinion will not hold sway over the design and development of better schemas and namespace mechanisms for XML. Regards, Murray xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Fri Jan 15 19:08:22 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:07:37 2004 Subject: What is a namespace ... really? Message-ID: <990115140517.15469@mail11.mitre.org.0> James Tauber wrote: >>(2) A namespace is a URI to a DTD. > >No. It doesn't have to be at all (although it *could* be and a URI for a DTD >is as good a URI as any and better than most) What good is a namespace if it *doesn't* reference a DTD? e.g., ... There is no way for a parser to validate the stuff between and . It seems like the *main* benefit to be gained from using namespaces should be the ability for an XML document to reuse other DTDs and validate against those DTDs, i.e., your document becomes an assembly of independently validated elements from various DTDs. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Jan 15 19:27:11 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:37 2004 Subject: What is a namespace ... really? Message-ID: <02a301be40bd$53887140$0300000a@othniel.cygnus.uwa.edu.au> >What good is a namespace if it *doesn't* reference a DTD? A good example is XSL. XSL allows the result tree to use any vocabulary the stylesheet writer wants, it could be HTML-in-XML (ie Voyager), the flow object vocabulary or any old DTD. XSL templates contain not only elements in this result vocabulary but also XSL's own elements that control processing, generated content, etc. XSL has element type names like "apply-templates", "value-of" and "number". Now say that the result vocabulary you are wanting to use in your stylesheet just happens to have an element type with the name "number". How would an XSL engine know if meant the XSL "number" element or the "number" element of the result vocabulary? The answer: namespaces Each element is associated with a URI. The XSL element types are associated with a namespace which is the URI for the XSL spec. It doesn't matter what the URI for the result tree namespace is as long as it isn't that of the XSL spec. So in this case, the namespace is a spec that described the elements, not a DTD. Namespaces are *not* a tool for validation of documents with a mixture of schemata, they are merely a way of making sure that my FOO is not confused with your FOO. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ATyler at compuskills.on.ca Fri Jan 15 19:43:44 1999 From: ATyler at compuskills.on.ca (Andrew Tyler) Date: Mon Jun 7 17:07:37 2004 Subject: msxml auction demo Message-ID: <00B62A756D64D2119AEC0060672C38B609AB7B@NT> When I run the auction demo in msxml 1.9. I get the error : java.lang.NoSuchMethodError: com/ms/xml/om/ElementFactory: method createElement(ILcom/ms/xml/util/Name;)Lcom/ms/xml/om/Element; not found It originates in main.htm. I have followed instructions and can see the method implemented in msxml.java: class NullElementFactory implements ElementFactory { public NullElementFactory() { } public Element createElement(Element parent, int type, Name tag, String text) { return null; } I am new to this. Can anyone help me? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Fri Jan 15 19:47:42 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:37 2004 Subject: Summary of XML schema languages In-Reply-To: <01BE40AC.477539D0@grappa.ito.tu-darmstadt.de> Message-ID: <3.0.1.32.19990115144734.00fab930@pop.uunet.ca> Ron, Thank you for performing this service to the community. The XML Schema WG is about to undertake a similar comparison with a requirements vs. capabilities emphasis. All in all, I certainly appreciate having this document available. I would be much happier if this comparison were less biased toward XSchema, but that is understandable considering that Ron is one of the co-authors of XSchema. With your indulgence, I would like to clarify some aspects of SOX... In the slide "Reusing schema elements: method 2", SOX is not listed. In fact, SOX does provide for including only required parts of schemas. This is accomplished by referencing elements in foreign schemas. The relationship between a SOX schema and a DTD is defined, but is not present in the public document. I anticipate that a revised and updated version of SOX will be made available in the near future. Under SOX, it would be more accurate to say that "SOX was submitted to the W3C by Veo Systems". My role, and that of Muzmo Communication Inc., was as a paid contractor. If you want to name the co-authors, they are Alex Milowski, Matt Fuchs and Murray Maloney. Namespace support in SOX is broader that that in "Namespaces in XML" and may well serve to inform the future development of the W3C schema specification. I am puzzled by the distinction that you make by saying that DCD's reuse mechanism is elegant. In what way is SOX reuse mechanisms less elegant? Furthermore, SOX reuse mechanisms are more comprehensive than any of the other offerings. Finally, I do not understand why you categorize SOX as complex. For the core set of features that are present in all of the schemas that you analyzed, SOX is comparably complex. For features that are novel within XML-Data, DCD and SOX, there is additional complexity. Regards, Murray xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 15 20:12:43 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:37 2004 Subject: Identifying XML Document Types (was XML media types revisited) Message-ID: <199901152012.PAA03477@hesketh.net> We've had a good deal of give and take over various ways for naming and otherwise identifying elements and documents over the last few days, and I'd like to summarize a lot of issues that have arisen (for me at least) from the discussion. I'm concerned that XML is a significant break from 'the old way of doing things', which, crummy as it was, had certain advantages of familiarity. Proprietary documents came with their own identifiers and their own rules for doing things, and I don't think anyone expected to open Word documents in a statistical program and get meaningful results. With XML the expectations (for being able to process documents with both specific and generic tools) are much higher, yet the tools for identifying document types are actually weaker in many ways. I'll list most of the tools for identifying document types here and their potential strengths and weaknesses. I'm hoping I'm wrong about some of these, but I'm also hoping I'm wrong in ways that can make users lives simpler, not ways that just have workarounds requiring users to trek 50 miles through mountains while wearing a straitjacket and ball-and-chain. 1) Filename extensions - The classic for the PC world, used to some extent in Unix, and typically sneered at by the Macintosh community. Advantages: Can be created on a whim. Easily connected to other systems, like MIME identifiers, when used in a supportive (HTTP) environment. Disadvantages: No central registry, so conflicts abound. Typically limited to three characters by old DOS rules, though longer extensions are becoming a bit more common. Makes it difficult to use periods in file names. Doesn't fit well with 'smarter' file systems that store document type and application information separately from the name of the document. Recurring Question: Why using .xml isn't enough to identify XML documents precisely to applications. (Recurring answer: because not all applications should work with every XML document fed them, using finer-grained identification is a good idea.) ---------------------------------------------------------------- 2) MIME types - The classic Internet standard, used by a variety of Internet applications and becoming more widespread in other systems. Advantages: IANA provides central registry, with mechanism (x-) for unregistered types. Can be made into public identifiers and notations fairly easily. Disadvantages: Like the .xml file extension, application/xml and text/xml provide no information about the _type_ of XML document inside the file they roughly describe, leaving applications to determine whether or not the information is actually meaningful. Recurring Question: Why using application/xml or text/xml isn't enough to identify XML documents precisely to applications. (Recurring answer: because not all applications should work with every XML document fed them, using finer-grained identification is a good idea.) ---------------------------------------------------------------- 3) DOCTYPE declarations - The de facto SGML standard, about the only thing that provides a description of the contents of a document. Advantages: Public Identifier vocabulary suitably rich to avoid most naming conflicts without required use of central repository. Disadvantages: Only reliable in validating environments when public identifiers are actually used, which isn't very often. SYSTEM pointers seem much more typical. Even when public identifiers are present, many declarations can be added or overridden in the internal subset, muddying the waters for applications that need a particular structure. Validation process doesn't make clear if this has happened. ANY opens black holes. Recurring Questions: Where do I buy a public identifier? Can I use a public identifier for documents that are only well-formed? (Recurring answer: pretty much no on both counts.) ---------------------------------------------------------------- 4) Root elements using Namespaces - A new possibility that gained some prominence with the accession to W3C Recommendation of 'Namespaces in XML'. Advantages: Namespaces ensure unique element names, making it less likely that you have someone else's DOCUMENT element. Disadvantages: Just because the root element is X doesn't mean its contents are Y. Especially given the problems of validating documents in namespace-aware environments, namespaces may not always be available. Half the XML community regards Namespaces as the worst thing since the plague. Because namespaces aren't supposed to point to anything, you can't sneak a DTD in at the URL identified by the namespace. Recurring Question: So how do I make this work reliably in a validating environment? (Recurring answer: Ask again next year, please.) Perhaps I'm being a little too hard, but none of these solutions seem viable. If all we were talking about was generic documents with style sheets, it might not matter so much, but unfortunately, we're not. Lots of XML standards are under development where putting the square document in the round processor is not a good idea. It seems wise to provide a generic mechanism to keep the square documents created with our generic tools from the round processor. Or maybe that's too much. I guess we'll see. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Fri Jan 15 20:30:15 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:07:37 2004 Subject: Identifying XML Document Types (was XML media types revisited) In-Reply-To: <199901152012.PAA03477@hesketh.net> Message-ID: <3.0.5.32.19990115142731.00909100@amati.techno.com> At 03:12 PM 1/15/99 -0500, Simon St.Laurent wrote: >Perhaps I'm being a little too hard, but none of these solutions seem >viable. You're correct: none of them are viable, because they do not create self-describing objects. What is needed is a mechanism that allows a document to unambiguously point to the definition of what it is, from which applications can then determine the right thing to do. MIME types go a long way, but they are managed outside the document, leaving open the question "how do I know what MIME types to associate with a document?". Note that the external identifier of the doctype declaration, if there is one, *CANNOT BE THIS POINTER* because it simply identifies an entity with some declarations in it, from which you can reliably infer nothing. Schema-use declarations (many have been proposed) and architecture use declarations (the new PI-based syntax) are examples of workable solutions because they point to authoritative definitions of what the rules for the document are. Note that architecture use declarations are standardized today and trivially easy to implement support for. The external identifier for the architecture definition itself can be anything, including public IDs and MIME types. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RDaniel at DATAFUSION.net Fri Jan 15 20:45:42 1999 From: RDaniel at DATAFUSION.net (Ron Daniel) Date: Mon Jun 7 17:07:37 2004 Subject: What is a namespace ... really? Message-ID: <0D611E39F997D0119F9100A0C931315C2E0EF7@datafusionnt1> Roger Costello wrote: > James Tauber wrote: > > >>(2) A namespace is a URI to a DTD. > > > >No. It doesn't have to be at all (although it *could* be and a URI > for a > DTD > >is as good a URI as any and better than most) > > What good is a namespace if it *doesn't* reference a DTD? > [Ron Daniel] The advantage is namespace scoping, along the lines of Java packages. But let me give an XML-based example. Assume you have gotten 2 XML documents, from different sources, and they both contain the element . How do you know if they mean the same thing? One might be a book title, the other might be a job title. (Or a royal title or a legal title to property or a championship title or ...). But, if one says <dc:title> and another says <aba:title> (and you look up the URIs and see they are different - one for the Dublin Core group and the other from the American Bar Association), then you can tell that they are not the same use of <title> and you should treat them differently. Namespaces allow us to prevent name collisions. This is very good. Now, the next thing to do is have the namespace URI point to something like a DTD, and there are lots of us who want to do such things. But that is outside the narrow bounds of the current spec. While I wish the spec had gone on to deal with parts of that topic, I also have to say that unique names are nothing to sneeze at, and are a valuable step forward. Regards, Ron Daniel Jr. DATAFUSION, Inc. 139 Townsend Street, Ste. 100 San Francisco, CA 94107 415.222.0100 fax 415.222.0150 rdaniel@datafusion.net http://www.datafusion.net > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 15 21:22:36 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:37 2004 Subject: Identifying XML Document Types (was XML media types revisited) In-Reply-To: <3.0.5.32.19990115142731.00909100@amati.techno.com> References: <199901152012.PAA03477@hesketh.net> Message-ID: <199901152121.QAA04800@hesketh.net> At 02:27 PM 1/15/99 -0600, W. Eliot Kimber wrote: >You're correct: none of them are viable, because they do not create >self-describing objects. What is needed is a mechanism that allows a >document to unambiguously point to the definition of what it is, from which >applications can then determine the right thing to do. MIME types go a >long way, but they are managed outside the document, leaving open the >question "how do I know what MIME types to associate with a document?". > >[...] > >Schema-use declarations (many have been proposed) and architecture use >declarations (the new PI-based syntax) are examples of workable solutions >because they point to authoritative definitions of what the rules for the >document are. Note that architecture use declarations are standardized >today and trivially easy to implement support for. The external identifier >for the architecture definition itself can be anything, including public >IDs and MIME types. Schemas may be a good answer (if they kill the internal subset escape hatch), combining an assertion about document type with a way to check it. Is there any comparable 'architecture validation' process? Or are they just assertions? The only (obvious, anyway) flaw with these options are the need to load the document before you know if it's worth processing - but that may be seen as more a flaw of today's limited filesystems and transfer protocols, I suppose. We're getting there... Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri Jan 15 12:13:50 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:37 2004 Subject: Names, Dates, Etc. Message-ID: <93CB64052F94D211BC5D0010A8001331068E68@WWMESS3> > >For all of these, we need architectures rather than markup languages > >per se, because applications may need more than one name, date, > >or money amount. I've actually hit this in a recent project which is using all three of these data types. I have to say I got myself a bit confused; in traditional data modelling we distinguish between the property name (e.g. recipient) and the domain (e.g. personalName), and I wasn't at all sure which of these to use as the XML element name, especially when the element had sub-structure. I guess architectural forms would have helped here, but they aren't mainstream XML. I toyed with double nesting (e.g. <recipient><personalName>Fred</personalName></recipient> but this seems horribly clumsy. I also thought of using a fixed attribute (dataType="personalName") in the DTD, but I don't particularly like fixed attributes e.g. because they vanish when you use a non-validating parser. In the end I just used the property name (<recipient>) and left the data type as implicit, something the receiving application is expected to know. Anyone have any better ideas? Mike Kay PS: I decided not to tag the substructure of dates and currency in XML, so currency appears just as GBP123.45, and dates as 1999-01-13. I tried XML substructures at one stage but the troops rebelled. Incidentally, I don't think "," as a decimal separator is any more international than ".", unless you use "international" in the U.S. sense of "not American". What you should really be using is a "middle dot"... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri Jan 15 12:13:58 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:37 2004 Subject: XML - NG Message-ID: <93CB64052F94D211BC5D0010A8001331068E67@WWMESS3> > If XML is truly a subset of SGML, how come nsgmls - a paragon of SGML > compliance - is not fully XML compliant? The XML standard defines conformance rules for "XML documents" and "XML processors". The following statements are both true (I believe): - every compliant XML document is a compliant SGML document - no compliant SGML processor is a compliant XML processor For example, a compliant XML processor is required to reject documents that are not valid XML, even though they may be valid SGML. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Fri Jan 15 21:45:00 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:07:38 2004 Subject: Identifying XML Document Types (was XML media types revisited) Message-ID: <000e01be40cf$d8893070$2ee044c6@arcot-main> Correct solution to this problem seems to be a combination approach where document type information from multiple sources (file extension, HTTP headers, etc.) are combined and presented to clients using abstracted interface. Java Activation Framework does some of this but it doesn't go far enough. Idealy clients should be able to specify a list of desired document types and the degree of document type conversion. Document type conversion comes into play when a requested document type is not available directly but can be produced through one or more document type converters. For example, if client can handle XSchema files but source document is in XML-Data format, XML-Data can be converted to pure DTD (with some information loss) and then converted to XSchema. Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joel at softopt.co.uk Fri Jan 15 13:19:02 1999 From: joel at softopt.co.uk (Joel Rosi-Schwartz) Date: Mon Jun 7 17:07:38 2004 Subject: Existing XSL processors References: <C12566FA.003546C4.00@mmfileserver.crpht.lu> Message-ID: <369F3F5E.EA17CB49@softopt.co.uk> I am also new to XML/XSL and one of the first cofusions I had to sort out was the "missing" piece of visual output processing software, be it on screen or paper. It just seemed so "obvious" to me that this "should" be there, that for a couple of weeks I kep thinking that I was missing something in the way it all came together and worked. Finally I figured out that no it is just not there yet as any kind of standard (official or de facto) means of implementing it. It would be really useful, in my opinion, if this was rectified (at least on the Java front) with a formating engine class library that easily processed XML+DTD+XLS into an AWT display and common (read PS + RTF + TeX + PDF, etc) output. I am aware that parts of this is being addressed with technology such as James Tauber's FOP, but a more comprehensive solution under an Open Software Licence would certainly be nice. hmm....I didn't start this note with this intention, but I guess what I am really getting down to is asking if there is interest among the members of this list to take this on. Regards, Joel anette.engel@crpht.lu wrote: > Hi Guy, > > Thanks for your answer. Unfortunately I am not only dealing with displaying > documents in a browser , but also with printout. Apart from that there are > still > browsers which don't support XML and XSL at all. > > Cheers > Anette > > Guy_Murphy@dialog.com on 01/14/99 03:22:49 PM > > Please respond to xsl-list@mulberrytech.com > > To: xsl-list@mulberrytech.com > cc: (bcc: Anette Engel/crmm) > Subject: Re: Existing XSL processors > > Hi Anette. > The second part is pretty much up to the browsers. You can output pretty > much aything you want (as long as it's well formed) as long as your target > browser will support it, and render it. At the moment that leaves us pretty > much with HTML and/or XML w/CSS. The second part is more an issue of agreed > output than anything. > There might be a proof of concept browser/application out there somewhere > that supports formatting object as per the current XSL spec, but not in > wide circulation. Anybody seen such a beast? > Cheers > Guy. > > xsl-list@mulberrytech.com on 01/14/99 07:22:51 PM > To: xsl-list@mulberrytech.com > cc: (bcc: Guy Murphy/UK/MAID) > Subject: Existing XSL processors > > Reading the XSL Draft of the w3 consortium it is said: > "XSL is a lnaguage for expressing stylsheets. It consists of two parts: > 1. a language for transforming XML documents, and > 2. an XML vocabulary for specifiying formatting semantics" > So far I had a look at XSL engines which implement the first part. > Is there by any chance a XSL engine, which implements > the second part too? > Regards > Anette > anette.engel@crpht.lu > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 14:16:43 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:38 2004 Subject: What is a namespace ... really? In-Reply-To: <990115090135.15469@mail11.mitre.org.0> References: <990115090135.15469@mail11.mitre.org.0> Message-ID: <13983.19260.449920.371632@localhost.localdomain> Roger L. Costello writes: > I thought I knew what a namespace was ... but now I think perhaps I > don't. It's simpler than you think. > Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I > define some elements, attributes, entities, etc. I define the > relationships between the elements, attributes, etc. I place > BookCatalogue.dtd in a directory: > > file://localhost/xml-course/xml-part1/BookCatalogue.dtd > > Is this a namespace? It's a namespace URI (in this case, a URL). > That is, is the file itself (BookCatalogue.dtd) a namespace? No -- it's irrelevant as far as the current namespaces REC is concerned. > In all the examples that I see in the namespace spec they don't > refer to a specific file. Instead, they refer to "some place", > such as: > > http://www.w3.org/TR/HTML/ Not a place, just a unique URI. The URI doesn't actually have to work (a URI that throws up a 404 is just fine). > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > namespace? i.e., > > file://localhost/xml-course/xml-part1/ No. > I thought I knew the way, now I don't. Help me find my way again. A namespace is very similar to a package name in Java -- it's just a way of disambiguating names. Consider package com.megginson.xml; class XMLNamespace { // [...] } This does not guarantee that if you enter the URL http://xml.megginson.com/ into Netscape, something will happen; however, by virtue of the fact that my company owns the megginson.com domain, I can guarantee that no one else can (or should) be able to use this package name, so there is no chance of my classes getting confused with someone else's. Likewise, consider <?xml version="1.0"?> <ph:phone-list xmlns:ph="http://www.megginson.com/ns/phone"> <ph:entry> <ph:name>Megginson Technologies Ltd.</ph:name> <ph:number>+1 613 722 8770</ph:number> </ph:entry> </ph:phone-list> This does not guarantee that if you enter the URL http://www.megginson.com/ns/phone into Netscape, something useful will happen; however, by virtue of the fact that my company owns the megginson.com domain, I can guarantee that no one else can (or should) be able to use this namespace URI, so there is no chance of my element type names getting confused with someone else's. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Fri Jan 15 14:03:11 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:07:38 2004 Subject: What is a namespace ... really? Message-ID: <990115090135.15469@mail11.mitre.org.0> I thought I knew what a namespace was ... but now I think perhaps I don't. Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I define some elements, attributes, entities, etc. I define the relationships between the elements, attributes, etc. I place BookCatalogue.dtd in a directory: file://localhost/xml-course/xml-part1/BookCatalogue.dtd Is this a namespace? That is, is the file itself (BookCatalogue.dtd) a namespace? In all the examples that I see in the namespace spec they don't refer to a specific file. Instead, they refer to "some place", such as: http://www.w3.org/TR/HTML/ So, perhaps the "directory" that BookCatalogue.dtd resides in is the namespace? i.e., file://localhost/xml-course/xml-part1/ I thought I knew the way, now I don't. Help me find my way again. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Fri Jan 15 22:01:58 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:07:38 2004 Subject: Identifying XML Document Types (was XML media types revisited) In-Reply-To: <199901152121.QAA04800@hesketh.net> References: <3.0.5.32.19990115142731.00909100@amati.techno.com> <199901152012.PAA03477@hesketh.net> Message-ID: <3.0.5.32.19990115155842.008b0c50@amati.techno.com> At 04:24 PM 1/15/99 -0500, Simon St.Laurent wrote: >Schemas may be a good answer (if they kill the internal subset escape >hatch), combining an assertion about document type with a way to check it. >Is there any comparable 'architecture validation' process? Or are they >just assertions? Yes--validation of a document against its architectural DTD (a component of the overall architecture definition) is defined and is, not surprisingly, just like normal SGML/XML validation. Validation against the other (non-SGML/XML) components of the architecture definition is not defined by the architecture standard, so at that point you're where you would be with other schema mechanisms). >The only (obvious, anyway) flaw with these options are the need to load the >document before you know if it's worth processing - but that may be seen as >more a flaw of today's limited filesystems and transfer protocols, I suppose. You only have to scan the document for the declaration, you don't have to process the whole thing. In the architecture PI spec, we explicitly require that the PI occur before the document instance for this very reason. It's really no different from "magic numbers" in graphics files or the XML character set declaration--you have to have a little bootstrapping knowledge. Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:49:48 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:38 2004 Subject: Names, Dates, Etc. References: <93CB64052F94D211BC5D0010A8001331068E68@WWMESS3> Message-ID: <369F5519.134613E3@locke.ccil.org> Michael.Kay@icl.com wrote: > Incidentally, I don't think "," as a decimal separator is any more > international than ".", unless you use "international" in the U.S. sense of > "not American". What you should really be using is a "middle dot"... There is an ISO spec for this, but I'm having no luck finding it. It explicitly says that , is the international decimal point, but that . may be substituted in North America. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:53:16 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:38 2004 Subject: XML - NG References: <93CB64052F94D211BC5D0010A8001331068E67@WWMESS3> Message-ID: <369F54C7.1B2568E1@locke.ccil.org> Michael.Kay@icl.com wrote: > For example, a compliant XML processor is required to reject documents that > are not valid XML, even though they may be valid SGML. For "valid" read "well-formed". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 14:47:49 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:38 2004 Subject: What is a namespace ... really? In-Reply-To: <13983.19260.449920.371632@localhost.localdomain> Message-ID: <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> This is the *current* state of affairs. There are people who also believe that in the future the namespace concept is to be extended to incorporate Schema definition. That is, when a namespace URN points to a Schema definition, the Schema may, can or will be enforced in the same way that a DTD is enforced by a validating parser and a <!DOCTYPE definition. So to summarize, today a namespace is simply a naming scheme but in the future namespaces may become part of a typing scheme. Jonathan Borden http://jabr.ne.mediaone.net > > > Roger L. Costello writes: > > > I thought I knew what a namespace was ... but now I think perhaps I > > don't. > > It's simpler than you think. > ... > > > That is, is the file itself (BookCatalogue.dtd) a namespace? > > No -- it's irrelevant as far as the current namespaces REC is > concerned. > > > In all the examples that I see in the namespace spec they don't > > refer to a specific file. Instead, they refer to "some place", > > such as: > > > > http://www.w3.org/TR/HTML/ > > Not a place, just a unique URI. The URI doesn't actually have to work > (a URI that throws up a 404 is just fine). > > > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > > namespace? i.e., > > > > file://localhost/xml-course/xml-part1/ > > No. > > > I thought I knew the way, now I don't. Help me find my way again. > > A namespace is very similar to a package name in Java -- it's just a > way of disambiguating names. Consider > > package com.megginson.xml; > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wunder at infoseek.com Fri Jan 15 22:06:00 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:07:38 2004 Subject: Identifying XML Document Types (was XML media types revisited) In-Reply-To: <199901152012.PAA03477@hesketh.net> Message-ID: <3.0.5.32.19990115135710.00b637c0@corp> At 03:12 PM 1/15/99 -0500, Simon St.Laurent wrote: > >With XML the expectations (for being able to process documents with both >specific and generic tools) are much higher, yet the tools for identifying >document types are actually weaker in many ways. I'm not sure that things are all that bad. An Excel spreadsheet can be a lot of different things, but it is always parsed the same way. Word documents or FrameMaker documents may use different templates, but the file format is the same. MIME types do a fine job at that level. More ambitious schemes for description become more and more application specific. For example, my application is reading XML so that our search engine can index it. The document features that are important to a search engine are not specified in DTDs, style-sheets, schemas, or anything else. We need to know which element is the title, which is the description, and whether some parts of the document are more important for search purposes (a bibliography is less important, a problem description might be more important). The search engine does not care whether the document is valid or has a DTD at all, but it does care whether XLink is used in the document (namespaces do help in this case). Documents are often put to unexpected uses--indexing for search, legal discovery, corpus linguistics, whatever. Committing to a document description too early can actually make a document harder to use. In case you're curious, the search engine is a commercial product (Ultraseek Server), and has supported simple XML searching since last September. wunder Walter R. Underwood wunder@infoseek.com wunder@best.com (home) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:54:28 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:38 2004 Subject: What is a namespace ... really? References: <990115090135.15469@mail11.mitre.org.0> Message-ID: <369F55F0.E18CA735@locke.ccil.org> Roger L. Costello wrote: > Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I define some > elements, attributes, entities, etc. I define the relationships between > the elements, attributes, etc. I place BookCatalogue.dtd in a directory: > > file://localhost/xml-course/xml-part1/BookCatalogue.dtd > > Is this a namespace? That is, is the file itself (BookCatalogue.dtd) a > namespace? No, not as such. To have a namespace, you must define attributes *in the document* that have the form xmlns:prefix='some URI' where "some URI" is intended to remain stable. > In all the examples that I see in the namespace spec they don't refer to a > specific file. Instead, they refer to "some place", such as: > > http://www.w3.org/TR/HTML/ > > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > namespace? i.e., It can be used as such if you decide to do so. Or you can refer to the DTD itself as the namespace name. Or any URL you want; the URL does not have to refer to anything in particular. > file://localhost/xml-course/xml-part1/ This wouldn't be so useful, because it means different things on different hosts. But again, the URI is just used as a thing to compare to determine if two namespaces are the same or different. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 15:10:59 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:38 2004 Subject: What is a namespace ... really? In-Reply-To: <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> References: <13983.19260.449920.371632@localhost.localdomain> <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> Message-ID: <13983.22028.629794.586609@localhost.localdomain> Borden, Jonathan writes: > This is the *current* state of affairs. There are people who also > believe that in the future the namespace concept is to be extended > to incorporate Schema definition. That is, when a namespace URN > points to a Schema definition, the Schema may, can or will be > enforced in the same way that a DTD is enforced by a validating > parser and a <!DOCTYPE definition. Ack! No! Please don't hardcode a one-to-one relationship between schemas and namespaces. A single schema could define structures using elements and attributes from more than one namespace, and elements and attributes from a single namespace can be used and structured in many different ways. SGML people handle this problem in a fairly clumsy way by using public identifiers for indirection and then swapping entity catalogues at different stages of production. We can do better if do what a database designer does for many-to-many relationships: add separate associations between the namespace and the schema. The alternative would be to rely on HTTP content negotiation to get the kind of schema you want, and that is a pretty grim prospect (especially for people with web sites hosted by large ISPs who really aren't going to let them fiddle with the web server). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 15:16:52 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:38 2004 Subject: XML media types revisited References: <3.0.1.32.19990114195819.0091bd10@mail.accessone.com> Message-ID: <369F5BA2.36856834@locke.ccil.org> David LeBlanc wrote: > I don't agree with the idea that XML is a replacement for ASCII. Figuratively, not literally. The idea is that XML is meant to become the (near)ubiquitous way of expressing structured text or data, just as plain ASCII is the (near)ubiquitous way of expressing plain text or data. (But not forever: Unicode plain text rulz!) > [T]here are no technical reasons that I > know of why XML could not be represtented in EBCDIC or ASCII (aside from > standard compliance). Indeed, it is perfectly standards-compliant to have EBCDIC XML documents, as long as they begin with the characters "<?xml" (expressed in EBCDIC) and mention a proper code-page in the character set declaration. EBCDIC code pages have 3 names each: "IBMnnn", "cpnnn", and "ebcdic-cp-xx" where nnn is a CP number and xx is a country code. Whether any XML parsers interpret these names is a question. > Neither does "application" imply C, C++, Java or whatever else. In fact, I > wonder if "application/xml" is appropriate at all - does "application/RTF" > or "application/TROFF" make sense? Yes, very much so. Troff source can and should be specified as "application/x-troff" and could be registered as "application/troff" if anyone wanted to bother. But "text/x-troff" would be reasonable too, since much troff source can reasonably read as plain text. RTF source is usually too *busy* to be read as plain text, though. Anent the "application" top-level type, RFC 2046 saith: # [...T]ypically either uninterpreted binary data or information to be # processed by an application. [... E]xpected uses for "application" # include spreadsheets, data for mail-based scheduling systems, and # languages for "active" (computational) messaging, and word # processing formats that are not directly readable. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri Jan 15 12:13:50 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:38 2004 Subject: Names, Dates, Etc. Message-ID: <93CB64052F94D211BC5D0010A8001331068E68@WWMESS3> > >For all of these, we need architectures rather than markup languages > >per se, because applications may need more than one name, date, > >or money amount. I've actually hit this in a recent project which is using all three of these data types. I have to say I got myself a bit confused; in traditional data modelling we distinguish between the property name (e.g. recipient) and the domain (e.g. personalName), and I wasn't at all sure which of these to use as the XML element name, especially when the element had sub-structure. I guess architectural forms would have helped here, but they aren't mainstream XML. I toyed with double nesting (e.g. <recipient><personalName>Fred</personalName></recipient> but this seems horribly clumsy. I also thought of using a fixed attribute (dataType="personalName") in the DTD, but I don't particularly like fixed attributes e.g. because they vanish when you use a non-validating parser. In the end I just used the property name (<recipient>) and left the data type as implicit, something the receiving application is expected to know. Anyone have any better ideas? Mike Kay PS: I decided not to tag the substructure of dates and currency in XML, so currency appears just as GBP123.45, and dates as 1999-01-13. I tried XML substructures at one stage but the troops rebelled. Incidentally, I don't think "," as a decimal separator is any more international than ".", unless you use "international" in the U.S. sense of "not American". What you should really be using is a "middle dot"... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri Jan 15 12:13:58 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:39 2004 Subject: XML - NG Message-ID: <93CB64052F94D211BC5D0010A8001331068E67@WWMESS3> > If XML is truly a subset of SGML, how come nsgmls - a paragon of SGML > compliance - is not fully XML compliant? The XML standard defines conformance rules for "XML documents" and "XML processors". The following statements are both true (I believe): - every compliant XML document is a compliant SGML document - no compliant SGML processor is a compliant XML processor For example, a compliant XML processor is required to reject documents that are not valid XML, even though they may be valid SGML. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 15 15:30:10 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:39 2004 Subject: XML media types revisited References: <199901141806.NAA07944@hesketh.net> Message-ID: <369F5B37.F9501C54@prescod.net> "Simon St.Laurent" wrote: > > I don't expect the IETF to change this anytime soon, but it does seem like > something that could stand improvement. XML isn't really a text format - > Tim Bray used to say, it's a replacement for ASCII. I think that Tim meant to say that it is *analogous* to ASCII. It sure isn't a replacement for Unicode or ASCII in any sense. There are going to be many places in the Web information system where ASCII and Unicode are used without XML. The most reasonable way to handle this would be to allow mime types to have arbitrary levels. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 15 15:53:44 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:39 2004 Subject: XML media types revisited In-Reply-To: <369F5B37.F9501C54@prescod.net> References: <199901141806.NAA07944@hesketh.net> Message-ID: <199901151553.KAA31113@hesketh.net> At 09:13 AM 1/15/99 -0600, Paul Prescod wrote: >There are going to >be many places in the Web information system where ASCII and Unicode are >used without XML. The most reasonable way to handle this would be to allow >mime types to have arbitrary levels. Of course plain text will still survive; I'm hardly proposing abolishing text or application as top-level types. I'm just saying that XML is a top-level type itself. Your arbitrary level proposal is quite reasonable, though I suspect that that would require considerably more development (through the full IETF process) than just adding a new top-level type. Intriguing possibility, though... Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 16:09:37 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:39 2004 Subject: What is a namespace ... really? In-Reply-To: <13983.22028.629794.586609@localhost.localdomain> Message-ID: <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> David, My mind is still out on this topic. I've had a look at Microsoft's XML Schema stuff in IE5 b2 however, and currently when the namespace uri starts with "urn:" the namespace behaves as you desire. When the namespace uri begins with another prefix, the implication is that this points to a schema definition. I don't see a problem with this one-to-one relationship, after all, a namespace *is* defined by a uri, so... and I don't immediately see why this precludes inclusion of elemements from different namespaces. I think the idea is that if a namespace is defined by a uri, it may inherit a meaning associated with that uri, for example, suppose the uri was a .DTD, would this cause a problem or work any less well than a DTD which defines a default namespace and is specified in a <!DOCTYPE definition? Jonathan Borden > > > Borden, Jonathan writes: > > > This is the *current* state of affairs. There are people who also > > believe that in the future the namespace concept is to be extended > > to incorporate Schema definition. That is, when a namespace URN > > points to a Schema definition, the Schema may, can or will be > > enforced in the same way that a DTD is enforced by a validating > > parser and a <!DOCTYPE definition. > > Ack! No! Please don't hardcode a one-to-one relationship between > schemas and namespaces. > > A single schema could define structures using elements and attributes > from more than one namespace, and elements and attributes from a > single namespace can be used and structured in many different ways. > > SGML people handle this problem in a fairly clumsy way by using public > identifiers for indirection and then swapping entity catalogues at > different stages of production. We can do better if do what a > database designer does for many-to-many relationships: add separate > associations between the namespace and the schema. > > The alternative would be to rely on HTTP content negotiation to get > the kind of schema you want, and that is a pretty grim prospect > (especially for people with web sites hosted by large ISPs who really > aren't going to let them fiddle with the web server). > > > All the best, > > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 16:20:10 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:39 2004 Subject: XML media types revisited In-Reply-To: <199901151553.KAA31113@hesketh.net> Message-ID: <002701be40a2$57314940$d3228018@jabr.ne.mediaone.net> Simon, It's not that its otherwise a bad idea (it is an excellent idea). the problem is that adding a top level MIME type requires changes to tons of MIME aware code. This is why I always use text/xml as opposed to application/xml because the "application" top level is quite frequently used to denote 8 bit character data or binary data types which need to be base64 encoded for SMTP transport whereas "text" data is 7bit (UNICODE aside :-) and is appropriately transfered as content-type: 7bit or quoted-printable. On the other hand, my MIME code takes special care when it sees the text/xml content-type (not that this should sway the IETF :-)) not that these assumptions are valid, its just that they exist. Jonathan Borden http://jabr.ne.mediaone.net > > Of course plain text will still survive; I'm hardly proposing abolishing > text or application as top-level types. I'm just saying that XML is a > top-level type itself. > > Your arbitrary level proposal is quite reasonable, though I suspect that > that would require considerably more development (through the full IETF > process) than just adding a new top-level type. > > Intriguing possibility, though... > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joel at softopt.co.uk Fri Jan 15 13:19:02 1999 From: joel at softopt.co.uk (Joel Rosi-Schwartz) Date: Mon Jun 7 17:07:39 2004 Subject: Existing XSL processors References: <C12566FA.003546C4.00@mmfileserver.crpht.lu> Message-ID: <369F3F5E.EA17CB49@softopt.co.uk> I am also new to XML/XSL and one of the first cofusions I had to sort out was the "missing" piece of visual output processing software, be it on screen or paper. It just seemed so "obvious" to me that this "should" be there, that for a couple of weeks I kep thinking that I was missing something in the way it all came together and worked. Finally I figured out that no it is just not there yet as any kind of standard (official or de facto) means of implementing it. It would be really useful, in my opinion, if this was rectified (at least on the Java front) with a formating engine class library that easily processed XML+DTD+XLS into an AWT display and common (read PS + RTF + TeX + PDF, etc) output. I am aware that parts of this is being addressed with technology such as James Tauber's FOP, but a more comprehensive solution under an Open Software Licence would certainly be nice. hmm....I didn't start this note with this intention, but I guess what I am really getting down to is asking if there is interest among the members of this list to take this on. Regards, Joel anette.engel@crpht.lu wrote: > Hi Guy, > > Thanks for your answer. Unfortunately I am not only dealing with displaying > documents in a browser , but also with printout. Apart from that there are > still > browsers which don't support XML and XSL at all. > > Cheers > Anette > > Guy_Murphy@dialog.com on 01/14/99 03:22:49 PM > > Please respond to xsl-list@mulberrytech.com > > To: xsl-list@mulberrytech.com > cc: (bcc: Anette Engel/crmm) > Subject: Re: Existing XSL processors > > Hi Anette. > The second part is pretty much up to the browsers. You can output pretty > much aything you want (as long as it's well formed) as long as your target > browser will support it, and render it. At the moment that leaves us pretty > much with HTML and/or XML w/CSS. The second part is more an issue of agreed > output than anything. > There might be a proof of concept browser/application out there somewhere > that supports formatting object as per the current XSL spec, but not in > wide circulation. Anybody seen such a beast? > Cheers > Guy. > > xsl-list@mulberrytech.com on 01/14/99 07:22:51 PM > To: xsl-list@mulberrytech.com > cc: (bcc: Guy Murphy/UK/MAID) > Subject: Existing XSL processors > > Reading the XSL Draft of the w3 consortium it is said: > "XSL is a lnaguage for expressing stylsheets. It consists of two parts: > 1. a language for transforming XML documents, and > 2. an XML vocabulary for specifiying formatting semantics" > So far I had a look at XSL engines which implement the first part. > Is there by any chance a XSL engine, which implements > the second part too? > Regards > Anette > anette.engel@crpht.lu > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 16:26:02 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:39 2004 Subject: XML media types revisited References: <199901141806.NAA07944@hesketh.net> <199901151553.KAA31113@hesketh.net> Message-ID: <369F6BE6.4F288EC@locke.ccil.org> Simon St.Laurent wrote: > Your arbitrary level proposal is quite reasonable, though I suspect that > that would require considerably more development (through the full IETF > process) than just adding a new top-level type. Either way requires a standards-track RFC. The trouble is that XML just isn't a content type analogous to "text", "video", "image", "audio", "model", etc: it's a format, or rather a metaformat. Content-types are supposed to be named based on what they are good for, rather than what the details of the internal format are. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Jan 15 16:49:31 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:39 2004 Subject: Existing XSL processors Message-ID: <021e01be40a7$39916aa0$0300000a@othniel.cygnus.uwa.edu.au> >output. I am aware that parts of this is being addressed with technology such >as James Tauber's FOP, but a more comprehensive solution under an Open Software >Licence would certainly be nice. I intend both for FOP to both become more comprehensive and for it to be placed under an Open Software Licence. James (who deliberated over the cross-posting :-) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 16:54:56 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:39 2004 Subject: What is a namespace ... really? In-Reply-To: <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> References: <13983.22028.629794.586609@localhost.localdomain> <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> Message-ID: <13983.28566.71365.447556@localhost.localdomain> Borden, Jonathan writes: > I don't see a problem with this one-to-one relationship, after all, > a namespace *is* defined by a uri, so... and I don't immediately > see why this precludes inclusion of elemements from different > namespaces. What if I want to create a schema specifying that (for my set of documents) an html:p element may contain a tei:foreign element, or a docbook:Trademark element in addition to the regular HTML elements? What if I want to create a schema specifying that (for my set of documents) an html:p element may *not* contain an html:font element? It doesn't make sense to have to create a new and different namespace for either of these -- I'm still using the individual elements in mostly the same way. I could, of course, use some kind of inheritance scheme, but I don't think the world will buy anything that requires retrieving 5 or 10 schemas from different servers just to figure out that an html:a element is from the HTML namespace. > I think the idea is that if a namespace is defined by a uri, it may > inherit a meaning associated with that uri, for example, suppose > the uri was a .DTD, would this cause a problem or work any less > well than a DTD which defines a default namespace and is specified > in a <!DOCTYPE definition? It would cause about the same set of problems as DOCTYPE (perhaps worse with datatyping and other niceties) -- that's why we need to get away from it. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Fri Jan 15 14:03:11 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:07:39 2004 Subject: What is a namespace ... really? Message-ID: <990115090135.15469@mail11.mitre.org.0> I thought I knew what a namespace was ... but now I think perhaps I don't. Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I define some elements, attributes, entities, etc. I define the relationships between the elements, attributes, etc. I place BookCatalogue.dtd in a directory: file://localhost/xml-course/xml-part1/BookCatalogue.dtd Is this a namespace? That is, is the file itself (BookCatalogue.dtd) a namespace? In all the examples that I see in the namespace spec they don't refer to a specific file. Instead, they refer to "some place", such as: http://www.w3.org/TR/HTML/ So, perhaps the "directory" that BookCatalogue.dtd resides in is the namespace? i.e., file://localhost/xml-course/xml-part1/ I thought I knew the way, now I don't. Help me find my way again. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 14:16:43 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:40 2004 Subject: What is a namespace ... really? In-Reply-To: <990115090135.15469@mail11.mitre.org.0> References: <990115090135.15469@mail11.mitre.org.0> Message-ID: <13983.19260.449920.371632@localhost.localdomain> Roger L. Costello writes: > I thought I knew what a namespace was ... but now I think perhaps I > don't. It's simpler than you think. > Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I > define some elements, attributes, entities, etc. I define the > relationships between the elements, attributes, etc. I place > BookCatalogue.dtd in a directory: > > file://localhost/xml-course/xml-part1/BookCatalogue.dtd > > Is this a namespace? It's a namespace URI (in this case, a URL). > That is, is the file itself (BookCatalogue.dtd) a namespace? No -- it's irrelevant as far as the current namespaces REC is concerned. > In all the examples that I see in the namespace spec they don't > refer to a specific file. Instead, they refer to "some place", > such as: > > http://www.w3.org/TR/HTML/ Not a place, just a unique URI. The URI doesn't actually have to work (a URI that throws up a 404 is just fine). > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > namespace? i.e., > > file://localhost/xml-course/xml-part1/ No. > I thought I knew the way, now I don't. Help me find my way again. A namespace is very similar to a package name in Java -- it's just a way of disambiguating names. Consider package com.megginson.xml; class XMLNamespace { // [...] } This does not guarantee that if you enter the URL http://xml.megginson.com/ into Netscape, something will happen; however, by virtue of the fact that my company owns the megginson.com domain, I can guarantee that no one else can (or should) be able to use this package name, so there is no chance of my classes getting confused with someone else's. Likewise, consider <?xml version="1.0"?> <ph:phone-list xmlns:ph="http://www.megginson.com/ns/phone"> <ph:entry> <ph:name>Megginson Technologies Ltd.</ph:name> <ph:number>+1 613 722 8770</ph:number> </ph:entry> </ph:phone-list> This does not guarantee that if you enter the URL http://www.megginson.com/ns/phone into Netscape, something useful will happen; however, by virtue of the fact that my company owns the megginson.com domain, I can guarantee that no one else can (or should) be able to use this namespace URI, so there is no chance of my element type names getting confused with someone else's. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 16:26:02 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:40 2004 Subject: XML media types revisited References: <199901141806.NAA07944@hesketh.net> <199901151553.KAA31113@hesketh.net> Message-ID: <369F6BE6.4F288EC@locke.ccil.org> Simon St.Laurent wrote: > Your arbitrary level proposal is quite reasonable, though I suspect that > that would require considerably more development (through the full IETF > process) than just adding a new top-level type. Either way requires a standards-track RFC. The trouble is that XML just isn't a content type analogous to "text", "video", "image", "audio", "model", etc: it's a format, or rather a metaformat. Content-types are supposed to be named based on what they are good for, rather than what the details of the internal format are. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:54:28 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:40 2004 Subject: What is a namespace ... really? References: <990115090135.15469@mail11.mitre.org.0> Message-ID: <369F55F0.E18CA735@locke.ccil.org> Roger L. Costello wrote: > Suppose that I create a DTD (BookCatalogue.dtd). In this DTD I define some > elements, attributes, entities, etc. I define the relationships between > the elements, attributes, etc. I place BookCatalogue.dtd in a directory: > > file://localhost/xml-course/xml-part1/BookCatalogue.dtd > > Is this a namespace? That is, is the file itself (BookCatalogue.dtd) a > namespace? No, not as such. To have a namespace, you must define attributes *in the document* that have the form xmlns:prefix='some URI' where "some URI" is intended to remain stable. > In all the examples that I see in the namespace spec they don't refer to a > specific file. Instead, they refer to "some place", such as: > > http://www.w3.org/TR/HTML/ > > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > namespace? i.e., It can be used as such if you decide to do so. Or you can refer to the DTD itself as the namespace name. Or any URL you want; the URL does not have to refer to anything in particular. > file://localhost/xml-course/xml-part1/ This wouldn't be so useful, because it means different things on different hosts. But again, the URI is just used as a thing to compare to determine if two namespaces are the same or different. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:53:16 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:40 2004 Subject: XML - NG References: <93CB64052F94D211BC5D0010A8001331068E67@WWMESS3> Message-ID: <369F54C7.1B2568E1@locke.ccil.org> Michael.Kay@icl.com wrote: > For example, a compliant XML processor is required to reject documents that > are not valid XML, even though they may be valid SGML. For "valid" read "well-formed". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 14:49:48 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:40 2004 Subject: Names, Dates, Etc. References: <93CB64052F94D211BC5D0010A8001331068E68@WWMESS3> Message-ID: <369F5519.134613E3@locke.ccil.org> Michael.Kay@icl.com wrote: > Incidentally, I don't think "," as a decimal separator is any more > international than ".", unless you use "international" in the U.S. sense of > "not American". What you should really be using is a "middle dot"... There is an ISO spec for this, but I'm having no luck finding it. It explicitly says that , is the international decimal point, but that . may be substituted in North America. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 14:47:49 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:40 2004 Subject: What is a namespace ... really? In-Reply-To: <13983.19260.449920.371632@localhost.localdomain> Message-ID: <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> This is the *current* state of affairs. There are people who also believe that in the future the namespace concept is to be extended to incorporate Schema definition. That is, when a namespace URN points to a Schema definition, the Schema may, can or will be enforced in the same way that a DTD is enforced by a validating parser and a <!DOCTYPE definition. So to summarize, today a namespace is simply a naming scheme but in the future namespaces may become part of a typing scheme. Jonathan Borden http://jabr.ne.mediaone.net > > > Roger L. Costello writes: > > > I thought I knew what a namespace was ... but now I think perhaps I > > don't. > > It's simpler than you think. > ... > > > That is, is the file itself (BookCatalogue.dtd) a namespace? > > No -- it's irrelevant as far as the current namespaces REC is > concerned. > > > In all the examples that I see in the namespace spec they don't > > refer to a specific file. Instead, they refer to "some place", > > such as: > > > > http://www.w3.org/TR/HTML/ > > Not a place, just a unique URI. The URI doesn't actually have to work > (a URI that throws up a 404 is just fine). > > > So, perhaps the "directory" that BookCatalogue.dtd resides in is the > > namespace? i.e., > > > > file://localhost/xml-course/xml-part1/ > > No. > > > I thought I knew the way, now I don't. Help me find my way again. > > A namespace is very similar to a package name in Java -- it's just a > way of disambiguating names. Consider > > package com.megginson.xml; > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Sat Jan 16 00:29:42 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:40 2004 Subject: What is a namespace ... really? Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEDE7@RED-MSG-08> I agree fully with David Megginson's statement that namespaces and schemas are not the same thing: "A single schema could define structures using elements and attributes from more than one namespace, and elements and attributes from a single namespace can be used and structured in many different ways." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Jan 16 20:29:58 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:40 2004 Subject: What is a namespace ... really? In-Reply-To: <002a01be4102$fee345c0$d3228018@jabr.ne.mediaone.net> References: <13983.28566.71365.447556@localhost.localdomain> <002a01be4102$fee345c0$d3228018@jabr.ne.mediaone.net> Message-ID: <13984.30837.215874.558788@localhost.localdomain> Borden, Jonathan writes: > > It would cause about the same set of problems as DOCTYPE (perhaps > > worse with datatyping and other niceties) -- that's why we need to get > > away from it. > > > Ok, so you are arguing against validation in general. I like > how XML works now: it is optional. Not at all -- I am a big fan of validation, and have even written a book about XML and SGML DTDs. One problem with DOCTYPE is that it forces a one-to-one mapping between the document and the DTD, and I have never worked on a medium or large SGML system that didn't need to use different variant DTDs at different stages of production. To work around this problem, most systems use shell scripts either to copy different DTD files into the same location, or to copy different entity catalogs into the same location. The second problem with DOCTYPE is that the internal subset can modify the meaning of the external subset, so the public and system identifers of the DOCTYPE really tell you nothing reliable about what DTD the document conforms to. Forcing a one-to-one mapping between namespaces and schemas would (probably) solve the second problem, but not the first. Architectural forms solve both problems, but at the cost (or benefit) of adding an additional level of indirection to the markup itself. I've been working with SGML DTDs and SGML systems for eight years now, and I've seen both the beauty and the shortcomings of ISO 8879. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rhavaldar at str.com Sat Jan 16 21:22:17 1999 From: rhavaldar at str.com (Raghunandan Havaldar) Date: Mon Jun 7 17:07:40 2004 Subject: specs for Coins 3.1 ? Message-ID: <000101be415c$e15e4180$3c2996d0@rhavaldar> Hello, Am new to Coins. Downloaded the Coins 3.1 version. Apart from one document on the website (jxml.com), there does not seem any other documentation or information regarding - specs, setup, usage of examples etc. Are there any pointers regarding version 3.1 ?. I know there is one on 4.0. Thanks Raghu rhavaldar@str.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 16:09:37 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:40 2004 Subject: What is a namespace ... really? In-Reply-To: <13983.22028.629794.586609@localhost.localdomain> Message-ID: <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> David, My mind is still out on this topic. I've had a look at Microsoft's XML Schema stuff in IE5 b2 however, and currently when the namespace uri starts with "urn:" the namespace behaves as you desire. When the namespace uri begins with another prefix, the implication is that this points to a schema definition. I don't see a problem with this one-to-one relationship, after all, a namespace *is* defined by a uri, so... and I don't immediately see why this precludes inclusion of elemements from different namespaces. I think the idea is that if a namespace is defined by a uri, it may inherit a meaning associated with that uri, for example, suppose the uri was a .DTD, would this cause a problem or work any less well than a DTD which defines a default namespace and is specified in a <!DOCTYPE definition? Jonathan Borden > > > Borden, Jonathan writes: > > > This is the *current* state of affairs. There are people who also > > believe that in the future the namespace concept is to be extended > > to incorporate Schema definition. That is, when a namespace URN > > points to a Schema definition, the Schema may, can or will be > > enforced in the same way that a DTD is enforced by a validating > > parser and a <!DOCTYPE definition. > > Ack! No! Please don't hardcode a one-to-one relationship between > schemas and namespaces. > > A single schema could define structures using elements and attributes > from more than one namespace, and elements and attributes from a > single namespace can be used and structured in many different ways. > > SGML people handle this problem in a fairly clumsy way by using public > identifiers for indirection and then swapping entity catalogues at > different stages of production. We can do better if do what a > database designer does for many-to-many relationships: add separate > associations between the namespace and the schema. > > The alternative would be to rely on HTTP content negotiation to get > the kind of schema you want, and that is a pretty grim prospect > (especially for people with web sites hosted by large ISPs who really > aren't going to let them fiddle with the web server). > > > All the best, > > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 15 16:20:10 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:40 2004 Subject: XML media types revisited In-Reply-To: <199901151553.KAA31113@hesketh.net> Message-ID: <002701be40a2$57314940$d3228018@jabr.ne.mediaone.net> Simon, It's not that its otherwise a bad idea (it is an excellent idea). the problem is that adding a top level MIME type requires changes to tons of MIME aware code. This is why I always use text/xml as opposed to application/xml because the "application" top level is quite frequently used to denote 8 bit character data or binary data types which need to be base64 encoded for SMTP transport whereas "text" data is 7bit (UNICODE aside :-) and is appropriately transfered as content-type: 7bit or quoted-printable. On the other hand, my MIME code takes special care when it sees the text/xml content-type (not that this should sway the IETF :-)) not that these assumptions are valid, its just that they exist. Jonathan Borden http://jabr.ne.mediaone.net > > Of course plain text will still survive; I'm hardly proposing abolishing > text or application as top-level types. I'm just saying that XML is a > top-level type itself. > > Your arbitrary level proposal is quite reasonable, though I suspect that > that would require considerably more development (through the full IETF > process) than just adding a new top-level type. > > Intriguing possibility, though... > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 15:10:59 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:40 2004 Subject: What is a namespace ... really? In-Reply-To: <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> References: <13983.19260.449920.371632@localhost.localdomain> <002101be4095$7913ad30$d3228018@jabr.ne.mediaone.net> Message-ID: <13983.22028.629794.586609@localhost.localdomain> Borden, Jonathan writes: > This is the *current* state of affairs. There are people who also > believe that in the future the namespace concept is to be extended > to incorporate Schema definition. That is, when a namespace URN > points to a Schema definition, the Schema may, can or will be > enforced in the same way that a DTD is enforced by a validating > parser and a <!DOCTYPE definition. Ack! No! Please don't hardcode a one-to-one relationship between schemas and namespaces. A single schema could define structures using elements and attributes from more than one namespace, and elements and attributes from a single namespace can be used and structured in many different ways. SGML people handle this problem in a fairly clumsy way by using public identifiers for indirection and then swapping entity catalogues at different stages of production. We can do better if do what a database designer does for many-to-many relationships: add separate associations between the namespace and the schema. The alternative would be to rely on HTTP content negotiation to get the kind of schema you want, and that is a pretty grim prospect (especially for people with web sites hosted by large ISPs who really aren't going to let them fiddle with the web server). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 15 16:54:56 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:40 2004 Subject: What is a namespace ... really? In-Reply-To: <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> References: <13983.22028.629794.586609@localhost.localdomain> <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> Message-ID: <13983.28566.71365.447556@localhost.localdomain> Borden, Jonathan writes: > I don't see a problem with this one-to-one relationship, after all, > a namespace *is* defined by a uri, so... and I don't immediately > see why this precludes inclusion of elemements from different > namespaces. What if I want to create a schema specifying that (for my set of documents) an html:p element may contain a tei:foreign element, or a docbook:Trademark element in addition to the regular HTML elements? What if I want to create a schema specifying that (for my set of documents) an html:p element may *not* contain an html:font element? It doesn't make sense to have to create a new and different namespace for either of these -- I'm still using the individual elements in mostly the same way. I could, of course, use some kind of inheritance scheme, but I don't think the world will buy anything that requires retrieving 5 or 10 schemas from different servers just to figure out that an html:a element is from the HTML namespace. > I think the idea is that if a namespace is defined by a uri, it may > inherit a meaning associated with that uri, for example, suppose > the uri was a .DTD, would this cause a problem or work any less > well than a DTD which defines a default namespace and is specified > in a <!DOCTYPE definition? It would cause about the same set of problems as DOCTYPE (perhaps worse with datatyping and other niceties) -- that's why we need to get away from it. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Jan 15 16:49:31 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:40 2004 Subject: Existing XSL processors Message-ID: <021e01be40a7$39916aa0$0300000a@othniel.cygnus.uwa.edu.au> >output. I am aware that parts of this is being addressed with technology such >as James Tauber's FOP, but a more comprehensive solution under an Open Software >Licence would certainly be nice. I intend both for FOP to both become more comprehensive and for it to be placed under an Open Software Licence. James (who deliberated over the cross-posting :-) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 15 15:30:10 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:41 2004 Subject: XML media types revisited References: <199901141806.NAA07944@hesketh.net> Message-ID: <369F5B37.F9501C54@prescod.net> "Simon St.Laurent" wrote: > > I don't expect the IETF to change this anytime soon, but it does seem like > something that could stand improvement. XML isn't really a text format - > Tim Bray used to say, it's a replacement for ASCII. I think that Tim meant to say that it is *analogous* to ASCII. It sure isn't a replacement for Unicode or ASCII in any sense. There are going to be many places in the Web information system where ASCII and Unicode are used without XML. The most reasonable way to handle this would be to allow mime types to have arbitrary levels. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Sat Jan 16 22:07:19 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:41 2004 Subject: XML media types revisited In-Reply-To: <369F5BA2.36856834@locke.ccil.org> References: <3.0.1.32.19990114195819.0091bd10@mail.accessone.com> Message-ID: <3.0.1.32.19990115074910.01111e70@mail.accessone.com> At 10:15 AM 1/15/99 -0500, John Cowan wrote: >David LeBlanc wrote: > >> I don't agree with the idea that XML is a replacement for ASCII. > >Figuratively, not literally. The idea is that XML is meant to become >the (near)ubiquitous way of expressing structured text or data, just as >plain ASCII is the (near)ubiquitous way of expressing plain text >or data. (But not forever: Unicode plain text rulz!) > Ah! agreed!! <snip> > >> Neither does "application" imply C, C++, Java or whatever else. In fact, I >> wonder if "application/xml" is appropriate at all - does "application/RTF" >> or "application/TROFF" make sense? > >Yes, very much so. Troff source can and should be specified as >"application/x-troff" and could be registered as "application/troff" >if anyone wanted to bother. But "text/x-troff" would be reasonable >too, since much troff source can reasonably read as plain text. >RTF source is usually too *busy* to be read as plain text, though. > >Anent the "application" top-level type, RFC 2046 saith: > ># [...T]ypically either uninterpreted binary data or information to be ># processed by an application. [... E]xpected uses for "application" ># include spreadsheets, data for mail-based scheduling systems, and ># languages for "active" (computational) messaging, and word ># processing formats that are not directly readable. > Ok, thanks for the clarification - I inferred that "application" meant "runnable". >-- >John Cowan http://www.ccil.org/~cowan cowan@ccil.org Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 15 15:53:44 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:41 2004 Subject: XML media types revisited In-Reply-To: <369F5B37.F9501C54@prescod.net> References: <199901141806.NAA07944@hesketh.net> Message-ID: <199901151553.KAA31113@hesketh.net> At 09:13 AM 1/15/99 -0600, Paul Prescod wrote: >There are going to >be many places in the Web information system where ASCII and Unicode are >used without XML. The most reasonable way to handle this would be to allow >mime types to have arbitrary levels. Of course plain text will still survive; I'm hardly proposing abolishing text or application as top-level types. I'm just saying that XML is a top-level type itself. Your arbitrary level proposal is quite reasonable, though I suspect that that would require considerably more development (through the full IETF process) than just adding a new top-level type. Intriguing possibility, though... Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (March) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From db at Eng.Sun.COM Sat Jan 16 23:14:22 1999 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:07:41 2004 Subject: Identifying XML Document Types (was XML media types revisited) References: <199901152012.PAA03477@hesketh.net> Message-ID: <36A10EA4.FEC5ADDF@eng.sun.com> "Simon St.Laurent" wrote: > > ... naming and otherwise identifying elements and documents ... > > 4) Root elements using Namespaces - A new possibility that gained some > prominence with the accession to W3C Recommendation of 'Namespaces in XML'. > > Advantages: Namespaces ensure unique element names, making it less likely > that you have someone else's DOCUMENT element. > > Disadvantages: Just because the root element is X doesn't mean its contents > are Y. Especially given the problems of validating documents in > namespace-aware environments, namespaces may not always be available. If you're using XML namespaces with a validating parser, just make sure each element has #FIXED "xmlns*" attributes and stick to the constraints of your content model, and you're fine ... living with the same DTD-derived restrictions you always had. > Because namespaces aren't supposed to point to anything, you can't sneak a > DTD in at the URL identified by the namespace. Yet the specification for a _specific_ namespace can easily say that the namespace URI is a URL holding data in some format ("schema"). All the namespace spec defines is that it's an identifier, used to make the XML document be more self-descriptive; but any particular namespace could define more than that, as part of its application architecture. > Recurring Question: So how do I make this work reliably in a validating > environment? (Recurring answer: Ask again next year, please.) There's another recurring answer, "it works just fine, even when you want to validate, so what's the confusion?". What's not fully understood is how to mix elements from different namespaces under control of a _new and unspecified_ validity model. Re what such models "ought to" be like ... ask again next year! And meanwhile, remember that namespaces work fine with today's models. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Jan 16 23:23:23 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:41 2004 Subject: What is a namespace ... really? Message-ID: <3.0.32.19990116112847.00c6ec80@pop.intergate.bc.ca> At 01:24 PM 1/15/99 -0500, Roger L. Costello wrote: > It seems that people have >differing ideas on what it is. I would like to try to summarize the points >of view, and add my own two cents. > >(1) A namespace is just a URI. It references some domain. It is simply >there to tell an application/processor what domain the associated XML >elements hail from. This is the "view" that is expressed by the actual namespace spec. Other views are simply incorrect. There is not one word in the namespace spec that suggests that namespace URIs represent DTDs, and in fact specific language (look it up) that says that it's a non-goal that the URI actually points at anything. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Jan 16 23:23:36 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:41 2004 Subject: What is a namespace ... really? Message-ID: <3.0.32.19990116115458.00aa5ec0@pop.intergate.bc.ca> At 02:42 PM 1/16/99 -0500, Borden, Jonathan wrote: >The >question is whether a namespace has meaning outside of the name, or what >meaning does the namespace uri have? No meaning. It's just a name. > > some people suggest it is just a unique name. others suggest it >ought to >point to a DTD, and others a schema. this issue is still under debate There are lots of interesting potential uses of the namespace URI. None of them are either blessed or forbidden by the namespace spec. For now, it's a name and that's all it is. >for >example dave megginson states to the effect that the namespace uri ought >have no meaning beyond a unique name (dave, i hope i've summarized you >correctly :-) but andrew layman believes otherwise (correct?) What Dave says is what the spec says. Since Andrew co-wrote the spec, I'd be surprised if he were saying anything different. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Jan 16 23:24:49 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:41 2004 Subject: What is a namespace ... really? Message-ID: <3.0.32.19990116112530.00bf9100@pop.intergate.bc.ca> At 09:43 AM 1/15/99 -0500, Borden, Jonathan wrote: >This is the *current* state of affairs. There are people who also believe >that in the future the namespace concept is to be extended to incorporate >Schema definition. That is, when a namespace URN points to a Schema >definition, the Schema may, can or will be enforced in the same way that a >DTD is enforced by a validating parser and a <!DOCTYPE definition. Other way around. There are people (most people who follow this stuff) who think that a future schema facility needs to be namespace-sensitive. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sat Jan 16 23:24:58 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:41 2004 Subject: What is a namespace ... really? In-Reply-To: <3.0.32.19990116112530.00bf9100@pop.intergate.bc.ca> Message-ID: <002e01be4188$4a388b90$d3228018@jabr.ne.mediaone.net> Tim, No doubt about the issue of schemas needing to be namespace sensitive. The question is whether a namespace has meaning outside of the name, or what meaning does the namespace uri have? some people suggest it is just a unique name. others suggest it ought to point to a DTD, and others a schema. this issue is still under debate, for example dave megginson states to the effect that the namespace uri ought have no meaning beyond a unique name (dave, i hope i've summarized you correctly :-) but andrew layman believes otherwise (correct?) Jonathan Borden http://jabr.ne.mediaone.net > > > At 09:43 AM 1/15/99 -0500, Borden, Jonathan wrote: > >This is the *current* state of affairs. There are people who also believe > >that in the future the namespace concept is to be extended to incorporate > >Schema definition. That is, when a namespace URN points to a Schema > >definition, the Schema may, can or will be enforced in the same > way that a > >DTD is enforced by a validating parser and a <!DOCTYPE definition. > > Other way around. There are people (most people who follow this > stuff) who think that a future schema facility needs to be > namespace-sensitive. -Tim > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sun Jan 17 00:09:01 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:41 2004 Subject: Namespace PR In-Reply-To: <014CB98EB81ED011B3E900805FE2D47A04F74AFF@X01SCHCORPGE> from "Cooper, Clark" at Jan 15, 99 11:00:18 am Message-ID: <199901170052.TAA14648@locke.ccil.org> Cooper, Clark scripsit: > I couldn't find it in the old Note and I can't find it in the new P.R.: > > How are namespaces for qualified names in declarations declared, since they > are outside the There is no way. Your logic is impeccable, but nevertheless there is no way. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tallen at sonic.net Sun Jan 17 02:35:48 1999 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 17:07:41 2004 Subject: What is a namespace ... really? Message-ID: <199901170235.SAA05961@bolt.sonic.net> Tim Bray wrote, in two messages: | At 01:24 PM 1/15/99 -0500, Roger L. Costello wrote: | > It seems that people have | >differing ideas on what it is. I would like to try to summarize the points | >of view, and add my own two cents. | > | >(1) A namespace is just a URI. It references some domain. It is simply | >there to tell an application/processor what domain the associated XML | >elements hail from. | | This is the "view" that is expressed by the actual namespace spec. Other | views are simply incorrect. There is not one word in the namespace spec | that suggests that namespace URIs represent DTDs, and in fact specific | language (look it up) that says that it's a non-goal that the URI | actually points at anything. ... | At 02:42 PM 1/16/99 -0500, Borden, Jonathan wrote: | >The | >question is whether a namespace has meaning outside of the name, or what | >meaning does the namespace uri have? | | No meaning. It's just a name. | | > | > some people suggest it is just a unique name. others suggest it | >ought to | >point to a DTD, and others a schema. this issue is still under debate | | There are lots of interesting potential uses of the namespace URI. None | of them are either blessed or forbidden by the namespace spec. For now, | it's a name and that's all it is. Now, RFC 2396 says (from the Abstract): A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document and (from section 1.1): Resource A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources. So the "namespace" URI must identify a resource, which is anything [any "thing"] that has identity. (Obviously and tautologically, the identity of any thing is itself; the thing makes its own identity simply by existing.) You say that it doesn't have to point to anything [any "thing"], and that it's "just a name". So is the resource ["thing"] identified by a "namespace" URI itself? or is it the name of itself (maybe Kant could explain)? How does something that is only itself or the name of itself encompass anything else? Me, myself, I think this is a bogus use of URIs. What you are really using is DNS, and you don't need to use fake URIs to do so; cf. the IOTP spec. Terry Allen Veo Systems, Inc. Business Language Designer 2440 W. El Camino Real tallen[at]sonic.net Mountain View, Calif., 94040 Common Business Library - available at http://www.veosystems.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sun Jan 17 03:42:08 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:41 2004 Subject: What is a namespace ... really? Message-ID: <3.0.32.19990116194151.00bf1470@pop.intergate.bc.ca> At 06:35 PM 1/16/99 -0800, Terry Allen wrote: >Now, RFC 2396 says (from the Abstract): ... [a URI identifies a resource, which can be anything] >So the "namespace" URI must identify a resource, Well, gosh, but what if it doesn't? The original design clearly is intended to support the identification of resources, but we're using it in a different way. >Me, myself, I think this is a bogus use of URIs. What you are >really using is DNS, and you don't need to use fake URIs to do so; >cf. the IOTP spec. That's a good point - clearly the DNS is a key part of this. But you might want more than one namespace per domain, so what we need is a DNS address plus some more identifying stuff; a bill that the URI seems to fill, so why re-invent it. Also, it leaves open the possibility that at some future point we figure out something that could usefully serve as the resource being pointed to. For those of you who (like me) had no idea what IOTP is, check out http://www.idg.net/idg_frames/english/content.cgi?vc=docid_9-62053.html -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Sun Jan 17 04:25:22 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:42 2004 Subject: What is a namespace ... really? Message-ID: <00e401be41d1$afe14920$0300000a@othniel.cygnus.uwa.edu.au> >>Me, myself, I think this is a bogus use of URIs. What you are >>really using is DNS, and you don't need to use fake URIs to do so; >>cf. the IOTP spec. > >That's a good point - clearly the DNS is a key part of this. But >you might want more than one namespace per domain, so what we need >is a DNS address plus some more identifying stuff; a bill that the >URI seems to fill, so why re-invent it. IMHO, the key is a hierarchical naming scheme. DNS provides the first few levels of the hierarchy; the path provides the remaining levels. It's worth noting that only the globally unique naming aspect of DNS is utilised - not the resolution mechanism. This is what seems to confuse people. They think that the resource at the other end of the URI is what determines the namespace. It's not the resource that determines the namespace (the resource might not even exist), it is just the URI, or perhaps even more precisely: the string of characters that is the URI. Maybe this *is* a bogus use of URIs. Other alternatives include: * domain name + some string eg ("w3.org","XSL FO") * ISO 9070 public identifiers Note that because these things never get resolved, it does not matter that there isn't a resolution mechanism for the first one or that there is no widespead use of delegating catalogs for the latter. All that matters is a recognised hierarchical naming scheme with a root authority. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Associate Researcher, Electronic Commerce Network Curtin University of Technology, Perth, Western Australia Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sun Jan 17 04:46:36 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:42 2004 Subject: What is a namespace ... really? In-Reply-To: <13983.22028.629794.586609@localhost.localdomain> Message-ID: <003a01be41d3$d5b16430$d3228018@jabr.ne.mediaone.net> Whoooops, since the list server has been spitting this out so many times and i've re-read this so many times I just realized that I made a misstatement here... That should read: "There are people who also believe that in the future the namespace *uri* is to specify a Schema definition. ..." The *concepts* of namespace and schema are different. The uri may in the future provide a link (for example, in IE5b2). Under the IE5b2 mechanism, there is a single schema for each namespace whose uri points to a schema defn. Since a namespace is specified by its uri and a schema is presumably located in a file (uri), this mechanism creates a 1-1 mapping. When a more flexible mapping is desired, the uri need not point directly to the schema uri, rather it could be a "urn:" (which puts off --but does not prevent-- a solution to the problem :-) Jonathan Borden http://jabr.ne.mediaone.net > > > Borden, Jonathan writes: > > > This is the *current* state of affairs. There are people who also > > believe that in the future the namespace concept is to be extended > > to incorporate Schema definition. That is, when a namespace URN > > points to a Schema definition, the Schema may, can or will be > > enforced in the same way that a DTD is enforced by a validating > > parser and a <!DOCTYPE definition. > > Ack! No! Please don't hardcode a one-to-one relationship between > schemas and namespaces. > > A single schema could define structures using elements and attributes > from more than one namespace, and elements and attributes from a > single namespace can be used and structured in many different ways. > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 15 15:16:52 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:42 2004 Subject: XML media types revisited References: <3.0.1.32.19990114195819.0091bd10@mail.accessone.com> Message-ID: <369F5BA2.36856834@locke.ccil.org> David LeBlanc wrote: > I don't agree with the idea that XML is a replacement for ASCII. Figuratively, not literally. The idea is that XML is meant to become the (near)ubiquitous way of expressing structured text or data, just as plain ASCII is the (near)ubiquitous way of expressing plain text or data. (But not forever: Unicode plain text rulz!) > [T]here are no technical reasons that I > know of why XML could not be represtented in EBCDIC or ASCII (aside from > standard compliance). Indeed, it is perfectly standards-compliant to have EBCDIC XML documents, as long as they begin with the characters "<?xml" (expressed in EBCDIC) and mention a proper code-page in the character set declaration. EBCDIC code pages have 3 names each: "IBMnnn", "cpnnn", and "ebcdic-cp-xx" where nnn is a CP number and xx is a country code. Whether any XML parsers interpret these names is a question. > Neither does "application" imply C, C++, Java or whatever else. In fact, I > wonder if "application/xml" is appropriate at all - does "application/RTF" > or "application/TROFF" make sense? Yes, very much so. Troff source can and should be specified as "application/x-troff" and could be registered as "application/troff" if anyone wanted to bother. But "text/x-troff" would be reasonable too, since much troff source can reasonably read as plain text. RTF source is usually too *busy* to be read as plain text, though. Anent the "application" top-level type, RFC 2046 saith: # [...T]ypically either uninterpreted binary data or information to be # processed by an application. [... E]xpected uses for "application" # include spreadsheets, data for mail-based scheduling systems, and # languages for "active" (computational) messaging, and word # processing formats that are not directly readable. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rhavaldar at str.com Sun Jan 17 05:52:51 1999 From: rhavaldar at str.com (Raghunandan Havaldar) Date: Mon Jun 7 17:07:42 2004 Subject: specs for Coins 3.1 ? Message-ID: <000101be415c$e15e4180$3c2996d0@rhavaldar> Hello, Am new to Coins. Downloaded the Coins 3.1 version. Apart from one document on the website (jxml.com), there does not seem any other documentation or information regarding - specs, setup, usage of examples etc. Are there any pointers regarding version 3.1 ?. I know there is one on 4.0. Thanks Raghu rhavaldar@str.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Sun Jan 17 07:53:18 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:42 2004 Subject: DTD vs DCD vs Schema Message-ID: <3.0.1.32.19990116214256.012314a0@mail.accessone.com> Hi; Are these going to be complimentary or is one of them going to supplement eiither or both of the others? Sincerely, Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Jan 17 08:01:26 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:07:42 2004 Subject: XML - NG Message-ID: <007001be41ef$d57f46f0$08f96d8c@NT.JELLIFFE.COM.AU> From: Tim Bray <tbray@textuality.com> >We have CDATA attribute content. CDATA element content is B.A.D. (broken >as designed) in SGML because it terminates with the first </ -Tim Too strong. CDATA elements per se are not BAD. I have processed many SGML documents with CDATA element types and never had any problem. They are just inappropriate for XML. If one does not have structure-using tools (e.g.you are using sed rather than OmniMark) then CDATA elements can sometimes cause a complication. On the other hand, sometimes CDATA elements simplify matters: for example, if you have a document of simple database fields, one per line: for non CDATA elements you have to have more code, to handle possible entity references. The Desparate Perl Hacker (DPH) is certainly a good class of user for XML to support. But being a DPH in a commercial company is probably a sign of management or technical incompetence somewhere. Using the right tools for the job is important in any trade. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Jan 17 08:14:40 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:07:42 2004 Subject: XSchema suggestion/wish: Parameter entity (or SGML DTD inclusions/exclusions?) "equivalent" Message-ID: <008d01be41f1$aabc6630$08f96d8c@NT.JELLIFFE.COM.AU> From: Jarle Stabell <jarle.stabell@dokpro.uio.no> >Advanced schema languages would be useful for DTD/schema designers even >without any XML parser knowing that particular schema language, because >authoring tools could automatically translate the advanced schemas into the >simpler ones. In effect, the people unhappy with DTDs want "parameter element types" rather than "parameter entities". The parameter entity mechanism is based on treating the DTD as text, and constructing the document that contains the declarations by referencing, including or ignoring smaller text entities. As TEI's "Chicago Pizza" model (pick the base elements and then add topping elements) shows, highly sophisticated DTDs can be successfully made using textual inclusion. (In fact, just as even C++ programs still sometimes still use cpp features when the programs are large or complex or multi-targeted, I doubt the practical wisdom of excluding textual inclusion entirely from future schema systems.) Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Sun Jan 17 09:44:29 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:07:42 2004 Subject: XML Component API Message-ID: <020301be41fd$65bbf260$3902a8c0@oren.capella.co.il> I raised the question of a standard API to XSL processors in the XSL mailing list. This question has quickly touched on general issues of how to combine XML processing modules, since there are two incompatible ways to pass XML data - as an in-memory DOM tree or as "parsing" events. I came up with the attached scheme. It allows writing all sorts of XML related components, using either of the APIs, and still easily combine them together to obtain complex XML processing goals, with little or no loss of efficiency. I understand that a new version of SAX interface is being considered, making it more like an implementation of the visitor pattern for DOM trees then a simple parser interface. This is a chance to add something along the attached API directly to the SAX interface, if that's the right place for it. Share & Enjoy, Oren Ben-Kiki -------------- next part -------------- /** * An object which wishes to receive XML from another should implement this * interface. At least one of the methods should return a non null value. */ interface XMLConsumer { /** * Return a SAX DocumentHandler if the object is interested in "parsing" * events (or, you can view this as applying the "Visitor" pattern * to an in-memory DOM tree). Returns null if the consumer won't accept * parsing events. */ public DocumentHandler asSAXHandler(); /** * Return a DOM Document handler is the object is interested in an * in-memory DOM tree. The consumer is free to modify this tree at will. * Returns null if the consumer won't accept a DOM tree. */ public DOMDocumentHandler asDOMHandler(); }; /** * Accept a DOM tree from an XML producer. This is the equivalent of the * SAX DocumentHandler class. :TBD: Should this be in the DOM API spec? Is * there something there already which satisfies this need? */ interface DOMDocumentHandler { /** * Receive the DOM tree. The handler may do anything it wants with it. * :TBD: Ought there be a way by which the handler would indicate that * it is not going to change the tree? * * @exception SAXException If there is some error handling the DOM * tree. :TBD: Should this be a DOMException? * If so, then everywhere below that is * written "SAXException", a "DOMException" * should be added. */ public void receiveDocument(Document document) throws SAXException; }; /** * An object which generates XML. This interface is not used directly; * it is shared by XMLFilter and XMLSource. */ interface XMLProducer { /** * Set the consumer to which the XML data would be sent. * The producer asks the consumer for a handler which fits the type the * producer can supply. Some producers might know how to provide their data * in multiple formats. Typically producing one format is more efficient * then the other, so the producer should ask the consumer to handle this * format first and only then ask for the a handler to the second one. * * @param consumer The consumer to send the XML to. * @exception SAXException If the consumer can't receive the data * format the producer creates. */ public void setConsumer(XMLConsumer consumer) throws SAXException; }; /** * An object which accepts XML from a producer and passes it on to a * consumer. Along the way, it might do arbitrary processing. One of the * more useful filters is one which can accept any form of XML data from * the producer and convert it to the form required by the consumer. */ interface XMLFilter implements XMLProducer, XMLConsumer { }; /** * An object which accepts XML from one producer and sends it to multiple * consumers. A useful one is a multiplexer which clones DOM trees and * gives each consumer a copy. One which simply passes the same DOM tree * to all interested consumers is also possible, but should be used with * great care. */ interface XMLMultiplexer implements XMLConsumer { /** * Add a consumer. :TBD: How to handle adding the same one twice? * * @exception SAXException If the filter can't accept this consumer. */ public void addConsumer(XMLConsumer consumer) throws SAXException; /** * Remove a consumer. :TBD: How to handle removing a nonexistant one. * Throw a SAXException? Simply ignore the operation? */ public void removeConsumer(XMLConsumer consumer); }; /** * An XML source - one which generates the XML internally (or from another * format). */ interface XMLSource implements XMLProducer { /** * Sends the XML data to the consumer. If there is a processing * chain (via filters or multiplexers) then this triggers the whole * chain. * * @exception SAXException If the consumer can't handle the format * the producer can supply, there is a problem * generating the XML, or the consumer has * thrown an exception while handling it. */ public void sendXml() throws SAXException; }; /** * The SAX parser interface should be modified to implement XMLSource. */ interface XMLParser implements XMLSource { // A slightly modified version of the current interface. }; /** * An XSL processor is "loaded" with an XSL stylesheet and from then on * serves as an XSLFilter - it takes an input XML document and converts * it into another. */ interface XSLProcessor implements XMLFilter { /** * Obtain the consumer to load with the XSL stylesheet XML representation. * This must be called before the filter is asked to process any XML data. */ XMLConsumer getXSLConsumer(); }; Also, some useful helper routines, controlled by system properties: XMLParser makeXMLParser(); XSLProcessor makeXSLProcessor(); XMLFilter makeXMLConverter(); // Convert from any format to another. XMLFilter makeXMLConverter(XMLConsumer consumer); // Call setConsumer as well. XMLConsumer makeXMLWriter(String encoding); XMLConsumer makeXMLWriter(); // Use UTF-8 by default. XMLMultiplexer makeXMLMultiplexer(boolean toClone); XMLMultiplexer makeXMLMultiplexer(); // Give each consumet a clone by default. So, after all this is done, may be create XSL processor, with logging of the input given to the XSL processor, by: XMLSource xmlParser = makeXMLParser(); XMLFilter xslProcessor = makeXSLProcessor(); XMLMultiplexer logger = makeXSLMultiplexer(); XMLConsumer inputWriter = makeXMLWriter(); XMLConsumer outputerWriter = makeXMLWriter(); // Initialize the parser and the writers... xslProcessor.setConsumer(outputWriter); logger.addConsumer(xslProcessor); logger.addConsumer(inputWriter); xmlParser.setConsumer(logger); xmlParser.sendXml(); This assumed that all the consumers can accept the formats the producers give them; otherwise, one would have to add instances of an appropriate converter XMLFilter class between mismatching consumers and producers. Note that the cost of such converters is zero if the consumer and producer do match, so it is a good habit to add such a converter unless it is absolutely certain that conversion is unnecessary: xslProcessor.setConsumer(makeXMLConverter(outputWriter)); logger.addConsumer(makeXMLConverter(xslProcessor)); logger.addConsumer(makeXMLConverter(inputWriter)); xmlParser.setConsumer(logger); xmlParser.sendXml(); From tyler at infinet.com Sun Jan 17 10:24:54 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:42 2004 Subject: XML Component API References: <020301be41fd$65bbf260$3902a8c0@oren.capella.co.il> Message-ID: <36A1B978.32D6D3B7@infinet.com> Oren Ben-Kiki wrote: > I raised the question of a standard API to XSL processors in the XSL mailing > list. This question has quickly touched on general issues of how to combine > XML processing modules, since there are two incompatible ways to pass XML > data - as an in-memory DOM tree or as "parsing" events. > > I came up with the attached scheme. It allows writing all sorts of XML > related components, using either of the APIs, and still easily combine them > together to obtain complex XML processing goals, with little or no loss of > efficiency. > This looks like it has a lot of different things in here which may or may not be directly applicable to an XSL Processor, nevertheless it is a good start and by the looks of things it seems that you have obviously put some time and thought into this. I am sure everyone here appreciates your comments as well as your efforts to date on the xsl-list, so please keep up the good work. On the SAX issue, SAX may or may not be updated soon. I guess a lot of this depends on David's plans (if he has any) as to whether he will donate more of his already much appreciated time to SAX, or else pass the torch to someone else. I am not so sure we should update SAX to support the latest namespaces spec so fast. I would like to see if some person or group could come up with a namespaces solution in the near future (or at least generate public debate) that generates more concensus among the XML developer community than the recent W3C recommendation "Namespaces in XML". I am not happy with "Namespaces in XML" and would prefer an alternative, even though at this point in time I don't think namespaces are all too important for the tasks people are acutally using XML for. With respect to namespaces, I think SAX should be updated on the following conditions: (1) If there is little or no interest in the developer community for using namespaces (whatever mechanism there is) to begin with, then SAX should not be updated with something that the great majority of the developer community deems as a de-facto useless issue. (2) If there is interest in the developer community for using namespaces, but that there is a good solid majority who believe SAX needs a namespaces alternative to "Namespaces in XML", then maybe someone here who is disappointed in "Namespaces in XML" and has a better idea could take up the lead on this issue. When and if this alternative is produced, then update SAX with this alternative (3) If there is interest in the developer community for using namespaces, and there is not as much angst over "Namespaces in XML" as a lot of people (including myself) feel there is, or else no one proposes an alternative that is better than "Namespaces in XML" then update the SAX spec to support the W3C recommendation. Lets not update SAX too hastily on this particular namepsaces issue when there appears to be little concensus on the namespaces issue among the developer community to begin with. Just because the W3C proposes something, does not mean us developers are forced to support it. Being able to say your XML Parser is "Namespaces compliant" may win marketing points among some less than knowledgeable XML developers, but the truth is unless people actually use this feature, it is nothing more than additional code bloat. Regards, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Sun Jan 17 11:46:22 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:07:42 2004 Subject: What is a namespace ... really? In-Reply-To: <199901170235.SAA05961@bolt.sonic.net> Message-ID: <3.0.6.32.19990117113858.00b10d20@gpo.iol.ie> [Terry Allen] > >So the "namespace" URI must identify a resource, which is anything >[any "thing"] that has identity. (Obviously and tautologically, >the identity of any thing is itself; the thing makes its own identity >simply by existing.) You say that it doesn't have to point to anything >[any "thing"], and that it's "just a name". So is the resource >["thing"] identified by a "namespace" URI itself? or is it the name >of itself (maybe Kant could explain)? How does something that is only >itself or the name of itself encompass anything else? > >Me, myself, I think this is a bogus use of URIs. What you are >really using is DNS, and you don't need to use fake URIs to do so; >cf. the IOTP spec. > IMHO, namespaces are predicated on the belief that the homesteading of DNS space is accompanied by a willingless amongst the homesteaders to respect each others property rights without resorting to a DNS arbitrator. (With apologies to Eric Raymond:-) e.g. I can freely name my Java packages com.amazon.* on my hard disk but would I? No. "amazon.com" is owned by someone else and I need to respect that ownership to be a responsible, law abiding net citizen. Amazon might announce that http://www.amazon.com/namespaces/SpecialOffers it the URI of an E-commerce namespace. They might document it on http://www.amazon.com/docs/namespaces. The latter physically exists, the former exists in name only. The scheme only works because we all agree that the set of names rooted at amazon.com is the property of amazon.com. In order to use a namespace its usage must be written somewhere though! I understand that there is no requirement for it to be at the end of the URI itself but presumably doing so will be considered good netiquette? <Sean uri="http://www.digitome.com/sean.html"/> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sun Jan 17 17:16:43 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:43 2004 Subject: XML - NG Message-ID: <3.0.32.19990117091223.00bfa5a0@pop.intergate.bc.ca> At 07:03 PM 1/17/99 +1100, Rick Jelliffe wrote: >The Desparate Perl Hacker (DPH) is certainly a good class of user for >XML to support. But being a DPH in a commercial company is probably a >sign of management or technical incompetence somewhere. I couldn't disagree with the that any more. One of the major wins in using XML is that you can put existing data to work for new, unforeseen, purposes. One good way to achieve this is with the use of script-ware level tools. >Using the right >tools for the job is important in any trade. Scripting languages, such as perl, python, Omnimark, Frontier, etc, are often the right tools for the job. I assume you're aware that pretty well every one of these now has a real XML processor and really handles XML syntax correctly. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sun Jan 17 17:16:51 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:43 2004 Subject: DTD vs DCD vs Schema Message-ID: <3.0.32.19990117090933.00bf0d70@pop.intergate.bc.ca> At 09:42 PM 1/16/99 -0800, David LeBlanc wrote: >Are these going to be complimentary or is one of them going to supplement >eiither or both of the others? At the moment, only DTD has any official standing. All those other things are submissions and proposals; the W3C has a process under way to sort them all out and propose a next-gen schema facility. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Sun Jan 17 17:44:29 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:43 2004 Subject: XML Component API Message-ID: <005101be4240$80c532e0$c9a8a8c0@thing2> Oren, This looks like you are treating SAX events and documents something like Java bean events, and I wonder if it would be appropriate to conform to a greater degree to the event method signature patterns. I would also like to refer you to MDSAX, which you may find somewhat complimentary. (It also provides an open-archecture for supporting alternatives to things like namespaces, if that is the issue of the moment.) http://www.jxml.com/mdsax/mdsaxintro.html We are now viewing the current release as just one possible implementation of a multi-document SAX-based framework. The next step will be to seperate and simplify the api, while still providing a sample implementation. It is open source software (BSD licence), but more than that, we really want to throw this effort open to the entire XML development community. Again, the work you are doing appears to be complimentary to ours, with the producer/consumer interfaces providing an api for connecting various processes, while MDSAX provides a means for defining a SAX-event process. Bill -----Original Message----- From: Oren Ben-Kiki <oren@capella.co.il> To: XML List <xml-dev@ic.ac.uk> Date: Sunday, January 17, 1999 4:46 AM Subject: XML Component API >I raised the question of a standard API to XSL processors in the XSL mailing >list. This question has quickly touched on general issues of how to combine >XML processing modules, since there are two incompatible ways to pass XML >data - as an in-memory DOM tree or as "parsing" events. > >I came up with the attached scheme. It allows writing all sorts of XML >related components, using either of the APIs, and still easily combine them >together to obtain complex XML processing goals, with little or no loss of >efficiency. > >I understand that a new version of SAX interface is being considered, making >it more like an implementation of the visitor pattern for DOM trees then a >simple parser interface. This is a chance to add something along the >attached API directly to the SAX interface, if that's the right place for >it. > >Share & Enjoy, > > Oren Ben-Kiki > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Sun Jan 17 17:53:36 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:43 2004 Subject: specs for Coins 3.1 ? Message-ID: <007601be4241$c12e5860$c9a8a8c0@thing2> http://www.jxml.com/coins/index.html A better list to post such questions might be java-xml-interest. For details, see: http://www.jxml.com/java-xml-interest/index.html Bill From: Raghunandan Havaldar <rhavaldar@str.com> To: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk> Date: Sunday, January 17, 1999 12:56 AM Subject: specs for Coins 3.1 ? >Hello, > >Am new to Coins. Downloaded the Coins 3.1 version. Apart from >one document on the website (jxml.com), there does not seem any other >documentation or information regarding - specs, setup, usage of examples >etc. > >Are there any pointers regarding version 3.1 ?. I know there is >one on 4.0. > >Thanks > >Raghu > >rhavaldar@str.com > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Sun Jan 17 19:33:27 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:43 2004 Subject: DTD vs DCD vs Schema In-Reply-To: <3.0.32.19990117090933.00bf0d70@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990117113616.01298d60@mail.accessone.com> Hi Tim; Thank you for your response. I understand that only DTDs have official standing and that DCD and XSchema (and others) are only submissions/proposals to W3C. What i'm asking, is it the intent that, in the fullness of time, one of these will supplant DTDs as a document type notation? Sincerely, Dave LeBlanc At 09:16 AM 1/17/99 -0800, Tim Bray wrote: >At 09:42 PM 1/16/99 -0800, David LeBlanc wrote: >>Are these going to be complimentary or is one of them going to supplement >>eiither or both of the others? > >At the moment, only DTD has any official standing. All those other >things are submissions and proposals; the W3C has a process under way >to sort them all out and propose a next-gen schema facility. -Tim > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Jan 17 19:44:20 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:43 2004 Subject: DTD vs DCD vs Schema In-Reply-To: <3.0.1.32.19990117113616.01298d60@mail.accessone.com> References: <3.0.32.19990117090933.00bf0d70@pop.intergate.bc.ca> Message-ID: <199901171944.OAA08748@hesketh.net> At 11:36 AM 1/17/99 -0800, David LeBlanc wrote: >What i'm asking, is it >the intent that, in the fullness of time, one of these will supplant DTDs >as a document type notation? I'm afraid it depends on who you ask. There are plenty of folks out there who know and like DTDs. Though I haven't heard anything them muttering 'you can take my DTD when you pry it from my cold dead hands', I'm sure there are a few folks who feel that way, for SGML compatibility reasons if nothing else. On my (highly unofficial) part, I'm looking forward very much to schemas. I'd like to see the final schema spec come in a few pieces (text replacement/entities, document structures, and data types being separated cleanly), but I think XML would gain a lot from a more flexible and less document-oriented spec. As for the official intent, I'm not sure anyone will (or can) say. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Sun Jan 17 20:45:33 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:43 2004 Subject: DTD vs DCD vs Schema In-Reply-To: <199901171944.OAA08748@hesketh.net> References: <3.0.1.32.19990117113616.01298d60@mail.accessone.com> <3.0.32.19990117090933.00bf0d70@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990117154533.006fb4bc@pop.uunet.ca> At 02:46 PM 1/17/99 -0500, Simon St.Laurent wrote: >At 11:36 AM 1/17/99 -0800, David LeBlanc wrote: >>What i'm asking, is it the intent that, in the fullness of time, >>one of these will supplant DTDs as a document type notation? I am not sure that 'supplant' is necesarily the right word to use, but I think that it is fairly certain that in the near future a majority of practitioners will opt for an XML schema language over XML DTDs as a document type definition language. > >I'm afraid it depends on who you ask. There are plenty of folks out there >who know and like DTDs. Though I haven't heard anything them muttering >'you can take my DTD when you pry it from my cold dead hands', I'm sure >there are a few folks who feel that way, for SGML compatibility reasons if >nothing else. Note that the ability to distill an XML DTD from a schema has been identified as an important feature among DTD die-hards. Thus, if we can build upon DTD functionality and maintain a path back to XML DTDs, we will probably not have to pry DTDs from anyone's cold dead hands. There are, however, aspects of extant proposals that cannot be reconciled with an XML DTD -- such as "open content models" in DCD and XML-Data. Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Sun Jan 17 22:59:40 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:07:43 2004 Subject: DTD vs DCD vs Schema In-Reply-To: <199901171944.OAA08748@hesketh.net> (simonstl@simonstl.com) References: <3.0.32.19990117090933.00bf0d70@pop.intergate.bc.ca> <199901171944.OAA08748@hesketh.net> Message-ID: <199901172259.QAA03193@bruno.techno.com> > At 11:36 AM 1/17/99 -0800, David LeBlanc wrote: > What i'm asking, is it the intent that, in the fullness of time, one > of these will supplant DTDs as a document type notation? This is really two questions: (1) Will the set of semantics expressible by DTDs be changed? (This is the primary question, although it's only implicit in your question.) (2) Will the existing syntax of DTDs be replaced by another syntax? The answer two both questions is "Yes, and certainly within the next millenium." The important thing is to go forward, and to avoid going backward, with respect to the set of semantics that are expressible using DTDs. I think today the first questions to ask are, "What's the goal?", "What's the direction toward the goal?", and "How can we minimize the likelihood of having to backtrack later, when huge investments in information assets would be jeopardized?" Then we need to ask, "What are the semantics we need to represent, in order to achieve the goal or move toward the goal?" Once we've decided these basic semantic issues, the syntax issues become a lot more straightforward. Here, just for example, are some as-yet-unsupported modeling features that it might be good to support: * Subtyping of element types. * Lexical modeling of strings in attribute values and in element content. * Association of *arbitrary* semantic properties, constraints, etc. with element types and attribute values. I'm using the term "arbitrary" here as the opposite of "built into the formalism", in the way that, for example, in today's DTD formalism, content models impose certain well-defined (and not at all arbitrary) *kinds* of constraints. Maybe this is just a matter of providing a means of associating comments unambiguously with the constructs that they're about, but maybe it can be more rigorous than that. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jan 18 02:19:55 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:43 2004 Subject: What is a namespace ... really? In-Reply-To: <3.0.32.19990116194151.00bf1470@pop.intergate.bc.ca> References: <3.0.32.19990116194151.00bf1470@pop.intergate.bc.ca> Message-ID: <13986.39102.256136.383326@localhost.localdomain> Tim Bray writes: > At 06:35 PM 1/16/99 -0800, Terry Allen wrote: > >Now, RFC 2396 says (from the Abstract): > .... [a URI identifies a resource, which can be anything] > > >So the "namespace" URI must identify a resource, > > Well, gosh, but what if it doesn't? The original design clearly > is intended to support the identification of resources, but we're > using it in a different way. Let's call it splits, and say that the resource that the URI identifies is the (intangible) namespace itself. DNS alone isn't suitable, because it leaves the authority in too few hands: when I belonged to the faculty of the English department at the University of Ottawa, I maintained the department's web site at http://www.uottawa.ca/academic/arts/english/ Note that I did *not* control the top-level www.uottawa.ca, and there was no subdomain english.uottawa.ca; however, by virtue of my control over the academic/arts/english part of www.uottawa.ca, I still would have been able to define a namespace; the same applies to my http://home.sprynet.com/sprynet/dmeggins/ personal web site. I don't think that tying namespaces too closely to DNS would have made sense. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jackpark at thinkalong.com Mon Jan 18 02:26:39 1999 From: jackpark at thinkalong.com (Jack Park) Date: Mon Jun 7 17:07:43 2004 Subject: just a test Message-ID: <E1024OX-00009E-00@punch.ic.ac.uk> Had lots of isp problems. Hope this goes through. Otherwise, I've been dropped from the list and will have to resubscribe. Cheers Jack xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Jan 18 04:38:00 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:43 2004 Subject: XML - NG References: <007001be41ef$d57f46f0$08f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <36A2B6A6.7FB873F3@prescod.net> Rick Jelliffe wrote: > > From: Tim Bray <tbray@textuality.com> > > >We have CDATA attribute content. CDATA element content is B.A.D. > (broken > >as designed) in SGML because it terminates with the first </ -Tim > > Too strong. CDATA elements per se are not BAD. I have processed many > SGML documents with CDATA element types and never had any problem. > They are just inappropriate for XML. You and Tim seem to agree. Tim says: yhe CDATA element content feature is poorly designed, non-intuitive and thus not very self-describing. In other words: it is Broken As Designed. You seem to be saying that they can still be useful. I can accept that, though I'd never use one myself. So the union of your points of view is that CDATA element types are B.A.D. but occasionally useful. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Jan 18 04:38:06 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:43 2004 Subject: XSchema suggestion/wish: Parameter entity (or SGML DTD inclusions/exclusions?) "equivalent" References: <008d01be41f1$aabc6630$08f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <36A2B793.2E5E9B11@prescod.net> Rick Jelliffe wrote: > > (In fact, just as even C++ programs still sometimes still use > cpp features when the programs are large or complex or multi-targeted, I > doubt the practical wisdom of excluding textual inclusion entirely from > future schema systems.) This analogy is not a good one. C++ is absolutely brutal to parse so making tools that extend C++ would be next to impossible without cpp. Java, on the other hand, is relatively easy to parse so there are several Java extensions that add to the Java syntax and "compile to Java." XML is even easier to parse so building complex systems based on the element structure is even easier. For instance I have Python tools that look for the HyTime VALUEREF attribute in an XML or SGML grove and go out and fetch a document, extract a portion of it and include it structurally in a grove. That's quite easy once you have the parse tree, and it completely replaces the need for external general text entities. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Mon Jan 18 11:10:38 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:43 2004 Subject: XML media types revisited Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136A4F@eukbant101.ericsson.se> > -----Original Message----- > From: Simon St.Laurent [SMTP:simonstl@simonstl.com] > > Of course plain text will still survive; I'm hardly proposing abolishing > text or application as top-level types. I'm just saying that XML is a > top-level type itself. > I've been thinking about this, and I think it's wrong. In a previous life I programmed on the Amiga. They had a hunked file format called IFF that was similar in some ways to XML, it allowed you to store structured data in (binary) files, and had many applications: iff/ilbm - the standard bitmap graphic format iff/ftext - an rtf-like standard iff/dr2d - a 2d vector graphic format etc. Now we wouldn't have considered this as a top level mime type, just because you used the same parser code to get at the data, because the data represents _completely_ different things. So personally I think we should just have: text/docbook image/vml application/x-resume (I'm working on a resume DTD if anyone's interested) etc. Just my .02 Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ R+++ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Jan 18 11:39:11 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:43 2004 Subject: What is a namespace ... really? References: <3.0.32.19990116194151.00bf1470@pop.intergate.bc.ca> <13986.39102.256136.383326@localhost.localdomain> Message-ID: <36A31E30.FCBD0A1F@mecomnet.de> it's simple - if one allows it to be. the thing named is the collection of names. the syntax for the names for these collections of names is that which is permitted for uri's. of all things about namespaces in xml, this is one aspect which obviates interpretation and permits no prevarication: that's exactly and all they wrote. david@megginson.com wrote: > > Tim Bray writes: > > > At 06:35 PM 1/16/99 -0800, Terry Allen wrote: > > >Now, RFC 2396 says (from the Abstract): > > .... [a URI identifies a resource, which can be anything] > > > > >So the "namespace" URI must identify a resource, > > > > Well, gosh, but what if it doesn't? The original design clearly > > is intended to support the identification of resources, but we're > > using it in a different way. > > Let's call it splits, and say that the resource that the URI > identifies is the (intangible) namespace itself. > nb. while it's not static, it's also not intangible. any given ns-conformant processor must have a quite concrete model of what a given namespace is at every point in time. (neglecting the "null" namespace, for the moment.) since the uri "names" a namespace only once an attribute-binding has appeared, its only meaning is exactly that which the processor models. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jan 18 11:53:47 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:43 2004 Subject: What is a namespace ... really? In-Reply-To: <36A31E30.FCBD0A1F@mecomnet.de> References: <3.0.32.19990116194151.00bf1470@pop.intergate.bc.ca> <13986.39102.256136.383326@localhost.localdomain> <36A31E30.FCBD0A1F@mecomnet.de> Message-ID: <13987.8052.944130.528454@localhost.localdomain> james anderson writes: > david@megginson.com wrote: > > Let's call it splits, and say that the resource that the URI > > identifies is the (intangible) namespace itself. > > nb. while it's not static, it's also not intangible. any given > ns-conformant processor must have a quite concrete model of what a > given namespace is at every point in time. (neglecting the "null" > namespace, for the moment.) since the uri "names" a namespace only > once an attribute-binding has appeared, its only meaning is exactly > that which the processor models. I was being perhaps overly literal -- I meant "intangible" in the etymological sense that transfer protocols cannot touch it. Programs have to know *about* namespaces (and may build or retrieve models of it), but they cannot retrieve a namespace itself. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Jan 18 11:55:49 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:43 2004 Subject: Universality [Re: What is a namespace ... really?] References: <13983.22028.629794.586609@localhost.localdomain> <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> <13983.28566.71365.447556@localhost.localdomain> Message-ID: <36A32239.659742A1@mecomnet.de> This question "how universal is a name" bears further discussion. In particular, I would presume that the "html" in mr megginson's note is literally a prefix term and that the reference is to the qualified and not the universal name. Where the structure and attribution vary, I would expect a distinct uri. The note leaves me uncertain as to the author's (and this list's) interpretation. This leads to the question of whether a processor / an application can expect a universal name to truly always describe the same thing. This question is distinct from how the description of the thing is located (ie whether the uri locates a schema). It does, however, figure in the question of how efficient schema processing is permitted to be. From the remarks on SGML practice (which is absent namespaces) schemas appear to have been ephemeral (ie. document-instance specific) and prohibited caching. In the presence of namespaces this practice could (and, I would argue, should) well change. The namespace-PR is very terse in this regard and I would welcome further discussion on this point. david@megginson.com wrote: > > What if I want to create a schema specifying that (for my set of > documents) an html:p element may contain a tei:foreign element, or a > docbook:Trademark element in addition to the regular HTML elements? > > What if I want to create a schema specifying that (for my set of > documents) an html:p element may *not* contain an html:font element? > > It doesn't make sense to have to create a new and different namespace > for either of these -- I'm still using the individual elements in > mostly the same way. I could, of course, use some kind of inheritance > scheme, but I don't think the world will buy anything that requires > retrieving 5 or 10 schemas from different servers just to figure out > that an html:a element is from the HTML namespace. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jan 18 13:43:07 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:44 2004 Subject: Universality [Re: What is a namespace ... really?] In-Reply-To: <36A32239.659742A1@mecomnet.de> References: <13983.22028.629794.586609@localhost.localdomain> <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> <13983.28566.71365.447556@localhost.localdomain> <36A32239.659742A1@mecomnet.de> Message-ID: <13987.14380.689674.86974@localhost.localdomain> james anderson writes: > In particular, I would presume that the "html" in mr megginson's > note is literally a prefix term and that the reference is to the > qualified and not the universal name. Not at all -- I used the "html:p" simply as shorthand for something like http://www.w3.org/Profiles/voyager-strict + p (By the way, I'd like to note that I strongly dislike the idea of having three separate HTML namespaces as proposed in the Voyager spec [1]; after all, an HTML <a> is an HTML <a> is an HTML <a>, whether you're using the loose, strict, or frameset version of HTML). > This leads to the question of whether a processor / an application > can expect a universal name to truly always describe the same > thing. This question is distinct from how the description of the > thing is located (ie whether the uri locates a schema). To the same extent, I think, that a Java program can expect org.xml.sax.DocumentHandler to truly always describe the same class (i.e. not perfectly, but close enough for jazz). All the best, David [1] http://www.w3.org/TR/WD-html-in-xml/ -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Mon Jan 18 16:27:37 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:44 2004 Subject: XML Component API Message-ID: <93CB64052F94D211BC5D0010A80013310EB27C@WWMESS3> > From: Oren Ben-Kiki [mailto:oren@capella.co.il] > > I raised the question of a standard API to XSL processors in > the XSL mailing > list. This question has quickly touched on general issues of > how to combine > XML processing modules, since there are two incompatible ways > to pass XML > data - as an in-memory DOM tree or as "parsing" events. > SAXON (http://home.iclweb.com/icl2/mhkay/saxon.html) provides a higher-level API that can be used to process XML documents on top of either SAX or DOM. It provides a useful model where most of your processing is sequential but you might occasionally (or in the future) want to navigate from a node that you reached serially, e.g. to follow an IDREF. I've recently been trying to implement an XSL subset using SAXON and have realised that the XSL processing model requires the document to be built in memory, even though 90% of useful applications don't. For an XSL API, therefore, I think you can forget any idea of an event-based approach. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rob at robco-inc.com Mon Jan 18 16:51:50 1999 From: rob at robco-inc.com (Rob Williams) Date: Mon Jun 7 17:07:44 2004 Subject: Template System Using XML Message-ID: <773251A595CFD111B8F800A0C998C55102D1AF@RIS3> I'm working on a project right now where we are converting an e-commerce application, attempting to do it in Java using servlets. What we want to do is develop a means of using templates for the product pages and the pages where products of a category are shown together. To do this, I was thinking about just allowing designers to mock up a product page for a particular store and then we could embed tags in it around the key elements. When that was done we could import the template and a program could parse it and check it for being valid. I'd love to use XML instead. There are already design tools that support XML (Dreamweaver, XMetal). If I have a tool like this then the designers will be producing a file I can immediately read. Question is how should that impact my presentation templates? Should I have the process of streaming HTML to the client involve XML directly or should I just create some HTML and do simple substitutions for our attributes and then stream it to the browser? Rob Williams RobCo Incorporated xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From moor0361 at tc.umn.edu Mon Jan 18 16:53:46 1999 From: moor0361 at tc.umn.edu (Kimberly S Moorman) Date: Mon Jun 7 17:07:44 2004 Subject: Second Call for Articles - Crossroads Magazine Message-ID: <Pine.SOL.4.05.9901181051330.13993-100000@garnet.tc.umn.edu> Call For Articles Crossroads, the Association for Computing Machinery Student Magazine Markup Languages (Winter 1999) DUE DATE: April 15, 1999 SUBMISSION ADDRESS: xrds-submit@acm.org INFORMATION: crossroads@acm.org http://www.acm.org/crossroads/ SPECIAL NOTE: If you are interested in being a Student Guest Editor for this issue, please contact us at crossroads@acm.org or fill out the online application for student guest editors. The Crossroads editorial staff invites authors to submit articles dealing with topics drawn from several areas pertaining to Markup Languages. The following partial list of topics is provided to give prospective authors ideas for articles and is by no means exhaustive; other relevant topics will be considered. History, future, and comparisons of markup languages like -Hypertext Markup Language (HTML), -Standard Generalized Markup Language (SGML), -Extensible Markup Language (XML), -Java Speech Markup Language (JSML), -Synchronized Multimedia Integration Language (SMIL), -Handheld Device Markup Language (HDML), -etc. Articles should include a basic description of the kinds of problems being worked on, the state of the art of research, the state of the art of commercial applications, open problems, or future research/commercial development trends. Interviews with researchers; reviews of related books, software, videos, or conferences; and opinion columns on related issues are also welcome. We especially encourage both undergraduate and graduate students to submit articles. However, articles written or coauthored by professionals will also be considered. Crossroads articles should be written for a broad audience. They should be easily understandable by someone who has had only the most basic computer science instruction, and yet still be interesting to the advanced computer enthusiast. Articles longer than 6000 words will generally not be considered for publication. Feature articles should be between 1500 and 6000 words; reviews should be between 800 and 2000 words; and opinion columns should be between 800 and 3000 words. Articles should be written in a magazine style rather than a research paper style. In consideration of our diverse readership, authors should try to use language that is inclusive of people regardless of their gender, race, religion, nationality, or field of study. Additional writing guidelines and submission information are available online at the Crossroads web site http://www.acm.org/crossroads/. Crossroads is published both online and in print. We have a print circulation of about 13,000. All back issues are available for free on our website. Authors that have an article printed in Crossroads can receive complementary copies of the issue they were published in. All submissions should be formatted in HTML or plain text format and emailed to xrds-submit@acm.org. Please include your submission in the body of your message: DO NOT include it as an attachment. Submissions are due April 15, 1999. They will be reviewed shortly thereafter and authors of accepted submissions will be notified within two to three weeks of the deadline. Prospective authors are invited to send email to the editors of Crossroads crossroads@acm.org indicating their intention to submit an article. In this way we can keep everyone informed of any changes in deadlines or formats and make sure we have a good variety of articles. General questions should also be sent to the Crossroads editors. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Jan 18 17:57:26 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:44 2004 Subject: Universality [Re: What is a namespace ... really?] References: <13983.22028.629794.586609@localhost.localdomain> <002601be40a0$df605510$d3228018@jabr.ne.mediaone.net> <13983.28566.71365.447556@localhost.localdomain> <36A32239.659742A1@mecomnet.de> <13987.14380.689674.86974@localhost.localdomain> Message-ID: <36A376E2.4320FF5F@mecomnet.de> ? Where the original note says: > What if I want to create a schema specifying that (for my set of > documents) an html:p element may contain a tei:foreign element, or a > docbook:Trademark element in addition to the regular HTML elements? > > What if I want to create a schema specifying that (for my set of > documents) an html:p element may *not* contain an html:font element? > > It doesn't make sense to have to create a new and different namespace > for either of these -- I'm still using the individual elements in > mostly the same way. is the reader to understand that both "peculiarities" would hold at once? hold "universally" in a given processing environment? that is, it's not a matter of wishing to present two documents, each with with a different specification for <html>:p . david@megginson.com wrote: > > james anderson writes: > > > In particular, I would presume that the "html" in mr megginson's > > note is literally a prefix term and that the reference is to the > > qualified and not the universal name. > > Not at all -- I used the "html:p" simply as shorthand for something > like > > http://www.w3.org/Profiles/voyager-strict + p > > (By the way, I'd like to note that I strongly dislike the idea of > having three separate HTML namespaces as proposed in the Voyager spec > [1]; after all, an HTML <a> is an HTML <a> is an HTML <a>, whether > you're using the loose, strict, or frameset version of HTML). > But, ... as soon as the content model changes - as would appear to be the case from the variations, for example, in the respective %block entities, then the respective schemas describe respective elements which do not meet the class/type conformity requirement set out below. The distinct namespaces thus seem quit appropriate here. > > > This leads to the question of whether a processor / an application > > can expect a universal name to truly always describe the same > > thing. This question is distinct from how the description of the > > thing is located (ie whether the uri locates a schema). > > To the same extent, I think, that a Java program can expect > org.xml.sax.DocumentHandler to truly always describe the same class > (i.e. not perfectly, but close enough for jazz). xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Mon Jan 18 17:59:33 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:44 2004 Subject: Template System Using XML Message-ID: <93CB64052F94D211BC5D0010A80013310EB27F@WWMESS3> > -----Original Message----- > From: Rob Williams [mailto:rob@robco-inc.com] > I'm working on a project right now where we are converting an e-commerce > application, attempting to do it in Java using servlets. What > we want to do is develop a means of using templates for the product pages > and the pages... > Question is how should that impact my presentation templates? Should I have the > process of streaming HTML to the client involve XML directly > or should I just create some HTML and do simple substitutions for our > attributes and then stream it to the browser? > I would definitely do things server-side for the time being unless you are in control of the browser environment for all your users. It will save you a lot of hassle. I've used Java servlets (with my SAXON library) very successfully. As for a templating mechanism, I don't know the answer. Most of the ways of producing HTML from XML are data-driven rather than display-driven, i.e. you say "do XYZ to display this data" rather than "at this place in the output page, put data XYZ". There's a shortage of tools that are really simple for non-programmers to use. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cerium at ibm.net Mon Jan 18 18:55:25 1999 From: cerium at ibm.net (John Hicks) Date: Mon Jun 7 17:07:44 2004 Subject: Template System Using XML In-Reply-To: <93CB64052F94D211BC5D0010A80013310EB27F@WWMESS3> Message-ID: <001c01be432c$ba3fadb0$01010101@c31cj> Hi Michael: You wrote: > As for a templating mechanism, I don't know the answer. Most of > the ways of producing HTML from XML are data-driven rather than > display-driven, i.e. you say "do XYZ to display this data" > rather than "at this place in the output page, put data XYZ". > There's a shortage of tools that are really simple for > non-programmers to use. We have used XMLServlet for a similar purpose on several large database websites. XMLServlet derives from our own experience building those sites. It reads XML and matching database tables and combines them into live HTML for delivery to a browser. It doesn't require XML at the browser, or on the client side. XMLServlet can talk to any browser. As you specified, XMLServlet keeps database logic and webpage layout separate. We found that other tools today mingle and entangle the two for most of the duration of a long project. Ideally, your database logic and your page design don't cross until runtime, and don't cross anywhere except in the XML. Database differences and webpage differences show up in the XML, not in the servlet. For new databases and new interfaces, you adapt the XML, not the servlet. Edit, not compile. A great many members of your development team who will never write a Java servlet can "program" XMLServlet with XML. You could also have a look at our article in JRun Magazine, January (http://jrunmag.com). Or contact me if I can help. John Hicks Cerium Component Software Build Your Database Website with Our XML Team or Tools XML Outline | XML DB | XML Servlet 212-662-3982 | 888-742-8989 http://ceriumworks.com > > Mike Kay > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Mon Jan 18 20:01:46 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:07:44 2004 Subject: XML Component API Message-ID: <00af01be431c$cca65270$3902a8c0@oren.capella.co.il> Michael.Kay@icl.com wrote: >> From: Oren Ben-Kiki [mailto:oren@capella.co.il] >> I raised the question of a standard API to XSL processors in >> the XSL mailing >> list. This question has quickly touched on general issues of >> how to combine >> XML processing modules, since there are two incompatible ways >> to pass XML >> data - as an in-memory DOM tree or as "parsing" events. > >SAXON (http://home.iclweb.com/icl2/mhkay/saxon.html) provides a higher-level >API that can be used to process XML documents on top of either SAX or DOM. >It provides a useful model where most of your processing is sequential but >you might occasionally (or in the future) want to navigate from a node that >you reached serially, e.g. to follow an IDREF. The SAXON framework seems well suited for doing XSL-like transformations, but doesn't solve the problem of combining different XML processing components into a single computation - at least, it doesn't seem to have have any advantage over the SAX interfaces in this very specific regard. SAXON does make one wonder what would have become of XSL if it was designed as a procedural instead of declerative language... Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Mon Jan 18 23:41:50 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:44 2004 Subject: XML Component API References: <93CB64052F94D211BC5D0010A80013310EB27C@WWMESS3> Message-ID: <36A3C5E7.B513EFE6@infinet.com> Michael.Kay@icl.com wrote: > > From: Oren Ben-Kiki [mailto:oren@capella.co.il] > > > > I raised the question of a standard API to XSL processors in > > the XSL mailing > > list. This question has quickly touched on general issues of > > how to combine > > XML processing modules, since there are two incompatible ways > > to pass XML > > data - as an in-memory DOM tree or as "parsing" events. > > > > SAXON (http://home.iclweb.com/icl2/mhkay/saxon.html) provides a higher-level > API that can be used to process XML documents on top of either SAX or DOM. > It provides a useful model where most of your processing is sequential but > you might occasionally (or in the future) want to navigate from a node that > you reached serially, e.g. to follow an IDREF. > > I've recently been trying to implement an XSL subset using SAXON and have > realised that the XSL processing model requires the document to be built in > memory, even though 90% of useful applications don't. For an XSL API, > therefore, I think you can forget any idea of an event-based approach. > > Mike Kay That has not been my experience. I have not had any problem with spitting out processed XSL Output to SAX events. Things could change, but for now I have not found any reason why you can't use DocumentHandler as an interface for delegating processing of XSL output. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Tue Jan 19 00:02:49 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:07:44 2004 Subject: Naming and reference Message-ID: <000501be433f$1bed74e0$bda8b4d1@yak.ptld.uswest.net> I am hoping that someone more knowledgeable than I am might be able to answer this question: Is there a convenient way to identify a document by name? For transient documents, it occurs to me that it might be very difficult to maintain an audit trail of documents without using application and domain specific tools. For e-commerce applications, this could be a serious shortcoming. It seems to me that signing and encryption would necessarily be involved in this scenario. As a document passes between systems a->b->c->d, more than likely systems b and c will have little interest in the contents of the document. However, it seems very likely that they would want to log a unique name for the document (perhaps with its credentials) in order to cross reference it in their system with some kind of annotation. This is important if only to preserve the integrity of the contents of the document. Presumably, we would like to know that the document at point A is the same document as the one arriving at point d. But if the only way we can refer to documents is through a URL, I do not see how this will be possible since the URL is a reference, not a name. It seems to me that this will be absolutely critical for XML in EC applications. Any suggestions on where to look? Rob Schoening xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tallen at sonic.net Tue Jan 19 00:33:49 1999 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 17:07:44 2004 Subject: re Naming and reference Message-ID: <199901190032.QAA23474@bolt.sonic.net> Rob Schoening wrote: | I am hoping that someone more knowledgeable than I am might be able to | answer this question: | | Is there a convenient way to identify a document by name? For transient | documents, it occurs to me that it might be very difficult to maintain an | audit trail of documents without using application and domain specific | tools. For e-commerce applications, this could be a serious shortcoming. | It seems to me that signing and encryption would necessarily be involved in | this scenario. | | As a document passes between systems a->b->c->d, more than likely systems b | and c will have little interest in the contents of the document. However, | it seems very likely that they would want to log a unique name for the | document (perhaps with its credentials) in order to cross reference it in | their system with some kind of annotation. This is important if only to | preserve the integrity of the contents of the document. Presumably, we | would like to know that the document at point A is the same document as the | one arriving at point d. But if the only way we can refer to documents is | through a URL, I do not see how this will be possible since the URL is a | reference, not a name. | | It seems to me that this will be absolutely critical for XML in EC | applications. Any suggestions on where to look? For CBL (see URL in my sig) I've used URNs to identify documents. In the scenario you describe, every party that may need to find the document by its URN has already received a copy of it, so the only resolution of the URN required is to look in the system's local registry of URNs and find the local identifier under which the document has been stored. YMMV. regards, Terry Allen Terry Allen Veo Systems, Inc. Business Language Designer 2440 W. El Camino Real tallen[at]sonic.net Mountain View, Calif., 94040 Common Business Library - available at http://www.veosystems.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jriedese at jnana.com Tue Jan 19 01:02:40 1999 From: jriedese at jnana.com (Joel Riedesel) Date: Mon Jun 7 17:07:45 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? Message-ID: <36A3D8FC.BD676F83@jnana.com> Would someone remind me where a page to commercially available (usable in a commercial environment - free or not) XML parsers is? Barring that, I'm really looking for an extremely fast XML parser for well-formed documents (not valid - no DTD). We're using XML for our basic API now and performance is a tad more important now. (In java.) I need to parse about 1500 characters, a dozen tags or so, about 800-1000 times a second (Sun Ultra 10). I'm currently using xml4j (1.1.9?) (IBM's) which I've hacked a bit so that I can reuse the Parser object and I'm only going about 1/3 as fast as I'd like.... of course this parser I don't think is intended to be really really fast. Thanks. (BTW, it's looking to me like XML and Java are entirely suitable for ecommerce environments. At this point I see XML as a nice open alternative to RMI for some of my work and see the possibility of better performance for certain aspects of what I'm trying to do - but that starts to stray from all of what RMI really does do which I don't appear to need for these purposes.) -- Joel Riedesel Jnana Technologies Corporation mailto:jriedese@jnana.com 303 805 8275 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Tue Jan 19 01:37:10 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:45 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? In-Reply-To: <36A3D8FC.BD676F83@jnana.com> Message-ID: <3.0.1.32.19990118173941.022fae00@mail.accessone.com> The best place to look for such information: http://www.oasis-open.org/cover/ There are many parsers there including these: James Clark has both C and Java parsers available. Freedom of use might be subject to your making your source available if you redistribute. Read his (Mozilla) license. http://www.jclark.com/xml/ Microsoft makes available an xml parser with source in Java through a technology partner Datachannel which is freely redistributable: http://www.datachannel.com/xml_resources/ IBM's Alphaworks has the source to an excellent java xml parser which is freely redistributable (read the license though!): http://www.alphaWorks.ibm.com/formula/XML James Clark's parsers are well formed parsers, Microsoft and IBM offer fully validating parsers. Hope This Helps Dave LeBlanc At 05:59 PM 1/18/99 -0700, Joel Riedesel wrote: >Would someone remind me where a page to commercially available (usable >in a commercial environment - free or not) XML parsers is? > >Barring that, I'm really looking for an extremely fast XML parser for >well-formed documents (not valid - no DTD). We're using XML for our basic >API now and performance is a tad more important now. (In java.) > >I need to parse about 1500 characters, a dozen tags or so, about 800-1000 >times a second (Sun Ultra 10). I'm currently using xml4j (1.1.9?) (IBM's) which I've hacked >a bit so that I can reuse the Parser object and I'm only going about 1/3 as >fast as I'd like.... of course this parser I don't think is intended to be >really really fast. > >Thanks. >(BTW, it's looking to me like XML and Java are entirely suitable for >ecommerce environments. At this point I see XML as a nice open alternative >to RMI for some of my work and see the possibility of better performance for >certain aspects of what I'm trying to do - but that starts to stray from all >of what RMI really does do which I don't appear to need for these purposes.) > >-- >Joel Riedesel >Jnana Technologies Corporation >mailto:jriedese@jnana.com >303 805 8275 > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Tue Jan 19 02:09:24 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:07:45 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? In-Reply-To: <36A3D8FC.BD676F83@jnana.com> Message-ID: <000101be4350$bf9a07a0$bda8b4d1@yak.ptld.uswest.net> > Would someone remind me where a page to commercially available (usable > in a commercial environment - free or not) XML parsers is? Check out the early access of Sun's XML package. It's on their Products & APIs page I believe. It's not open source, but I suspect that it will be well supported. Since Microsoft is so close to DataChannel now, I don't think that they can afford to let this market slip through the cracks...especially with M$ pushing their new XML data typing standard (can't remember the name at the moment). > (BTW, it's looking to me like XML and Java are entirely suitable for > ecommerce environments. At this point I see XML as a nice open > alternative > to RMI for some of my work and see the possibility of better > performance for > certain aspects of what I'm trying to do - but that starts to > stray from all > of what RMI really does do which I don't appear to need for these > purposes.) Personally, I think that there is some real opportunity for innovation here. If there was an XML-based spec for serialization and invocation, I think that it might be possible to implement an IIOP-ish protocol using XML. This would be really interesting, IMHO, since it would allow the document and component models to converge. CORBA, EJB, and DCOM tend to be rather heavyweight ($$$) in deployment. But if the client could be pared down so as to require little or no client-side code for certain transactional systems, things could get really interesting. For straightforward deployments, XML over HTTP (or even SMTP) could have compelling value. Imagine if you could take a DTD and build a server side component to process it. If you could apply translation to build an HTML or PDF form, the end user could be tied in to the back office without the need to develop custom software. Groupware allows this now, but if you could cut out that layer of complexity and have the browser speak directly to the middleware, without the need to write application specific code, the benefits could be tremendous. After all, groupware breaks down at the borders of organizations...at exactly the point where EC begins. Just a thought... There is an XML-RPC spec out there, but to my mind it misses the bigger picture. Might be a good stepping stone though. Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jan 19 02:32:10 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:07:45 2004 Subject: XML - NG Message-ID: <001f01be4354$1fd26ab0$39f96d8c@NT.JELLIFFE.COM.AU> From: Tim Bray <tbray@textuality.com> >At 07:03 PM 1/17/99 +1100, Rick Jelliffe wrote: >>The Desparate Perl Hacker (DPH) is certainly a good class of user for >>XML to support. But being a DPH in a commercial company is probably a >>sign of management or technical incompetence somewhere. > >I couldn't disagree with the that any more. One of the major wins in >using XML is that you can put existing data to work for new, unforeseen, >purposes. One good way to achieve this is with the use of script-ware >level tools. We are not disagreeing! I am not saying that scripting languages are bad. I said the DPH is a good class of users to support. I am merely saying that * desparation * Perl, and *hacking are not benchmarks of competence, especially in combination. For example, in Perl it is easy to write unmaintainable programs. Without management or technical discipline to enforce coding guidelines Perl encourages or enforces hacking, IMHX. >Scripting languages, such as perl, python, Omnimark, Frontier, etc, >are often the right tools for the job. Yes. I have used OmniMark for 6 years, and highly recommend it. Rick. ricko@gate.sinica.edu.tw I assume you're aware that >pretty well every one of these now has a real XML processor and >really handles XML syntax correctly. -Tim > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jan 19 02:41:19 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:07:45 2004 Subject: DTD vs DCD vs Schema Message-ID: <004401be4355$6f209500$39f96d8c@NT.JELLIFFE.COM.AU> From: Steven R. Newcomb <srn@techno.com> >The important thing is to go forward, and to avoid going backward, >with respect to the set of semantics that are expressible using DTDs. Personally, I don't think that compatability with what DTDs can model should be any constraint on a schema language, at least as far as element content models. The current content model syntax is * terse * easy to read and write * functional for a wide class of documents * standard and well-understood * part of XML * fragment-friendly (SGML's global inclusions and exclusions have been removed) I would much prefer the schema system to assume to existance of a DTD, and provide the missing parts. For example, 1) a set of data types for attributes and elements 2) use XSL patterns to assert that if one pattern is found, then another pattern must exist. The second in particular gets us out of the content-model approach and into a "partial validation" approach which is more in tune with namespaces. Rick Jelliffe ricko@gate.sinica.edu.tw xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Tue Jan 19 02:52:44 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:45 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? In-Reply-To: <000101be4350$bf9a07a0$bda8b4d1@yak.ptld.uswest.net> References: <36A3D8FC.BD676F83@jnana.com> Message-ID: <3.0.1.32.19990118183114.011912d0@mail.accessone.com> Darned if I can remember where, but I think I surfed past someone doing such. Maybe it could be called Xorba? :-) Dave LeBlanc At 06:09 PM 1/18/99 -0800, Rob Schoening wrote: <snip> >Personally, I think that there is some real opportunity for innovation here. >If there was an XML-based spec for serialization and invocation, I think >that it might be possible to implement an IIOP-ish protocol using XML. This >would be really interesting, IMHO, since it would allow the document and >component models to converge. CORBA, EJB, and DCOM tend to be rather >heavyweight ($$$) in deployment. But if the client could be pared down so >as to require little or no client-side code for certain transactional >systems, things could get really interesting. For straightforward >deployments, XML over HTTP (or even SMTP) could have compelling value. > <snip> >Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jriedese at jnana.com Tue Jan 19 03:05:39 1999 From: jriedese at jnana.com (Joel Riedesel) Date: Mon Jun 7 17:07:45 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? References: <36A3D8FC.BD676F83@jnana.com> <3.0.1.32.19990118183114.011912d0@mail.accessone.com> Message-ID: <36A3F5CC.AAD94480@jnana.com> Are you referring to the Coins work? (That might be a bit more than what you're thinking of as that's more like serialization of Java objects into XML - if I recall correctly.) This would actually be quite easy to do right now. In the server environment that I work in, we have our web server embedded in our Java server environment. That enables us to deploy our server with servlets without requiring non-technical people to figure out servlets, web servers, etc. We could continue down that road and use HTTP and XML for all of our communication quite easily at this point. However, for some other reasons I'm not ready to go to that step (almost entirely performance related... our architecture has plug in processing code that needs to operate very fast...). (However, to back-peddle just a little, we'll probably offer multiple APIs for some of our architecture, that allows just this capability.) But, the point being that this is doable today (in my opinion) and without a lot of effort. Throwing XSL into the mix, and now you've really got an open modular system for the Web. David LeBlanc wrote: > > Darned if I can remember where, but I think I surfed past someone doing such. > > Maybe it could be called Xorba? :-) > > Dave LeBlanc > > At 06:09 PM 1/18/99 -0800, Rob Schoening wrote: > <snip> > >Personally, I think that there is some real opportunity for innovation here. > >If there was an XML-based spec for serialization and invocation, I think > >that it might be possible to implement an IIOP-ish protocol using XML. This > >would be really interesting, IMHO, since it would allow the document and > >component models to converge. CORBA, EJB, and DCOM tend to be rather > >heavyweight ($$$) in deployment. But if the client could be pared down so > >as to require little or no client-side code for certain transactional > >systems, things could get really interesting. For straightforward > >deployments, XML over HTTP (or even SMTP) could have compelling value. > -- Joel Riedesel Jnana Technologies Corporation mailto:jriedese@jnana.com 303 805 8275 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Tue Jan 19 03:23:06 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:45 2004 Subject: DTD vs DCD vs Schema In-Reply-To: <004401be4355$6f209500$39f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <3.0.1.32.19990118191002.0097e310@mail.accessone.com> After perusing comp.text.xml, I was reminded that xml is a proper subset of sgml and thus whence came dtds etc. I guess it would be hard to do away entirely with dtds and retain that relationship. My question was originally prompted by a desire to make provision in (ok, yet another) xml parser (in C++) i'm starting work on for future developments wrt dcd/schema etc. Maybe I can make the dtd parser pluggable. Seems to me that the below idea of something complementing dtds rather then replacing them is a good one. Sincerely, Dave LeBlanc At 01:42 PM 1/19/99 +1100, Rick Jelliffe wrote: > >From: Steven R. Newcomb <srn@techno.com> > >>The important thing is to go forward, and to avoid going backward, >>with respect to the set of semantics that are expressible using DTDs. > >Personally, I don't think that compatability with what DTDs can model >should be any constraint on a schema language, at least as far as >element >content models. > >The current content model syntax is > * terse > * easy to read and write > * functional for a wide class of documents > * standard and well-understood > * part of XML > * fragment-friendly (SGML's global inclusions and exclusions >have been removed) > >I would much prefer the schema system to assume to existance of a >DTD, and provide the missing parts. For example, > 1) a set of data types for attributes and elements > 2) use XSL patterns to assert that if one pattern is found, >then another pattern must exist. > >The second in particular gets us out of the content-model approach >and into a "partial validation" approach which is more in tune with >namespaces. > >Rick Jelliffe >ricko@gate.sinica.edu.tw xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Tue Jan 19 03:32:54 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:07:45 2004 Subject: re Naming and reference In-Reply-To: <199901190032.QAA23474@bolt.sonic.net> Message-ID: <000201be435c$68aca630$bda8b4d1@yak.ptld.uswest.net> Thanks for the info. Any thoughts as to the best way to embed a message digest and/or signature into a document without disrupting the DTD? Rob > For CBL (see URL in my sig) I've used URNs to identify documents. > In the scenario you describe, every party that may need to find the > document by its URN has already received a copy of it, so the only > resolution of the URN required is to look in the system's local > registry of URNs and find the local identifier under which the > document has been stored. > > YMMV. > > regards, Terry Allen > > > > Terry Allen Veo Systems, Inc. > Business Language Designer 2440 W. El Camino Real > tallen[at]sonic.net Mountain View, Calif., 94040 > Common Business Library - available at http://www.veosystems.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shinichiro.hamada at toshiba.co.jp Tue Jan 19 07:38:52 1999 From: shinichiro.hamada at toshiba.co.jp (=?ISO-8859-1?B?lWyTYyCQTIjqmFk=?=) Date: Mon Jun 7 17:07:46 2004 Subject: How 2 output tags att with XSL Message-ID: <004f01be437e$6ced8bc0$db247385@hoge.ssel.toshiba.co.jp> Mr.Ken, thank you for your reply. >>BTW, you seemed to use "call msxsl" dos command for debugging xsl behavior. >>I don't know it. I want to debug xsl too, i don't have that command. Where >>can i get it? >> >>>T:\FTEMP>call msxsl test.xml test.msxsl test.htm >>>T:\FTEMP>type test.htm > >There was a 5-line script posted on the XSL list as follows: > > var data = WScript.CreateObject("Microsoft.XMLDOM"); > var style = WScript.CreateObject("Microsoft.XMLDOM"); > data.load(WScript.Arguments(0)); > style.load(WScript.Arguments(1)); > WScript.Echo( data.transformNode( style.documentElement )); > >There is a command line environment for scripting called the Windows >Scripting Host available at: > > http://www.microsoft.com/management/wsh.htm I see! Very convenient! This help me very much. Thank you. And Mr.Glassbox, thank you for your advice. Regards. -- Shinichiro Hamada xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Tue Jan 19 08:53:25 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:07:46 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? References: <3.0.1.32.19990118173941.022fae00@mail.accessone.com> Message-ID: <36A3FE50.FAC00005@jclark.com> David LeBlanc wrote: > James Clark has both C and Java parsers available. Freedom of use might be > subject to your making your source available if you redistribute. Read his > (Mozilla) license. > http://www.jclark.com/xml/ My XML parser in Java (XP) isn't under the Mozilla license: it's under the same license as SP, Jade. My XML parser in C (expat) is under the Mozilla license. The Mozilla license requires you to make available the source only for any changes that you make to the expat source files. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Tue Jan 19 08:57:06 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:46 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? In-Reply-To: <36A3D8FC.BD676F83@jnana.com> References: <36A3D8FC.BD676F83@jnana.com> Message-ID: <wkzp7fod5a.fsf@ifi.uio.no> * Joel Riedesel | | Would someone remind me where a page to commercially available | (usable in a commercial environment - free or not) XML parsers is? You can look here: <URL:http://www.stud.ifi.uio.no/~larsga/linker/XMLtools.html> As far as I am aware, this is the most complete collection of XML parsers anywhere. If you're going to keep switching parsers I would take a close look at SAX, which can make that job easier. | Barring that, I'm really looking for an extremely fast XML parser | for well-formed documents (not valid - no DTD). [...] (In java.) Have a look at XP, Lark and AElfred. They are all very fast. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jan 19 09:37:47 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:46 2004 Subject: XML Component API Message-ID: <93CB64052F94D211BC5D0010A80013310EB281@WWMESS3> > The SAXON framework seems well suited for doing XSL-like > transformations, > but doesn't solve the problem of combining different XML processing > components into a single computation - at least, it doesn't > seem to have > have any advantage over the SAX interfaces in this very > specific regard. You're right: I've been struggling this week trying to implement stylesheets using SAXON, which requires multiple XML processing components, and it's not easy. SAXON is good at producing multiple outputs from one input, but multiple inputs (files or views) is more difficult. If anyone has any suggestions, please let me know! I've started looking at MDSAX to see if that offers any inspiration: perhaps it will, when I understand it better. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jan 19 09:41:06 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:46 2004 Subject: XML Component API Message-ID: <93CB64052F94D211BC5D0010A80013310EB282@WWMESS3> > > I've recently been trying to implement an XSL subset using SAXON and have > > realised that the XSL processing model requires the document to be built in > > memory, even though 90% of useful applications don't. For an XSL API, > > therefore, I think you can forget any idea of an event-based approach. > > > > Mike Kay > > That has not been my experience. I have not had any problem with spitting out > processed XSL Output to SAX events. Things could change, but for now I have not > found any reason why you can't use DocumentHandler as an interface for delegating > processing of XSL output. > > Tyler > Sorry, I wasn't clear and you misunderstood me. By "the document" I meant the input document to XSL, not its output. For the output document, yes, you are right. Mike xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From didier at cln46ae.der.edf.fr Tue Jan 19 09:44:22 1999 From: didier at cln46ae.der.edf.fr (Didier BOLF) Date: Mon Jun 7 17:07:46 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? Message-ID: <199901191040.KAA07515@cln46ms.der.edf.fr> > Would someone remind me where a page to commercially available (usable > in a commercial environment - free or not) XML parsers is? > > Barring that, I'm really looking for an extremely fast XML parser for > well-formed documents (not valid - no DTD). We're using XML for our basic > API now and performance is a tad more important now. (In java.) Hi. Last year in May, Mike Kay made a parser benchmark with a simple SAX 1.0 application. The bench was between AElfred, Lark, MSXML, xml4j and XP and at the time XP was the fastest. Perhaps he could do the benchmark again? Best regards. Didier Bolf. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tallen at sonic.net Tue Jan 19 16:16:25 1999 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 17:07:46 2004 Subject: re Naming and reference Message-ID: <199901191616.IAA25195@bolt.sonic.net> Rob Schoening wrote: | Any thoughts as to the best way to embed a message digest and/or signature | into a document without disrupting the DTD? My approach has been to send it along with the document in a multipart MIME message. regards, Terry Allen Terry Allen Veo Systems, Inc. Business Language Designer 2440 W. El Camino Real tallen[at]sonic.net Mountain View, Calif., 94040 Common Business Library - available at http://www.veosystems.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nikita.ogievetsky at csfb.com Tue Jan 19 16:52:57 1999 From: nikita.ogievetsky at csfb.com (Ogievetsky, Nikita) Date: Mon Jun 7 17:07:46 2004 Subject: Xpointer Entity Message-ID: <9C998CDFE027D211B61300A0C9CF9AB44246CB@SNYC11309> Is it (or will it be?) possible to use XPointer as Entity reference? This will allow me to generic element content, changing depending on children/ancestors surrounding... (so close to real life...) Of course it is dangerous as a source of circular references... - so it will be an extra burden for a parser. Nikita Ogievetsky. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jan 19 18:43:11 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:46 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? Message-ID: <93CB64052F94D211BC5D0010A80013310EB28A@WWMESS3> > Last year in May, Mike Kay made a parser benchmark with a > simple SAX 1.0 application. The bench was between AElfred, Lark, MSXML, > xml4j and XP and at the time XP was the fastest. Perhaps he could do the > benchmark again? It so happens I did some recent measurements (different data file) as follows: SAX parsers: xp 4387 ms oracle 7862 ms xml4j 7771 ms sun 3736 ms DOM implementations: sun 9634 ms xml4j 11677 ms oracle 9784 ms docuverse 10685 ms (using xp parser) So SUN is looking pretty good at the SAX level, but at present its licensing terms are rather restrictive. For DOM products, they're all remarkably close. I think that the oracle and ibm SAX parsers are slower because they build a parse tree even if you don't need it. Can anyone confirm this? I was intending to complete the survey by running other parsers such as aelfred, lark, datachannel, silfide; but either I've had problems getting them to run, or I just haven't found the time. Unfortunately, once again, I'm using a confidential data set, in this case one from a client. Sorry! Its size is 690Kb, and its internal structure is quite rich. The figures are obtained directly from the com.icl.saxon.Renderer main program within SAXON, selecting different parsers by editing the ParserManager.properties file. So you can easily run the same tests on your own data files. This program includes the basic SAXON processing (which builds a stack and selects an element handler for each element based on its type), but it uses a null element handler for all elements. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jan 19 21:38:52 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:46 2004 Subject: XSchema is now DDML Message-ID: <36A4FB55.BB3663BD@locke.ccil.org> XSchema is now called DDML, and is available as a W3 Note at http://www.w3.org/TR/NOTE-ddml with the help of Ingo Macherius of GMD. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Maneesha.Jain at Ebay.Sun.COM Wed Jan 20 00:35:27 1999 From: Maneesha.Jain at Ebay.Sun.COM (Maneesha Jain) Date: Mon Jun 7 17:07:46 2004 Subject: Questions on DCD Message-ID: <199901200033.QAA18019@hsnwk02h.EBay.Sun.COM> Hi, I have following questions on DCD. Any help would be a great help. 1) If I define an ElementDef type "A", and then a ElementDef type "B" which could contain two elements/members of type A. How do I define that ? Can I do the following: <ElementDef Type="A"> <Element>foo</Element> </ElementDef> <ElementDef Type="B"> <Element> Ist</Element> (first member of type A) <Element> Second</Element> (second member of type A) </ElementDef> <ElementDef Type="Ist" Model="Data" Datatype="A"/> <ElementDef Type="2nd" Model="Data" Datatype="A"/> Or is the value of attribute "Datatype" reserved to what is defined in the spec ? 2) Wish <Element> could allow <Description> just like <ElementDef>. Is it possible ? 4) What is the syntax for defining multiple inheritance ? 5) Where is the DTD for DCD ? 6) Is there any site containing couple of examples for defining DCDs ? Regards, Maneesha xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Wed Jan 20 01:35:24 1999 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:07:46 2004 Subject: Questions on DCD Message-ID: <B9D1827FDF66D111925800805F3102E309660E7F@RED-MSG-57> > -----Original Message----- > From: Maneesha Jain [mailto:Maneesha.Jain@Ebay.Sun.COM] > Sent: Tuesday, January 19, 1999 4:34 PM > To: petsa@us.ibm.com; xml-dev@ic.ac.uk; tbray@textuality.com; Charles > Frankston > Cc: Maneesha.Jain@Ebay.Sun.COM > Subject: Questions on DCD > > > Hi, > > I have following questions on DCD. Any help would be a great help. > > 1) > If I define an ElementDef type "A", and then a ElementDef type "B" > which could contain two elements/members of type A. How do I > define that ? By inheritance (defined in Appendix B of DCD). But even there you don't get to pick arbitrary members of type A. If B inherits from A, it inherits the entire content model. B may extend A's content model, but not remove things from it. > > Can I do the following: > > <ElementDef Type="A"> > <Element>foo</Element> > </ElementDef> > > <ElementDef Type="B"> > <Element> Ist</Element> (first member of type A) > <Element> Second</Element> (second member of type A) > </ElementDef> > > <ElementDef Type="Ist" Model="Data" Datatype="A"/> > <ElementDef Type="2nd" Model="Data" Datatype="A"/> > > Or is the value of attribute "Datatype" reserved to what is > defined in the spec > ? The meaning of Datatype is as defined in the spec. Although there are sensible ways to think about extending this concept to user defined datatypes, DCD does not do so. There are three distinct concepts in DCD: use or reference, inheritance (in the appendix at least), and datatypes. You are mushing them all together. An ElementDef is not a means for defining a "datatype", it is the means for defining the content model of an XML tag. The value of the Element property must match the value of the "Type" property of some ElementDef. So: <ElementDef Type="A" Model="Data"/> <ElementDef Type="B" Model="Elements" Content="Closed"> <Element>A</Element> </ElementDef> means that <B><A>some text</A></B> is legal. <B>some text</B> is not. By contrast inheritance gives us: <ElementDef Type="A" Model="Data"/> <ElementDef Type="B" Model="Mixed" Content="Closed"> <Extends Type="A"/> <ElementDef> which means that <B>some text</B> is legal. <B><A>some text</A></B> is not because <B> doesn't identify any elements that it may contain. > > 2) Wish <Element> could allow <Description> just like > <ElementDef>. Is it > possible ? Lacking a precise DTD, it is hard to say whether DCD allows this or not. There is no question 3. > > 4) What is the syntax for defining multiple inheritance ? <ElementDef Type="B" Model="Mixed" Content="Closed"> <Extends Type="A"/> <Extends Type="C"/> <ElementDef> The content model of "B" is simply the concatenation of the content models of "A" and "C". > > 5) Where is the DTD for DCD ? No DTD was written for DCD. It would be messy to do so because per RDF rules, properties may be either attributes or element values. > > 6) Is there any site containing couple of examples for defining DCDs ? None that I know of aside from what's in the paper, perhaps one of the other authors knows of some. > > Regards, > Maneesha > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From JeremyP at clbooks.com Wed Jan 20 02:02:25 1999 From: JeremyP at clbooks.com (Jeremy Pascual) Date: Mon Jun 7 17:07:46 2004 Subject: mxxml parser Message-ID: <073841B11720D2119E6200104B2474FB010C4754@CLBEXCHANGE.cbooks.com> hi, i'm trying to use msxml com object within an asp/vb script page to parse some xmldata passed to the page. i was wondering where i can get a list of methods i can use with this object and if anyone knows a good source of information for this parser? thanks, jeremy --------------------------------------------- jeremy pascual computerliteracy (bookshops+online) http://www.clbooks.com Corporate Office 1308 orleans drive sunnyvale, ca 94089 email: jeremyp@clbooks.com phone: 408 541-2020 x170 fax1: 408-752-9919 (Better Choice) fax2: 408-752-9917 --------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From prabakar at ad1.vsnl.net.in Wed Jan 20 02:55:57 1999 From: prabakar at ad1.vsnl.net.in (Hemant Agarwal) Date: Mon Jun 7 17:07:47 2004 Subject: XML EDI career question Message-ID: <01be43a1$6ea734c0$LocalHost@202.54.4.114.202.54.4.114> I am interested in making a career in Ecommerce. I am doing a course in EDI and also have learned about the Internet EDI facility put up by emergence of XML. Kindly let me know, other than EDI , what technologuies should I be thorough with. XML is one of them,where can I find XML-EDI integration cases. Is Java necessary . Kindly write in detail and also guide me to good resources on the above and Specially XML-EDI Your suggestions and views are welcomed. Regards, Hemant Agarwal Ahmedabad, India is@vsnl.com Voice: 9179 6465663 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990120/10627529/attachment.htm From b.laforge at jxml.com Wed Jan 20 06:09:40 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:47 2004 Subject: XML Component API Message-ID: <007501be443a$f13ab120$c9a8a8c0@thing2> The focus of MDSAX is to enable the processing of multiple document types, each type being handled a little differently. This would be a document processing object. There could be different kinds of document processors, implemented with different classes, all in the same runtime. The emphasis of MDSAX is to construct a process with a set of filters which share a common state. Note that this is quite distinct from the movement of events and/or DOM Document objects between different document processors (still in the same runtime). I would say that MDSAX and something like the api that Oren Ben-Kiki is working on, because they work at a different granularity, are quite complimentary. Mike, I hope you don't give up on trying to understand MDSAX. Our plan is to start working on the api documentation now and to develop the next level of detail on the web pages in February. As we make this more understandable, I expect that we be getting more suggestions from the XML community on how to make it more useful. For now, its pretty hard to participate in the design process, but changing that is our current priority. Right now I'm working with Paul Rabin to help bring him up-to-speed on MDSAX. The first consequence of that was a change to a lot of the class names, as well as a clean up on how the ElementFilter worked. But I think the result has made it easier to understand. Bill -----Original Message----- From: Michael.Kay@icl.com <Michael.Kay@icl.com> To: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk> Date: Tuesday, January 19, 1999 4:39 AM Subject: RE: XML Component API >> The SAXON framework seems well suited for doing XSL-like >> transformations, >> but doesn't solve the problem of combining different XML processing >> components into a single computation - at least, it doesn't >> seem to have >> have any advantage over the SAX interfaces in this very >> specific regard. > >You're right: I've been struggling this week trying to implement stylesheets >using SAXON, which requires multiple XML processing components, and it's not >easy. SAXON is good at producing multiple outputs from one input, but >multiple inputs (files or views) is more difficult. If anyone has any >suggestions, please let me know! I've started looking at MDSAX to see if >that offers any inspiration: perhaps it will, when I understand it better. > >Mike Kay > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From anderst at toolsmiths.se Wed Jan 20 09:00:34 1999 From: anderst at toolsmiths.se (Anders W. Tell) Date: Mon Jun 7 17:07:47 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? (C-expat) References: <93CB64052F94D211BC5D0010A80013310EB28A@WWMESS3> Message-ID: <36A59B89.98FC2074@toolsmiths.se> What about "expat" ? Have you had time and interest to run the same datafile through expat ? It would be interesting to be able to compare Java parsers with a C parser. /anders Michael.Kay@icl.com wrote: > > Last year in May, Mike Kay made a parser benchmark with a > > simple SAX 1.0 application. The bench was between AElfred, Lark, MSXML, > > xml4j and XP and at the time XP was the fastest. Perhaps he could do the > > benchmark again? > > It so happens I did some recent measurements (different data file) as > follows: > > SAX parsers: > xp 4387 ms > oracle 7862 ms > xml4j 7771 ms > sun 3736 ms > > > Mike Kay -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ / Financial Toolsmiths AB / / Anders W. Tell / /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shinichiro.hamada at toshiba.co.jp Wed Jan 20 09:39:10 1999 From: shinichiro.hamada at toshiba.co.jp (=?iso-2022-jp?B?GyRCSU1FRBsoQiAbJEI/LTBsTzobKEI=?=) Date: Mon Jun 7 17:07:47 2004 Subject: value of "this" in IE5b2-XSL script Message-ID: <001c01be4458$404495c0$db247385@hoge.ssel.toshiba.co.jp> Hello, all. I'm studying XSL with IE5b2 and then I encountered a strange phenomena which bothers me very much. I wrote a following XML and XSL based on a sample of MS web page. These files should show XML's element values with using XSL's "this" keyword and Javascript. But IE5b2 sometimes shows so, and sometimes shows nothing! That is why? IE5b2's bug? Do I misunderstand anything on XSL? Please give me any advices. Thank you in advance. Regards. -- Shinichiro HAMADA ---- simple.xml ---- <?xml version='1.0'?> <?xml:stylesheet type="text/xsl" href="simple.xsl" ?> <breakfast-menu> <food> <name>Belgian Waffles</name> <price>$5.95</price> </food> <food> <name>Strawberry Belgian Waffles</name> <price>$7.95</price> </food> </breakfast-menu> ---- simple.xsl ---- <?xml version="1.0"?> <html xmlns:xsl="http://www.w3.org/TR/WD-xsl"> <xsl:script> function PutSrc() { return "" + this }; </xsl:script> <body> <xsl:for-each select="breakfast-menu/food"> <div style="margin-left:20px; margin-bottom:1em; font-size:10pt"> elements:<br/> <xsl:eval>PutSrc()</xsl:eval> </div> </xsl:for-each> </body> </html> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Wed Jan 20 10:18:05 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:07:47 2004 Subject: XML Component API Message-ID: <003301be445d$9426f160$3902a8c0@oren.capella.co.il> Bill la Forge wrote: >The emphasis of MDSAX is to construct a process with a set of filters which share >a common state. Note that this is quite distinct from the movement of events and/or >DOM Document objects between different document processors (still in the same >runtime). I'm not quite certain that this distinction is as strong as you make it. The API that I suggested is meant for independent processing components, that's true, but I don't see why one can't simply give each component a reference to a shared state object. For common tasks (e.g., full-standard-XML-processing) this state object could provide a standard interface (such as an element stack). This leaves the issue of setting up the set of components to achieve the desired task - I understand that MDSAX helps in this regard, while my API requires the programmer explicitly connect the pieces. I'd like to see just how MDSAX achieves this. >I would say that MDSAX and something like the api that Oren Ben-Kiki is working on, >because they work at a different granularity, are quite complimentary. I'd rather have a single API for connecting XML processors, which would work at both granularities, then one for "inside a document processor" and one for "combining document processors", unless there's a very good technical reason to separate the two. For all I care this single API might be based on MDSAX, if that's appropriate. Could you give an example of combining components within MDSAX which couldn't be done easily/reasonably using my API with shared state objects? Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Livinsb at rbos.co.uk Wed Jan 20 11:31:40 1999 From: Livinsb at rbos.co.uk (Livingstone, Stephen) Date: Mon Jun 7 17:07:47 2004 Subject: value of "this" in IE5b2-XSL script Message-ID: <217258E84FF7CF11B4630001FA44B2D5027A6F86@REFROWTECX1> I tried it a few times, but it seemed OK. Does it work OK on B2? steven Steven Livingstone BSc MSc GradInstP Corporate Systems Development (TCN) Royal Bank Of Scotland. > *: mailto:livinsb@rbos.co.uk > *: +44 0131 523 4354 [x24354] > Networking Technical Associates, Glasgow, Scotland. > *: mailto:ntw_uk@hotmail.com > *: +44 07771-957-280 > > -----Original Message----- > From: shinichiro.hamada@toshiba.co.jp > [SMTP:shinichiro.hamada@toshiba.co.jp] > Sent: Wednesday, January 20, 1999 9:36 AM > To: ML XMLDev > Cc: ?? ??? > Subject: value of "this" in IE5b2-XSL script > > > *** Warning : this message originates from the Internet **** > > Hello, all. > > I'm studying XSL with IE5b2 and then I encountered a strange phenomena > which > bothers me very much. > > I wrote a following XML and XSL based on a sample of MS web page. > These > files should show XML's element values with using XSL's "this" keyword > and > Javascript. But IE5b2 sometimes shows so, and sometimes shows nothing! > That > is why? IE5b2's bug? > > Do I misunderstand anything on XSL? Please give me any advices. > Thank you in advance. > Regards. > > -- > Shinichiro HAMADA > > ---- simple.xml ---- > <?xml version='1.0'?> > <?xml:stylesheet type="text/xsl" href="simple.xsl" ?> > > <breakfast-menu> > > <food> > <name>Belgian Waffles</name> > <price>$5.95</price> > </food> > > <food> > <name>Strawberry Belgian Waffles</name> > <price>$7.95</price> > </food> > > </breakfast-menu> > > ---- simple.xsl ---- > <?xml version="1.0"?> > > <html xmlns:xsl="http://www.w3.org/TR/WD-xsl"> > > <xsl:script> > function PutSrc() { return "" + this }; > </xsl:script> > > <body> > <xsl:for-each select="breakfast-menu/food"> > <div style="margin-left:20px; margin-bottom:1em; font-size:10pt"> > elements:<br/> > <xsl:eval>PutSrc()</xsl:eval> > </div> > </xsl:for-each> > </body> > > </html> > > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. 'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.' xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shinichiro.hamada at toshiba.co.jp Wed Jan 20 11:53:36 1999 From: shinichiro.hamada at toshiba.co.jp (Shinichiro HAMADA) Date: Mon Jun 7 17:07:47 2004 Subject: value of "this" in IE5b2-XSL script Message-ID: <001f01be446b$420a18e0$db247385@hoge.ssel.toshiba.co.jp> >I tried it a few times, but it seemed OK. > >Does it work OK on B2? Thank you for checking my source. Umm... -- Shinichiro HAMADA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shinichiro.hamada at toshiba.co.jp Wed Jan 20 12:37:52 1999 From: shinichiro.hamada at toshiba.co.jp (Shinichiro HAMADA) Date: Mon Jun 7 17:07:47 2004 Subject: embed original XML in HTML converted by XSL Message-ID: <004601be4471$79e693a0$db247385@hoge.ssel.toshiba.co.jp> Hello. Thank you for helping me everytime. I asked you about XSL in "value of this in IE5b2-XSL script", but I don't understand IE5's behavior very well on it, so I will change the solution way. What I want to do was following: 1 an XML source describes formated data. 2 gives the XML source to IE5 as direct browsing. 3 convert the XML src to table with a stylesheet. 4 when an image icon in a table row is clicked, XML source which correspond to it's row is output such as with alert(). So, I tried as following: 1 by XSL, convert XML src into HTML Table in which CSS source is linked. 2 in linked CSS source, onclick event handler is defined as CSS behavior-attribute (* IE5's new function) 3 and invisible <span> is embeded in the table row, and unconverted original XML source is embedded in it. 4 onclick handler reads <span>'s innerHTML and output. In short word, I want to render XML's data as table and let event handler process the XML source which corresponds to the event target. But, I had no idea to embed XML source in the <span> at step#3 finally. The reason why I tried to use XSL is that it seems impossible to layout data as table with using CSS only. But if there is no way to achieve above with XSL, I will give up to layout data into table. Are there better way? Please give me any advices. Thank you. Regards. -- Shinichiro HAMADA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ch at student.unsw.edu.au Wed Jan 20 13:07:32 1999 From: ch at student.unsw.edu.au (Chris Howard) Date: Mon Jun 7 17:07:47 2004 Subject: mxxml parser In-Reply-To: <073841B11720D2119E6200104B2474FB010C4754@CLBEXCHANGE.cbooks.com> Message-ID: <001001be4475$fe747520$0700a9c0@wks1> hi jeremy, See http://www.microsoft.com/workshop/xml/xmldom/reference/XMLDOM_Interfaces.asp for the msxml COM interfaces (C++) docs. or http://www.microsoft.com/workshop/xml/xmldom/reference/XMLDOM_Objects.asp if you are using it as an activex control in scripting. regards, Chris Howard ch@student.unsw.edu.au > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Jeremy Pascual > Sent: Wednesday, 20 January 1999 12:58 > To: 'xml list' > Subject: mxxml parser > > > hi, > > i'm trying to use msxml com object within an asp/vb script page to parse > some xmldata passed to the page. i was wondering where i can get > a list of > methods i can use with this object and if anyone knows a good source of > information for this parser? > > thanks, > jeremy > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rmcintosh at kcp.com Wed Jan 20 14:37:27 1999 From: rmcintosh at kcp.com (rmcintosh@kcp.com) Date: Mon Jun 7 17:07:48 2004 Subject: xml-dev Digest V1 #222 Message-ID: <E102ykh-0007Sw-00@punch.ic.ac.uk> Also check out IBM's XML parser for java at www.alphaworks.com. It is supposed to be pretty fast. Rob is correct about Sun's not being open source, but that is only because it is an early release at this time and not a 'shipping' product yet. I am currently testing with Sun's at the moment and find it fairly easy. As a side note to using XML instead of RMI, I found that quite interesting because I may end up doing the same thing for a short time due to certain restrictions placed upon me, and other developer's where I work, on using certain application protocols (RMI, CORBA, etc). Anyway, I wrote a class that takes a java object, which in my case is a "business object" and creates an xml document for it. It works recursively in that if an object is a container for others, for example an invoice contains line items which contain products, etc., then it will work through all of those objects also. I haven't tested it extensively yet, but it works. It does not at this time create a DTD ,mostly because I don't need one for what I am doing, but I plan on adding DTD support. Robert McIntosh owner-xml-dev-digest@ic.ac.uk on 01/19/99 08:00:09 PM Please respond to $SENDER@ic.ac.uk To: xml-dev-digest@ic.ac.uk cc: (bcc: Robert McIntosh/ASFMT) Subject: xml-dev Digest V1 #222 xml-dev Digest Wednesday, 20 January 1999 Volume 01 : Number 222 ---------------------------------------------------------------------- From: "Rob Schoening" <rschoening@unforgettable.com> Date: Mon, 18 Jan 1999 18:09:30 -0800 Subject: RE: Ptr to Fast Well-Formed XML parser (Java)? > Would someone remind me where a page to commercially available (usable > in a commercial environment - free or not) XML parsers is? Check out the early access of Sun's XML package. It's on their Products & APIs page I believe. It's not open source, but I suspect that it will be well supported. Since Microsoft is so close to DataChannel now, I don't think that they can afford to let this market slip through the cracks...especially with M$ pushing their new XML data typing standard (can't remember the name at the moment). > (BTW, it's looking to me like XML and Java are entirely suitable for > ecommerce environments. At this point I see XML as a nice open > alternative > to RMI for some of my work and see the possibility of better > performance for > certain aspects of what I'm trying to do - but that starts to > stray from all > of what RMI really does do which I don't appear to need for these > purposes.) Personally, I think that there is some real opportunity for innovation here. If there was an XML-based spec for serialization and invocation, I think that it might be possible to implement an IIOP-ish protocol using XML. This would be really interesting, IMHO, since it would allow the document and component models to converge. CORBA, EJB, and DCOM tend to be rather heavyweight ($$$) in deployment. But if the client could be pared down so as to require little or no client-side code for certain transactional systems, things could get really interesting. For straightforward deployments, XML over HTTP (or even SMTP) could have compelling value. Imagine if you could take a DTD and build a server side component to process it. If you could apply translation to build an HTML or PDF form, the end user could be tied in to the back office without the need to develop custom software. Groupware allows this now, but if you could cut out that layer of complexity and have the browser speak directly to the middleware, without the need to write application specific code, the benefits could be tremendous. After all, groupware breaks down at the borders of organizations...at exactly the point where EC begins. Just a thought... There is an XML-RPC spec out there, but to my mind it misses the bigger picture. Might be a good stepping stone though. Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: "Rick Jelliffe" <ricko@allette.com.au> Date: Tue, 19 Jan 1999 13:33:31 +1100 Subject: Re: XML - NG From: Tim Bray <tbray@textuality.com> >At 07:03 PM 1/17/99 +1100, Rick Jelliffe wrote: >>The Desparate Perl Hacker (DPH) is certainly a good class of user for >>XML to support. But being a DPH in a commercial company is probably a >>sign of management or technical incompetence somewhere. > >I couldn't disagree with the that any more. One of the major wins in >using XML is that you can put existing data to work for new, unforeseen, >purposes. One good way to achieve this is with the use of script-ware >level tools. We are not disagreeing! I am not saying that scripting languages are bad. I said the DPH is a good class of users to support. I am merely saying that * desparation * Perl, and *hacking are not benchmarks of competence, especially in combination. For example, in Perl it is easy to write unmaintainable programs. Without management or technical discipline to enforce coding guidelines Perl encourages or enforces hacking, IMHX. >Scripting languages, such as perl, python, Omnimark, Frontier, etc, >are often the right tools for the job. Yes. I have used OmniMark for 6 years, and highly recommend it. Rick. ricko@gate.sinica.edu.tw I assume you're aware that >pretty well every one of these now has a real XML processor and >really handles XML syntax correctly. -Tim > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: "Rick Jelliffe" <ricko@allette.com.au> Date: Tue, 19 Jan 1999 13:42:56 +1100 Subject: Re: DTD vs DCD vs Schema From: Steven R. Newcomb <srn@techno.com> >The important thing is to go forward, and to avoid going backward, >with respect to the set of semantics that are expressible using DTDs. Personally, I don't think that compatability with what DTDs can model should be any constraint on a schema language, at least as far as element content models. The current content model syntax is * terse * easy to read and write * functional for a wide class of documents * standard and well-understood * part of XML * fragment-friendly (SGML's global inclusions and exclusions have been removed) I would much prefer the schema system to assume to existance of a DTD, and provide the missing parts. For example, 1) a set of data types for attributes and elements 2) use XSL patterns to assert that if one pattern is found, then another pattern must exist. The second in particular gets us out of the content-model approach and into a "partial validation" approach which is more in tune with namespaces. Rick Jelliffe ricko@gate.sinica.edu.tw xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: David LeBlanc <whisper@accessone.com> Date: Mon, 18 Jan 1999 18:31:14 -0800 Subject: RE: Ptr to Fast Well-Formed XML parser (Java)? Darned if I can remember where, but I think I surfed past someone doing such. Maybe it could be called Xorba? :-) Dave LeBlanc At 06:09 PM 1/18/99 -0800, Rob Schoening wrote: <snip> >Personally, I think that there is some real opportunity for innovation here. >If there was an XML-based spec for serialization and invocation, I think >that it might be possible to implement an IIOP-ish protocol using XML. This >would be really interesting, IMHO, since it would allow the document and >component models to converge. CORBA, EJB, and DCOM tend to be rather >heavyweight ($$$) in deployment. But if the client could be pared down so >as to require little or no client-side code for certain transactional >systems, things could get really interesting. For straightforward >deployments, XML over HTTP (or even SMTP) could have compelling value. > <snip> >Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: Joel Riedesel <jriedese@jnana.com> Date: Mon, 18 Jan 1999 20:02:36 -0700 Subject: Re: Ptr to Fast Well-Formed XML parser (Java)? Are you referring to the Coins work? (That might be a bit more than what you're thinking of as that's more like serialization of Java objects into XML - if I recall correctly.) This would actually be quite easy to do right now. In the server environment that I work in, we have our web server embedded in our Java server environment. That enables us to deploy our server with servlets without requiring non-technical people to figure out servlets, web servers, etc. We could continue down that road and use HTTP and XML for all of our communication quite easily at this point. However, for some other reasons I'm not ready to go to that step (almost entirely performance related... our architecture has plug in processing code that needs to operate very fast...). (However, to back-peddle just a little, we'll probably offer multiple APIs for some of our architecture, that allows just this capability.) But, the point being that this is doable today (in my opinion) and without a lot of effort. Throwing XSL into the mix, and now you've really got an open modular system for the Web. David LeBlanc wrote: > > Darned if I can remember where, but I think I surfed past someone doing such. > > Maybe it could be called Xorba? :-) > > Dave LeBlanc > > At 06:09 PM 1/18/99 -0800, Rob Schoening wrote: > <snip> > >Personally, I think that there is some real opportunity for innovation here. > >If there was an XML-based spec for serialization and invocation, I think > >that it might be possible to implement an IIOP-ish protocol using XML. This > >would be really interesting, IMHO, since it would allow the document and > >component models to converge. CORBA, EJB, and DCOM tend to be rather > >heavyweight ($$$) in deployment. But if the client could be pared down so > >as to require little or no client-side code for certain transactional > >systems, things could get really interesting. For straightforward > >deployments, XML over HTTP (or even SMTP) could have compelling value. > - -- Joel Riedesel Jnana Technologies Corporation mailto:jriedese@jnana.com 303 805 8275 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: David LeBlanc <whisper@accessone.com> Date: Mon, 18 Jan 1999 19:10:02 -0800 Subject: Re: DTD vs DCD vs Schema After perusing comp.text.xml, I was reminded that xml is a proper subset of sgml and thus whence came dtds etc. I guess it would be hard to do away entirely with dtds and retain that relationship. My question was originally prompted by a desire to make provision in (ok, yet another) xml parser (in C++) i'm starting work on for future developments wrt dcd/schema etc. Maybe I can make the dtd parser pluggable. Seems to me that the below idea of something complementing dtds rather then replacing them is a good one. Sincerely, Dave LeBlanc At 01:42 PM 1/19/99 +1100, Rick Jelliffe wrote: > >From: Steven R. Newcomb <srn@techno.com> > >>The important thing is to go forward, and to avoid going backward, >>with respect to the set of semantics that are expressible using DTDs. > >Personally, I don't think that compatability with what DTDs can model >should be any constraint on a schema language, at least as far as >element >content models. > >The current content model syntax is > * terse > * easy to read and write > * functional for a wide class of documents > * standard and well-understood > * part of XML > * fragment-friendly (SGML's global inclusions and exclusions >have been removed) > >I would much prefer the schema system to assume to existance of a >DTD, and provide the missing parts. For example, > 1) a set of data types for attributes and elements > 2) use XSL patterns to assert that if one pattern is found, >then another pattern must exist. > >The second in particular gets us out of the content-model approach >and into a "partial validation" approach which is more in tune with >namespaces. > >Rick Jelliffe >ricko@gate.sinica.edu.tw xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: "Rob Schoening" <rschoening@unforgettable.com> Date: Mon, 18 Jan 1999 19:32:58 -0800 Subject: RE: re Naming and reference Thanks for the info. Any thoughts as to the best way to embed a message digest and/or signature into a document without disrupting the DTD? Rob > For CBL (see URL in my sig) I've used URNs to identify documents. > In the scenario you describe, every party that may need to find the > document by its URN has already received a copy of it, so the only > resolution of the URN required is to look in the system's local > registry of URNs and find the local identifier under which the > document has been stored. > > YMMV. > > regards, Terry Allen > > > > Terry Allen Veo Systems, Inc. > Business Language Designer 2440 W. El Camino Real > tallen[at]sonic.net Mountain View, Calif., 94040 > Common Business Library - available at http://www.veosystems.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: "=?ISO-8859-1?B?lWyTYyCQTIjqmFk=?=" <shinichiro.hamada@toshiba.co.jp> Date: Tue, 19 Jan 1999 16:36:27 +0900 Subject: RE: How 2 output tags att with XSL Mr.Ken, thank you for your reply. >>BTW, you seemed to use "call msxsl" dos command for debugging xsl behavior. >>I don't know it. I want to debug xsl too, i don't have that command. Where >>can i get it? >> >>>T:\FTEMP>call msxsl test.xml test.msxsl test.htm >>>T:\FTEMP>type test.htm > >There was a 5-line script posted on the XSL list as follows: > > var data = WScript.CreateObject("Microsoft.XMLDOM"); > var style = WScript.CreateObject("Microsoft.XMLDOM"); > data.load(WScript.Arguments(0)); > style.load(WScript.Arguments(1)); > WScript.Echo( data.transformNode( style.documentElement )); > >There is a command line environment for scripting called the Windows >Scripting Host available at: > > http://www.microsoft.com/management/wsh.htm I see! Very convenient! This help me very much. Thank you. And Mr.Glassbox, thank you for your advice. Regards. - -- Shinichiro Hamada xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: James Clark <jjc@jclark.com> Date: Tue, 19 Jan 1999 10:38:56 +0700 Subject: Re: Ptr to Fast Well-Formed XML parser (Java)? David LeBlanc wrote: > James Clark has both C and Java parsers available. Freedom of use might be > subject to your making your source available if you redistribute. Read his > (Mozilla) license. > http://www.jclark.com/xml/ My XML parser in Java (XP) isn't under the Mozilla license: it's under the same license as SP, Jade. My XML parser in C (expat) is under the Mozilla license. The Mozilla license requires you to make available the source only for any changes that you make to the expat source files. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: Lars Marius Garshol <larsga@ifi.uio.no> Date: 19 Jan 1999 09:55:13 +0100 Subject: Re: Ptr to Fast Well-Formed XML parser (Java)? * Joel Riedesel | | Would someone remind me where a page to commercially available | (usable in a commercial environment - free or not) XML parsers is? You can look here: <URL:http://www.stud.ifi.uio.no/~larsga/linker/XMLtools.html> As far as I am aware, this is the most complete collection of XML parsers anywhere. If you're going to keep switching parsers I would take a close look at SAX, which can make that job easier. | Barring that, I'm really looking for an extremely fast XML parser | for well-formed documents (not valid - no DTD). [...] (In java.) Have a look at XP, Lark and AElfred. They are all very fast. - --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: Michael.Kay@icl.com Date: Tue, 19 Jan 1999 09:33:25 -0000 Subject: RE: XML Component API > The SAXON framework seems well suited for doing XSL-like > transformations, > but doesn't solve the problem of combining different XML processing > components into a single computation - at least, it doesn't > seem to have > have any advantage over the SAX interfaces in this very > specific regard. You're right: I've been struggling this week trying to implement stylesheets using SAXON, which requires multiple XML processing components, and it's not easy. SAXON is good at producing multiple outputs from one input, but multiple inputs (files or views) is more difficult. If anyone has any suggestions, please let me know! I've started looking at MDSAX to see if that offers any inspiration: perhaps it will, when I understand it better. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: Michael.Kay@icl.com Date: Tue, 19 Jan 1999 09:36:32 -0000 Subject: RE: XML Component API > > I've recently been trying to implement an XSL subset using SAXON and have > > realised that the XSL processing model requires the document to be built in > > memory, even though 90% of useful applications don't. For an XSL API, > > therefore, I think you can forget any idea of an event-based approach. > > > > Mike Kay > > That has not been my experience. I have not had any problem with spitting out > processed XSL Output to SAX events. Things could change, but for now I have not > found any reason why you can't use DocumentHandler as an interface for delegating > processing of XSL output. > > Tyler > Sorry, I wasn't clear and you misunderstood me. By "the document" I meant the input document to XSL, not its output. For the output document, yes, you are right. Mike xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: didier@cln46ae.der.edf.fr (Didier BOLF) Date: Tue, 19 Jan 1999 10:40:10 GMT Subject: Re: Ptr to Fast Well-Formed XML parser (Java)? > Would someone remind me where a page to commercially available (usable > in a commercial environment - free or not) XML parsers is? > > Barring that, I'm really looking for an extremely fast XML parser for > well-formed documents (not valid - no DTD). We're using XML for our basic > API now and performance is a tad more important now. (In java.) Hi. Last year in May, Mike Kay made a parser benchmark with a simple SAX 1.0 application. The bench was between AElfred, Lark, MSXML, xml4j and XP and at the time XP was the fastest. Perhaps he could do the benchmark again? Best regards. Didier Bolf. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: Terry Allen <tallen@sonic.net> Date: Tue, 19 Jan 1999 08:16:05 -0800 Subject: RE: re Naming and reference Rob Schoening wrote: | Any thoughts as to the best way to embed a message digest and/or signature | into a document without disrupting the DTD? My approach has been to send it along with the document in a multipart MIME message. regards, Terry Allen Terry Allen Veo Systems, Inc. Business Language Designer 2440 W. El Camino Real tallen[at]sonic.net Mountain View, Calif., 94040 Common Business Library - available at http://www.veosystems.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: "Ogievetsky, Nikita" <nikita.ogievetsky@csfb.com> Date: Tue, 19 Jan 1999 11:49:53 -0500 Subject: Xpointer Entity Is it (or will it be?) possible to use XPointer as Entity reference? This will allow me to generic element content, changing depending on children/ancestors surrounding... (so close to real life...) Of course it is dangerous as a source of circular references... - - so it will be an extra burden for a parser. Nikita Ogievetsky. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: Michael.Kay@icl.com Date: Tue, 19 Jan 1999 18:38:43 -0000 Subject: RE: Ptr to Fast Well-Formed XML parser (Java)? > Last year in May, Mike Kay made a parser benchmark with a > simple SAX 1.0 application. The bench was between AElfred, Lark, MSXML, > xml4j and XP and at the time XP was the fastest. Perhaps he could do the > benchmark again? It so happens I did some recent measurements (different data file) as follows: SAX parsers: xp 4387 ms oracle 7862 ms xml4j 7771 ms sun 3736 ms DOM implementations: sun 9634 ms xml4j 11677 ms oracle 9784 ms docuverse 10685 ms (using xp parser) So SUN is looking pretty good at the SAX level, but at present its licensing terms are rather restrictive. For DOM products, they're all remarkably close. I think that the oracle and ibm SAX parsers are slower because they build a parse tree even if you don't need it. Can anyone confirm this? I was intending to complete the survey by running other parsers such as aelfred, lark, datachannel, silfide; but either I've had problems getting them to run, or I just haven't found the time. Unfortunately, once again, I'm using a confidential data set, in this case one from a client. Sorry! Its size is 690Kb, and its internal structure is quite rich. The figures are obtained directly from the com.icl.saxon.Renderer main program within SAXON, selecting different parsers by editing the ParserManager.properties file. So you can easily run the same tests on your own data files. This program includes the basic SAXON processing (which builds a stack and selects an element handler for each element based on its type), but it uses a null element handler for all elements. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: John Cowan <cowan@locke.ccil.org> Date: Tue, 19 Jan 1999 16:38:29 -0500 Subject: XSchema is now DDML XSchema is now called DDML, and is available as a W3 Note at http://www.w3.org/TR/NOTE-ddml with the help of Ingo Macherius of GMD. - -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: Maneesha Jain <Maneesha.Jain@Ebay.Sun.COM> Date: Tue, 19 Jan 1999 16:33:35 -0800 (PST) Subject: Questions on DCD Hi, I have following questions on DCD. Any help would be a great help. 1) If I define an ElementDef type "A", and then a ElementDef type "B" which could contain two elements/members of type A. How do I define that ? Can I do the following: <ElementDef Type="A"> <Element>foo</Element> </ElementDef> <ElementDef Type="B"> <Element> Ist</Element> (first member of type A) <Element> Second</Element> (second member of type A) </ElementDef> <ElementDef Type="Ist" Model="Data" Datatype="A"/> <ElementDef Type="2nd" Model="Data" Datatype="A"/> Or is the value of attribute "Datatype" reserved to what is defined in the spec ? 2) Wish <Element> could allow <Description> just like <ElementDef>. Is it possible ? 4) What is the syntax for defining multiple inheritance ? 5) Where is the DTD for DCD ? 6) Is there any site containing couple of examples for defining DCDs ? Regards, Maneesha xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ From: Charles Frankston <cfranks@microsoft.com> Date: Tue, 19 Jan 1999 17:34:03 -0800 Subject: RE: Questions on DCD > -----Original Message----- > From: Maneesha Jain [mailto:Maneesha.Jain@Ebay.Sun.COM] > Sent: Tuesday, January 19, 1999 4:34 PM > To: petsa@us.ibm.com; xml-dev@ic.ac.uk; tbray@textuality.com; Charles > Frankston > Cc: Maneesha.Jain@Ebay.Sun.COM > Subject: Questions on DCD > > > Hi, > > I have following questions on DCD. Any help would be a great help. > > 1) > If I define an ElementDef type "A", and then a ElementDef type "B" > which could contain two elements/members of type A. How do I > define that ? By inheritance (defined in Appendix B of DCD). But even there you don't get to pick arbitrary members of type A. If B inherits from A, it inherits the entire content model. B may extend A's content model, but not remove things from it. > > Can I do the following: > > <ElementDef Type="A"> > <Element>foo</Element> > </ElementDef> > > <ElementDef Type="B"> > <Element> Ist</Element> (first member of type A) > <Element> Second</Element> (second member of type A) > </ElementDef> > > <ElementDef Type="Ist" Model="Data" Datatype="A"/> > <ElementDef Type="2nd" Model="Data" Datatype="A"/> > > Or is the value of attribute "Datatype" reserved to what is > defined in the spec > ? The meaning of Datatype is as defined in the spec. Although there are sensible ways to think about extending this concept to user defined datatypes, DCD does not do so. There are three distinct concepts in DCD: use or reference, inheritance (in the appendix at least), and datatypes. You are mushing them all together. An ElementDef is not a means for defining a "datatype", it is the means for defining the content model of an XML tag. The value of the Element property must match the value of the "Type" property of some ElementDef. So: <ElementDef Type="A" Model="Data"/> <ElementDef Type="B" Model="Elements" Content="Closed"> <Element>A</Element> </ElementDef> means that <B><A>some text</A></B> is legal. <B>some text</B> is not. By contrast inheritance gives us: <ElementDef Type="A" Model="Data"/> <ElementDef Type="B" Model="Mixed" Content="Closed"> <Extends Type="A"/> <ElementDef> which means that <B>some text</B> is legal. <B><A>some text</A></B> is not because <B> doesn't identify any elements that it may contain. > > 2) Wish <Element> could allow <Description> just like > <ElementDef>. Is it > possible ? Lacking a precise DTD, it is hard to say whether DCD allows this or not. There is no question 3. > > 4) What is the syntax for defining multiple inheritance ? <ElementDef Type="B" Model="Mixed" Content="Closed"> <Extends Type="A"/> <Extends Type="C"/> <ElementDef> The content model of "B" is simply the concatenation of the content models of "A" and "C". > > 5) Where is the DTD for DCD ? No DTD was written for DCD. It would be messy to do so because per RDF rules, properties may be either attributes or element values. > > 6) Is there any site containing couple of examples for defining DCDs ? None that I know of aside from what's in the paper, perhaps one of the other authors knows of some. > > Regards, > Maneesha > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ------------------------------ End of xml-dev Digest V1 #222 ***************************** xml-dev-digest: A list for W3C XML Developers[digest] 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-digest List coordinator, Henry Rzepa (rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Leif.Ydreborn at saab.se Wed Jan 20 15:00:51 1999 From: Leif.Ydreborn at saab.se (Leif.Ydreborn@saab.se) Date: Mon Jun 7 17:07:48 2004 Subject: Generating XML Message-ID: <36A5EFA1.7EF329DA@saab.se> What is the "normal" way of generating a XML-file (data) from a Java program. Leif Ydreborn xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dante at mstirling.gsfc.nasa.gov Wed Jan 20 15:15:10 1999 From: dante at mstirling.gsfc.nasa.gov (Dante Lee) Date: Mon Jun 7 17:07:48 2004 Subject: Inserting an image into an XML document Message-ID: <Pine.LNX.3.95.990120105835.13917A-100000@mstirling.gsfc.nasa.gov> Does anyone know how to insert an image into an XML document? Is this done in the XSL or the XML? Also, do you have an example that is on the web of an image actually within the xml or xsl (whichever) document? Dante M. Lee Code 588 NASA/GSFC Greenbelt MD 20771 Voice = 301-521-1077 Bldg = 23 Rm = W415 Email = dante@mstirling.gsfc.nasa.gov dante4@hotmail.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dante at mstirling.gsfc.nasa.gov Wed Jan 20 15:29:14 1999 From: dante at mstirling.gsfc.nasa.gov (Dante Lee) Date: Mon Jun 7 17:07:48 2004 Subject: An example of handling regular data Message-ID: <009f01be44ee$25d76190$ded9b780@gsfc.nasa.gov> Can anyone send me an example of an XSL document with regular data. For instance, irregular data uses templates and template matches. Regular data doesn't. Dante Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990120/b883a638/attachment.htm From Steven_DeRose at Brown.edu Wed Jan 20 15:43:44 1999 From: Steven_DeRose at Brown.edu (Steve DeRose) Date: Mon Jun 7 17:07:48 2004 Subject: Xpointer Entity In-Reply-To: <9C998CDFE027D211B61300A0C9CF9AB44246CB@SNYC11309> Message-ID: <v03110701b2cb9574975d@[153.35.91.91]> At 12:49 PM -0400 1/19/99, Ogievetsky, Nikita wrote: >Is it (or will it be?) possible to use XPointer as Entity reference? >This will allow me to generic element content, changing depending on >children/ancestors surrounding... (so close to real life...) >Of course it is dangerous as a source of circular references... >- so it will be an extra burden for a parser. I imagine you mean "in" the system identifier of an entity declaration, right? For example, ... <!ENTITY mysection SYSTEM "http://z.com/stuff/mybook.html#id(chap2).child(3,sec)"> ... &mysection; ... I hope and expect that will be the case; it's an obvious and useful application. We discussed it during the development of XPointer. Of course XPointer can't compel applications to support it; but it seems an obvious thing to support if you're writing an app. It's also not really any more work after you've built support for entities in general, and for XPointer in general. I think this adds no more problem for circular entity references, than is already handled for entities in general (SGML prohibits circular entity references, by the way). Anyway, they're not hard to catch. <!ENTITY boom "&boom;"> SGML and XML have the limitation that entities have no parameters; one advantage of is that any time you get a circular reference it must be wrong, because the circle could never terminate. If entities were parameterized somehow, then you could possibly have useful recursion that eventually terminated; but they aren't, so you can't. If you know of any implementations that support this usage, please send me the info and I'll add them to my page about xpointer and xlink implementations at http://www.stg.brown.edu/~sjd/XML-Linking/xptr-implementations.html Steve Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd Chief Scientist, Scholarly Technology Group, and Adjunct Associate Professor, Brown University; Chief Scientist, Inso Corporation xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed Jan 20 16:11:40 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:07:48 2004 Subject: Generating XML Message-ID: <93CB64052F94D211BC5D0010A80013310EB291@WWMESS3> > From: Leif.Ydreborn@saab.se [mailto:Leif.Ydreborn@saab.se] > > What is the "normal" way of generating a XML-file (data) from > a Java program. > My normal way is to have a "writeXML()" method on the relevant object, which calls writeXML() methods on its component objects, and so on. A lot depends on how close the java object structure is to the desired XML document structure. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Jan 20 16:27:19 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:48 2004 Subject: XML Component API Message-ID: <000a01be4491$1d811ca0$c9a8a8c0@thing2> >>I would say that MDSAX and something like the api that Oren Ben-Kiki is >working on, >>because they work at a different granularity, are quite complimentary. > >I'd rather have a single API for connecting XML processors, which would work >at both granularities, then one for "inside a document processor" and one >for "combining document processors", unless there's a very good technical >reason to separate the two. For all I care this single API might be based on >MDSAX, if that's appropriate. I don't think it is ever safe to ignore granularity and that APIs for different levels of granularity should be free to develop in different directions. I've seen proposals to the OMG which had URLs as separate CORBA objects, with remote-access methods for fetching the various parts of the URL. Closer to home, I've heard from several sources the idea that DOM elements should be implemented as CORBA objects, with support for independent retrieval/update. A reverse form of this problem is the overly simple api used for UNIX processes, where perhaps a richer and more flexible interface might have been helpful in the long run. (Yes, MS windows goes too far, IMHO, in the other direction.) With very low-level api, it is quite helpful if applications of the api can consist largely of inline code, and if the overhead for handling the interface is low. Efficiency considerations rule! At a high-level api, the applications can always make use of lower-level components to handle a heavy-weight interface. The real need is to be able to interconnect a wide range of components. When connecting various document processes, you want to be able to connect a document- flow with a SAX event flow. And in connecting various sources and sinks, you may need something like a UNIX pipe: a thread-safe event queue. But at the lower level, within a process, you want to be able to extend a base-level filter class and just add 10 lines of code to manipulate a specific type of event. And you do not want any extraneous overhead whatsoever. There is another consideration as well. Within an MDSAX-based process, it is reasonable to mandate that all filters implement the DocumentHandler interface and that the glue code for chaining various filters together always reside in a factory class which implements the MDFilterFactory interface. But when interconnecting different processes, you want to allow for a much greater range of implementations. There should not be a requirement that all the document processes within a single runtime use MDSAX internally, only that they can serve as either a source or sink for a document or a SAX event. You want a framework for this larger granularity into which you can plug almost any kind of document processor. (And in this case, the framework may be quite application-specific, though that doesn't preclude the development of a toolkit to help with the task.) Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jan 20 16:48:49 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:48 2004 Subject: Generating XML In-Reply-To: <93CB64052F94D211BC5D0010A80013310EB291@WWMESS3> References: <93CB64052F94D211BC5D0010A80013310EB291@WWMESS3> Message-ID: <13990.1889.731592.996664@localhost.localdomain> Michael.Kay@icl.com writes: > My normal way is to have a "writeXML()" method on the relevant > object, which calls writeXML() methods on its component objects, > and so on. A lot depends on how close the java object structure is > to the desired XML document structure. A more elegant (if slightly more verbose) alternative is to have a separate XMLWriter interface, so that you can write the XML out in different ways (with or without preserving internal entity references, etc.). This approach can work very nicely if the component object implements the Visitor design pattern: the writer can act as a visitor, and the XML component object can invoke the correct method in the writer object based on the component's type. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Jan 20 17:58:15 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:48 2004 Subject: Generating XML Message-ID: <000901be449d$e9262ce0$c9a8a8c0@thing2> Is this one of those areas where we could really use an additional (optional) interface on DOM elements? I usually just call normalize on the sub-tree in question and then generate the XML while doing a tree transversal. But it would be nice to check each individual element and see if it implements a write interface, which would indicate that it is taking responsibility for the XML composition for itself and its subordinate elements. Bill -----Original Message----- From: david@megginson.com <david@megginson.com> To: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk> Date: Wednesday, January 20, 1999 12:07 PM Subject: RE: Generating XML >Michael.Kay@icl.com writes: > > > My normal way is to have a "writeXML()" method on the relevant > > object, which calls writeXML() methods on its component objects, > > and so on. A lot depends on how close the java object structure is > > to the desired XML document structure. > >A more elegant (if slightly more verbose) alternative is to have a >separate XMLWriter interface, so that you can write the XML out in >different ways (with or without preserving internal entity references, >etc.). > >This approach can work very nicely if the component object implements >the Visitor design pattern: the writer can act as a visitor, and the >XML component object can invoke the correct method in the writer >object based on the component's type. > > >All the best, > > >David > >-- >David Megginson david@megginson.com > http://www.megginson.com/ > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From byrnes at prl.research.philips.com Wed Jan 20 18:03:29 1999 From: byrnes at prl.research.philips.com (Nigel Byrnes) Date: Mon Jun 7 17:07:48 2004 Subject: XML for dynamic content? Message-ID: <36A619E2.81EB0E2D@prl.research.philips.com> Hi all We all know the benefits of representing "static" documents in XML. But considering where [HTML, VRML, etc] content is to be generated on the fly, as is frequently done by CGI scripts, is XML suitable for encoding the output data in these types of applications? Considering a simple hangman game, the application could either: 1. receive user-input and generate XML as output, which then has to be formated 2. receive user-input and generate format markup language-content as output 3. another possibility? The first option has the advantage of allowing the service to be viewed in different formats for different clients. For the game's developer, the second approach is better because the presentation of content can be optimised for presentation on [a single] client device. Nonetheless, this level of formating could be achieved with style sheets. Apart from the obvious, the question is what value does the intermediate XML-step buy us? Why should the hangman-developer want this intermediate XML-step? Does anyone have any comments on the use of XML in this context. Thanks Nigel -- Nigel Byrnes "We continue..." Pete Tong Software Engineering and Applications Group, Philips Research Labs, Redhill. Tel: +44 (0)1293 815578 RH1 5HA. Fax: +44 (0)1293 815024 UK. GSM: +44 (0)7899 940391 Email: byrnes@prl.research.philips.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Curt.Arnold at hyprotech.com Wed Jan 20 20:01:36 1999 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:07:48 2004 Subject: Questions on DCD Message-ID: <61DAD58E8F4ED211AC8400A0C9B468730121DB@THOR> Maneesha Jain [mailto:Maneesha.Jain@Ebay.Sun.COM] wrote >>1) >>If I define an ElementDef type "A", and then a ElementDef type "B" >>which could contain two elements/members of type A. How do I define that ?Question 1: What you appear to want to do is something equivalent to a (A,A) content in the DTD. You would do this (approximate syntax). (This requires you to have two A's) <ElementDef Type="B"> <Group RDF:Order="Seq"> <Element Name="A"/> <Element Name="A"/> </Group> </ElementDef> If you could have 0 or two A (A,A)+, you would do <ElementDef Type="B"> <Group RDF:Order="Seq" Occurs="Optional"> <Element Name="A"/> <Element Name="A"/> </Group> </ElementDef> I don't believe there is a way to restrict content to 0,1, or 2. The best you could do is allow 0 or more A's (A*) have have to limit it in your processor <ElementDef Type="B"> <Group RDF:Order="Seq" Occurs="ZeroOrMore"> <Element Name="A"/> </Group> </ElementDef> >> 5) Where is the DTD for DCD ? One of the guys from IBM (Dean Roddey?) posted a experimental DTD for DCD to this mailing list a few days after the announcement of DCD. You should be able to locate it in the message archives (see mailing list trailer for locations). xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arabbit at earthlink.net Wed Jan 20 21:20:47 1999 From: arabbit at earthlink.net (Paul Butkiewicz) Date: Mon Jun 7 17:07:48 2004 Subject: XML for dynamic content? In-Reply-To: <36A619E2.81EB0E2D@prl.research.philips.com> Message-ID: <000601be44ba$d7ed1fc0$d636bfa8@arabbit> >Apart from the obvious, the question is what value does the intermediate >XML-step buy us? Why should the hangman-developer want this intermediate >XML-step? Does anyone have any comments on the use of XML in this >context. Well, I haven't done much web development in a while, but it seems like XML in this scenario provides a good standard way of integrating the work done by a developer writing the CGI to just return XML, and by someone who is more inclined towards presentation issues. But on a "dreaming" sort of note, suppose the client's browser was working on the XML directly, either because the HTML was embedded with XML tags or because the client's browser is working off of style sheets as well. Wouldn't it be cool if you could somehow update just a fraction of the XML document? Suppose you could just retrieve the document element pertaining to the hangman or the word (to borrow from your example) and just re-retrieve that part of the document rather than the whole thing. Wouldn't that be cool? Paul xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jan 20 21:24:17 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:48 2004 Subject: SAX: Next Round Message-ID: <199901202122.QAA00962@megginson.com> [I started a thread like this before the holidays, but then got drawn away, so I'll try again.] I've been thinking about what new SAX interfaces we need the most (with much prodding from users). Here's what I think we need as a minimum: 1. A standard filter interface (and perhaps an optional base class). 2. A handler interface for lexical events like comments, CDATA sections, and entity references. 3. Some kind of namespace support. I'd like to lose EntityResolver and DTDHandler (who uses them?), but I don't know if we can. 1. Filter Interface ------------------- My first inclination here was to have the filter interface extend org.xml.sax.Parser, something like this: public interface ParserFilter extends Parser { public abstract void setParent (Parser parser); } Upon more careful consideration, though, I think that we might want to make Filter an entirely independent interface: public interface Filter { public abstract void setParent (Parser parser); } The advantage to the second approach is that you can have something like public class SAXDriver implements Parser, LexicalProcessor, Filter, NamespaceProcessor { } and mix and match different capabilities (see further, below). A third alternative (suggested by James Clark) is to have the filter interface extend DocumentHandler rather than parser -- i.e., to filter on the client side: public interface Filter extends DocumentHandler { public void setDocumentHandler(DocumentHandler handler); public void setParameter(String name, String value) throws SAXException; } 2. Lexical Event Handler ------------------------ What do we really need here? public interface LexicalHandler { public void startDTD (String name, String pubid, String sysid) throws SAXException; public void endDTD (String name); public void startExternalEntity (String name, String pubid, String sysid) throws SAXException; public void endExternalEntity (String name) throws SAXException; public void startCDATA () throws SAXException; public void endCDATA () throws SAXException; public void comment (String data) throws SAXException; } I haven't checked, but I think that this gives us everything we need for DOM level one. Of course, we need a new parser interface that knows about lexical handlers: public interface LexicalParser extends Parser { public void setLexicalHandler (LexicalHandler handler); } This could also be an entirely independent interface that doesn't extend Parser: public interface LexicalProcessor { public void setLexicalHandler (LexicalHandler handler); } 3. Namespace Support -------------------- Where should we go with this? At a minimum, we need to be able to provide fully-expanded element and attribute names, but it would also be nice to be able to know about namespace prefixes so that an application can expand them in attribute values and character data content. Here's a minimal approach: public interface NamespaceParser extends Parser { } Doesn't look like much, does it? We could provide an on-off switch: public interface NamespaceParser extends Parser { public void enableNamespaceProcessing (boolean flag); } Another nice thing to do would be to allow the application to choose a separator between the URI part and the local name: public interface NamespaceParser extends Parser { public void enableNamespaceProcessing (boolean flag); public void setSeparator (String sep); } To keep things pure, it might be a good idea not to have this extend the Parser interface: public interface NamespaceParser { public void enableNamespaceProcessing (boolean flag); public void setSeparator (String sep); } Now, the best way to find out about namespace prefixes is to introduce a new handler interface: public interface NamespaceHandler { public void startNamespacePrefix (String prefix, String uri) throws SAXException; public void endNamespacePrefix (String prefix) throws SAXException; } Of course, NamespaceParser has to know about this: public interface NamespaceParser { public void enableNamespaceProcessing (boolean flag); public void setSeparator (String sep); public void setNamespaceHandler (NamespaceHandler handler); } Finally, we might want a helper class that can split up names, etc. Do we munge all of this with inheritance, or keep a series of separate mix-and-match interfaces? Comments? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Maneesha.Jain at Ebay.Sun.COM Wed Jan 20 21:50:44 1999 From: Maneesha.Jain at Ebay.Sun.COM (Maneesha Jain) Date: Mon Jun 7 17:07:48 2004 Subject: Questions on DCD Message-ID: <199901202149.NAA24384@hsnwk02h.EBay.Sun.COM> Hi Arnold, Thanks for the response. I guess I was looking for a way to represent following java class in DCD syntax. In java--> class Kid { Person mother; ***** Person father; } In DCD --> <ElementDef Type="Kid"> <Element>Person</Element> <Element>Person</Element> </ElementDef> <ElementDef Type="Person"> <Element>Name</Element> <Element>Address</Element> </ElementDef> What I don't understand is where in DCD can I specify that the "Ist Person" information is about the "mother" and "Second Person" information is about "father". In concept, I was looking for a way to specify the "type" and "name" for a <Element> just like in java definition marked as (*****). Regards, Maneesha > > >>1) > >>If I define an ElementDef type "A", and then a ElementDef type "B" > >>which could contain two elements/members of type A. How do I define that > ?Question 1: > > What you appear to want to do is something equivalent to a (A,A) content in > the DTD. You would do this (approximate syntax). (This requires you to > have two A's) > > <ElementDef Type="B"> > <Group RDF:Order="Seq"> > <Element Name="A"/> > <Element Name="A"/> > </Group> > </ElementDef> > > If you could have 0 or two A (A,A)+, you would do > > <ElementDef Type="B"> > <Group RDF:Order="Seq" Occurs="Optional"> > <Element Name="A"/> > <Element Name="A"/> > </Group> > </ElementDef> > > I don't believe there is a way to restrict content to 0,1, or 2. The best > you could do is allow 0 or more A's (A*) have have to limit it in your > processor > > <ElementDef Type="B"> > <Group RDF:Order="Seq" Occurs="ZeroOrMore"> > <Element Name="A"/> > </Group> > </ElementDef> > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jan 20 22:29:35 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:49 2004 Subject: Questions on DCD In-Reply-To: <199901202149.NAA24384@hsnwk02h.EBay.Sun.COM> Message-ID: <3.0.1.32.19990120172215.00fc2cc0@pop.uunet.ca> At 04:49 PM 1/20/99 -0500, Maneesha Jain wrote: >Thanks for the response. I guess I was looking for a way to >represent following java class in DCD syntax. > >In java--> > >class Kid >{ > Person mother; ***** > Person father; >} >In DCD --> > ><ElementDef Type="Kid"> > <Element>Person</Element> > <Element>Person</Element> ></ElementDef> > ><ElementDef Type="Person"> > <Element>Name</Element> > <Element>Address</Element> ></ElementDef> > In SOX, you can do this as: <elementtype name="Person"> <model><sequence> <element name="Name"/> <element name="Address"/> </sequence><model> </elementtype> <elementtype name="Kid"> <model><sequence> <element name="father"/> <element name="mother"/> </sequence></model> </elementttype> <elementtype name="father"> <instanceof name="Person"/> </elementtype> <elementtype name="mother"> <instanceof name="Person"/> </elementtype> >What I don't understand is where in DCD can I specify that the "Ist Person" >information is about the "mother" and "Second Person" information is about >"father". In concept, I was looking for a way to specify the "type" and "name" >for a <Element> just like in java definition marked as (*****). Does my example address your question? Regards, Murray Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmg at trivida.com Wed Jan 20 22:32:45 1999 From: jmg at trivida.com (Jeff Greif) Date: Mon Jun 7 17:07:49 2004 Subject: Questions on DCD Message-ID: <009801be44c4$362648b0$a24630d1@greif.trivida.com> I'm not familiar with details of DCD, but based on what I see below, I think this might work: <ElementDef Type="Kid"> <Element>Mother</Element> <Element>Father</Element> </ElementDef> <ElementDef Type="Mother"> <Element>Person</Element> </ElementDef> <ElementDef Type="Father"> <Element>Person</Element> </ElementDef> <ElementDef Type="Person"> <Element>Name</Element> <Element>Address</Element> </ElementDef> This is very similar to what you might put in a DTD: <!Element kid (mother,father)> <!Element mother (person)> <!Element father (person)> <!Element person (name, address)> Jeff -----Original Message----- From: Maneesha Jain <Maneesha.Jain@Ebay.Sun.COM> To: Maneesha.Jain@Ebay.Sun.COM <Maneesha.Jain@Ebay.Sun.COM>; Curt.Arnold@hyprotech.com <Curt.Arnold@hyprotech.com> Cc: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk> Date: Wednesday, January 20, 1999 1:54 PM Subject: RE: Questions on DCD >Hi Arnold, > >Thanks for the response. I guess I was looking for a way to represent following >java class in DCD syntax. > >In java--> > >class Kid >{ > Person mother; ***** > Person father; >} > >In DCD --> > ><ElementDef Type="Kid"> > <Element>Person</Element> > <Element>Person</Element> ></ElementDef> > ><ElementDef Type="Person"> > <Element>Name</Element> > <Element>Address</Element> ></ElementDef> > >What I don't understand is where in DCD can I specify that the "Ist Person" >information is about the "mother" and "Second Person" information is about >"father". In concept, I was looking for a way to specify the "type" and "name" >for a <Element> just like in java definition marked as (*****). > >Regards, >Maneesha > >> >> >>1) >> >>If I define an ElementDef type "A", and then a ElementDef type "B" >> >>which could contain two elements/members of type A. How do I define that >> ?Question 1: >> >> What you appear to want to do is something equivalent to a (A,A) content in >> the DTD. You would do this (approximate syntax). (This requires you to >> have two A's) >> >> <ElementDef Type="B"> >> <Group RDF:Order="Seq"> >> <Element Name="A"/> >> <Element Name="A"/> >> </Group> >> </ElementDef> >> >> If you could have 0 or two A (A,A)+, you would do >> >> <ElementDef Type="B"> >> <Group RDF:Order="Seq" Occurs="Optional"> >> <Element Name="A"/> >> <Element Name="A"/> >> </Group> >> </ElementDef> >> >> I don't believe there is a way to restrict content to 0,1, or 2. The best >> you could do is allow 0 or more A's (A*) have have to limit it in your >> processor >> >> <ElementDef Type="B"> >> <Group RDF:Order="Seq" Occurs="ZeroOrMore"> >> <Element Name="A"/> >> </Group> >> </ElementDef> >> > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 20 22:37:18 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:49 2004 Subject: SAX: Next Round References: <199901202122.QAA00962@megginson.com> Message-ID: <36A65A55.E5445A28@locke.ccil.org> David Megginson scripsit: > I'd like to lose EntityResolver and DTDHandler (who uses them?), but I > don't know if we can. Nope, nope, nope. In particular, I still have a project to finish a standard EntityResolver that understands Socats. By having such a thing, you can fit Socat support into arbitrary applications using arbitrary SAX parsers. Keep it. As for DTDHandler, it exposes stuff that XML 1.0 requires a parser to expose. > 1. Filter Interface I propose a fourth alternative: provide ParserFilter as a helper class, and don't have a separate interface. Parser filters are just parsers that have a "parser(Parser)" constructor. One particularly nice feature of this is that it is the pattern used by Java {Input,Output}Streams and Readers/Writers: Chain of Responsibility. > 2. Lexical Event Handler I'll post on this later. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nikita.ogievetsky at csfb.com Wed Jan 20 22:55:17 1999 From: nikita.ogievetsky at csfb.com (Ogievetsky, Nikita) Date: Mon Jun 7 17:07:49 2004 Subject: Xpointer Entity Message-ID: <9C998CDFE027D211B61300A0C9CF9AB44246CF@SNYC11309> Steve DeRose wrote: >I imagine you mean "in" the system identifier of an entity declaration, right? >For example, >... ><!ENTITY mysection SYSTEM >"http://z.com/stuff/mybook.html#id(chap2 <http://z.com/stuff/mybook.html>).child(3,sec)"> >... >&mysection; >... >>Is it (or will it be?) possible to use XPointer as Entity reference? >>This will allow me to generic element content, changing depending on >>children/ancestors surrounding... (so close to real life...) >>Of course it is dangerous as a source of circular references... >>- so it will be an extra burden for a parser. Yes this will be really good to have. But I want to go even further: Sort of XPoiter function. For example: <About>My name is &ancestor(1,this,FirstName,*);</About> i.e. XPointer relative to context of current #element. I do not want to hardcode it becouse a user should be free to modify document however he wants. I am working now on an application that needs this kind of functionality. I do not know of any parser that has it, so will have to create an add-on. If you have any advice, would greatly appreciate it. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Williams at East.Sun.COM Wed Jan 20 22:59:19 1999 From: James.Williams at East.Sun.COM (James Williams - Sun East Coast IR Development) Date: Mon Jun 7 17:07:49 2004 Subject: SAX: Next Round Message-ID: <199901202256.RAA24759@volcano.East.Sun.COM> If you're opening a discussion on SAX 2.0, here's an idea ... How about adding the capabililty to register multiple handlers of a given type with a parser instance? The parser would send the event to the handlers in the order they were registered. I think it would aid in the development of modular, re-usable handlers if you could register more than one with a parser. Jim Williams xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Maneesha.Jain at Ebay.Sun.COM Wed Jan 20 22:59:39 1999 From: Maneesha.Jain at Ebay.Sun.COM (Maneesha Jain) Date: Mon Jun 7 17:07:49 2004 Subject: Questions on DCD Message-ID: <199901202256.OAA26704@hsnwk02h.EBay.Sun.COM> Thanks Murray, "instanceof" tag in SOX is definetly much closer to a programmer's thoughts. Maneesha > X-Sender: maloney.murray@pop.uunet.ca > Date: Wed, 20 Jan 1999 17:22:15 -0500 > To: Maneesha Jain <Maneesha.Jain@Ebay> > From: Murray Maloney <murray@muzmo.com> > Subject: RE: Questions on DCD > Cc: Maneesha.Jain@Ebay, Curt.Arnold@hyprotech.com, xml-dev@ic.ac.uk > Mime-Version: 1.0 > > At 04:49 PM 1/20/99 -0500, Maneesha Jain wrote: > >Thanks for the response. I guess I was looking for a way to > >represent following java class in DCD syntax. > > > >In java--> > > > >class Kid > >{ > > Person mother; ***** > > Person father; > >} > >In DCD --> > > > ><ElementDef Type="Kid"> > > <Element>Person</Element> > > <Element>Person</Element> > ></ElementDef> > > > ><ElementDef Type="Person"> > > <Element>Name</Element> > > <Element>Address</Element> > ></ElementDef> > > > > In SOX, you can do this as: > > <elementtype name="Person"> > <model><sequence> > <element name="Name"/> > <element name="Address"/> > </sequence><model> > </elementtype> > > <elementtype name="Kid"> > <model><sequence> > <element name="father"/> > <element name="mother"/> > </sequence></model> > </elementttype> > > <elementtype name="father"> > <instanceof name="Person"/> > </elementtype> > > <elementtype name="mother"> > <instanceof name="Person"/> > </elementtype> > > >What I don't understand is where in DCD can I specify that the "Ist Person" > >information is about the "mother" and "Second Person" information is about > >"father". In concept, I was looking for a way to specify the "type" and "name" > >for a <Element> just like in java definition marked as (*****). > > Does my example address your question? > > Regards, > > Murray > > > Murray Maloney, Esq. Phone: (905) 509-9120 > Muzmo Communication Inc. Fax: (905) 509-8637 > 671 Cowan Circle Email: murray@muzmo.com > Pickering, Ontario Email: murray@yuri.org > Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Wed Jan 20 23:06:35 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:07:49 2004 Subject: Next Round In-Reply-To: <199901202122.QAA00962@megginson.com> Message-ID: <000001be44c9$7c0992b0$bda8b4d1@yak.ptld.uswest.net> > > > Do we munge all of this with inheritance, or keep a series of separate > mix-and-match interfaces? > > > Comments? Mix and match interfaces tend to be instructional as "facets" that group sets of functionality. If nothing else, they make the API easier to understand. However I have found that the actual ability to mix and match tends to be more of a liability than an asset in an API this small. If the facets are not merged together into a hierarchy, I'm afraid the proliferation of interfaces will frustrate the user. If the mix and match approach is to be successful, I believe that it should be hidden for ordinary use through some kind of aggregation. This would necessitate either 1) multiple inheritance of interfaces or 2) language specific abstract classes. Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Jan 21 00:11:07 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:49 2004 Subject: Identifying XML Document Types (was XML media types revisited) References: <199901152012.PAA03477@hesketh.net> Message-ID: <36A66D2C.DFA2DE98@prescod.net> > Namespaces Disadvantages: Surprisingly (to me) I find these arguments to be unpersuasive. Namespaces seem like the right solution to me. > Just because the root element is X doesn't mean its contents > are Y. If the definition of the namespace (whereever it is) says that the namespace's X must contain a Y, then an X *must* contain a Y, just as if it were a DOCTYPE declaration. The only difference is that the validation is done at some other level, using some other mechanism. > Especially given the problems of validating documents in > namespace-aware environments, namespaces may not always be available. These problems go away if you use the namespace convention in ways that are not in contradiction with validation (i.e. #FIXED xmlns: attributes). > Half > the XML community regards Namespaces as the worst thing since the plague. I suppose, but if we agreed that they solved the problem you describe then maybe less people would hate them. > Because namespaces aren't supposed to point to anything, you can't sneak a > DTD in at the URL identified by the namespace. That's what the DOCTYPE or architectural use declaration is for. Your real complaint is that there is no way to automatically invoke a schema processor based on a namespace declaration alone. My response is that there is also no way to automatically invoke a stylesheet engine or speech-to-text reader. The complaint about pointers to DTDs is only more relevant if you posit that every namespace should always be associated with a single schema and that schema should be a DTD. That can't be the case if we are going to allow non-DTD schemas. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Paul.V.Biron at kp.ORG Thu Jan 21 00:34:52 1999 From: Paul.V.Biron at kp.ORG (Biron,Paul V) Date: Mon Jun 7 17:07:49 2004 Subject: Word and XML (was: XML standards coherency and so forth) Message-ID: <36a675341a48002@laurel.kp.org> > From: "Ogievetsky, Nikita" <nikita.ogievetsky@csfb.com> > Date: Wed, 13 Jan 1999 12:37:06 -0500 > Subject: RE: XML standards coherency and so forth > > >Andreas Berg wrote: > > I am searching for a converter from Word documents to XML. Unfortunatly > >I > have > > no time to wait for Office 2000..... Is there something like this > available? > > In the MS Word go to <File>/<Save As> menu, select "Save as HTML > document". > It will create a well formed XML file: HTML with all elements having start > and end tags. > (Just remember to exhume the <body> - sorry for bad joke). > > Nikita Ogievetsky. > Actually, it is very easy to generate a Word '97 document which when saved as HTML will be non-wellformed. Try the following, where *xxx* means "make xxx bold", and _yyy_ means "make yyy italicized". This is *a test _of the* emergency_ broadcast system The relevant portion of the HTML produced by word is <P>This is <B>a test <I>of the</B> emergency</I> broadcast system</P> The "nesting" of the B and I elements is not well-formed. As far as I can tell this works (or doesn't as the case may be) for any format/font changes. Word 97 also produced several well-formedness violations when doing anything more than simple nested lists. pvb SGML Business Analyst Kaiser Permanente, So Cal. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Jan 21 01:57:18 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:07:50 2004 Subject: Next Round Message-ID: <00f401be44e1$3f816e90$2ee044c6@arcot-main> David, >I'd like to lose EntityResolver and DTDHandler (who uses them?), but I >don't know if we can. I don't recommend this. People are using it. >1. Filter Interface I agree with James that DocumentHandler is the appropriate place. >2. Lexical Event Handler Looks good. >Of course, we need a new parser interface that knows about lexical >handlers: Or we could just redefine setDocumentHandler so that LexicalHandler is automatically set if the given DocumentHandler implementation also implements that interface. The two interfaces are strongly related after all. >3. Namespace Support How about this? public interface NamespaceHandler { public void startNamespace(Namespace ns); public void endNamespace(); } public interface Namespace { public String getPrefix(String qname); public String getURI(String qname); } Namespace implemention is responsible for keeping track of inheritance. Again, we can use setDocumentHandler to automatically check for NamespaceHandler implementation. For efficiency sake, we might also require that if NamespaceHandler is supported then all names (tag name, attribute name, namespace prefix and URI) should be 'interned'. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu Jan 21 02:12:32 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:50 2004 Subject: Inserting an image into an XML document In-Reply-To: <Pine.LNX.3.95.990120105835.13917A-100000@mstirling.gsfc.nasa.gov> Message-ID: <000f01be44e2$ea1401f0$d3228018@jabr.ne.mediaone.net> Send an email with an attached image to mailto:test-xmtp@jabr.ne.mediaone.net and it will e-mail you back the (MIME) message including attached image in XML. XMTP defines a MIME<->XML mapping. Jonathan Borden http://jabr.ne.mediaone.net > > > Does anyone know how to insert an image into an XML document? Is this > done in the XSL or the XML? Also, do you have an example that is on the > web of an image actually within the xml or xsl (whichever) document? > > > Dante M. Lee Code 588 > NASA/GSFC Greenbelt MD 20771 > Voice = 301-521-1077 Bldg = 23 Rm = W415 > Email = dante@mstirling.gsfc.nasa.gov > dante4@hotmail.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 02:53:53 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:50 2004 Subject: Next Round Message-ID: <004f01be44e8$ba245fc0$c9a8a8c0@thing2> Lexical Event Handler ------------------------ I think it would be particularly handy if LexicalProcessor extended DocumentHandler. Given a document handler object, the parser could simply check to see if it was also an instance of LexicalProcessor and, if it was, pass it the additional events. My reasoning here is that many of the events associated with LexicalProcessor would likely need to pass through the same filters as the DocumentHandler events. Mmm. Perhaps this could better be handled by splitting off the start/endDTD events and placing them on an extension of DTDHandler. Basically, I agree here with Don Park. Namespace Support -------------------- Why not support Namespaces through a filter? Why put everything into a monilithic parser? If we have good support for filters, then we can have a reasonable scope for parsers and allow applications to configure their filters to meet their particular needs. Filter Interface ------------------- We are looking at building trees of event filters in MDSAX, with event processing dependent on document type, element type, and other application-specific considerations. An api which constrains filters to a simple sequence doesn't really get us where we want to go. Our hope is to support a variety of filter implementations, with the glue code hidden in the filter factory which supports this interface: public interface MDFilterFactory { /** * Creates a chained document handler (a filter). */ public DocumentHandler createFilter(MDContext context, DocumentHandler nextHandler); } The third alternative, where filters extend DocumentHandler, would certainly be the easiest to accomodate. And if LexicalProcessor extends DocumentHandler, then Filter should extend LexicalProcessor. This would really be ideal! Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 02:57:31 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:50 2004 Subject: SAX: Next Round In-Reply-To: <36A65A55.E5445A28@locke.ccil.org> References: <199901202122.QAA00962@megginson.com> <36A65A55.E5445A28@locke.ccil.org> Message-ID: <13990.38254.660176.629594@localhost.localdomain> John Cowan writes: > David Megginson scripsit: > > > I'd like to lose EntityResolver and DTDHandler (who uses them?), > > but I don't know if we can. > > Nope, nope, nope. In particular, I still have a project to finish > a standard EntityResolver that understands Socats. By having such > a thing, you can fit Socat support into arbitrary applications > using arbitrary SAX parsers. Keep it. As for DTDHandler, it > exposes stuff that XML 1.0 requires a parser to expose. Yes, yes, yes, I know -- I've made the same argument before in many places. In retrospect, I think that unparsed entities and notations were a mistake for XML (there are less opaque and more web-friendly ways to accomplish the same thing), but they're there in the REC and, as you say, the spec is quite explicit about reporting requirements. I was just fantasising out loud... > > 1. Filter Interface > > I propose a fourth alternative: provide ParserFilter as a helper > class, and don't have a separate interface. Parser filters are > just parsers that have a "parser(Parser)" constructor. Yes, but what interface should the helper class implement? Will have have a hard-coded level-two parser interface that knows about namespace and lexical handlers? What if we add another standard capability in the future? The advantage of a separate interface is that it's easy to mix and match; the disadvantage of a separate interface is also that it's easy to mix and match. > One particularly nice feature of this is that it is the pattern > used by Java {Input,Output}Streams and Readers/Writers: Chain of > Responsibility. I agree -- chain of responsibility is a great benefit of the filter approach, however we manage it. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 02:59:38 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:50 2004 Subject: SAX: Next Round In-Reply-To: <199901202256.RAA24759@volcano.East.Sun.COM> References: <199901202256.RAA24759@volcano.East.Sun.COM> Message-ID: <13990.38569.432819.386859@localhost.localdomain> James Williams - Sun East Coast IR Development writes: > How about adding the capabililty to register multiple > handlers of a given type with a parser instance? The parser > would send the event to the handlers in the order they were > registered. This is actually easy to handle with a special filter on top of any SAX implementation (as is namespace processing, for that matter). > I think it would aid in the development of modular, > re-usable handlers if you could register more than one with > a parser. I disagree with this point -- I think that the filter approach goes much further towards general-purpose, reusable handlers; that said, there are other benefits to broadcasting events (such as doing two completely different things with the same input stream). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 03:03:02 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:50 2004 Subject: Next Round In-Reply-To: <00f401be44e1$3f816e90$2ee044c6@arcot-main> References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> Message-ID: <13990.38710.290365.535530@localhost.localdomain> Don Park writes: > Or we could just redefine setDocumentHandler so that LexicalHandler is > automatically set if the given DocumentHandler implementation also > implements that interface. The two interfaces are strongly related after > all. That's a bit Java-specific -- not all languages actually allow you to dynamically determine this sort of thing at runtime. > >3. Namespace Support > > > How about this? > > public interface NamespaceHandler { > public void startNamespace(Namespace ns); > public void endNamespace(); > } > > public interface Namespace { > public String getPrefix(String qname); > public String getURI(String qname); > } That's really one level higher -- in general, SAX provides information at the lowest possible level so that implementations can build on top of it. > For efficiency sake, we might also require that if NamespaceHandler is > supported then all names (tag name, attribute name, namespace prefix and > URI) should be 'interned'. The trouble is that Java's intern, at least in 1.1, is incredibly inefficient -- it turned up as one of the biggest bottlenecks back when I was profiling AElfred -- so any parser writer worth his/her salt is implementing a separate intern anyway. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 21 03:22:57 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:50 2004 Subject: Next Round References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> Message-ID: <36A69CC4.1F8A0CF6@infinet.com> Don Park wrote: > >3. Namespace Support > > How about this? > > public interface NamespaceHandler { > public void startNamespace(Namespace ns); > public void endNamespace(); > } > > public interface Namespace { > public String getPrefix(String qname); > public String getURI(String qname); > } > > Namespace implemention is responsible for keeping track of inheritance. > Again, we can use setDocumentHandler to automatically check for > NamespaceHandler implementation. > > For efficiency sake, we might also require that if NamespaceHandler is > supported then all names (tag name, attribute name, namespace prefix and > URI) should be 'interned'. This is a good idea. I have been thinking alot about how to implement this in the native parser interface for an XML Parser I have written in a manner that is efficient yet easy to use. My recommendation to SAX is a little more radical. In this sense Parser should not be extended but instead you now have an additional NamespaceParser which is of its own type. This is the clean way of doing things since you cannot dynamically know if a SAX Parser implementation also supports namespaces. Maybe there is a way, but it would be a pain to handle. Plus a lot of XML parsers do not have namespaces built in and may never have namespaces support. In this case some sort of Namespaces filter could be used to supplement the native support for namespaces that the parser does not support. First, we will need to define a new type, namely Name. public interface Name { String getPrefix(); String getLocalName(); String getQualifiedName(); String getNamespace(); String getExpandedName(); Name clone(); } Then change the startElement method to: void startElement(Name name, AttributeList attributes); and the endElement method to: void endElement(Name name); also the AttributeList interface may need to be changed a bit: the method getName() will need to be changed from: String getName(int index); to: Name getName(int index); Also for the getType(String name) and getValue(String name) methods will need to be changed and made to: String getTypeByQualifiedName(String prefix, String localName); // prefix + ':' + localName String getTypeByQualifiedName(String qualifiedName); String getTypeByExpandedName(String namespace, String localName); // namespace + ':' + localName String getTypeByExpandedName(String expandedName); String getValueByQualifiedName(String prefix, String localName); // prefix + ':' + localName String getValueByQualifiedName(String qualifiedName); String getValueByExpandedName(String namespace, String localName); // namespace + ':' + localName String getValueByExpandedName(String expandedName); Note: these method names are quite long and could be improved but I do not have any better ideas off of the top of my head for now. Names could lazily return the String values of the prefix, local name, qualified name, namespace, and expanded name. For startElement and endElement the parser itself could implement Name as Names would be fail fast. For the attribute method Name getName(int index) a new name would need to be created, or at least you could not cache those Name objects for resuse until the startElement method returns. >From my initial thoughts on this, this would allow applications to get at both the non-namespace processed values as well as the processed namespace values. For parsing an XML Document into a DOM tree, preserving the true document structure is very necessary and who knows, maybe the DOM will do something like this later down the line so you can get at element names in a variety of ways. One last nidpick... Should SAX ignore treat namespace declaration attributes as part of the AttributeList (having namespace declarations declared as attributes is one of the many things I detest about "Namespaces in XML" as it makes things very, very, very, very, very sloppy and unclean to deal with like in this particular case) or else pretend they are not really there. Regards, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 21 03:54:55 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:50 2004 Subject: Next Round References: <004f01be44e8$ba245fc0$c9a8a8c0@thing2> Message-ID: <36A6A449.99A881FE@infinet.com> Bill la Forge wrote: > Namespace Support > -------------------- > > Why not support Namespaces through a filter? Why put everything into a monilithic parser? > If we have good support for filters, then we can have a reasonable scope for parsers and > allow applications to configure their filters to meet their particular needs. Well, if the namespaces recommendation was done intelligently, you could do exactly what you are saying without bearing a major cost in processing efficiency. Just one more reason why "Namespaces in XML" should be scrapped and the W3C should have the courage to start over. The way things are currently defined, you pretty much have to do namespaces at the parser level. This whole namespaces issue got me to thinking about a movie on HBO I saw a few weeks called the Pentagon Wars. It was about a general in the U.S. Army (Kelsey Grammer) who was in charge or developing and procuring the Bradley fighting vehicle. A colonel in the U.S. Air Force (the actor who played Robin Hood in Mel Brooks' Robin Hood Men in Tights) was commissioned by congress to test the safety and effectiveness of the Bradley fighting vehicle. The entire movie the general did whatever he could to sabotage the colonel's tests (the colonel was commissioned to provide a level of interdpeartmental objectivity) so that the truth that the Bradley fighting vehicle was an unsake hunk of junk would never be known. The reasons for the general's actions (as well as many others around him) was that he did not want to lose face professionally considering that the United States had already spent close to 20 years and 20 billion dollars developing this one weapon that did not even work (this movie was based on a true story that occurred during the Reagan era). Basicly the three-star general would never become a four start general if Casper Weinberger (secretary of defense) ever found out that he had not succeeded. Eventually of course someone would find out but not until he got his promotion and then it would be someone else's problem even if there was a war with the Soviet Union and massive casualties occurred in units who operated the Bradley fighting vehicle which had no armor, emitted poisoned gas when hit (burning aluminum), and blew up entirely upon one hit from a small shell. "Namespaces in XML" seems to be going down this path as no one will admit that it is a massive failure. We either bite the bullet and start over now, or else the entire world pays for it later because a few people could not admit that their solution is less than adequate. I honestly pray the W3C does not operate with the politics of the Pentagon. It is funny because I have had many offline remarks that concur with my feelings, probably because these people are afraid of retribution for not marching in lock step with a standards organization. This reminds me a lot of another general in "Pentagon Wars" who was secretly feeding the colonel information about how crappy the Bradley fighting vehicle really was. He was afraid that he would have his reputation smeared if he did not just "go along with everyone else". Nevertheless, everyone seems to be jumping on this grand bandwagon of eventual failure, so I might as well jump on myself and say "see I told you so" when down the road people complain about XML being too complex and too sloppy to deal with. Since I am writing an XSL Processor, I pretty much have a gun to my head on this issue on whether or not I support namespaces. The XSL draft says you must support "Namespaces in XML" so I have no choice but to swallow "Namespaces in XML" while I am kicking and screaming. Does anyone else here feel that "Namespaces in XML" is being shoved down their throat? SAX I feel is a success because it was a process of patience, objectivity, and non-political action. I just wish "Namespaces in XML" could share these same ideals. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Thu Jan 21 04:13:42 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:07:50 2004 Subject: SAX: Next Round In-Reply-To: <13990.38569.432819.386859@localhost.localdomain> Message-ID: <000001be44f4$90347ae0$bda8b4d1@yak.ptld.uswest.net> > > I think it would aid in the development of modular, > > re-usable handlers if you could register more than one with > > a parser. > > I disagree with this point -- I think that the filter approach goes > much further towards general-purpose, reusable handlers; that said, > there are other benefits to broadcasting events (such as doing two > completely different things with the same input stream). I agree with David. The event/listener model is useful. But unless it is integral to the API, this kind of thing can be implemented easily outside the API proper. There are times when it is useful to have this kind of functionality included in an API...particularly when you are using a factory and don't have good control over the objects being instantiated. But this doesn't seem to be such a case. I feel that the key issues here are function, not OO design. Ultimately we want the right code to get the right events with a minimum of effort. Since we're dealing *only* with events, it is possible to write adapters and filters to end up with just about any interface imaginable. The question is (in my mind) how to do it so that 80% of uses need no custom adapters. Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 04:19:12 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:50 2004 Subject: OSS vs W3C? was: Next Round Message-ID: <003401be44f4$a9cac5e0$c9a8a8c0@thing2> If the validity of a standard is based on the process which defines it, I suspect that the work done on xml-dev has the greater validity. Open Source Software and vendor controlled standards bodies, IMHO, are a poor marrage. The advantage of Java and XML is that they let you do significant work without the need for a large team effort. Agreement and support of a few large vendors is no longer the significant factor. We need standards. But I suspect the process needs to be updated. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 04:29:24 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:50 2004 Subject: Next Round Message-ID: <004b01be44f6$12cb27a0$c9a8a8c0@thing2> > > Or we could just redefine setDocumentHandler so that LexicalHandler is > > automatically set if the given DocumentHandler implementation also > > implements that interface. The two interfaces are strongly related after > > all. > >That's a bit Java-specific -- not all languages actually allow you to >dynamically determine this sort of thing at runtime. Having LexicalProcessor extend DocumentHandler would be a significant aid in developing a generic filter framework, as it reduces the number of interface combinations that need to be supported. (Filter structures for Document events likely being the same structure needed to support Lexical events.) One way to avoid being too Java-specific would be to support methods for each interface, but adopt the convention that calling either method nullifies the effect of previous calls to both methods. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 04:57:08 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:51 2004 Subject: Next Round Message-ID: <005e01be44f9$f8a71ec0$c9a8a8c0@thing2> What about supporting specified (boolean) in the attribute list? This would mean that XML generated from a DOM would be able to omit default values which were not specified in the input. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Jan 21 06:25:52 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:07:51 2004 Subject: Next Round Message-ID: <004301be4506$bed39450$2ee044c6@arcot-main> >First, we will need to define a new type, namely Name. Turning names into first class objects does solve the namespace problem as well as providing an opportunity to solve the 'intern' problem by adding name comparison methods. Implementations that maintains 'interned' name within Name will obviously be very efficient past the tree building process. It is not a very well known fact that Docuverse DOM SDK uses 'interned' names and it has been very useful to many of our customers although it does cost about 10% speed penalty during tree building. Going beyond the Name interface, I would love to have Data interface which does not force the content data to be turned into 'String' unnecessarily. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 21 07:16:59 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:51 2004 Subject: Next Round References: <004301be4506$bed39450$2ee044c6@arcot-main> Message-ID: <36A6D3AB.6971B04D@infinet.com> Don Park wrote: > >First, we will need to define a new type, namely Name. > > Turning names into first class objects does solve the namespace problem as > well as providing an opportunity to solve the 'intern' problem by adding > name comparison methods. Implementations that maintains 'interned' name > within Name will obviously be very efficient past the tree building process. > It is not a very well known fact that Docuverse DOM SDK uses 'interned' > names and it has been very useful to many of our customers although it does > cost about 10% speed penalty during tree building. > > Going beyond the Name interface, I would love to have Data interface which > does not force the content data to be turned into 'String' unnecessarily. I have had exactly this in my parser interface for a while, namely a CharacterData interface. It has methods for retrieving the content as a character arrays, Strings, normalized character arrays, normalized strings, and support for direct parsing of characters into primitive values like ints, booleans, and floats (this support is there so you are not forced to create a new String object just to parse content into a number with methods like Integer.parseInt(String s)). Not sure if this would be in the realm of SAX since SAX is supposed to be a Simple API for XML, but some sort of character data interface with a lazy data model behind it that at least supports new character arrays, copying, strings, and normalized content would not be such a bad idea. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Jan 21 07:33:48 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:07:51 2004 Subject: Next Round Message-ID: <3.0.32.19990120233555.00f02dfc@pop.intergate.bc.ca> At 10:51 PM 1/20/99 -0500, Tyler Baker wrote: >Well, if the namespaces recommendation was done intelligently ... various opinions excised... > I >honestly pray the W3C does not operate with the politics of the Pentagon. >It is funny because I have had many offline remarks that concur with my >feelings, probably because these people are afraid of retribution for not >marching in lock step with a standards organization. Damn straight. In fact, I can reveal that the W3C has subcontracted with a major sub-unit of the Pentagon (quite a bit of extra time on their hands these days over there) and those boys are monitoring this list vigilantly for the first sign of someone getting out of lock-step. There's now a markup-thoughtcrime massive-retaliation strike force on 24-hour alert hiding behind an NNTP server in Falls Church, so straighten up and fly right, girls 'n' boys. There's a bit of a problem in that xml-dev is hosted in a Foreign Country, but they're working on leveraging the NATO liaison; so the kind of dangerous anarchy we've seen around here can't last long, thank goodness. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Thu Jan 21 09:00:24 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:51 2004 Subject: OSS vs W3C? was: Next Round Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136A74@eukbant101.ericsson.se> > -----Original Message----- > From: Bill la Forge [SMTP:b.laforge@jxml.com] > > If the validity of a standard is based on the process which defines it, I > suspect that > the work done on xml-dev has the greater validity. > > Open Source Software and vendor controlled standards bodies, IMHO, are a > poor marrage. > The advantage of Java and XML is that they let you do significant work > without the need > for a large team effort. Agreement and support of a few large vendors is > no longer the > significant factor. > > We need standards. But I suspect the process needs to be updated. > It's interesting I was thinking about the very same thing just the other day. Currently our standards as defined by the W3C (and other standards bodies) are defined by effectively locking a group of "members" in a room and waiting until they emerge with something worthwhile. It's a fairly impenetrable room from the outside, even though it's possible at certain stages of the process to make suggestions from the outside - there's no guarantee that those suggestions will even be considered. The "members" tend to be large corporations who have a vested interest in the technology (yes, I know Tim is the exception here). Is this neccessarily a bad thing? I don't know - we've never really experienced anything different. And yet when I compare it to the software world, and read "The Cathedral and The Bazaar", I can't help wondering if developing standards in a Bazaar might be a better model. It would certainly be interesting to try. Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Thu Jan 21 09:20:44 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:51 2004 Subject: XML for dynamic content? Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136A76@eukbant101.ericsson.se> > -----Original Message----- > From: Nigel Byrnes [SMTP:byrnes@prl.research.philips.com] > > Hi all > > We all know the benefits of representing "static" documents in XML. But > considering where [HTML, VRML, etc] content is to be generated on the > fly, as is frequently done by CGI scripts, is XML suitable for encoding > the output data in these types of applications? > > Considering a simple hangman game, the application could either: > > 1. receive user-input and generate XML as output, which then has to be > formated > 2. receive user-input and generate format markup language-content as > output > 3. another possibility? > Why not 1 and 2? That's what our web application here is doing. We use XML because there has to be different levels of processing done on the information stored in the XML. It's highly structured data, so we could have chosen an object database, but i hate making purchase requests, and so XML seemed like a good option. That and we needed to access the data from different platforms and languages (Linux, NT, Perl, VBScript, Java). I developed a solution that allows us to easily edit the XML in a HTML form, and it automatically generates structured XML on the back end - this XML is totally based on the form - there's no processing going on to create structure when processing a form. Currently these solutions are all in Perl, but they are implemented on top of the raw expat API so they should convert easily to other languages. Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Veillard at w3.org Thu Jan 21 09:45:25 1999 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:07:51 2004 Subject: SAX: Next Round In-Reply-To: <199901202122.QAA00962@megginson.com>; from david@megginson.com on Wed, Jan 20, 1999 at 04:22:02PM -0500 References: <199901202122.QAA00962@megginson.com> Message-ID: <19990121044511.C10232@w3.org> > I've been thinking about what new SAX interfaces we need the most > (with much prodding from users). Here's what I think we need as a > minimum: > > 1. A standard filter interface (and perhaps an optional base class). > 2. A handler interface for lexical events like comments, CDATA > sections, and entity references. > 3. Some kind of namespace support. I suggest the following: 4. an IDL definition of the SAX interface to allow a clean interface for non-Java languages (like in the DOM REC). Daniel -- [Yes, I have moved back to France !] Daniel.Veillard@w3.org | W3C INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind, Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Amaya. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 21 10:02:32 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:51 2004 Subject: SAX: Next Round References: <199901202122.QAA00962@megginson.com> <19990121044511.C10232@w3.org> Message-ID: <36A6FA4A.3D10F6F3@infinet.com> Daniel Veillard wrote: > > I've been thinking about what new SAX interfaces we need the most > > (with much prodding from users). Here's what I think we need as a > > minimum: > > > > 1. A standard filter interface (and perhaps an optional base class). > > 2. A handler interface for lexical events like comments, CDATA > > sections, and entity references. > > 3. Some kind of namespace support. > > I suggest the following: > 4. an IDL definition of the SAX interface to allow a clean interface > for non-Java languages (like in the DOM REC). > > Daniel Someone already did this a while back. But I have not heard of it since. Nevertheless, for a set of event interfaces, I am not so sure straight CORBA would do the trick in terms of doing things over the wire. Integrating SAX with the Events Service would probably do the trick here... Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Jan 21 10:09:55 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:51 2004 Subject: OSS vs W3C? was: Next Round References: <5F052F2A01FBD11184F00008C7A4A80001136A74@eukbant101.ericsson.se> Message-ID: <36A6FA82.7AB5B7E4@prescod.net> "Matthew Sergeant (EML)" wrote: > > Is this neccessarily a bad thing? I don't know - we've never really > experienced anything different. And yet when I compare it to the software > world, and read "The Cathedral and The Bazaar", I can't help wondering if > developing standards in a Bazaar might be a better model. It would certainly > be interesting to try. It wouldn't really be an experiment. Many standards are made in more open models. For instance the IETF model is very open. The W3C was formed in large part in reaction to the failure of the IETF HTML working group "bazaar" to complete a post-HTML 2.0 specification. We could argue whether that was a particular failure or systemic. The ISO model is also very open although discussions do not proceed on the Internet to the same extent. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Thu Jan 21 10:41:19 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:07:51 2004 Subject: Fw: XML for dynamic content? Message-ID: <000301be4529$d9bbece0$3902a8c0@oren.capella.co.il> Nigel Byrnes <byrnes@prl.research.philips.com> wrote: >We all know the benefits of representing "static" documents in XML. But >considering where [HTML, VRML, etc] content is to be generated on the >fly, as is frequently done by CGI scripts, is XML suitable for encoding >the output data in these types of applications? > >Considering a simple hangman game, the application could either: > >1. receive user-input and generate XML as output, which then has to be >formated >2. receive user-input and generate format markup language-content as >output >3. another possibility? Attach JavaScript code to the document and have it manipulate the XML tree dynamically through the DOM interface. That's what DHTML does (for an HTML tree instead of an XML tree). It has the advantages of: - Being client side if you want it to (no round trip delay, no server CPU load). - Being server side if you want it (the JavaScript code may contact the server if it wants). - Reduces bandwidth (no need to send the whole XML document just to change the color of a menu entry :-) - Builds on existing standards (ECMAScript). - Allows gateways to external computing resources (to Java at least, and throuh it and JNI to anything else - though I'd love to see a JNI-equivalent directly for JavaScript). - Defining it is easy; no need to create new complex standard. Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Thu Jan 21 10:41:33 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:07:51 2004 Subject: Fw: Generating XML Message-ID: <000201be4529$d94adb90$3902a8c0@oren.capella.co.il> david@megginson.com wrote: >Michael.Kay@icl.com writes: > > > My normal way is to have a "writeXML()" method on the relevant > > object, which calls writeXML() methods on its component objects, > > and so on. A lot depends on how close the java object structure is > > to the desired XML document structure. > >A more elegant (if slightly more verbose) alternative is to have a >separate XMLWriter interface, so that you can write the XML out in >different ways (with or without preserving internal entity references, >etc.). And we already have this interface defined (or 90% of it, at least) - the SAX "parsing events" interface. I really think it should be defined as "DOM tree visitor" interface - the parsing application is just one sample. It is already used as an "XMLWriter" interface in XP, for example. Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Thu Jan 21 10:49:04 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:51 2004 Subject: OSS vs W3C? was: Next Round Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136A7A@eukbant101.ericsson.se> > -----Original Message----- > From: Paul Prescod [SMTP:paul@prescod.net] > > "Matthew Sergeant (EML)" wrote: > > > > Is this neccessarily a bad thing? I don't know - we've never > really > > experienced anything different. And yet when I compare it to the > software > > world, and read "The Cathedral and The Bazaar", I can't help wondering > if > > developing standards in a Bazaar might be a better model. It would > certainly > > be interesting to try. > > It wouldn't really be an experiment. Many standards are made in more open > models. For instance the IETF model is very open. The W3C was formed in > large part in reaction to the failure of the IETF HTML working group > "bazaar" to complete a post-HTML 2.0 specification. We could argue whether > that was a particular failure or systemic. > I think that failure occured because of in-fighting between Microsoft and Netscape who both had too much power in that group (my humble opinion). I don't think it's /quite/ the same though. A re-reading of The Cathedral and The Bazaar will tell you the following points which I think could apply well to specification development process: - Release early, release often. And listen to your customers. Sure we get interim releases of the specs, but for example XSL changed quite dramitically between versions, and we the end users don't get wind of that until much later (perhaps one consequence of this is that it's the big corporate members of the standards organisations who get to build the tools first, and become de-facto). A better release schedule would be a constant release model. Everyone always has access to the current release of the spec. Spelling mistakes and all <g>. And listening to your customers is *v. important*. - Given a large enough beta-tester and co-developer base, almost every problem will be characterised quickly, and the fix obvious to someone. If the process just occured on ordinary public mailing lists this would be true I think. Having said all this I do think the XML spec is a triumph of a closed team, although I personally would have disposed of <!NOTATION>... Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From didier at cln46ae.der.edf.fr Thu Jan 21 11:07:21 1999 From: didier at cln46ae.der.edf.fr (Didier BOLF) Date: Mon Jun 7 17:07:51 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? Message-ID: <199901211205.MAA08993@cln46ms.der.edf.fr> > > Last year in May, Mike Kay made a parser benchmark with a > > simple SAX 1.0 application. The bench was between AElfred, Lark, MSXML, > > xml4j and XP and at the time XP was the fastest. Perhaps he could do the > > benchmark again? > > It so happens I did some recent measurements (different data file) as > follows: > > SAX parsers: > xp 4387 ms > oracle 7862 ms > xml4j 7771 ms > sun 3736 ms > > DOM implementations: > sun 9634 ms > xml4j 11677 ms > oracle 9784 ms > docuverse 10685 ms (using xp parser) Thanks. And what is your bench configuration? Parser versions, computer, OS, memory, JVM, ...? Best regards. Didier Bolf. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 11:47:16 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:51 2004 Subject: Next Round In-Reply-To: <004f01be44e8$ba245fc0$c9a8a8c0@thing2> References: <004f01be44e8$ba245fc0$c9a8a8c0@thing2> Message-ID: <13991.4785.521557.223113@localhost.localdomain> Bill la Forge writes: > Namespace Support > -------------------- > > Why not support Namespaces through a filter? Why put everything > into a monilithic parser? If we have good support for filters, > then we can have a reasonable scope for parsers and allow > applications to configure their filters to meet their particular > needs. I think that there is a reasonable probability that many parsers will already be handling namespace processing internally, so it would be more efficient to be able to take advantage of their work rather than duplicating it in an external filter. > Filter Interface > ------------------- > > We are looking at building trees of event filters in MDSAX, with > event processing dependent on document type, element type, and > other application-specific considerations. An api which constrains > filters to a simple sequence doesn't really get us where we want to > go. All you need is one standard broadcast filter and you're set -- think of tee-joints in a pipeline. > And if LexicalProcessor extends DocumentHandler, then Filter should > extend LexicalProcessor. This would really be ideal! I'm a little nervous, though, about pouring concrete over our design like this -- I'd like to keep it a little more modular, especially with schemas still far from being resolved. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 11:49:40 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:51 2004 Subject: Next Round In-Reply-To: <36A69CC4.1F8A0CF6@infinet.com> References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> Message-ID: <13991.5020.462694.966202@localhost.localdomain> Tyler Baker writes: > First, we will need to define a new type, namely Name. > > public interface Name { > String getPrefix(); > String getLocalName(); > String getQualifiedName(); > String getNamespace(); > String getExpandedName(); > Name clone(); > } [...] I proposed something like this early on as well, but have since backed away from it. I like to keep SAX very dumb and low level, so that other APIs (like SAXON or MDSAX) can build on top of it with little constraint. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 11:53:31 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:52 2004 Subject: Next Round In-Reply-To: <005e01be44f9$f8a71ec0$c9a8a8c0@thing2> References: <005e01be44f9$f8a71ec0$c9a8a8c0@thing2> Message-ID: <13991.5284.951445.738337@localhost.localdomain> Bill la Forge writes: > What about supporting specified (boolean) in the attribute list? > > This would mean that XML generated from a DOM would be able to > omit default values which were not specified in the input. Ah, yes -- I knew that I was forgetting something from the DOM. Unfortunately, this makes backwards-compatibility quite a bit messier. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 21 12:48:38 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:52 2004 Subject: SAX: Next Round In-Reply-To: <199901202122.QAA00962@megginson.com> Message-ID: <199901211248.HAA11653@hesketh.net> At 04:22 PM 1/20/99 -0500, david@megginson.com wrote: >I've been thinking about what new SAX interfaces we need the most >(with much prodding from users). I'm very pleased to see this project getting going again. >Here's what I think we need as a >minimum: > >1. A standard filter interface (and perhaps an optional base class). >2. A handler interface for lexical events like comments, CDATA > sections, and entity references. >3. Some kind of namespace support. > >I'd like to lose EntityResolver and DTDHandler (who uses them?), but I >don't know if we can. I'd really prefer to go the other direction. In the course of writing and working with filters, I've come to see them as a very powerful tool that is hampered to a significant degree by the total lack of DTD information that comes out of the parser. Even if it's optional, I would _very_ much like to see a set of events for DTD declarations - <!ELEMENT, <!ATTRIBUTE, etc. If necessary, I'd be willing to do a lot of work in this area - after I finish the current crushing load of books. See http://www.simonstl.com/articles/layering/layered.htm for some of the reasons I'd like access to this information. Please keep in mind that it's a very rough draft. > >1. Filter Interface >------------------- I think you may be doing too much to the filters themselves here; I'd really prefer to see this coordination performed by an external framework, like MDSAX (http://www.jxml.com/mdsax/). >2. Lexical Event Handler >------------------------ > >What do we really need here? > > public interface LexicalHandler > { > public void startDTD (String name, String pubid, String sysid) > throws SAXException; > public void endDTD (String name); > public void startExternalEntity (String name, String pubid, String sysid) > throws SAXException; > public void endExternalEntity (String name) throws SAXException; > public void startCDATA () throws SAXException; > public void endCDATA () throws SAXException; > public void comment (String data) throws SAXException; > } > >I haven't checked, but I think that this gives us everything we need >for DOM level one. I'd like to have startInternalEntity as well; coupled with the DTD declarations I mentioned above, it would let applications that found they actually needed an external resource for processing get it, even in a non-validating environment that didn't do that by default. Also, going back to the DTD events, it would be useful to know which attributes had assigned values and which were defaulted; I believe this is also a DOM Level One issue. >3. Namespace Support >-------------------- This seems like something better done by a filter layer, provided we can describe what the results of that processing should be. It may take extension of the API, or it may just take modification of element names, as in John Cowan's NamespaceFilter (http://www.ccil.org/~cowan/XML/). Glad this is going again; SAX 1.0 did a great job for what it did, but I'd like to see it present a more complete picture of documents. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 21 13:02:56 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:52 2004 Subject: OSS vs W3C? was: Next Round In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136A74@eukbant101.ericss on.se> Message-ID: <199901211302.IAA11792@hesketh.net> At 10:00 AM 1/21/99 +0100, Matthew Sergeant (EML) wrote: > It's interesting I was thinking about the very same thing just the >other day. Currently our standards as defined by the W3C (and other >standards bodies) are defined by effectively locking a group of "members" in >a room and waiting until they emerge with something worthwhile. [...] > > Is this neccessarily a bad thing? I don't know - we've never really >experienced anything different. And yet when I compare it to the software >world, and read "The Cathedral and The Bazaar", I can't help wondering if >developing standards in a Bazaar might be a better model. It would certainly >be interesting to try. XML-Dev has had two such open efforts I'd call successful - SAX and XSchema. While XSchema (now submitted to the W3C as DDML) hasn't recieved the broad implementation SAX has - it's a much more crowded field, the standard-building process definitely had an effect on the way the XML world, including the W3C, looks at schemas. For more on DDML and the process used to build it, see http://purl.oclc.org/NET/ddml. (Yes, I'll be updating the page to reflect acceptance of XSchema as the DDML note shortly.) Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 21 13:41:37 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:52 2004 Subject: Next Round References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <13991.5020.462694.966202@localhost.localdomain> Message-ID: <36A72D7C.7996203B@infinet.com> david@megginson.com wrote: > Tyler Baker writes: > > > First, we will need to define a new type, namely Name. > > > > public interface Name { > > String getPrefix(); > > String getLocalName(); > > String getQualifiedName(); > > String getNamespace(); > > String getExpandedName(); > > Name clone(); > > } > > [...] > > I proposed something like this early on as well, but have since backed > away from it. I like to keep SAX very dumb and low level, so that > other APIs (like SAXON or MDSAX) can build on top of it with little > constraint. I agree totally with you except for the fact that namespaces automatically makes XML no longer dumb or necessarily low-level. The main reason for this suggestion is that the alternative is for applications to manage namespace processing themselves or else dump some filter on top which may add major inefficiencies. Before making any judgement on this regarding MDSAX or SAXON, I would ask Michael Kay and Bill la Forge what they think about a Name type and anyone else who has written some higher-level API's for XML (this includes DOM implementors). I know that with an XSL Processor I have been working on which has SAX support for building the stylesheet tree, a specific Name type would help out alot in implementing the "Namespaces in XML" parts of constructing the result tree. Another major reason for doing Names this way is that for objects (perhaps beans) may have no global idea of what the current namespace they are to be applied to. If you attach a Name type, when spitting out XML you can automatically construct the namespace nodes (attribute namespace declarations) as needed (note, I am not speaking about XSL right now). Of course you can do all of this on top of SAX, but it may be inefficient and certainly very much unnatural for developers using SAX in applications to handle. "Namespaces in XML" is complicated enough as it is so I feel that making an effort at simplifying things as much as possible for the end user would do a great deal of justice in presenting something so complicated to handle in a simple way. Last but not least, for DOM implementations that are built with SAX and may have proprietary namespaces support (don't know when or if the DOM will have any kind of namespace awareness in the future) it would really help these folks out a lot. Docuverse SDK would be just one off the top of my head. The point here is that pretty much anyone who uses "Namespaces in XML" (which I feel will likely be less than 1% of the XML user community in the future if even that high) will have to deal with the myriad of problems that "Namespaces in XML" creates one way or another. I would prefer to try and remove as much complexity from the application developer as possible so that using "Namespaces in XML" will not be too much of a pain (most people I don't think will accept the toothache and instead stay away from "Namespaces in XML" altogether). Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From byrnes at prl.research.philips.com Thu Jan 21 14:48:17 1999 From: byrnes at prl.research.philips.com (Nigel Byrnes) Date: Mon Jun 7 17:07:52 2004 Subject: XML for dynamic content? References: <36A619E2.81EB0E2D@prl.research.philips.com> <36A64113.5DEC3A80@zveno.com> Message-ID: <36A73CA0.931D0ACC@prl.research.philips.com> Hi steve Thanks for your reply to my mail. i have one question: Steve Ball wrote: > Firstly, it is just as easy to generate XML dynamically in a CGI script (or equivalent > server-side mechanism) as it is to generate HTML. Perhaps even easier since > DOM implementations will probably provide a serialise method which does most of > the tedious work for you. I agree that it is as simple to generate XML as HTML (or any other FML) from a CGI script. But can you tell me why this task would be even more straight forward with DOM. (Apologies if the answer to this question is blindingly obvious, but i'm not a DOM expert) > Cheers, > Steve Ball -- Nigel Byrnes "We continue..." Pete Tong Software Engineering and Applications Group, Philips Research Labs, Redhill. Tel: +44 (0)1293 815578 RH1 5HA. Fax: +44 (0)1293 815024 UK. GSM: +44 (0)7899 940391 Email: byrnes@prl.research.philips.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jan 21 15:41:04 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:07:52 2004 Subject: Next Round In-Reply-To: <36A6A449.99A881FE@infinet.com> (message from Tyler Baker on Wed, 20 Jan 1999 22:51:37 -0500) Message-ID: <199901211539.KAA09173@ruby.ora.com> As someone completely uninvolved with the Namespaces development, I find your rhetoric pretty funny. I especially liked the bit about dying childless at 40. What, exactly, are the problems with the draft? It provides a scheme for uniquely naming objects. When I say, "html:a", I mean the anchor element from HTML; when I say, "faq:a", I mean the answer element from the FAQ ML. Just like when, in the context of HTML, I say "p", I mean the paragraph from HTML. If you know what to do with "the anchor element from HTML", you do it, if not, you don't. Why are namespace- derived names harder to handle than any other system of naming? As far as I can tell, the biggest problem is the possibility that a prefix's meaning can change within a document. But your processor should be operating on URI+suffix, not the prefix, and changing a mapping table can't be *that* hard. True, I'm not a sophisticated programmer, and I may be overlooking something. But I have a hard time seeing Tim Bray and James Clark bulled by political pressure, even (especially?) from Microsoft. In short, can we try to keep the discussion, at least on this list, to concrete technical issues? -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Thu Jan 21 15:43:14 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:07:52 2004 Subject: XML for dynamic content? In-Reply-To: <000601be44ba$d7ed1fc0$d636bfa8@arabbit> References: <36A619E2.81EB0E2D@prl.research.philips.com> Message-ID: <3.0.1.32.19990120185034.00952be0@mail.accessone.com> Isn't there a W3C working group on something called xml fragments? Don't know if it's the same idea you have here though. Dave LeBlanc At 04:21 PM 1/20/99 -0500, Paul Butkiewicz wrote: <snip> >But on a "dreaming" sort of note, suppose the client's browser was working >on the XML directly, either because the HTML was embedded with XML tags or >because the client's browser is working off of style sheets as well. >Wouldn't it be cool if you could somehow update just a fraction of the XML >document? Suppose you could just retrieve the document element pertaining >to the hangman or the word (to borrow from your example) and just >re-retrieve that part of the document rather than the whole thing. Wouldn't >that be cool? > >Paul xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 21 16:08:04 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:52 2004 Subject: Forums In-Reply-To: <199901211539.KAA09173@ruby.ora.com> References: <36A6A449.99A881FE@infinet.com> Message-ID: <199901211605.LAA14418@hesketh.net> At 10:39 AM 1/21/99 -0500, Chris Maden wrote (re Namespaces): >True, I'm not a sophisticated programmer, and I may be overlooking >something. But I have a hard time seeing Tim Bray and James Clark >bulled by political pressure, even (especially?) from Microsoft. A key problem, however, is that none of us outside the charmed circle can see in, leaving us to draw our own conclusions about who is doing the bullying, if in fact there is any. This does little to enhance the W3C's credibility or that of Tim Bray, James Clarke, or Microsoft. >In short, can we try to keep the discussion, at least on this list, to >concrete technical issues? It's a good idea - but where exactly should we go with the more abstract and political stuff? There isn't a forum, and even if there was, what assurances would there be that the W3C (or anyone else in fact) would be listening? Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu Jan 21 16:30:42 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:52 2004 Subject: OSS vs W3C? was: Next Round In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136A74@eukbant101.ericsson.se> Message-ID: <001a01be4544$ebf46e30$d3228018@jabr.ne.mediaone.net> > > > > If the validity of a standard is based on the process which > defines it, I > > suspect that > > the work done on xml-dev has the greater validity. > > > > Open Source Software and vendor controlled standards bodies, IMHO, are a > > poor marrage. Not always, take JPEG for example, a standard with an excellent reference implementation. > > The advantage of Java and XML is that they let you do significant work > > without the need > > for a large team effort. Agreement and support of a few large vendors is > > no longer the > > significant factor. Same for JavaScript and XML or C++ and XML for that matter. > > > > We need standards. But I suspect the process needs to be updated. > > > Currently our standards as defined by the W3C (and other > standards bodies) are defined by effectively locking a group of > "members" in > a room and waiting until they emerge with something worthwhile. ... The "members" > tend to be large corporations who have a vested interest in the technology > (yes, I know Tim is the exception here). There are smart and capable people at large corporations, small start-ups and individuals. Perhaps a better solution would be to provide more flexibility in the standards organization or WG membership. If people are donating their time and contributing code, their ought not be a large financial donation required as well. But that's politics. > > Is this neccessarily a bad thing? I don't know - we've never really > experienced anything different. And yet when I compare it to the software > world, and read "The Cathedral and The Bazaar", I can't help wondering if > developing standards in a Bazaar might be a better model. It > would certainly > be interesting to try. > > Matt. Compare SAX vs. DOM for a direct example. Both have their places. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Jan 21 16:37:20 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:52 2004 Subject: Next Round References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> Message-ID: <36A75899.9D1CF338@mecomnet.de> yes, but... Tyler Baker wrote: > > Don Park wrote: > > First, we will need to define a new type, namely Name. > > public interface Name { > String getPrefix(); // inappropriate > String getLocalName(); > String getQualifiedName(); // inappropriate > String getNamespace(); > String getExpandedName(); > Name clone(); > } Neither the prefix nor the qualified name have the same permanence as the local name, the namespace and the expanded name. One could well collect all prefixes in connection with which as symbol appeared, but the values are of no use as the bindings have dynamic extent. the prefix and the qualified name need to be handled separately, through an interface which combines symbols (here called names) with a dynamic parsing or serialization context. The other additions have to be modified accordingly: as the prefix has no meaning outside of the parser's dynamic context, those interfaces have no purpose. I know the spec gives you no binding for a prefix to a uri within the dtd, but using the prefix is worse setting some binding rules and sticking to them. Setting binding rules yields the same results as using the perfix in cases which are unambiguous, offers a consistent interfaces, and - by virtue of the bindings rules - at least yields defined results in cases where using the prefix would yields an undefined result due to ambiguity. Three arguments for the approach and none against. > > Then change the startElement method to: > > ... > this, for example, is defined only at the moment the element is being processed. outside of the element's scope there is no defined result. > String getTypeByQualifiedName(String prefix, String localName); > // prefix + ':' + localName > String getTypeByQualifiedName(String qualifiedName); > It would be better to use functions like the following (the results of which are always defined) > String getTypeByExpandedName(String namespace, String localName); > // namespace + ':' + localName > String getTypeByExpandedName(String expandedName); The former can be combined with a function to determine the uri bound to a prefix - if need be. In my experience this latter function is of no use to an application, as an application operates is better operating in terms of the universal names only. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 16:39:28 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:52 2004 Subject: Next Round Message-ID: <000801be454e$070b4fa0$c9a8a8c0@thing2> My personal experience is that things are ever so much easier when addressed at the appropriate level. And in particular, replacing a name string with an object that can be subclassed means that an API can be extended very cleanly. This means that it might be sufficient simply to replace tag and attribute names with objects that hold the name string, and then define an extended interface that can be used for namespaces. Again the objection that this is too Java specific? I would say that for non-Java languages, the base interface should also support an additional method, say isInstanceOf. Nothing as heavy as the MS IUnknown is needed. Then to raise again a previous suggestion from Don, we could simply extend the functionality of the Parser.setDocumentHandler method by checking to see if the lexical processor interface is implemented. And again, for non-Java languages, the DocumentHandler interface should implement an isInstanceOf method. Refining this further, we could have an interface that is only useful for non-Java languages: public interface nonJava { public boolean isInstanceOf(String interfaceName); } This then could be the base interface for all SAX interfaces, when not using Java. (I would NOT want to do this in Java, as the instanceOf operator is very convenient.) Bill -----Original Message----- From: Tyler Baker <tyler@infinet.com> To: david@megginson.com <david@megginson.com> Cc: Don Park <donpark@quake.net>; XML Developers' List <xml-dev@ic.ac.uk> Date: Thursday, January 21, 1999 8:45 AM Subject: Re: Next Round >david@megginson.com wrote: > >> Tyler Baker writes: >> >> > First, we will need to define a new type, namely Name. >> > >> > public interface Name { >> > String getPrefix(); >> > String getLocalName(); >> > String getQualifiedName(); >> > String getNamespace(); >> > String getExpandedName(); >> > Name clone(); >> > } >> >> [...] >> >> I proposed something like this early on as well, but have since backed >> away from it. I like to keep SAX very dumb and low level, so that >> other APIs (like SAXON or MDSAX) can build on top of it with little >> constraint. > >I agree totally with you except for the fact that namespaces automatically >makes XML no longer dumb or necessarily low-level. The main reason for >this suggestion is that the alternative is for applications to manage >namespace processing themselves or else dump some filter on top which may >add major inefficiencies. Before making any judgement on this regarding >MDSAX or SAXON, I would ask Michael Kay and Bill la Forge what they think >about a Name type and anyone else who has written some higher-level API's >for XML (this includes DOM implementors). I know that with an XSL >Processor I have been working on which has SAX support for building the >stylesheet tree, a specific Name type would help out alot in implementing >the "Namespaces in XML" parts of constructing the result tree. > >Another major reason for doing Names this way is that for objects (perhaps >beans) may have no global idea of what the current namespace they are to >be applied to. If you attach a Name type, when spitting out XML you can >automatically construct the namespace nodes (attribute namespace >declarations) as needed (note, I am not speaking about XSL right now). Of >course you can do all of this on top of SAX, but it may be inefficient and >certainly very much unnatural for developers using SAX in applications to >handle. "Namespaces in XML" is complicated enough as it is so I feel that >making an effort at simplifying things as much as possible for the end >user would do a great deal of justice in presenting something so >complicated to handle in a simple way. Last but not least, for DOM >implementations that are built with SAX and may have proprietary >namespaces support (don't know when or if the DOM will have any kind of >namespace awareness in the future) it would really help these folks out a >lot. Docuverse SDK would be just one off the top of my head. > >The point here is that pretty much anyone who uses "Namespaces in XML" >(which I feel will likely be less than 1% of the XML user community in the >future if even that high) will have to deal with the myriad of problems >that "Namespaces in XML" creates one way or another. I would prefer to >try and remove as much complexity from the application developer as >possible so that using "Namespaces in XML" will not be too much of a pain >(most people I don't think will accept the toothache and instead stay away >from "Namespaces in XML" altogether). > >Tyler > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Thu Jan 21 16:45:15 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:07:52 2004 Subject: Forums In-Reply-To: <199901211605.LAA14418@hesketh.net> References: <199901211539.KAA09173@ruby.ora.com> <36A6A449.99A881FE@infinet.com> Message-ID: <3.0.1.32.19990121114429.01000360@pop.uunet.ca> At 11:08 AM 1/21/99 -0500, Simon St.Laurent wrote: >At 10:39 AM 1/21/99 -0500, Chris Maden wrote (re Namespaces): >>True, I'm not a sophisticated programmer, and I may be overlooking >>something. But I have a hard time seeing Tim Bray and James Clark >>bulled by political pressure, even (especially?) from Microsoft. > >A key problem, however, is that none of us outside the charmed circle can >see in, leaving us to draw our own conclusions about who is doing the >bullying, if in fact there is any. This does little to enhance the W3C's >credibility or that of Tim Bray, James Clarke, or Microsoft. > >>In short, can we try to keep the discussion, at least on this list, to >>concrete technical issues? > >It's a good idea - but where exactly should we go with the more abstract >and political stuff? There isn't a forum, and even if there was, what >assurances would there be that the W3C (or anyone else in fact) would be >listening? There are plenty of people who participate in the W3C who are listening. There have been numerous occasions when discussions on this list have been brought up in W3C WG calls/meetings. This is an incredibly useful list, and I think that we would ignore it at our peril. Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Jan 21 16:52:38 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:53 2004 Subject: Next Round References: <004f01be44e8$ba245fc0$c9a8a8c0@thing2> <36A6A449.99A881FE@infinet.com> Message-ID: <36A75C34.2B967693@mecomnet.de> there are some of us who believe that this is where such processing well belongs. my misgivings about the spec (expressed at length in the past) have little to with the model required to implement it - which is, as i've recounted in the past, quite simple. it has to do with the barouqness and the incompleteness of the encoding. Tyler Baker wrote: > > Bill la Forge wrote: > > > Namespace Support > > -------------------- > > > > Why not support Namespaces through a filter? Why put everything into a monilithic parser? > ... The > way things are currently defined, you pretty much have to do namespaces at the parser level. > as well should be done. > ... Does anyone else here feel that "Namespaces in XML" > is being shoved down their throat? Yes, but not for the reasons you note. I regret having to implement a spec which is incomplete. I also note that many of the complaints about it are analogous to complaining that it is more complicated to code for a domain where numbers are represented in packed decimal form, binary integer, and ascii base x, while simultaneously refusing to recognizes that the role of a parser is to transform into a uniform, easily manipulated representation. i recognize that both the multi gigabyte filtering applications and the 64K smart-card applications are in a different ballbark, and might not agree to these sentiments, but by the same token, I see no reason that a well structured sdk have to play by those extreme rules. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Thu Jan 21 16:59:00 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:53 2004 Subject: Forums Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136A81@eukbant101.ericsson.se> > -----Original Message----- > From: Murray Maloney [SMTP:murray@muzmo.com] > > >>In short, can we try to keep the discussion, at least on this list, to > >>concrete technical issues? > > > >It's a good idea - but where exactly should we go with the more abstract > >and political stuff? There isn't a forum, and even if there was, what > >assurances would there be that the W3C (or anyone else in fact) would be > >listening? > > There are plenty of people who participate in the W3C who are listening. > There have been numerous occasions when discussions on this list > have been brought up in W3C WG calls/meetings. This is an incredibly > useful list, and I think that we would ignore it at our peril. > It's just a shame that we would have no idea that they ever discussed any issues raised here. I don't think anyone doubts the usefulness of this list though. Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 21 17:02:09 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:53 2004 Subject: Forums In-Reply-To: <3.0.1.32.19990121114429.01000360@pop.uunet.ca> References: <199901211605.LAA14418@hesketh.net> <199901211539.KAA09173@ruby.ora.com> <36A6A449.99A881FE@infinet.com> Message-ID: <199901211701.MAA15618@hesketh.net> At 11:44 AM 1/21/99 -0500, Murray Maloney wrote: >At 11:08 AM 1/21/99 -0500, Simon St.Laurent wrote: >[...] >>It's a good idea - but where exactly should we go with the more abstract >>and political stuff? There isn't a forum, and even if there was, what >>assurances would there be that the W3C (or anyone else in fact) would be >>listening? > >There are plenty of people who participate in the W3C who are listening. >There have been numerous occasions when discussions on this list >have been brought up in W3C WG calls/meetings. This is an incredibly >useful list, and I think that we would ignore it at our peril. Agreed - people do listen to XML-Dev. But would they bother to watch a forum discussing just the politics? I doubt it, and that's why I don't see removing the politics from XML-Dev as a good thing for XML. This could change, of course, if the W3C starts inviting the public as well as listening, and creates public forums with 'official' standing. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Jan 21 17:08:07 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:53 2004 Subject: Next Round References: <004301be4506$bed39450$2ee044c6@arcot-main> Message-ID: <36A75F95.EBE957AE@mecomnet.de> Don Park wrote: > > >First, we will need to define a new type, namely Name. > > Turning names into first class objects does solve the namespace problem as > well as providing an opportunity to solve the 'intern' problem by adding > name comparison methods. Implementations that maintains 'interned' name > within Name For which application domains is it necessary to intern the string itself? Have "cross-namespace" name comparisons turned out to be significant enough to make this "second level" interning pay off? > will obviously be very efficient past the tree building process. Doesn't the "first level" intern of the name object suffice? > It is not a very well known fact that Docuverse DOM SDK uses 'interned' > names and it has been very useful to many of our customers although it does > cost about 10% speed penalty during tree building. It would be interesting to hear if any of them use functions which include the prefix among thir arguments and, if so, what for? Perhaps there's something peculiar about our approach, but 100% of our coding has been in terms of the universal names. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Thu Jan 21 17:12:34 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:07:53 2004 Subject: Fw: Next Round Message-ID: <002601be4560$35353910$3902a8c0@oren.capella.co.il> Bill la Forge <b.laforge@jxml.com> wrote: >Then to raise again a previous suggestion from Don, we could simply extend the >functionality of the Parser.setDocumentHandler method by checking to see if the >lexical processor interface is implemented. And again, for non-Java languages, >the DocumentHandler interface should implement an isInstanceOf method. Ugh. What's wrong with adding setLexicalHandler? feel free to give the same object both to it and to setDocumentHandler. Or, if the two are _that_ close, add a getLexicalHandler method to the DocumentHandler interface; it could return null, 'this', or anything you want. I'd argue that in this case its better to simply add the events to the DocumentHandler interface; the BaseHandler will define them to a no-op anyway. There's no need to rely on 'instanceOf' kludges. Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 17:33:39 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:53 2004 Subject: Next Round Message-ID: <007501be4563$8b23a340$c9a8a8c0@thing2> >I'd argue that in this case >its better to simply add the events to the DocumentHandler interface; the >BaseHandler will define them to a no-op anyway. I'm seeing LexicalHandler as additional events which might have been included with DocumentHandler originally. I'd be delighted to see them combined, but then we have backward compatibility issues. I see having LexicalHandler extend DocumentHandler as a good comprimise. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Thu Jan 21 18:19:09 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:07:53 2004 Subject: Questions on DCD Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEE35@RED-MSG-08> Maneesha Jain asks how to represent the following java class in DCD: class Kid { Person mother; ***** Person father; } speculating that the answer is <ElementDef Type="Kid"> <Element>Person</Element> <Element>Person</Element> </ElementDef> <ElementDef Type="Person"> <Element>Name</Element> <Element>Address</Element> </ElementDef> but then saying 'What I don't understand is where in DCD can I specify that the "Ist Person" information is about the "mother" and "Second Person" information is about "father". In concept, I was looking for a way to specify the "type" and "name" for a <Element> just like in java definition marked as (*****).' The key to the solution is to realize that of the items in the problem, two are object types (Kid and Person) while two are relations between objects (mother and father). Your proposed solution doesn't quite have enought parts, and the relation between the parts is not explicit. You can find a proposal by me for this sort of problem at the W3c (http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html). Here is an example of instance data reflecting a Kid and his mother and father: <Person id="Jane" /> <Person id="Leroy" /> <Kid mother="Jane" father="Leroy" /> I'm not familiar enough with DCD to write the schema in DCD notation, so let me write it in XML-Data notation; I'm sure you can make the translation: <ElementType name="Person" > <AttributeType name="id" dt:type="id" /> <attribute type="id" /> <ElementType> <ElementType name="Kid" > <AttributeType name="mother" dt:type="idref" /> <attribute type="mother" /> <AttributeType name="father" dt:type="idref" /> <attribute type="father" /> <ElementType> I hope this is helpful, Andrew Layman xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Thu Jan 21 18:36:17 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:07:53 2004 Subject: Inheritance using DTDs Message-ID: <990121133441.23385@mail11.mitre.org.0> Perhaps a silly/obvious question ... If you have an XML document with a DOCTYPE declaration and an internal DTD subset, wouldn't you consider that a form of inheritance? The internal subset is inheriting all the definitions in the external DTD document, and is able to override/extend it. Seems just like object inheritance, with the proviso that it is a one-deep inheritance. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 18:54:21 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:53 2004 Subject: Next Round References: <000001be44c9$7c0992b0$bda8b4d1@yak.ptld.uswest.net> Message-ID: <36A777C6.845C5BD4@locke.ccil.org> Rob Schoening wrote: > If the mix and match approach is to be successful, I believe that it should > be hidden for ordinary use through some kind of aggregation. This would > necessitate either 1) multiple inheritance of interfaces Which Java has, fortunately. > or 2) language > specific abstract classes. "Language-specific" in the sense that they have to actually be implemented in each language. The org.xml.sax.helpers package already contains several such classes. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 18:59:24 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:53 2004 Subject: Identifying XML Document Types (was XML media types revisited) References: <199901152012.PAA03477@hesketh.net> <36A66D2C.DFA2DE98@prescod.net> Message-ID: <36A778F3.37109@locke.ccil.org> Paul Prescod wrote: > If the definition of the namespace (whereever it is) says that the > namespace's X must contain a Y, then an X *must* contain a Y, just as if > it were a DOCTYPE declaration. The only difference is that the validation > is done at some other level, using some other mechanism. Namespaces needn't have definitions (schemas) in this sense, although some will. The model of namespaces as defined by the Recommendation contains solely names, each tagged as Element, GlobalAttribute, or ElementType<X>SpecificAttribute, where <X> is a name of type Element. There is nothing about content models, defaults, or anything else. > These problems go away if you use the namespace convention in ways that > are not in contradiction with validation (i.e. #FIXED xmlns: attributes). Using #FIXED attributes is neither necessary nor sufficient. What is necessary and sufficient is to alpha-convert all namespace prefixes so that each namespace has a unique prefix, and to modify the DTD to use those same prefixes. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 19:02:06 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:53 2004 Subject: Word and XML (was: XML standards coherency and so forth) References: <36a675341a48002@laurel.kp.org> Message-ID: <36A7796C.93059A91@locke.ccil.org> Biron,Paul V wrote: > Actually, it is very easy to generate a Word '97 document which when saved > as HTML will be non-wellformed. Try the following, where *xxx* means "make > xxx bold", and _yyy_ means "make yyy italicized". > > This is *a test _of the* emergency_ broadcast system > > The relevant portion of the HTML produced by word is > > <P>This is <B>a test <I>of the</B> emergency</I> broadcast > system</P> Un*censored*believable. This not only isn't XML, it isn't even HTML. What were they thinking of? (I know, I know: $$$$.) Microsoft folks, is there any hope of getting this fixed for Office 2K? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 19:05:18 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:53 2004 Subject: Next Round References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> Message-ID: <36A779C7.A223D5CF@locke.ccil.org> Don Park wrote: > >1. Filter Interface > > I agree with James that DocumentHandler is the appropriate place. But what if you want to filter DTDHandler, or the new LexicalHandler, or some combination? By implementing Parser, you can do it all. See http://www.ccil.org/~cowan/XML/ParserFilter.java . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 19:10:26 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:53 2004 Subject: Next Round References: <004f01be44e8$ba245fc0$c9a8a8c0@thing2> Message-ID: <36A77A5F.44DE644B@locke.ccil.org> Bill la Forge wrote: > Why not support Namespaces through a filter? Why put everything into a monilithic parser? > If we have good support for filters, then we can have a reasonable scope for parsers and > allow applications to configure their filters to meet their particular needs. There is an efficiency improvement if parsers do their own namespace processing, simply because otherwise you have to search linearly through each attribute to hack on it and check it for being an xmlns[:*] attribute. But I certainly agree that retrofitting namespace processing using a filter is a Good Thing. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amd0978 at acf3.nyu.edu Thu Jan 21 19:11:43 1999 From: amd0978 at acf3.nyu.edu (Adam M Donahue) Date: Mon Jun 7 17:07:53 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: <36A7796C.93059A91@locke.ccil.org> Message-ID: <Pine.OSF.3.95.990121140654.354A-100000@acf3.nyu.edu> > > <P>This is <B>a test <I>of the</B> emergency</I> broadcast > > system</P> > > Un*censored*believable. This not only isn't XML, it isn't even > HTML. What were they thinking of? (I know, I know: $$$$.) > Microsoft folks, is there any hope of getting this fixed for > Office 2K? <shakes head> We're putting our hopes in these people?? Adam xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 19:17:52 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:53 2004 Subject: OSS vs W3C? was: Next Round References: <003401be44f4$a9cac5e0$c9a8a8c0@thing2> Message-ID: <36A77CEE.A86A2DBF@locke.ccil.org> Bill la Forge wrote: > Open Source Software and vendor controlled standards bodies, IMHO, are a poor marrage. > The advantage of Java and XML is that they let you do significant work without the need > for a large team effort. Say what? Java is not open source; there is an open-source version (Kaffe), but it's not yet ready for prime time (feel free to contradict me if you know otherwise). Java is a vendor-controlled standard (maybe soon to go away). XML is a vendor-consortium-controlled standard. If you don't like these processes, try IETF or ISO. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 19:20:10 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:53 2004 Subject: Next Round References: <005e01be44f9$f8a71ec0$c9a8a8c0@thing2> Message-ID: <36A77D82.413FBFBD@locke.ccil.org> Bill la Forge wrote: > What about supporting specified (boolean) in the attribute list? A must, if we want DOM-from-SAX to really work. Don Park's DOM violates the DOM Rec in this particular; it has no way of telling specified from defaulted attribute values. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at isogen.com Thu Jan 21 19:40:14 1999 From: robin at isogen.com (Robin Cover) Date: Mon Jun 7 17:07:53 2004 Subject: Word and XML (was: XML standards coherency and so forth) Message-ID: <Pine.GSO.3.96.990121133722.22632J-100000@grind> John Cowan wrote: >> <P>This is <B>a test <I>of the</B> emergency</I> broadcast >> system</P> > Un*censored*believable. This not only isn't XML, it isn't even > HTML. What were they thinking of? [. . .] I agree that this is bad. Unfortunately, a lot of companies (and some that really *do* know better) are still creating and selling products that generate invalid HTML (SGML). For one example: 'URL's of the kind: <a href="http://foo.bar.com/search?&status=clear&PageCall=1&mode=on"> viz., unescaped ampersand in attribute values, which is simply illegal. So long as software companies across the board will tolerate an attitude of "close is good enough" - what should we expect? Come to think of it: why should this be "Un*censored*believable" given that 99% of Net stuff is illegal HTML, despite a couple generations (years) of HTML DTDs? -rcc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 19:47:51 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:53 2004 Subject: OSS vs W3C? was: Next Round References: <5F052F2A01FBD11184F00008C7A4A80001136A7A@eukbant101.ericsson.se> Message-ID: <36A78443.E7197DB2@locke.ccil.org> Matthew Sergeant (EML) wrote: > Having said all this I do think the XML spec is a triumph of a > closed team, although I personally would have disposed of <!NOTATION>... IMHO the objections to notations are really reactions to the failure of the XML spec to explain its purpose: datatyping. A notation can be applied to the #PCDATA content of an element (via a NOTATION attribute) or to an external file. The general failure to understand this causes new mechanisms for datatyping to be constantly reinvented. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 19:57:02 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:53 2004 Subject: Next Round Message-ID: <00d201be4577$a088d7a0$c9a8a8c0@thing2> >> What about supporting specified (boolean) in the attribute list? > >A must, if we want DOM-from-SAX to really work. Don Park's DOM >violates the DOM Rec in this particular; it has no way of telling >specified from defaulted attribute values. I'd really like to extend the DOM to include attribute type, too. SAX and DOM should be able to play well together. One thing that keeps coming up but which isn't being explicitly addressed is backward compatability. In this case, I don't see how subclassing the Attribute list interface to support specified would create any compatibility problems. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 21 20:01:26 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:53 2004 Subject: OSS vs W3C? was: Next Round In-Reply-To: <36A77CEE.A86A2DBF@locke.ccil.org> References: <003401be44f4$a9cac5e0$c9a8a8c0@thing2> Message-ID: <199901212000.PAA19157@hesketh.net> At 02:15 PM 1/21/99 -0500, John Cowan wrote: >Bill la Forge wrote: >> Open Source Software and vendor controlled standards bodies, IMHO, are a poor marrage. >> The advantage of Java and XML is that they let you do significant work without the need >> for a large team effort. > >Say what? > >Java is not open source; there is an open-source version (Kaffe), >but it's not yet ready for prime time (feel free to contradict me >if you know otherwise). > >Java is a vendor-controlled standard (maybe soon to go away). > >XML is a vendor-consortium-controlled standard. I think you missed his point, which I suspect has something to do with the fact that XML and Java are good foundations on which we can layer further work (SAX, MDSAX, etc.) without having to turn it over to a bunch of vendors who can't be trusted to do the right things for users (including developers). >If you don't like these processes, try IETF or ISO. Or, better yet, you can try to get organizations that are already custodians of important projects to open the doors. Sun hasn't been happy about it, but they're doing it, with a lot of grumbling. We'll see what happens to the W3C over the next few years, but I hope for similar changes. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 20:05:23 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:54 2004 Subject: Next Round References: <199901211539.KAA09173@ruby.ora.com> Message-ID: <36A787F8.472D8CE2@locke.ccil.org> Chris Maden wrote: > As far as I can tell, the biggest problem is the possibility that a > prefix's meaning can change within a document. But your processor > should be operating on URI+suffix, not the prefix, and changing a > mapping table can't be *that* hard. Except for DTD-based validation, which has to stay backward compatible. So either we heave over DTD's altogether, or we apply Tim's algorithm (which unquestionably works, but at a price). > True, I'm not a sophisticated programmer, and I may be overlooking > something. But I have a hard time seeing Tim Bray and James Clark > bulled by political pressure, even (especially?) from Microsoft. How about from W3C staff? After all, the PI-based version of the namespace rec made it almost all the way up before being vetoed, as I understand (I wasn't there, so I speak under correction). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From uche.ogbuji at fourthought.com Thu Jan 21 20:09:43 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:07:54 2004 Subject: SAX: Next Round In-Reply-To: Your message of "Thu, 21 Jan 1999 04:45:11 EST." <19990121044511.C10232@w3.org> Message-ID: <199901212008.NAA01189@malatesta.local> > > I've been thinking about what new SAX interfaces we need the most > > (with much prodding from users). Here's what I think we need as a > > minimum: > > > > 1. A standard filter interface (and perhaps an optional base class). > > 2. A handler interface for lexical events like comments, CDATA > > sections, and entity references. > > 3. Some kind of namespace support. > > I suggest the following: > 4. an IDL definition of the SAX interface to allow a clean interface > for non-Java languages (like in the DOM REC). Strongly seconded. I would, however, mention that this effort should be more careful than the DOM REC about leaving artifacts in the interface for certain languages. What I have in mind is the DOM REC's mess with regard to attributes, which I heard was left in to give ECMAScript a leg-up. This sort of tinkering is an easy trap to fall into, and just ends up tripping up those of us implementing in different languages, such as Python. I guess today is the day to criticize W3C WGs. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 20:11:19 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:54 2004 Subject: Next Round Message-ID: <00db01be4579$26162f20$c9a8a8c0@thing2> >> >1. Filter Interface >> >> I agree with James that DocumentHandler is the appropriate place. > >But what if you want to filter DTDHandler, or the new LexicalHandler, >or some combination? By implementing Parser, you can do it all. >See http://www.ccil.org/~cowan/XML/ParserFilter.java . John, I've always thought using the Parser interface for filters was a bit heavy weight. I wanted to keep filters very light so that the cost of doing things like namespace and bunches of other things would be no greater than having them done inside the parser, and yet give you a lot more configurability. I also didn't think a lot of folks would be filtering DTD events, that is unless they got extended. But now I'm less convinced. And with lexical events, even if they were always combined with document events, there would still be the backward compatibility issue for old filters. And going with Parser for filters would make it easier to work with your code. Mike, your input on this would be especially appreciated!!! Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 20:14:17 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:54 2004 Subject: Next Round References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> Message-ID: <36A78971.C04FB742@locke.ccil.org> james anderson wrote: > Neither the prefix nor the qualified name have the same permanence as the > local name, the namespace and the expanded name. One could well collect all > prefixes in connection with which as symbol appeared, but the values are of no > use as the bindings have dynamic extent. Granted, but it is still necessary to publish the current prefix->URI map, as things that are semantically interpretable by a specific application as QNames may appear in #PCDATA content, CDATA attribute values, PI content, or other such places where an unassisted parser cannot detect and decode them. The application must therefore determine the URI itself. > this, for example, is defined only at the moment the element is being > processed. outside of the element's scope there is no defined result. This is already true of the SAX attribute map, as the SAX documentation warns; in fact, parsers are free to reuse the same object for *every* attribute map. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jan 21 20:17:25 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:07:54 2004 Subject: OSS vs W3C? was: Next Round In-Reply-To: <199901212000.PAA19157@hesketh.net> (simonstl@simonstl.com) Message-ID: <199901212010.PAA19912@ruby.ora.com> [Bill la Forge] > Open Source Software and vendor controlled standards bodies, IMHO, > are a poor marrage. The advantage of Java and XML is that they let > you do significant work without the need for a large team effort. [John Cowan] > Java is a vendor-controlled standard (maybe soon to go away). > > XML is a vendor-consortium-controlled standard. [Simon St.Laurent] > I think you missed his point, which I suspect has something to do > with the fact that XML and Java are good foundations on which we can > layer further work (SAX, MDSAX, etc.) without having to turn it over > to a bunch of vendors who can't be trusted to do the right things > for users (including developers). Did you mean the bunch of vendors who invented XML, or the one vendor of that bunch that developed Java? If you don't trust them, why are you building further on their technology? And if that technology was so good, why not give them a chance to keep going? I wish the process were more open. But we had an open process, and Netscape and Microsoft ignored it. If we have to throw them a bone of early adoption to get buy-in, I'll go for it. Unfortunately, it looks like the actual buy-in may have been temporary, but I'll wait for an FCS to make that judgment. -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From uche.ogbuji at fourthought.com Thu Jan 21 20:18:02 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:07:54 2004 Subject: SAX: Next Round In-Reply-To: Your message of "Thu, 21 Jan 1999 04:58:34 EST." <36A6FA4A.3D10F6F3@infinet.com> Message-ID: <199901212014.NAA01203@malatesta.local> > > 4. an IDL definition of the SAX interface to allow a clean interface > > for non-Java languages (like in the DOM REC). > > Someone already did this a while back. But I have not heard of it since. > Nevertheless, for a set of event interfaces, I am not so sure straight CORBA > would do the trick in terms of doing things over the wire. Integrating SAX with > the Events Service would probably do the trick here... I don't think the particular aim is to marshal SAX events over an ORB. The aim is simply to define an interface so that all applications in languages with a CORBA mapping can implement the SAX interfaces uniformly, improving standardization. A SAX parser that uses the Event service to allow distributed use would, however, be a good exercise, and might even find real-world use. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 20:23:41 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:54 2004 Subject: Word and XML (was: XML standards coherency and so forth) References: <Pine.GSO.3.96.990121133722.22632J-100000@grind> Message-ID: <36A78B88.C2C07126@locke.ccil.org> Robin Cover wrote: > Come to think of it: why should this be "Un*censored*believable" > given that 99% of Net stuff is illegal HTML, despite a couple > generations (years) of HTML DTDs? Most of that was generated by hand, though (or by programs written by hand, etc.). Ugly, unreadable HTML is one thing: violating basic SGML principles like nestedness is quite another. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 20:33:16 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:54 2004 Subject: OSS vs W3C? was: Next Round References: <000001be4577$3b1c7ca0$5118a8c0@kuantech1.quokka.com> Message-ID: <36A78E49.1D6B1326@locke.ccil.org> A correspondent asked me privately to say more about the designed uses of XML notations that makes 'em worth having. > Your comment here intrigues me, though I'm not sure exactly what > you're saying. Can you say more? Let's say that you have an element with #PCDATA content that's supposed to contain a date, like this: <CREATED>1999-01-21</CREATED> You can say that this is a date in a standard way by adding the following to the DTD: <!NOTATION ISO-8601-date SYSTEM "http://www.iso.ch/8601"> <!ATTLIST CREATED type NOTATION(ISO-8601-date) #FIXED "ISO-8601-date"> which says that all CREATED elements have an attribute named "type", of type NOTATION, with fixed value "ISO-8601-date", which is a notation bound to the ISO 8601 definition of a date. This notation is verbose because there's flexibility in it which I'm not really exercising, to have elements whose content can be one of multiple datatypes, like: <!NOTATION int32 SYSTEM "..."> <!NOTATION int64 SYSTEM "...."> <!NOTATION float SYSTEM "......"> <!ATTLIST MUTABLE type NOTATION(int32,int64,float) #REQUIRED> which declares that MUTABLE elements must have a "type" attribute whose value is either "int32" or "int64" or "float", and the notation declarations tell you what those mean. The systemids are URLs that point to the definition of the datatype (in English or whatever language natural or formalized). Of course, applications need not be able to fetch the definition and parse it; they only need to be able to recognize the specific systemid or publicid that means "ISO 8601 date". It is implementors who should be able to fetch the definition and implement in conformance to it (thus learning that "nnnn-nn-nn" is yyyy-mm-dd). Similarly, when you want to have a non-XML object referenced from XML, you use an ENTITY attribute whose value is the name of an external entity that refers to a notation that in turn refers to the definition of the format of the external entity. (Read twice, slowly :-)). My DTD fragment http://www.ccil.org/~cowan/XML/media-types.dtd declares notations that refer to the definitions of MIME types. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 21 20:33:43 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:54 2004 Subject: Next Round References: <199901211539.KAA09173@ruby.ora.com> Message-ID: <36A78DAE.EF9CEE4@infinet.com> Chris Maden wrote: > What, exactly, are the problems with the draft? It provides a scheme > for uniquely naming objects. When I say, "html:a", I mean the anchor > element from HTML; when I say, "faq:a", I mean the answer element from > the FAQ ML. Just like when, in the context of HTML, I say "p", I mean > the paragraph from HTML. If you know what to do with "the anchor > element from HTML", you do it, if not, you don't. Why are namespace- > derived names harder to handle than any other system of naming? It is not that namespaces are the problem it is the handling of them at the application level, as well as the fact that using namespaces requires making namespace declarations using attributes. This would be fine for strict document formats like HTML where you pretty much keep all of the relevant application data as content, and you don't need to think of elements as a mapping of serialized content to objects but for interchange (a potential of XML that the W3C to date has pretty much ignored) where people use attributes for all kinds of different things, adding in these namespace attributes makes processing at the application level a pain. For giant document formats like HTML, "Namespaces in XML" may not seem so bad at first, but if you ever want to have a hope and prayer of using XML in non-trivial forms of electronic commerce or object serialization, you better think twice before even thinking about adding in these xmlns:* attributes. > As far as I can tell, the biggest problem is the possibility that a > prefix's meaning can change within a document. But your processor > should be operating on URI+suffix, not the prefix, and changing a > mapping table can't be *that* hard. That is easy to do. It is not as much of a problem as it is sloppy. Handling this at the parser level is very simple, at the application level this is another matter. If someone with a non-trivial use of "Namespaces in XML" can refute my claim by showing a real world XML based application (XSL processors not included) that makes effective use of "Namespaces in XML" than please be my guest. To date, other than XSL, I have not seen any non-trivial use of the "Namespaces in XML" recommendation or even talk about applications that will actually use this namespaces mechanism. Someone please show me the money here so I can see the light into the motivation for the design of "Namespaces in XML". > True, I'm not a sophisticated programmer, and I may be overlooking > something. But I have a hard time seeing Tim Bray and James Clark > bulled by political pressure, even (especially?) from Microsoft. These folks I have a lot of respect for, but I don't speak for them. I have never been to a W3C meeting so I don't know what kind of cigars are smoked at the meetings (-: Also, I don't think Microsoft wants to create something that does not work either. I just think that after all of the time that has been spent on "Namespaces in XML" no one is brave enough to stand out and say "hey some people have some real problems with this draft so maybe we should openly consider alternatives". Really for me it just all boils down to my impression that the "Namespaces in XML" WG is afraid to admit that this recommendation is very much sub-optimal and not ready for prime time. I guess deadlines are taking priority over common sense. > In short, can we try to keep the discussion, at least on this list, to > concrete technical issues? Well, concrete technical issues or not, since "Namespaces in XML" is now a recommendation, this essentially can be translated to "we will never go back on this and you are stuck with it for eternity". I very, very, very, very, reluctantly will have support for "Namespaces in XML" in XML related projects I work on, though I will probably never actively support it in terms of it being something I think is "good" (unless of course it changes to something that is more useful). Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jan 21 20:42:06 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:07:54 2004 Subject: Next Round In-Reply-To: <36A787F8.472D8CE2@locke.ccil.org> (message from John Cowan on Thu, 21 Jan 1999 15:03:04 -0500) Message-ID: <199901212038.PAA21241@ruby.ora.com> [John Cowan] > Except for DTD-based validation, which has to stay backward > compatible. So either we heave over DTD's altogether, or we apply > Tim's algorithm (which unquestionably works, but at a price). If you need namespaces and DTDs, it can be done. Tim's algorithm is for the very hard problem of mechanically merging the restrictions of multiple namespaces. But if you *need* a DTD, odds are it's because you have some particular restrictions you need to express. So express them! Namespace-style names don't introduce any new problems here. They *do* make assembling of semantics (but not restrictions) from disparate document types possible. -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 21 20:45:08 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:54 2004 Subject: OSS vs W3C? was: Next Round In-Reply-To: <199901212010.PAA19912@ruby.ora.com> References: <199901212000.PAA19157@hesketh.net> Message-ID: <199901212042.PAA20075@hesketh.net> At 03:10 PM 1/21/99 -0500, Chris Maden wrote: >Did you mean the bunch of vendors who invented XML, or the one vendor >of that bunch that developed Java? If you don't trust them, why are >you building further on their technology? And if that technology was >so good, why not give them a chance to keep going? Because sometimes you get a tool that's good enough, and you don't need the vendors to carry on extensions as usual. XML 1.0 isn't perfect, but it's a foundation that we can build lots of things on without having to care what MS or NS might think. Java isn't perfect either, but it makes building software on top of it a lot easier, and you don't need Sun for that. How far do I trust vendors? About as far as I can throw them. Given the real estate involved, that's not very far. >I wish the process were more open. But we had an open process, and >Netscape and Microsoft ignored it. If we have to throw them a bone of >early adoption to get buy-in, I'll go for it. I wish we could all stop wishing and start doing. I've yet to hear anyone wholeheartedly defend the W3C's 'buy-in' of $15,000 for access to information, but I've also yet to see anyone do anything about it. I'm working on a few ideas of my own, but it's damn hard to do anything about a well-funded consortium with name recognition. >Unfortunately, it looks like the actual buy-in may have been >temporary, but I'll wait for an FCS to make that judgment. All the more reason to move on. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 21 20:48:52 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:54 2004 Subject: Next Round References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> Message-ID: <36A79026.DF2BF45A@infinet.com> james anderson wrote: > yes, but... > > Tyler Baker wrote: > > > > Don Park wrote: > > > > First, we will need to define a new type, namely Name. > > > > public interface Name { > > String getPrefix(); // inappropriate > > String getLocalName(); > > String getQualifiedName(); // inappropriate > > String getNamespace(); > > String getExpandedName(); > > Name clone(); > > } > > Neither the prefix nor the qualified name have the same permanence as the > local name, the namespace and the expanded name. One could well collect all > prefixes in connection with which as symbol appeared, but the values are of no > use as the bindings have dynamic extent. > the prefix and the qualified name need to be handled separately, through an > interface which combines symbols (here called names) with a dynamic parsing or > serialization context. > > The other additions have to be modified accordingly: as the prefix has no > meaning outside of the parser's dynamic context, those interfaces have no purpose. Very true, but sometimes applications (or even the DOM) may want to preserve the exact document structure in memory and be able to write out that exact document structure as well. That is the only reason for providing the prefix and qualified name methods. > I know the spec gives you no binding for a prefix to a uri within the dtd, but > using the prefix is worse setting some binding rules and sticking to them. > Setting binding rules yields the same results as using the perfix in cases > which are unambiguous, offers a consistent interfaces, and - by virtue of the > bindings rules - at least yields defined results in cases where using the > prefix would yields an undefined result due to ambiguity. Three arguments for > the approach and none against. Good point. I have a bad habit of only thinking positively sometimes (-: > > > > Then change the startElement method to: > > > > ... > > > this, for example, is defined only at the moment the element is being > processed. outside of the element's scope there is no defined result. > > String getTypeByQualifiedName(String prefix, String localName); > > // prefix + ':' + localName > > String getTypeByQualifiedName(String qualifiedName); > > > > It would be better to use functions like the following (the results of which > are always defined) I agree, it is just that there may be reasons I cannot ascertain that an application may want the exact document structure presented to the application. Perhaps an XML tree viewer for example or as I said before the DOM. Calling getTypeByQualifiedName(String qualifiedName) would function pretty much exactly as things are defined now. In other words, if an XML document does not implement namespaces, then using this method may be your cup of tea. > > String getTypeByExpandedName(String namespace, String localName); > > // namespace + ':' + localName > > String getTypeByExpandedName(String expandedName); > > The former can be combined with a function to determine the uri bound to a > prefix - if need be. In my experience this latter function is of no use to an > application, as an application operates is better operating in terms of the > universal names only. It can be of use in Java if the entire expanded name is interned and you do your string comparisons by identity. It is just a matter of whether you want to process things like: if (namespace == "foo") { if (localName == "bar") { // Do something } } or else do something like: if (expandedName == "foo:bar") { // Do something } Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 21 20:52:06 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:07:55 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: <36A78B88.C2C07126@locke.ccil.org> References: <Pine.GSO.3.96.990121133722.22632J-100000@grind> Message-ID: <199901212047.PAA20214@hesketh.net> At 03:18 PM 1/21/99 -0500, John Cowan wrote: >Robin Cover wrote: > >> Come to think of it: why should this be "Un*censored*believable" >> given that 99% of Net stuff is illegal HTML, despite a couple >> generations (years) of HTML DTDs? > >Most of that was generated by hand, though (or by programs >written by hand, etc.). Ugly, unreadable >HTML is one thing: violating basic SGML principles like nestedness >is quite another. To put it bluntly, 'violating basic SGML principles' isn't something the vast majority of the HTML community has cared about - ever. Convincing them that they should care about 'violating basic XML principles' is a lot easier, partly because there's a lot less to explain, but this stuff isn't as obvious as a lot of SGML and XML folks would like to think. There's a long road ahead, and putting it down to 'violations of basic principles' isn't going to get us anywhere if we don't figure out how to sell those principles without sounding like latter-day Puritans. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 21:12:00 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:55 2004 Subject: Next Round References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A79026.DF2BF45A@infinet.com> Message-ID: <36A797F2.70B72FCE@locke.ccil.org> Tyler Baker wrote: > Very true, but sometimes applications (or even the DOM) may want to preserve the exact > document structure in memory and be able to write out that exact document structure as > well. That is the only reason for providing the prefix and qualified name methods. Again: not so. Interpreting QNames in unexpected positions is also sometimes necessary. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 21:13:13 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:55 2004 Subject: Next Round In-Reply-To: <00db01be4579$26162f20$c9a8a8c0@thing2> References: <00db01be4579$26162f20$c9a8a8c0@thing2> Message-ID: <13991.38513.184793.486651@localhost.localdomain> Bill la Forge writes: > I've always thought using the Parser interface for filters was a > bit heavy weight. I wanted to keep filters very light so that the > cost of doing things like namespace and bunches of other things > would be no greater than having them done inside the parser, and > yet give you a lot more configurability. If there's a common helper class that people can use as a base, then filters can be very light anyway (the base class should just pass through all events unmodified and provide access to registered handlers). Here's a filter that renames all "foo" elements to "bar": import org.xml.sax.AttributeList; import org.xml.sax2.helpers.SAXFilter; public class FooFilter extends SAXFilter { public void startElement (String name, AttributeList atts) { if (name.equals("foo")) { getDocumentHandler().startElement("bar", atts); } else { getDocumentHandler().startElement(name, atts); } } public void endElement (String name) { if (name.equals("foo")) { getDocumentHandler().endElement("bar"); } else { getDocumentHandler().endElement(name); } } } > I also didn't think a lot of folks would be filtering DTD events, > that is unless they got extended. If people are using DTD events at all, they'll probably want to filter them (fiddling with notations, etc.). Likewise with lexical events. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 21:17:13 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:55 2004 Subject: Next Round In-Reply-To: <36A78971.C04FB742@locke.ccil.org> References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A78971.C04FB742@locke.ccil.org> Message-ID: <13991.38864.2404.88757@localhost.localdomain> John Cowan writes: > This is already true of the SAX attribute map, as the SAX > documentation warns; in fact, parsers are free to reuse the same > object for *every* attribute map. In most cases, they probably _should_ do that to avoid unnecessary allocation. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jan 21 21:17:15 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:55 2004 Subject: SAX: Next Round In-Reply-To: <199901202122.QAA00962@megginson.com> References: <199901202122.QAA00962@megginson.com> Message-ID: <wkzp7c2ux5.fsf@ifi.uio.no> * david@megginson.com | | public interface ParserFilter extends Parser | [...] | public interface Filter | [...] | public interface Filter extends DocumentHandler { I think one of the main things we have to decide for SAX 2 is whether to go with the middle option (separate interfaces for everything) or whether to use subclassing/subtyping. Separate interfaces: - more flexible (mix and match) and cleaner in general - more confusing (subtyping/inheritance provide documentation of the intent of the designer), also slightly risky since the number of possible combinations becomes very large Sub(classing|typing): - we can either have the SAX 1.0 classes act as roots in an inheritance/subtyping tree (which is no better than the separate interfaces solution) or collect things into a sort of SAX2Parser subclass (makes future extensions difficult) Tough call, I'd say. The separate interfaces seem better to me, and much of the confusion can be dealt with by good documentation (which we need anyway). The separate interfaces solution in fact reminds me of the OOram modelling method, which is very powerful and would be very well suited for modelling SAX. (In fact I think I'll sit down and create a model to clear things up in my head.) | 2. Lexical Event Handler | ------------------------ | | What do we really need here? An event to signal the end of the internal subset would be nice, in addition to what you listed. | public interface LexicalParser extends Parser { | [...] | public interface LexicalProcessor { Here we are back with the issue above. | 3. Namespace Support | -------------------- | | public interface NamespaceParser extends Parser | [...] | public interface NamespaceParser And again... :) | Now, the best way to find out about namespace prefixes is to introduce | a new handler interface: | | public interface NamespaceHandler | { | public void startNamespacePrefix (String prefix, String uri) | throws SAXException; | public void endNamespacePrefix (String prefix) | throws SAXException; | } This looks slightly bothersome to me at first sight, but maybe it's the way to go, since the solution I think best isn't backwards compatible anyway: public interface DocumentHandler { public void startElement(String namespaceUri, String name, AttributeList attrs); public void endElement(String namespaceUri, String name); } However, the low-level solution you propose makes it possible to develop a slightly non-standard parser filter with this interface. Oh, and of course I still want metadata about parsers. At some point not too far into the future, I think it would be a good idea to identify a list of issues and then start a separate thread about each. The discussion here is getting rather unfocused and hard to follow. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jan 21 21:25:24 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:55 2004 Subject: SAX: Next Round In-Reply-To: <199901211248.HAA11653@hesketh.net> References: <199901211248.HAA11653@hesketh.net> Message-ID: <wkyamw2uf8.fsf@ifi.uio.no> * Simon St.Laurent | | I think you may be doing too much to the filters themselves here; | I'd really prefer to see this coordination performed by an external | framework, like MDSAX (http://www.jxml.com/mdsax/). To some extent I agree with this. However, I think the Filter interface itself should be a part of SAX. The FilterManager, however, is perhaps best left for external frameworks, since it will probably be rather complex (especially once one starts with broadcasting and filter trees instead of just filter chains), and might need optimizing for different purposes. And while we're on the subject of parser filter proposals, I put together one in Python a while ago: <URL:http://birk105.studby.uio.no/tmp/filters.zip> | > 2. Lexical Event Handler | > ------------------------ | | I'd like to have startInternalEntity as well; It will have to be endInternalSubset, since the internal subset is processed first. :) | >3. Namespace Support | >-------------------- | | This seems like something better done by a filter layer, provided we | can describe what the results of that processing should be. I agree with David: this is something that belongs in parsers, partly since they will have to be namespace-aware to do schema validation properly. You can still do this as a filter to get the exact interface you want. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 21:33:19 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:55 2004 Subject: Next Round Message-ID: <014c01be4584$d54dd500$c9a8a8c0@thing2> I'm sold! MDSAX filters will implement Parser! Now, I still think having a FilterFactory interface for filter factories is the way to go--a good place to hide differences in constructors, and a good place to put meta data. Well, I thought I had a code freeze. This is a small change. I'll sneak it in tonight. (My real priority is writing the doc for the api.) With this, I remove all objections to having seperate event handler interfaces! Thanks all! Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Jan 21 21:33:33 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:07:55 2004 Subject: Next Round Message-ID: <006d01be4585$56428700$2ee044c6@arcot-main> >Not sure if this would be in the realm of SAX since SAX is supposed to be a >Simple API for XML, but some sort of character data interface with a lazy data >model behind it that at least supports new character arrays, copying, strings, >and normalized content would not be such a bad idea. Well. Maybe we need another API which looks like SAX but uses DOM interfaces. DocumentHandler.startElement, for example, will then look like: void startElement(org.w3c.dom.Element); Same for contents. I am thinking about calling it MAX (Maximum API for XML). TAX (Terrible API for XML) or WAX (Worst API for XML) just don't cut it I am afraid. SAX Extension for XML (SEX) is a tad tacky also. <g> Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Jan 21 21:36:09 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:55 2004 Subject: SAX: Next Round Message-ID: <015101be4585$0fb5eb60$c9a8a8c0@thing2> >Oh, and of course I still want metadata about parsers. MDSAX uses meta data extensively. Factory objects are a great place for it. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Jan 21 21:37:40 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:07:55 2004 Subject: Next Round Message-ID: <007001be4585$dcfcbb30$2ee044c6@arcot-main> >Damn straight. In fact, I can reveal that the W3C has subcontracted >with a major sub-unit of the Pentagon (quite a bit of extra time on >their hands these days over there) and those boys are monitoring this >list vigilantly for the first sign of someone getting out of lock-step. >There's now a markup-thoughtcrime massive-retaliation strike force >on 24-hour alert hiding behind an NNTP server in Falls Church, so >straighten up and fly right, girls 'n' boys. There's a bit of a problem >in that xml-dev is hosted in a Foreign Country, but they're working >on leveraging the NATO liaison; so the kind of dangerous anarchy >we've seen around here can't last long, thank goodness. -T. I vote for moving the xml-dev list server to Kosovo for safety. NATO won't be able to touch us there. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jan 21 21:50:08 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:55 2004 Subject: SAX: Next Round In-Reply-To: <015101be4585$0fb5eb60$c9a8a8c0@thing2> References: <015101be4585$0fb5eb60$c9a8a8c0@thing2> Message-ID: <wkww2g2t87.fsf@ifi.uio.no> * Lars Marius Garshol | | Oh, and of course I still want metadata about parsers. * Bill la Forge | | MDSAX uses meta data extensively. Factory objects are a great place | for it. Sorry, I was unclear. What I want is information like: - which parser is this? - which version? - which version of the driver? - does it validate? --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Thu Jan 21 22:01:40 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:07:55 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: <36A7796C.93059A91@locke.ccil.org> References: <36a675341a48002@laurel.kp.org> Message-ID: <3.0.6.32.19990121202020.00928ec0@gpo.iol.ie> >Biron,Paul V wrote: > >> Actually, it is very easy to generate a Word '97 document which when saved >> as HTML will be non-wellformed. Try the following, where *xxx* means "make >> xxx bold", and _yyy_ means "make yyy italicized". >> >> This is *a test _of the* emergency_ broadcast system >> >> The relevant portion of the HTML produced by word is >> >> <P>This is <B>a test <I>of the</B> emergency</I> broadcast >> system</P> > [John Cowan] >Un*censored*believable. This not only isn't XML, it isn't even >HTML. What were they thinking of? (I know, I know: $$$$.) >Microsoft folks, is there any hope of getting this fixed for >Office 2K? > RTF doesn't map well to XML -- even very low level -- formatting oriented XML -- because of the way RTF is structured. It is stack based and allows structures to overlap:- \b1 bold \i1 bold italic \b0 italic \i0 plain Matching up the on/offs:- <b> bold <i> bold italic </b> italic </i> plain invalid XML (or indeed SGML) because of the overlaps. This kind of overlapping structure is nasty to do in XML/SGML. (Which is a real pity because it crops up in some important areas -- looseleaf publishing for example.) SGML made a stab at it with an optional feature called CONCUR (never implemented to my knowledge). Sean <Sean uri="http://www.digitome.com/sean.htm"/> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 21 22:07:48 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:55 2004 Subject: SAX: Next Round In-Reply-To: <wkzp7c2ux5.fsf@ifi.uio.no> References: <199901202122.QAA00962@megginson.com> <wkzp7c2ux5.fsf@ifi.uio.no> Message-ID: <13991.41975.494212.645715@localhost.localdomain> Lars Marius Garshol writes: > | 2. Lexical Event Handler > | ------------------------ > | > | What do we really need here? > > An event to signal the end of the internal subset would be nice, in > addition to what you listed. You'd get that through the start/endExternalEntity event -- the external subset is just a special entity, read after the internal subset (we might want to use the special name '[dtd]' for it). > | Now, the best way to find out about namespace prefixes is to introduce > | a new handler interface: > | > | public interface NamespaceHandler > | { > | public void startNamespacePrefix (String prefix, String uri) > | throws SAXException; > | public void endNamespacePrefix (String prefix) > | throws SAXException; > | } > > This looks slightly bothersome to me at first sight, but maybe it's > the way to go, since the solution I think best isn't backwards > compatible anyway: SAX in general is designed to be bothersome, in part to encourage people to build decent, friendly interfaces (SAXON, MDSAX, DocuverseSDK, Sun's XML library) on top of it. The idea is to defer any design decisions that we can defer. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jan 21 22:14:21 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:55 2004 Subject: Word and XML (was: XML standards coherency and so forth) References: <36a675341a48002@laurel.kp.org> <3.0.6.32.19990121202020.00928ec0@gpo.iol.ie> Message-ID: <36A7A699.3E1153E8@locke.ccil.org> Sean Mc Grath wrote: > RTF doesn't map well to XML -- even very low level -- formatting > oriented XML -- because of the way RTF is structured. Actually it's easy, just not DIRT easy. HTML Tidy does the right thing, inserting extra end tags but remembering that it has done so and then inserting start tags at the first possible minute so that <b>foo<i>bar</b>baz</i> becomes <b>foo<i>bar></i></b><i>baz</i> -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sawhneya at ms.com Thu Jan 21 22:58:42 1999 From: sawhneya at ms.com (Avneet Sawhney) Date: Mon Jun 7 17:07:55 2004 Subject: Inheritance using DTDs Message-ID: <36A7B0F6.71471A7C@ms.com> Hi, The more I look into it, I don't see DTD's as an efficient way to support inheritance. The use of internal subsets seems just a workaround. The use of parameter entities and the INCLUDE and IGNORE statements require too much collaboration between the interested parties. I guess you could make every element and attribute an entity, but that does not seem appropriate. Also, as stated, inheritance at more than one level is especially difficult. For instance, how would I implement the following type of an N-deep object for a memo: Let's say a memo is maintained as an industry standard DTD of (header, body, trailer), each of these having their own subelements. Now, an individual firm will use this DTD, but wants to simply extend the header element for internal needs, and reuse the other subelements without having to redefine those. Then, a department within that firm wants to tack on its own attributes to one of the header elements, again, reusing the base definition, and not having to redefine it as part of an entity. This can continue to a group within the dept., and finally to the application in that group which actually uses the memo. This kind of structure would allow the flexibility for changes at the company or department level without the normal dependencies. Without the use of namespaces, simply redefining the elements as is supported now is not appropriate because of the possible name clashing. Is namespaces the answer, or is the "extends" feature from DCD's what I need? Thanks, -Avneet xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jan 21 23:46:31 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:55 2004 Subject: SAX: Next Round In-Reply-To: <13991.41975.494212.645715@localhost.localdomain> References: <199901202122.QAA00962@megginson.com> <wkzp7c2ux5.fsf@ifi.uio.no> <13991.41975.494212.645715@localhost.localdomain> Message-ID: <wkr9so2nsz.fsf@ifi.uio.no> * Lars Marius Garshol | | An event to signal the end of the internal subset would be nice, in | addition to what you listed. * david@megginson.com | | You'd get that through the start/endExternalEntity event -- the | external subset is just a special entity, read after the internal | subset (we might want to use the special name '[dtd]' for it). I should have thought of this, of course, and, yes, I think we should use a separate name for the external subset entity, to make it easier to identify. Doing so isn't as clean as we might wish, but I can't think of any good alternatives offhand. | SAX in general is designed to be bothersome, in part to encourage | people to build decent, friendly interfaces (SAXON, MDSAX, | DocuverseSDK, Sun's XML library) on top of it. The idea is to defer | any design decisions that we can defer. Yeah, I know, and I agree. I think it's the right way to go. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Jan 21 23:58:45 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:07:55 2004 Subject: OSS vs W3C? was: Next Round References: <5F052F2A01FBD11184F00008C7A4A80001136A74@eukbant101.ericsson.se> Message-ID: <36A7BE84.10CA@hiwaay.net> Matthew Sergeant (EML) wrote: > > It's interesting I was thinking about the very same thing just the > other day. Currently our standards as defined by the W3C (and other > standards bodies) are defined by effectively locking a group of "members" in > a room and waiting until they emerge with something worthwhile. It's a > fairly impenetrable room from the outside, even though it's possible at > certain stages of the process to make suggestions from the outside - there's > no guarantee that those suggestions will even be considered. The "members" > tend to be large corporations who have a vested interest in the technology > (yes, I know Tim is the exception here). > > Is this neccessarily a bad thing? I don't know - we've never really > experienced anything different. And yet when I compare it to the software > world, and read "The Cathedral and The Bazaar", I can't help wondering if > developing standards in a Bazaar might be a better model. It would certainly > be interesting to try. In effect, that has always been the capability of using DTDs, schema, what have you as the negotiable, validatible means of contracting. Define a set of properties and values, organize their relationships and in some cases containment, create the software to send, receive, and process these, and then all you need are members of your community willing to share information based on that contract. The problem with the Web is almost everyone wants to be a hero and be recognized as such, or get wealthy by creating the killer app. Heroism is recognized, not posessed and wealth is obtained from others, so the first task is to build a community of exchange. That's all there is. That's all you need. That is what SGML has been about since day one. XML just makes it easier, so there you are. The W3C is there when you need to share it with a bigger community. Don't do what the SGML community did badly; standardize yourself to death. Do what we did well; create contracts and implement them. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 22 00:25:54 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:56 2004 Subject: SAX: Next Round Message-ID: <02e201be459d$33da9e60$c9a8a8c0@thing2> I just realized something significant about the difference between John Cowan's filters and MDSAX. MDSAX builds its filters from leaf to root, where the leaves of the filter tree are the final destinations of the transformed events. The root filter is registered with the parser. Events then travel from root filter to a particular leaf, the route depending on the document type and possibly the element type as well. (DocumentRouter and ElementRouter being filters which handle this routing.) John's filter works in reverse, building layer upon layer of filter/parser, with events flowing up the stack from the first filter put on the stack to the last. MDSAX does have an interface which extends Parser: MDContext. An instance of MDContext could serve as a filter in a stack of filter/parsers, while putting a filter/parser in the MDSAX filter tree would be a bit more challenging. The conclusion, then, is that the less SAX says about filters, the better. Guess I get to eat my own words now. Could you pass the salt? Bill >I'm sold! > >MDSAX filters will implement Parser! > [cut] > >With this, I remove all objections to having seperate event handler interfaces! > >Thanks all! > >Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 22 01:02:50 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:56 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: <3.0.6.32.19990121202020.00928ec0@gpo.iol.ie> References: <36a675341a48002@laurel.kp.org> <36A7796C.93059A91@locke.ccil.org> <3.0.6.32.19990121202020.00928ec0@gpo.iol.ie> Message-ID: <13991.52341.623152.23870@localhost.localdomain> Sean Mc Grath writes: > RTF doesn't map well to XML -- even very low level -- formatting > oriented XML -- because of the way RTF is structured. > > It is stack based and allows structures to overlap:- > > \b1 bold \i1 bold italic \b0 italic \i0 plain > > Matching up the on/offs:- > <b> bold <i> bold italic </b> italic </i> plain > > invalid XML (or indeed SGML) because of the overlaps. This is actually quite simple to handle algorithmically by maintaining a stack and doing a pushback when tags aren't nested: RTF Tags Stack ------------------------ \b1 <b> (b) \i1 <i> (b i) \b0 </i></b><i> (i) \i0 </i> () You'd need only four or five lines of code to handle it -- just walk back on the stack to the nearest matching state (closing all open tags), then reopen everything except what you just closed. I'm not saying that you'll always get valid HTML, but at least the tags will be properly nested. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 22 02:57:09 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:56 2004 Subject: Inheritance using DTDs References: <36A7B0F6.71471A7C@ms.com> Message-ID: <36A7E476.95DFDF6A@prescod.net> Avneet Sawhney wrote: > > Hi, > > The more I look into it, I don't see DTD's as an efficient way to > support inheritance. DTDs were not intended to support inheritance. > The use of internal subsets seems just a > Is namespaces the answer, or is the "extends" feature from DCD's what I > need? The "extends" feature of DCDs is not appropriate because it does not adhere to basic rules of object orientation. Consider the following content model: <!ELEMENT BOOLEAN (TRUE|FALSE)> Now I write software based on this definition. It presumes that the BOOLEAN element contains TRUE or FALSE. Now I use "extends" to add "MAYBE". What happens to my software? It ceases to function. This is a violation of Liskov's substitutability principle. [Liskov] http://www.kinetica.com/ootips/lsp.html Extends is not as dangerous if the element you are extending is basically sequential. Even so it is poorly thought out. Once you open up your model with "extends" you have no mechanism for maintaining sanity. Subclassers can completely violate your model by including any random thing as an extension. That will wreak havoc on computer programs and stylesheets. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jan 22 02:57:19 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:56 2004 Subject: ANN: XMOP Open Source Message-ID: <002501be45b2$6067e770$d3228018@jabr.ne.mediaone.net> XML MetaData Object Persistence (XMOP) is now available in beta form at http://jabr.ne.mediaone.net/xmop/signup.htm documentation is available at http://jabr.ne.mediaone.net/documents/xmop.htm The XMOP DTD: http://jabr.ne.mediaone.net/documents/xmop.dtd XMOP, in final form, will be freely available open source. For development purposes there are no redistribution rights associated with the beta. Please send me any suggestions and/or modifications for inclusion in the final open source version. The Java side of XMOP is being released now. I haven't had sufficient time to get the C++ version code ready for public view :-) Part of the issue regards the XML parser. At the time it was written, XMOP used MSXML IE4. This is not DOM compliant and I haven't had the time to update things to IE5 which is DOM compliant. The other issue regards my use of class libraries which I can't release as open source at the moment (I have to extract releasable code from the libraries). The Java version uses IBM XML4J and JDK 1.1.6+. This can be obtained from alphaworks.ibm.com. My apologies for the delay, it's just been a packaging issue. Comments and suggestions are welcome. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jeremy at omsys.com Fri Jan 22 03:16:18 1999 From: jeremy at omsys.com (Jeremy H. Griffith) Date: Mon Jun 7 17:07:56 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: <3.0.6.32.19990121202020.00928ec0@gpo.iol.ie> References: <36a675341a48002@laurel.kp.org> <3.0.6.32.19990121202020.00928ec0@gpo.iol.ie> Message-ID: <37abd1ed.3192020833@smtp.omsys.com> On Thu, 21 Jan 1999 20:20:20 +0000, Sean Mc Grath <digitome@iol.ie> wrote: >RTF doesn't map well to XML -- even very low level -- formatting >oriented XML -- because of the way RTF is structured. > >It is stack based and allows structures to overlap:- > > \b1 bold \i1 bold italic \b0 italic \i0 plain It depends on the RTF implementation. You are correct about "stack based", but that's actually contradictory to the example given. Word (7/95) really writes this: {\b bold }{\b\i bold italic }{\i italic }plain for that sequence. In fact, it gets a bit fanatical about using braces, even if the \b0 method would save bytes. So properly-nested XML would seem *more* likely, as it would be the no-brainer conversion from the RTF! I conclude that the XML generator is not based on the RTF-producing code... or on the underlying Word format, which is similar in design. -- Jeremy H. Griffith, at Omni Systems Inc. (jeremy@omsys.com) http://www.omsys.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 22 03:30:23 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:56 2004 Subject: OSS vs W3C? was: Next Round References: <5F052F2A01FBD11184F00008C7A4A80001136A7A@eukbant101.ericsson.se> Message-ID: <36A7E76E.70FDD698@prescod.net> "Matthew Sergeant (EML)" wrote: > > - Given a large enough beta-tester and co-developer base, almost > every problem will be characterised quickly, and the fix obvious to someone. > > If the process just occured on ordinary public mailing lists this > would be true I think. That is not true. There were many bugs found in XML months after it was available on a public mailing list. Characterizing bugs in specifications is much, much harder than characterizing them in code. It wouldn't be so hard if the specs were more formal, but that isn't the way things are going. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Leif.Ydreborn at saab.se Fri Jan 22 08:04:14 1999 From: Leif.Ydreborn at saab.se (Leif.Ydreborn@saab.se) Date: Mon Jun 7 17:07:56 2004 Subject: Generating XML Message-ID: <36A83115.1F9EA736@saab.se> I think it should be useful to have some "output tool" (classes) that helps you to do as much syntax check (DTD) as possible ( even helps you to write end tags). For example, you are collecting a lot of different objects ( calling writeXML() for each ) from many different EJBs (you don't have control, DTD version problems) and you have to deliver the result ( a lot of data ) based on a special DTD on the fly (a web application). I don't have enough of memory to parse in memory. I want to deliver data as quick as possible. I think this will be a normal problem. Is there any good praxis. Leif Ydreborn xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri Jan 22 09:07:45 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:56 2004 Subject: <!NOTATION> Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136A86@eukbant101.ericsson.se> > -----Original Message----- > From: John Cowan [SMTP:cowan@locke.ccil.org] > > Let's say that you have an element with #PCDATA content that's > supposed to contain a date, like this: > > <CREATED>1999-01-21</CREATED> > > You can say that this is a date in a standard way by adding the > following to the DTD: > > <!NOTATION ISO-8601-date SYSTEM "http://www.iso.ch/8601"> > <!ATTLIST CREATED > type NOTATION(ISO-8601-date) #FIXED "ISO-8601-date"> > > which says that all CREATED elements have an attribute named "type", > of type NOTATION, with fixed value "ISO-8601-date", which is a > notation bound to the ISO 8601 definition of a date. This notation > is verbose because there's flexibility in it which I'm not really > exercising, to have elements whose content can be one of multiple > datatypes, like: > > <!NOTATION int32 SYSTEM "..."> > <!NOTATION int64 SYSTEM "...."> > <!NOTATION float SYSTEM "......"> > <!ATTLIST MUTABLE > type NOTATION(int32,int64,float) #REQUIRED> > > which declares that MUTABLE elements must have a "type" attribute > whose value is either "int32" or "int64" or "float", and the notation > declarations tell you what those mean. The systemids are > URLs that point to the definition of the datatype (in English or > whatever language natural or formalized). > Unfortunately that information is only really useful for document authors (which is fine, in itself) - it doesn't appear (to me) to be any use to parsers. It can be of /some/ use to custom parser code, but only when that code has prior knowledge of these notation definitions. And that's a shame. Perhaps we need some standard notations? Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shecter at darmstadt.gmd.de Fri Jan 22 11:12:14 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:07:56 2004 Subject: Anybody doing a XML DO MOM? Message-ID: <36A85CA6.20DD650B@darmstadt.gmd.de> Hi, I'm interested in XML being used in distributed object services or communication. I'm really interested, though, in alternatives to the RPC model of communication. So, things like an XML-based publish/subscribe system come to mind. Anyone doing anything here, or know of resources about this? Thanks, Robb xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jan 22 11:32:24 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:56 2004 Subject: SAX: Next Round In-Reply-To: <02e201be459d$33da9e60$c9a8a8c0@thing2> References: <02e201be459d$33da9e60$c9a8a8c0@thing2> Message-ID: <wk7luflf2q.fsf@ifi.uio.no> * Bill la Forge | | [Excellent description of the two different directions filters | can be viewed in] | | The conclusion, then, is that the less SAX says about filters, the | better. I agree with this in the sense that the FilterManager should not be specified by SAX, however, the actual Filters themselves should, I think, be specified. The goal must be that both views should be supportable by any SAX Filter, allowing the same filters to be reused in MDSAX, Cowans model and in any other filter models that may spring up later. I think the best way to achieve this is to use interfaces that present different views of the Filter, essentially what I yesterday (yesterday for me, anyway :) called the 'separate interfaces' model. I'll see if I can find the time tomorrow to devise a design that allows this. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri Jan 22 12:16:30 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:07:56 2004 Subject: XMLForms Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136A8C@eukbant101.ericsson.se> I've produced a HTML documentation of my HTML Form to XML gateway (XMLForms) for anyone interested in the project. I've released the module now, and there's a download link on the page below. You may want to wait a couple of days until version 0.06 hits CPAN, as this contains some important bug fixes and patches to XML::Parser. Of course this is only relevant if you intend to use the code - the idea remains the same. http://www.fastnetltd.ndirect.co.uk/Perl/XMLForm.html Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ R+++ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 22 13:27:26 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:56 2004 Subject: Inheritance using DTDs In-Reply-To: <36A7B0F6.71471A7C@ms.com> References: <36A7B0F6.71471A7C@ms.com> Message-ID: <13992.31275.963526.751180@localhost.localdomain> Avneet Sawhney writes: > The more I look into it, I don't see DTD's as an efficient way to > support inheritance. The use of internal subsets seems just a > workaround. The use of parameter entities and the INCLUDE and > IGNORE statements require too much collaboration between the > interested parties. I guess you could make every element and > attribute an entity, but that does not seem appropriate. That's exactly what TEI did in their SGML DTD (and more). Take a look at the declaration for <p> (paragraph): <!ENTITY % p 'INCLUDE' > <![ %p; [ <!ELEMENT %n.p; - O (%paraContent;) > <!ATTLIST %n.p; %a.global; TEIform CDATA 'p' > ]]> If you declare <!ENTITY % p 'IGNORE'> the <p> element will be omitted from the DTD altogether; if you declare <!ENTITY % n.p 'paragraphe'> Then the element type will be named 'paragraphe' rather than 'p' (but the TEIform attribute will still be 'p' so that software knows how to process it). You can, of course, also influence the content model in subtle ways. I'd say that all of this pushes DTD syntax about as far as it should be pushed, if not several steps further -- it reminds me of all the C-can-be-object-oriented-with-clever-enough-macros examples that proliferated early this decade as a rear-guard action against C++. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 22 13:37:36 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:56 2004 Subject: Why informal specs usually win In-Reply-To: <36A7E76E.70FDD698@prescod.net> References: <5F052F2A01FBD11184F00008C7A4A80001136A7A@eukbant101.ericsson.se> <36A7E76E.70FDD698@prescod.net> Message-ID: <13992.31871.489850.774574@localhost.localdomain> Paul Prescod writes: > That is not true. There were many bugs found in XML months after it > was available on a public mailing list. Characterizing bugs in > specifications is much, much harder than characterizing them in > code. It wouldn't be so hard if the specs were more formal, but > that isn't the way things are going. Informal specs fit into the Worse-is-Better pattern [1]: a less formal spec that many people can understand easily will generally be adopted and implemented much more successfully than a more formal spec that fewer people can understand, despite the disadvantage that the less formal spec probably contains ambiguities, inconsistencies and omissions. Paul and I are among the five or six (I exaggerate -- 10 or 20) people who ever bothered to figure out SGML groves, from one of the more obfuscated formal specs, so we're not a good sample. All the best, David [1] http://www.naggum.no/worse-is-better.html -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 22 13:54:22 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:56 2004 Subject: SAX: Next Round Message-ID: <004e01be460d$fbca2240$c9a8a8c0@thing2> >I agree with this in the sense that the FilterManager should not be >specified by SAX, however, the actual Filters themselves should, I >think, be specified. > >The goal must be that both views should be supportable by any SAX >Filter, allowing the same filters to be reused in MDSAX, Cowans model >and in any other filter models that may spring up later. > >I think the best way to achieve this is to use interfaces that present >different views of the Filter, essentially what I yesterday (yesterday >for me, anyway :) called the 'separate interfaces' model. > >I'll see if I can find the time tomorrow to devise a design that >allows this. Lars, I think the answer is staring us right in the face. Look at John's ParserFilter: public abstract class ParserFilter implements Parser, AttributeList, DocumentHandler, DTDHandler, EntityResolver, ErrorHandler { From James.Anderson at mecomnet.de Fri Jan 22 14:30:44 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:56 2004 Subject: namespaces and document structure [Re: Next Round] References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A79026.DF2BF45A@infinet.com> Message-ID: <36A88C91.DFFC9C0C@mecomnet.de> Tyler Baker wrote: > > james anderson wrote: > > > yes, but... > ... > > Neither the prefix nor the qualified name have the same permanence as the > > local name, the namespace and the expanded name. One could well collect all > > prefixes in connection with which as symbol appeared, but the values are of no > > use as the bindings have dynamic extent. > > the prefix and the qualified name need to be handled separately, through an > > interface which combines symbols (here called names) with a dynamic parsing or > > serialization context. > > > > The other additions have to be modified accordingly: as the prefix has no > > meaning outside of the parser's dynamic context, those interfaces have no purpose. > > Very true, but sometimes applications (or even the DOM) may want to preserve the exact > document structure in memory and be able to write out that exact document structure as > well. That is the only reason for providing the prefix and qualified name methods. > The prefixes bear no relation to document structure. **Strictly speaking** neither they nor even the URI's have anything to do with content. They simply aid in identifying the names which figure in the content. That the prefixes appear in bindings which appear as attributes is a (regrettable) anomoly, but it does not change their nature. (When I hear of application which process *prefixes* I'll take this back.) As "mr. Bray's" algorithm makes clear, a given document actually is an instance of an infinately large equivalence class in which the same "content" appears in varying encodings, each of which employs difference prefixes to bind respectively identical namespaces. The particular prefixes in one encoding have no bearing on the ability to write out the same document structure. To the extent that they affect the ability to duplicate the *encoding* they do so as a consequence of the relation between prefixes and *namespaces*, not as a consequence of the relation between prefixes and individual *names*. > > I agree, it is just that there may be reasons I cannot ascertain that an application > may want the exact document structure presented to the application. Perhaps an XML > tree viewer for example or as I said before the DOM. Calling > getTypeByQualifiedName(String qualifiedName) would function pretty much exactly as > things are defined now. In other words, if an XML document does not implement > namespaces, then using this method may be your cup of tea. See above... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Fri Jan 22 14:33:41 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:56 2004 Subject: implemented namespaces [Re: Next Round] References: <199901211539.KAA09173@ruby.ora.com> <36A78DAE.EF9CEE4@infinet.com> Message-ID: <36A88D0A.EAB359F2@mecomnet.de> Tyler Baker wrote: > > > As far as I can tell, the biggest problem is the possibility that a > > prefix's meaning can change within a document. But your processor > > should be operating on URI+suffix, not the prefix, and changing a > > mapping table can't be *that* hard. > > That is easy to do. It is not as much of a problem as it is sloppy. Handling > this at the parser level is very simple, at the application level this is another > matter. If someone with a non-trivial use of "Namespaces in XML" can refute my > claim by showing a real world XML based application (XSL processors not included) > that makes effective use of "Namespaces in XML" than please be my guest. To > date, other than XSL, I have not seen any non-trivial use of the "Namespaces in > XML" recommendation or even talk about applications that will actually use this > namespaces mechanism. Someone please show me the money here so I can see the > light into the motivation for the design of "Namespaces in XML". there is a validating xml processor included with the cl-http release. the current version still requires pi's in the dtd, but that will change soon. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Fri Jan 22 14:37:30 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:57 2004 Subject: interned names [Re: Next Round] References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A78971.C04FB742@locke.ccil.org> Message-ID: <36A88D8B.ECB991E5@mecomnet.de> John Cowan wrote: > > james anderson wrote: > > > Neither the prefix nor the qualified name have the same permanence as the > > local name, the namespace and the expanded name. One could well collect all > > prefixes in connection with which as symbol appeared, but the values are of no > > use as the bindings have dynamic extent. > > Granted, but it is still necessary to publish the current > prefix->URI map, as things that are semantically interpretable by a It should well be published as an interface which makes use of the prefix<->uri map, with the restriction that either it depends the dynamic context - and as such is unambiguous - or falls back on the cumulative bindings - and as such has no guaranteed result. To publish the prefix<->uri binding as an aspect of a name is misleading. > specific application as QNames may appear in #PCDATA content, CDATA > attribute values, PI content, or other such places where > an unassisted parser cannot detect and decode them. The application > must therefore determine the URI itself. To depend on the prefix-URI bindings outside of the dynamic context is to permit erroneous results. It suffices to permit the application to process names in the parser's dynamic context. To this end it need no explicit access to the prefix<->uri map, just to an interface which interns qualified names given the parser's dynamic context. Reserialization is handled by letting the parser generate unique names for namespaces as discovered and using those names as prefixes when encoding. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Fri Jan 22 14:46:20 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:07:57 2004 Subject: QName interpretation [Re: Next Round] References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A79026.DF2BF45A@infinet.com> <36A797F2.70B72FCE@locke.ccil.org> Message-ID: <36A88FF0.45CD947B@mecomnet.de> John Cowan wrote: > > Tyler Baker wrote: > > > Very true, but sometimes applications (or even the DOM) may want to preserve the exact > > document structure in memory and be able to write out that exact document structure as > > well. That is the only reason for providing the prefix and qualified name methods. > > Again: not so. Interpreting QNames in unexpected positions is > also sometimes necessary. As well may be. It remains, however, that the only *time* when such an interpretation has value is in the parser's dynamic context. Which means that there are two options. 1. The parser offers an interface which enables a processor to map qualified names to universal names within the parser's dynamic context. This is just the same facility which the parser itself needs - exposed to the processor. 2. Cache the dynamic context in each *element*. Note - not each *name*. This is possible. It is necessary if it is desired to retain the naming implications of a given encoding in the face of side-effects in the DOM. (It's the upward-funarg problem revisited.) Otherwise it is a waste of space and time. Otherwise "interpreting QNames in unexpected positions" can be guaranteed to produce "unexpected results". xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jan 22 14:46:41 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:57 2004 Subject: SAX: Next Round In-Reply-To: <004e01be460d$fbca2240$c9a8a8c0@thing2> References: <004e01be460d$fbca2240$c9a8a8c0@thing2> Message-ID: <wkvhhzjrl7.fsf@ifi.uio.no> * Bill la Forge | | public abstract class Filter | implements Parser, DocumentHandler, DTDHandler, EntityResolver, | ErrorHandler { What I had in mind was something more on the lines of: public interface EventSource { // basically equivalent to Parser } public interface ParserFilter extends EventSource { public void setEventSource(EventSource es) } public interface EventFilter { public void setEventReceiver(EventReceiver er) } and then in the application public class NamespaceFilter implements ParserFilter, EventFilter { ... } This would allow Filters to present different views from both directions, and should be able to accomodate both John's approach as well as yours. The trick is making it backwards-compatible and natural. Whether we can do that is an open question. Do we aim for binary backwards compatibility (integration with class files compiled to SAX 1.0) or do we just aim for a SAX 2.0 that SAX 1.0 applications can be compiled unchanged against? The latter case gives us a lot more flexibility, methinks. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 22 14:51:58 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:57 2004 Subject: namespaces and document structure [Re: Next Round] Message-ID: <000c01be4614$f7a616e0$c9a8a8c0@thing2> >(When I hear of application which process *prefixes* I'll take this back.) Lets say SAX is extended to pass comment events to the application. Suddenly it becomes more reasonable to write a SAX-based editor. Shouldn't there be support in such an editor for processing those prefixes? Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 22 14:52:11 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:57 2004 Subject: interned names [Re: Next Round] Message-ID: <001301be4615$90c46480$c9a8a8c0@thing2> >Reserialization is handled by letting the parser generate unique names for >namespaces as discovered and using those names as prefixes when encoding. Are we then abandoning the idea that XML can also be created with a simple editor? And if not, then isn't it poor practice to introduce arbitrary changes to a source document? Wouldn't changing the prefixes might reduce readability? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 22 15:21:36 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:57 2004 Subject: SAX: Next Round Message-ID: <002901be461a$404350c0$c9a8a8c0@thing2> I think weare very very close, particular when you consider that DocumentHandler, DTDHandler, EntityResolver are the event receivers. Now remember that, so far as event passing goes, MDSAX and ParserFilter work the same. Its only in wiring them up that they are "particular". All we really need is to loosen the wiring requirements. In both cases, this means little more than providing a null constructor and subsequent set methods. I do like your idea of having a seperate EventSource, which Parser and Filter both extend. For when you have a tree of filters, it seems silly to call parse on one of the leaves, especially if the leaf is particular to an element type. On the other hand, I can see arguments for just using Parser. For simple filter stacks, it makes things real easy and I like that. So I really think the following is just great: public interface Filter implements Parser, DocumentHandler, DTDHandler, EntityResolver, ErrorHandler { public void setParser(Parser eventSource); } It means that in MDSAX we only need to change one interface and 4 classes. Changes to ParserFilter can even be handled just by subclassing existing implementations, since John was careful to use protected on the parser variable and will accept a null value in the constructor! Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 22 15:33:01 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:57 2004 Subject: <!NOTATION> References: <5F052F2A01FBD11184F00008C7A4A80001136A86@eukbant101.ericsson.se> Message-ID: <36A89A0E.E8A5E169@locke.ccil.org> Matthew Sergeant (EML) wrote: > [Information from notations] doesn't appear (to me) to be any use > to parsers. If by "parsers" you mean narrowly what the XML Rec calls "XML processors, you are quite right. It is meant for the lowest level of XML applications, just above the parser proper. > It can be of /some/ use to custom parser code, but only when > that code has prior knowledge of these notation definitions. And that's a > shame. There has to be such knowledge somewhere. The model of "tag data of a given type with a magic string" has worked well for MIME; one advantage of notations is that they allow anybody to standardize a type, not just IANA. > Perhaps we need some standard notations? We do. Lay on, Macduff. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sawhneya at ms.com Fri Jan 22 15:36:27 1999 From: sawhneya at ms.com (Avneet Sawhney) Date: Mon Jun 7 17:07:57 2004 Subject: Inheritance using DTDs References: <36A7B0F6.71471A7C@ms.com> <13992.31275.963526.751180@localhost.localdomain> Message-ID: <36A89A5E.197AA270@ms.com> Hi, Thanks for the replies. So, since DTD's were not designed to support inheritance, what are my options here? Even declaring all attributes and elements as entities is not sufficient. Will namespaces (and DTD's) be sufficient, or are there any proposed schemas that have proper inheritance as a required spec? Sorry if this is obvious, but I would like to know my alternates to vanilla DTD's. Thanks, -Avneet david@megginson.com wrote: > Avneet Sawhney writes: > > > The more I look into it, I don't see DTD's as an efficient way to > > support inheritance. The use of internal subsets seems just a > > workaround. The use of parameter entities and the INCLUDE and > > IGNORE statements require too much collaboration between the > > interested parties. I guess you could make every element and > > attribute an entity, but that does not seem appropriate. > > That's exactly what TEI did in their SGML DTD (and more). Take a look > at the declaration for <p> (paragraph): > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jan 22 15:41:33 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:57 2004 Subject: interned names [Re: Next Round] In-Reply-To: <36A88D8B.ECB991E5@mecomnet.de> References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A78971.C04FB742@locke.ccil.org> <36A88D8B.ECB991E5@mecomnet.de> Message-ID: <wkn23bjoz9.fsf@ifi.uio.no> For what it's worth I modified xmlproc to intern _all_ names it encounters yesterday. The net result under Python 1.5.2b1 was that speed on the non-validating benchmark went down from 30.7 seconds to 29.0, and on the validating benchmark it went down from 106 to 100. I guess the real costs lie elsewhere. :) I did not check memory consumption, but I suppose you need to build a DOM tree to really notice that, since without an application the parser hardly uses more than its data buffer anyway. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jan 22 15:50:40 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:07:57 2004 Subject: SAX: Next Round In-Reply-To: <002901be461a$404350c0$c9a8a8c0@thing2> References: <002901be461a$404350c0$c9a8a8c0@thing2> Message-ID: <wklnivjok5.fsf@ifi.uio.no> * Bill la Forge | | I think we are very very close, particular when you consider that | DocumentHandler, DTDHandler, EntityResolver are the event receivers. Well, I like my solution, but I'm not sure that it can be used. I'll try to figure out the implications tomorrow. | Now remember that, so far as event passing goes, MDSAX and | ParserFilter work the same. Its only in wiring them up that they are | "particular". Yup. This is what my proposal hinges on. | All we really need is to loosen the wiring requirements. In both | cases, this means little more than providing a null constructor and | subsequent set methods. Yup again. | I do like your idea of having a seperate EventSource, which Parser | and Filter both extend. So do I, but I'm pretty sure that means breaking binary backward compatibility. Ie: if you try to use it with an old SAX parser or application you'll probably get some dynamic linking-related error from the JVM crashing your application. With a recompile it should be OK. We need to decide whether that's OK or not. Personally, I think it we should say that it is, since the cost isn't that large and since the cost of inflexibility in API evolution may well be huge in the long term. Oh, and for Python this isn't a problem at all, of course. :) | For when you have a tree of filters, it seems silly to call parse on | one of the leaves, especially if the leaf is particular to an | element type. Agreed. | On the other hand, I can see arguments for just using Parser. For | simple filter stacks, it makes things real easy and I like that. It should be easy to develop a simple FilterManager that retains that benefit anyway, so I'm inclined to disregard that argument. | So I really think the following is just great: | | public interface Filter | implements Parser, DocumentHandler, DTDHandler, EntityResolver, | ErrorHandler | public void setParser(Parser eventSource); | } Hmmm. This is uni-directionaly (handler -> parser) only, and also I'm leery of making filter implement all the handlers. I'd rather keep them separate. | It means that in MDSAX we only need to change one interface and 4 | classes. Changes to ParserFilter can even be handled just by [...] I don't mean to sounds dismissive, but I think it's so important to get SAX 2.0 right that the implications for MDSAX and ParserFilter should IMHO be completely disregarded. Anyway, that's it for today for me. I'm now off to the pub. :) --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 22 15:59:20 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:57 2004 Subject: SAX: Next Round References: <004e01be460d$fbca2240$c9a8a8c0@thing2> Message-ID: <36A89FE8.D57875BF@locke.ccil.org> Bill la Forge wrote: > I think the answer is staring us right in the face. Look at John's > ParserFilter: > > public abstract class ParserFilter > implements Parser, AttributeList, > DocumentHandler, DTDHandler, EntityResolver, ErrorHandler { I'm looking, but this message seemed to get truncated here. Anyway, ParserFilter implements the last five interfaces so that it can pass itself to the next lower layer in each case. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 22 16:08:42 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:57 2004 Subject: interned names [Re: Next Round] References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A78971.C04FB742@locke.ccil.org> <36A88D8B.ECB991E5@mecomnet.de> Message-ID: <36A8A262.911366D1@locke.ccil.org> james anderson wrote: > It should well be published as an interface which makes use of the > prefix<->uri map, with the restriction that either it depends the dynamic > context - and as such is unambiguous I think this mechanism is the only meaningful one, which was why I spoke of the *current* (viz. at a given point in the document) map. > To depend on the prefix-URI bindings outside of the dynamic context is to > permit erroneous results. True. > It suffices to permit the application to process > names in the parser's dynamic context. To this end it need no explicit access > to the prefix<->uri map, just to an interface which interns qualified names > given the parser's dynamic context. Probably sufficient; it may be, however, that there is an occasional need to generate a currently-correct Qname from a URI+NCName. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Fri Jan 22 16:12:42 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:07:57 2004 Subject: XML-RPC spec revised Message-ID: <3.0.5.32.19990122081440.00be2e20@scripting.com> Yesterday we posted revisions to the XML-RPC spec: http://www.scripting.com/frontier5/xml/code/rpc.html#update1 There were clarifications on formats for values of params and returned values. A new value type, <base64>, was added, to allow transmission of binary encoded data. There are now Python, Perl, Java and Frontier implementations of XML-RPC. Many of the clarifications were needed to support the new implementations. The <base64> value type was suggested by the Python folks, and it was a very good idea and solved a lot of thorny problems. We're also making good progress working with Allaire on bridging WDDX and XML-RPC. The project heated up last week, but has quieted down this week because Allaire is doing their IPO today! That's a good excuse in my book. ;-> Still diggin! Dave ----------------------------- http://www.scriptingnews.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 22 16:15:33 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:57 2004 Subject: SAX: Next Round References: <002901be461a$404350c0$c9a8a8c0@thing2> <wklnivjok5.fsf@ifi.uio.no> Message-ID: <36A8A374.8E04C0AB@locke.ccil.org> Lars Marius Garshol wrote: > Hmmm. This is uni-directionaly (handler -> parser) only, and also I'm > leery of making filter implement all the handlers. I'd rather keep > them separate. The ParserFilter *class* implements everything but Parser for implementation reasons: it could do the same thing by having a singleton sub-object that implemented them instead. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rabin at shore.net Fri Jan 22 16:41:39 1999 From: rabin at shore.net (Paul Rabin) Date: Mon Jun 7 17:07:57 2004 Subject: SAX: Next Round In-Reply-To: <13991.41975.494212.645715@localhost.localdomain> References: <wkzp7c2ux5.fsf@ifi.uio.no> <199901202122.QAA00962@megginson.com> <wkzp7c2ux5.fsf@ifi.uio.no> Message-ID: <E103jdh-0004Zx-00@siren.shore.net> David, et al, A number of contributors to this discussion are interested in using SAX as a general interface for assembling XML-processing components. The extension of parser+application to a chain of filters is an important first step, but only supports components with at most one event stream input and at most one event stream output. What SAX extensions would be needed to support multiple event stream inputs and outputs? Filters that route events to one or more event stream outputs have been implemented. What is the best way to register the handlers for multiple event stream outputs? Should extended versions of setDocumentHandler(), etc., take an additional index parameter? Support for multiple event stream inputs raises control flow issues. One solution is to have a new version of parse() that returns immediately after initializing the parse context, but without generating any events, and a new getNextEvent() method that causes a single call to the appropriate upstream handler to be made before returning. I'd appreciate hearing about experiences with these or other approaches to improving the connectivity of SAX-based XML processing components. Paul Rabin JXML xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 22 16:55:21 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:57 2004 Subject: SAX: Next Round Message-ID: <003701be4627$60ed8400$c9a8a8c0@thing2> >I don't mean to sounds dismissive, but I think it's so important to >get SAX 2.0 right that the implications for MDSAX and ParserFilter >should IMHO be completely disregarded. Agreed. I'll admidt that, since MDSAX is still being finalized, I've been looking at the short-term compatibility issues. If we get it right, MDSAX could be a lot of fun. And at this point, I think we are very very close. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 22 17:00:22 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:58 2004 Subject: Fw: SAX: Next Round Message-ID: <004a01be4627$f9d97700$c9a8a8c0@thing2> John, Looks like the list server chopped things off when a '.' was the only thing on the line. Bill -----Original Message----- From: Bill la Forge <b.laforge@jxml.com> To: Lars Marius Garshol <larsga@ifi.uio.no>; XML Developers' List <xml-dev@ic.ac.uk> Date: Friday, January 22, 1999 8:49 AM Subject: Re: SAX: Next Round >>I agree with this in the sense that the FilterManager should not be >>specified by SAX, however, the actual Filters themselves should, I >>think, be specified. >> >>The goal must be that both views should be supportable by any SAX >>Filter, allowing the same filters to be reused in MDSAX, Cowans model >>and in any other filter models that may spring up later. >> >>I think the best way to achieve this is to use interfaces that present >>different views of the Filter, essentially what I yesterday (yesterday >>for me, anyway :) called the 'separate interfaces' model. >> >>I'll see if I can find the time tomorrow to devise a design that >>allows this. > > >Lars, > >I think the answer is staring us right in the face. Look at John's >ParserFilter: > >public abstract class ParserFilter > implements Parser, AttributeList, > DocumentHandler, DTDHandler, EntityResolver, ErrorHandler { >. >. >. >} > >Now that's a lot of interfaces. Lets say we simplify this just a tad... > >public abstract class Filter > implements Parser, DocumentHandler, DTDHandler, EntityResolver, ErrorHandler { > > public Filter() > { > } > > public void setSourceParser(Parser sourceParser) > { > sourceParser.setDocumentHandler(this); > sourceParser.setDTDHandler(this); > sourceParser.setEntityResolver(this); > sourceParser.setErrorHandler(this); > } > > public void setDestinationFilter(Filter destinationFilter) > { > destinationFilter.setSourceParser(this); > } > >} > >This is a minor generalization of ParserFilter which could also serve as a >basis for MDSAX. > >Bill > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shirin at kom.tu-darmstadt.de Fri Jan 22 17:24:31 1999 From: shirin at kom.tu-darmstadt.de (shirin) Date: Mon Jun 7 17:07:58 2004 Subject: inserting an image into an XML document Message-ID: <36A8B490.BA261991@kom.tu-darmstadt.de> >Jonatan Borden wrote >Send an email with an attached image to >mailto:test-xmtp@jabr.ne.mediaone.net >and it will e-mail you back the (MIME) message including attached image in >XML. XMTP defines a MIME<->XML mapping. >Jonathan Borden I sent an Gif-image to test-xmp@jabr.ne.mediaone.net and recieved the (MIME) message, but I don't know how ca xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shirin at kom.tu-darmstadt.de Fri Jan 22 17:39:37 1999 From: shirin at kom.tu-darmstadt.de (shirin) Date: Mon Jun 7 17:07:58 2004 Subject: Inserting an image into an XML document References: <000f01be44e2$ea1401f0$d3228018@jabr.ne.mediaone.net> Message-ID: <36A8B7EF.9B857618@kom.tu-darmstadt.de> "Borden, Jonathan" wrote: > Send an email with an attached image to > > mailto:test-xmtp@jabr.ne.mediaone.net > > and it will e-mail you back the (MIME) message including attached image in > XML. XMTP defines a MIME<->XML mapping. > > Jonathan Borden > http://jabr.ne.mediaone.net > > > > > > > Does anyone know how to insert an image into an XML document? Is this > > done in the XSL or the XML? Also, do you have an example that is on the > > web of an image actually within the xml or xsl (whichever) document? > > > > > > Dante M. Lee Code 588 > > NASA/GSFC Greenbelt MD 20771 > > Voice = 301-521-1077 Bldg = 23 Rm = W415 > > Email = dante@mstirling.gsfc.nasa.gov > > dante4@hotmail.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) I sent an image to test-xmtp and recieved the (MIME) message ,but I can not see it as an image.I see it like a text.How should I do? I work with IE5! Shirin Email = shirin@kom.tu-darmstadt.de xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Jan 22 17:46:57 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:58 2004 Subject: namespaces and document structure [Re: Next Round] References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A79026.DF2BF45A@infinet.com> <36A88C91.DFFC9C0C@mecomnet.de> Message-ID: <36A8B7D2.94286B70@infinet.com> james anderson wrote: > Tyler Baker wrote: > > > > james anderson wrote: > > > > > yes, but... > > ... > > > Neither the prefix nor the qualified name have the same permanence as the > > > local name, the namespace and the expanded name. One could well collect all > > > prefixes in connection with which as symbol appeared, but the values are of no > > > use as the bindings have dynamic extent. > > > the prefix and the qualified name need to be handled separately, through an > > > interface which combines symbols (here called names) with a dynamic parsing or > > > serialization context. > > > > > > The other additions have to be modified accordingly: as the prefix has no > > > meaning outside of the parser's dynamic context, those interfaces have no purpose. > > > > Very true, but sometimes applications (or even the DOM) may want to preserve the exact > > document structure in memory and be able to write out that exact document structure as > > well. That is the only reason for providing the prefix and qualified name methods. > > > > The prefixes bear no relation to document structure. **Strictly speaking** > neither they nor even the URI's have anything to do with content. They simply > aid in identifying the names which figure in the content. That the prefixes > appear in bindings which appear as attributes is a (regrettable) anomoly, but > it does not change their nature. > > (When I hear of application which process *prefixes* I'll take this back.) You may have content which is processed by multiple applications, some of which are namespace aware and some which are not. Some applications may want to do their own namespace processing and will want to know the exact document structure of the original document. Hey, when I hear of an application which actually uses "Namespaces in XML" I'll take a lot of things back. It would be nice if some developers here could post examples of successful uses of "Namespaces in XML" so we have some sort of context to move forward with intregating "Namespaces in XML" into SAX. > As "mr. Bray's" algorithm makes clear, a given document actually is an > instance of an infinately large equivalence class in which the same "content" > appears in varying encodings, each of which employs difference prefixes to > bind respectively identical namespaces. The particular prefixes in one > encoding have no bearing on the ability to write out the same document > structure. To the extent that they affect the ability to duplicate the > *encoding* they do so as a consequence of the relation between prefixes and > *namespaces*, not as a consequence of the relation between prefixes and > individual *names*. Plain and simple, each Name belongs to a particular namespace at a given point in time. The prefix meanings may be volatile, but for applications which want to know "exactly" what the text of the original document looked like (for example editors), I think exposing namespace prefixes, or at a minimum the qualified name would be a good thing. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Fri Jan 22 18:01:35 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:07:58 2004 Subject: Inheritance using DTDs In-Reply-To: <36A89A5E.197AA270@ms.com> (message from Avneet Sawhney on Fri, 22 Jan 1999 10:33:50 -0500) References: <36A7B0F6.71471A7C@ms.com> <13992.31275.963526.751180@localhost.localdomain> <36A89A5E.197AA270@ms.com> Message-ID: <199901221745.LAA03086@bruno.techno.com> [Avneet Sawhney <sawhneya@ms.com>:] > So, since DTD's were not designed to support inheritance, what are > my options here? Even declaring all attributes and elements as > entities is not sufficient. > Will namespaces (and DTD's) be sufficient, or are there any proposed > schemas that have proper inheritance as a required spec? > Sorry if this is obvious, but I would like to know my alternates to > vanilla DTD's. Actually, unless I misunderstand what you're talking about, there is already an ISO standard way of achieving semantic/syntactic inheritance (or, more properly, subtyping); it is already supported by the SP parser for SGML, and it is more extensively supported by GroveMinder for both SGML and XML. The paradigm is variously called "SGML architectures", "architectural forms", "inheritable architectures", "meta-DTDs", "element subtyping", etc. In W3C-land, a similar (and still fairly compatible) paradigm is emerging, variously known as "namespaces" or "vocabularies". If you want to use the full power and rigor of the ISO paradigm in XML, that's just fine; indeed, there is an ISO syntax for using the ISO paradigm with XML (see http://www.ornl.gov/sgml/wg8/document/1957.htm). ISOGEN International Corp is, at least from my perspective, the most visible pioneer in commercializing these ideas. It regularly uses the ISO architectural inheritance paradigm to meet the needs of its consulting and systems integration clients, and they seem pretty happy (and often even ecstatic) about the results. I'll be giving a presentation on this topic at XTech 99 in San Jose on March 7-11 (http://www.gca.org): "Vocabularies: Opportunities for Efficiency and Reliability". Now, if we're talking about what *might* be done in the nebulous future, there do appear to be opportunities for improving the syntax and functionality of DTD notation, so as to support architectural inheritance more elegantly and conveniently (for instance), probably at the cost of increasing the complexity of the notation. However, the ISO standard DTD formalism, as well as XML's currently-almost-identical-to-a-subset-of-ISO DTD formalism, can be used today to declare element types as subtypes of other element types in other DTDs. This has been true since 1997, when ISO/IEC 10744:1997 (http://www.ornl.gov/sgml/wg8/document/1920.htm) was published, but, as was the case with object orientation in general, it takes time for these ideas to percolate throughout the community. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Fri Jan 22 18:42:32 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:07:58 2004 Subject: Representing '&' in URLs In-Reply-To: <199901221745.LAA03086@bruno.techno.com> Message-ID: <Pine.GHP.4.02A.9901221833480.12963-100000@mail.ilrt.bris.ac.uk> Hopefully a simple but not too simple query... Can anyone point me to a best practice note on representing URLs that contain '&' in XML? eg. <ABC DEF="http://abc.def/cgi-bin/search.pl?term=foo&query=bar"/> where we don't want & to generate an error through looking like a broken XML entity. (Not sure how this was ever allowed in HTML in the first place, but that's another story...) I did find a thread at http://www.lists.ic.ac.uk/hypermail/xml-dev/9711/0035.html but that was a while back. Is... <ABC DEF="http://abc.def/cgi-bin/search.pl?term=foo&query=bar"/> the thing to do? Dan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Fri Jan 22 18:56:11 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:07:58 2004 Subject: Representing '&' in URLs In-Reply-To: <Pine.GHP.4.02A.9901221833480.12963-100000@mail.ilrt.bris.ac.uk> (message from Dan Brickley on Fri, 22 Jan 1999 18:42:08 +0000 (GMT)) Message-ID: <199901221854.NAA26686@ruby.ora.com> [Dan Brickley] > Is... > > <ABC DEF="http://abc.def/cgi-bin/search.pl?term=foo&query=bar"/> > > the thing to do? Yes. -Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at isogen.com Fri Jan 22 19:02:49 1999 From: robin at isogen.com (Robin Cover) Date: Mon Jun 7 17:07:58 2004 Subject: Representing '&' in URLs In-Reply-To: <Pine.GHP.4.02A.9901221833480.12963-100000@mail.ilrt.bris.ac.uk> Message-ID: <Pine.GSO.3.96.990122125119.24381A-100000@grind> On Fri, 22 Jan 1999, Dan Brickley wrote: > Hopefully a simple but not too simple query... > > Can anyone point me to a best practice note on representing URLs that > contain '&' in XML? > > eg. <ABC DEF="http://abc.def/cgi-bin/search.pl?term=foo&query=bar"/> > > where we don't want & to generate an error through looking like a broken > XML entity. (Not sure how this was ever allowed in HTML in the first > place, but that's another story...) > is > <ABC DEF="http://abc.def/cgi-bin/search.pl?term=foo&query=bar"/> > > the thing to do? This makes the syntax valid, but unfortunately, only a few Web servers will be able to handle this notation. The same engineers (apparently) who have designed the software to generate the malformed URLs have also designed the servers to grok ONLY raw (unescaped) ampersand. For the notation you have offered, most processors will choke. So, as a document author attempting to compose valid HTML/XML with links of this kind - you're hosed. At least, that's been my experience. -rcc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 22 19:11:44 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:07:58 2004 Subject: Representing '&' in URLs References: <Pine.GSO.3.96.990122125119.24381A-100000@grind> Message-ID: <36A8CD42.D86F7E81@locke.ccil.org> Robin Cover wrote: > This makes the syntax valid, but unfortunately, only a few Web servers > will be able to handle this notation. The same engineers (apparently) > who have designed the software to generate the malformed URLs have > also designed the servers to grok ONLY raw (unescaped) ampersand. For > the notation you have offered, most processors will choke. So, as > a document author attempting to compose valid HTML/XML with links > of this kind - you're hosed. Note that this stricture applies only when you are trying to make well-formed XML that is also usable HTML. If you are only concerned with XML, then use & without fear, as any XML processor will do the right thing before passing the hyperlink to your application. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Fri Jan 22 19:19:05 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:07:58 2004 Subject: Representing '&' in URLs In-Reply-To: <Pine.GSO.3.96.990122125119.24381A-100000@grind> (message from Robin Cover on Fri, 22 Jan 1999 13:02:15 -0600 (CST)) Message-ID: <199901221917.OAA27724@ruby.ora.com> [Robin Cover] > This makes the syntax valid, but unfortunately, only a few Web > servers will be able to handle this notation. The same engineers > (apparently) who have designed the software to generate the > malformed URLs have also designed the servers to grok ONLY raw > (unescaped) ampersand. For the notation you have offered, most > processors will choke. So, as a document author attempting to > compose valid HTML/XML with links of this kind - you're hosed. The problem isn't servers, it's browsers. The browser should come across the markup: href="http://ee.org/%7Euser/cgi/ohm.pl?volt=7&amp=3" and extract the parsed value http://ee.org/%7Euser/cgi/ohm.pl?volt=7&=3 which is then interpreted by the browser: Get '/%7Euser/cgi/ohm.pl?volt=7&=3' from ee.org port 80. The server interprets the requested file, and resolves hex encodings: Run '/~user/cgi/ohm.pl' with QUERY_STRING set to 'volt=7&=3'. The CGI script parses the QUERY_STRING: 'volt' is '7'; 'amp' is '3'. The CGI script should be able to deal with the recommended semicolons as well as the deprecated ampersands ('volt=7;amp=3'). Where the problem occurs is that, until Netscape 3 or so, entity references were never resolved in attribute values. This meant you couldn't do <IMG ALT="-->">. (You couldn't have a raw > in older versions of Netscape because it would end the attribute value there, despite the quotes.) So Netscape applied their entity recognition algorithm: '&' known-entity-name ';'? to attribute values. Netscape will render '◃' as '<ri;' and the same thing happens in attribute values. The markup: href="http://ee.org/%7Euser/cgi/ohm.pl?amp=3&volt=7" will pass without alteration, but the markup: href="http://ee.org/%7Euser/cgi/ohm.pl?volt=7&=3" will be parsed as http://ee.org/%7Euser/cgi/ohm.pl?volt=7&=3 Oh, well. The HTML 2.0 RFC, published over two years ago and in draft for nearly a year before that, recommended using semicolons instead of ampersands for separating parameters, but most CGI scripts don't implement that, so only Lynx has implemented it in the browser, and then only if the ENCTYPE attribute on the <FORM> is some proprietary string. Please pardon my ranting. -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From falk at icon.at Fri Jan 22 20:00:57 1999 From: falk at icon.at (Falk, Alexander) Date: Mon Jun 7 17:07:58 2004 Subject: XML Spy - a new Shareware XML editor for Windows Message-ID: <A01C76E644CAD111B83A0000E8D8890E0579E6@melange.icon.co.at> Fellow members of the XML-Dev mailing list, please forgive me if I slightly "abuse" this discussion list for a brief announcment, but it concerns a shareware development tool that might be interesting for many colleagues here - and I'll keep it very terse: My company has just today released a new structured XML and DTD editor for Windows called "XML Spy" that is distributed as Shareware. Please check out our web-site at http://www.xmlspy.com/ if you are interested in further details... Thank you - and sorry to bother you (I promise there will be no further announcements, so please don't flame me), Alexander Falk http://www.icon-is.com/falk/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990122/96d51fef/attachment.htm From david at megginson.com Fri Jan 22 21:36:58 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:58 2004 Subject: [ADMIN] I am not Paul Butkiewicz Message-ID: <199901222135.QAA00863@megginson.com> I've just looked at the XML-Dev archive, and I noticed that random names are being assigned to my postings, such as "Paul Butkiewicz" (http://www.lists.ic.ac.uk/archives/xml-dev/9901/0478.html) and "Bill la Forge" (http://www.lists.ic.ac.uk/archives/xml-dev/9901/0493.html). The e-mail address is always correct, but the name varies -- has anyone else noticed this problem? Of course, it's nice that I can say stupid things and have them attributed to someone else -- who's next? Thanks, and all the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 22 21:42:56 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:58 2004 Subject: SAX: Next Round In-Reply-To: <E103jdh-0004Zx-00@siren.shore.net> References: <wkzp7c2ux5.fsf@ifi.uio.no> <199901202122.QAA00962@megginson.com> <13991.41975.494212.645715@localhost.localdomain> <E103jdh-0004Zx-00@siren.shore.net> Message-ID: <13992.61347.658381.956807@localhost.localdomain> Paul Rabin writes: > A number of contributors to this discussion are interested in using > SAX as a general interface for assembling XML-processing > components. The extension of parser+application to a chain of > filters is an important first step, but only supports components > with at most one event stream input and at most one event stream > output. Not really -- all you need is one specialised filter for splitting an event stream. > What SAX extensions would be needed to support multiple event > stream inputs and outputs? Filters that route events to one or > more event stream outputs have been implemented. What is the best > way to register the handlers for multiple event stream outputs? The Java-beans-ish way would be to have public void addDocumentHandler(DocumentHandler handler); public removeDocumentHandler(DocumentHandler handler); > Support for multiple event stream inputs raises control flow issues. One > solution is to have a new version of parse() that returns immediately after > initializing the parse context, but without generating any events, and a > new getNextEvent() method that causes a single call to the appropriate > upstream handler to be made before returning. I don't want to deal with synchronization issues at the SAX layer -- the idea is that SAX provides the raw information for higher layers to work with. As long as SAX gives you the basic information about an XML document, you can build a rich superstructure for more complex processing. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Fri Jan 22 21:47:04 1999 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:07:59 2004 Subject: Word and XML (was: XML standards coherency and so forth) Message-ID: <B9D1827FDF66D111925800805F3102E309660E90@RED-MSG-57> > -----Original Message----- > From: John Cowan [mailto:cowan@locke.ccil.org] > Sent: Thursday, January 21, 1999 11:01 AM > To: XML Dev > Subject: Re: Word and XML (was: XML standards coherency and so forth) > > Biron,Paul V wrote: > > > Actually, it is very easy to generate a Word '97 document > which when saved > > as HTML will be non-wellformed. Try the following, where > *xxx* means "make > > xxx bold", and _yyy_ means "make yyy italicized". > > > > This is *a test _of the* emergency_ broadcast system > > > > The relevant portion of the HTML produced by word is > > > > <P>This is <B>a test <I>of the</B> emergency</I> broadcast > > system</P> > > Un*censored*believable. This not only isn't XML, it isn't even > HTML. What were they thinking of? (I know, I know: $$$$.) > Microsoft folks, is there any hope of getting this fixed for > Office 2K? >From my Word 2000 beta: This is <b>a test <i>of the</i></b><i> emergency</i> broadcast system. As some others on this thread have pointed out, the Office 2000 applications do not claim to be using XML as a file format. What they do support is HTML as a "first-class" file save format, using embedded XML islands to describe things (such as OfficeArt) that HTML cannot describe. Steve Mohr's article http://webdev.wrox.co.uk/resources/articles/xmlc/off2000.htm is a pretty good description of how this is done. "First-class" means that HTML is considered co-equal in capabilities and importance to the "native" (e.g. DOC, XLS, etc.) formats. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Fri Jan 22 23:14:14 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:07:59 2004 Subject: Inheritance using DTDs In-Reply-To: <36A89A5E.197AA270@ms.com> (message from Avneet Sawhney on Fri, 22 Jan 1999 10:33:50 -0500) Message-ID: <199901222314.RAA03358@bruno.techno.com> Excuse me, please; I need to add something important to my earlier note: The architectural form paradigm also appears in the "XAF" Java software written my David Megginson and capably documented by him at http://www.megginson.com/XAF. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 22 23:39:33 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:07:59 2004 Subject: ParserFilter & MDSAX Message-ID: <000801be465f$e5ae5ec0$c9a8a8c0@thing2> The MDSAX filters now subclasses John Cowan's ParserFilter. http://www.jxml.com/mdsax/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From grabner at interdim.com Sat Jan 23 00:18:27 1999 From: grabner at interdim.com (Philip J Grabner) Date: Mon Jun 7 17:07:59 2004 Subject: parsing entity values Message-ID: <Pine.GSO.4.02.9901221842160.19389-100000@insanity.interdim.com> hi! i have a dilemna regarding how to parse EntityValue, specifically (as a demonstration of my issue with it) in the following case: <!ENTITY % ap "&#39;" > ( 38 = "&" , 39 = "'" ) <!ENTITY msg "he said %ap;hi!%ap;" > as i understand it, the replacement text for "ap" should be stored as "'" because char ref's and pe's must be replaced by their values. cool. now i get to parsing "msg" and i find the pe. it would be simple to (1) replace '%ap;' with the replacement text thus giving: "he said 'hi!'" (replacement text for "msg") but perhaps this is incorrect, eg you must (2) substitue in the replacement text and 'reparse', thus giving: "he said 'hi!'" (replacement text for "msg") in this particular case, it does not matter. but if indeed the replacement text must be reparsed, as in (2), then this makes the parsing actually quite difficult: according to the XML 1.0 spec section 4.4.5, the characters ' and " no longer are special! eg. the following would be a pain since the parser must remember where the ' is special and where not: <!ENTITY % ap "&#39;" > <!ENTITY % said "%ap;hi!%ap;" > <!ENTITY msg 'he said %said;' > with the following results: entity no-reparse with-reparse ------- ----------- ------------- ap ' ' said 'hi!' 'hi!' msg he said 'hi!' he said 'hi!' the problem is that if "&msg;" is ever used in the document content, they will both evaluate to the same thing. the only difference is that "with-reparse" is more difficult... i hope you understand my dilemna, and thanks for your help. phil. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sat Jan 23 00:57:41 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:59 2004 Subject: Representing '&' in URLs In-Reply-To: <36A8CD42.D86F7E81@locke.ccil.org> Message-ID: <004501be466a$dfda5ca0$d3228018@jabr.ne.mediaone.net> John Cowan wrote: > > Robin Cover wrote: > > > This makes the syntax valid, but unfortunately, only a few Web servers > > will be able to handle this notation. The same engineers (apparently) > > who have designed the software to generate the malformed URLs have > > also designed the servers to grok ONLY raw (unescaped) ampersand. For > > the notation you have offered, most processors will choke. So, as > > a document author attempting to compose valid HTML/XML with links > > of this kind - you're hosed. > > Note that this stricture applies only when you are trying to make > well-formed XML that is also usable HTML. If you are only concerned > with XML, then use & without fear, as any XML processor will > do the right thing before passing the hyperlink to your application. > > > The way I have handled this issue in my XSL sheets that generate HTML from XML is in the following (sample template) ... here the HTML href is created from individual XML attributes and the '&' is used to concatenate these into the output href attribute ... the HTML looks like <img href="dicomjpeg.asp?Study=1.2.840.111&Series=1&Image=54" alt="here is an example" /> <xsl:template match="Images"> <xsl:for-each match="Image"> <xsl:element name="img"> <xsl:attribute name="src">dicomjpeg.asp?Study=<xsl:value-of select="/DICOM:Study/@href"/>&Series=<xsl:value-of select="ancestor(Series)/@Number" />&Image=<xsl:value-of select="@Number"/></xsl:attribute> <xsl:attribute name="alt"><xsl:value-of select="@desc" /></xsl:attribute> </xsl:element> </xsl:for-each> </xsl:template> Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sat Jan 23 01:09:11 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:07:59 2004 Subject: Inserting an image into an XML document In-Reply-To: <36A8B7EF.9B857618@kom.tu-darmstadt.de> Message-ID: <004701be466c$63e11420$d3228018@jabr.ne.mediaone.net> shirin wrote: > > "Borden, Jonathan" wrote: > > > Send an email with an attached image to > > > > mailto:test-xmtp@jabr.ne.mediaone.net > > > > and it will e-mail you back the (MIME) message including > attached image in > > XML. XMTP defines a MIME<->XML mapping. > > I sent an image to test-xmtp and recieved the (MIME) message ,but > I can not > see it as an image.I see it like a text.How should I do? I work with IE5! > The intention is not to demonstrate embedded images in e-mail, rather how embedded image may be represented as base64 encoded data in an XML document, or further how a MIME message is transformed into XML. That being said, I do, of course, have software to display this using XSL and HTML... currently I am doing the XSL conversion on the server and the messages come out as straight HTML pages ... is this at all interesting to people? I can also produce a XML/XSL document which can be transformed on the client i.e. in IE5b2 ... currently, XSL doesn't help transforming a base64 encoded text element into a jpeg file for client viewing so the server needs to pull off the jpeg and send it as a separate document... if there is interest, I can set up either/both as a demo... so far the best pictures have come from the folks in australia :-) Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Jan 23 02:52:45 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:07:59 2004 Subject: DDML Documentation Capabilities Message-ID: <199901230251.VAA00725@megginson.com> First, congratulations to everyone on the publication of DDML as a W3C NOTE. I've started reading through DDML (I looked at XSchema early on, but haven't had time to follow the work), and I'd like to comment not on the schema part, but on the documentation part. I think that the DDML:Doc element, while useful, is insufficient for documentation. There is a certain structural hierarchy of documentation that DTD designers and documentation people almost invariably end up using: 1. The element type name 2. A full title 3. A short description 4. A long description For example: 1. a 2. Anchor 3. The start and/or end point of a hyperlink. 4. The HTML <a> element allows users to... [blah blah blah] DDML covers (1) with the 'Name' attribute, and (4) with the DDML:Doc element, but it completely misses capturing the structure of (2) and (3) in any standard way. What we need to do is something like this: <ElementDef Name="doc"> <Title>Document The root element of a document. ....
You might even want to get fancy and allow , <Desc>, and <DDML:Doc> to be repeated with different values for xml:lang. Obviously, the information for (2) and (3) can be included in <DDML:Doc>, but since it has no standard structure, it is difficult to automatically generate menus, help-files, etc. for DTDs from a DDML description. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Sat Jan 23 03:29:22 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:59 2004 Subject: parsing entity values Message-ID: <00a501be4680$c3145380$0300000a@othniel.cygnus.uwa.edu.au> ><!ENTITY % ap "&#39;" > ( 38 = "&" , 39 = "'" ) ><!ENTITY msg "he said %ap;hi!%ap;" > > > >as i understand it, the replacement text for "ap" should be stored >as "'" because char ref's and pe's must be replaced by their values. Right. The replacement text for ap is ' With msg, the parameter entity is included as part of the replacement text and so the replacement text of msg is he said 'hi!' When the entity msg is referenced within the document element, the character reference is interpreted, resulting in he said 'hi!' Replacement text is never reparsed at the point of declaration. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jan 23 05:37:12 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:07:59 2004 Subject: Office 2000 and XML Islands References: <B9D1827FDF66D111925800805F3102E309660E90@RED-MSG-57> Message-ID: <36A95D1A.A47A7380@prescod.net> Charles Frankston wrote: > > As some others on this thread have pointed out, the Office 2000 applications > do not claim to be using XML as a file format. What they do support is HTML > as a "first-class" file save format, using embedded XML islands to describe > things (such as OfficeArt) that HTML cannot describe. Steve Mohr's article > http://webdev.wrox.co.uk/resources/articles/xmlc/off2000.htm is a pretty > good description of how this is done. "First-class" means that HTML is > considered co-equal in capabilities and importance to the "native" (e.g. > DOC, XLS, etc.) format. #1. What feature of HTML, SGML or XML allows you to change markup languages mid-stream? #2. Will Microsoft publish the schema for Office 2000 data? Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Sat Jan 23 11:21:09 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:07:59 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: <13991.52341.623152.23870@localhost.localdomain> References: <3.0.6.32.19990121202020.00928ec0@gpo.iol.ie> <36a675341a48002@laurel.kp.org> <36A7796C.93059A91@locke.ccil.org> <3.0.6.32.19990121202020.00928ec0@gpo.iol.ie> Message-ID: <3.0.6.32.19990123102850.00b6fe70@gpo.iol.ie> >[Sean Mc Grath] > > RTF doesn't map well to XML -- even very low level -- formatting > > oriented XML -- because of the way RTF is structured. > > > > It is stack based and allows structures to overlap:- > > > > \b1 bold \i1 bold italic \b0 italic \i0 plain > > > > Matching up the on/offs:- > > <b> bold <i> bold italic </b> italic </i> plain > > > > invalid XML (or indeed SGML) because of the overlaps. > [David Megginson] >This is actually quite simple to handle algorithmically by maintaining >a stack and doing a pushback when tags aren't nested: > >RTF Tags Stack >------------------------ >\b1 <b> (b) >\i1 <i> (b i) >\b0 </i></b><i> (i) >\i0 </i> () > I agree that removing the overlap is doable but the fun starts when you try and layer descriptive semantics onto the elements. For typographic effects it doesn't matter because the turn-off-and-immediately-turn-back-on markup is seamless. Different story when, say bold in some context signals telphone element and you get this after unravelling:-) <Telephone>+353 96</Telephone><Telephone><i>473</i></Telephone> I guess I get worried when people say things like "Office 2000 can save stuff in XML therefore we can author our structured documents with it...." If the XML is concerned with low level typography "Save as XML" is still a million miles away from OFX, Duckbook or whatever. <Sean uri="http://www.digitome.com/sean.htm"/> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Sat Jan 23 12:37:20 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:07:59 2004 Subject: Are PI targets arbitrary? Message-ID: <028401be46cd$5cd73400$0300000a@othniel.cygnus.uwa.edu.au> I'm starting to put some options into FOP that are triggered by processing instructions. My initial thought was use 'fop' as the target. But then it occurred to me: PI targets can be associated with a URI via a NOTATION declaration. This is *a lot* like namespaces. Does that mean PI targets should be arbitrary proxies? Instead of looking for PIs with the target "fop" should I instead be looking for PIs with the target which is a NOTATION declared with URI http://www.jtauber.com/fop/ After all, some other application might use the target "fop" but only mine would use the NOTATION with URI http://www.jtauber.com/fop/. What do people think? James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Associate Researcher, Electronic Commerce Network Curtin University of Technology, Perth, Western Australia Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Sat Jan 23 14:53:00 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:07:59 2004 Subject: Are PI targets arbitrary? References: <028401be46cd$5cd73400$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <36A9E17A.91DCDA4@infinet.com> James Tauber wrote: > I'm starting to put some options into FOP that are triggered by processing > instructions. My initial thought was use 'fop' as the target. > > But then it occurred to me: PI targets can be associated with a URI via a > NOTATION declaration. This is *a lot* like namespaces. Does that mean PI > targets should be arbitrary proxies? > > Instead of looking for PIs with the target "fop" should I instead be looking > for PIs with the target which is a NOTATION declared with URI > http://www.jtauber.com/fop/ > After all, some other application might use the target "fop" but only mine > would use the NOTATION with URI http://www.jtauber.com/fop/. This with a little more thought and creativity could evolve into a usable alternative to "Namespaces in XML". I have had ideas myself about using pi's as namespace delimiters, but because of my lack of SGML experience, I really have not looked into the utility of using notations in any of my applications. This looks like something that combined with PI's would be a powerful and simple namespaces implementation that would surpass the the usefulness of "Namespaces in XML" in just about every way imaginable. Perhaps there may be a use of Notations in XML after all. This is a great idea. You would do the XML community a great favor if you could expand upon this concept to cover namespaces in general, since the current "Namespaces in XML" is pretty much unusable for any component-oriented application as well as for using XML for interchange. This has a lot of potential and considering your success with FOP to date, you probably have a better idea than anyone around as to the direction you think this should go. Thanx for the ideas, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tony.mcdonald at ncl.ac.uk Sat Jan 23 15:12:39 1999 From: tony.mcdonald at ncl.ac.uk (Tony McDonald) Date: Mon Jun 7 17:07:59 2004 Subject: Translating XML -> HTML & RTF Message-ID: <v04103c00b2cf933e2969@[128.240.198.13]> Hi all, I'm working on a document management system for Medical Student 'Study Guides' which will allow combining of elements from various XML documents into a single 'document' and thereonto either an HTML or RTF rendering. I would expect our students to select (say) all the sections that are of type 'Core Content' across various sections of the curriculum and then the system combines them into a single unit. My (tentative layout is something like) <studyguide title='Organisation of Tissues'> ... <section title='Core Content' sg_title='Organisation of Tissues'> *1* <text>This part of the course.... </text> <items> <item>Survey of human development;</item> <item>Pre-implantation stages of pregnancy: fertilization, cleavage and implantation;</item> <item>Formation of germ layers and early derivatives;</item> <item>Establishment of the basic embryonic body plan;</item> <item>Causal mechanisms in early development and their clinical relevance.</item> </items> </section> *2* ... </studyguide> I'm using an Expat enabled parser to scan the resultant documents and (try) to do the translations. My problem (or at least one of them) is that I would like the <section>..</section> tag to be replaced by a <h2 class="section">Core Content: Organisation of Tissues</h2> construct, but using expat, I end up with the closing </h2> tag at the line marked *2* above. I've written some bloody messy code that gets around that (ie places the <h2>..</h2> tag sequence up at *1*), but I'm wondering if this doesn't imply that there's something inherently wrong with my document structure (or more likely my understanding). Am I missing a rather obvious (and hopefully simple) point here? I'm pretty pleased with my initial attempts at getting my documents into XML (thanks Marcus!!) and I can see *so* many good things coming out of doing this project 'the XML way' that the loong hours put in at the keyboard is well worth it. They aren't kidding that up-translation is an entropy lowering process, I feel like I've personally lowered the global temperature by a degree or two....sheesh! many thanks in advance, Tone ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Sat Jan 23 16:04:11 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:07:59 2004 Subject: Translating XML -> HTML & RTF In-Reply-To: <v04103c00b2cf933e2969@[128.240.198.13]> Message-ID: <3.0.5.32.19990123110045.01ad9150@nexus.polaris.net> At 03:12 PM 1/23/99 +0000, Tony McDonald wrote: ><studyguide title='Organisation of Tissues'> >... ><section title='Core Content' sg_title='Organisation of Tissues'> *1* [snip] ></section> *2* >... ></studyguide> > >I'm using an Expat enabled parser to scan the resultant documents and >(try) to do the translations. > >...I would like the <section>..</section> tag to be replaced by a <h2 >class="section">Core Content: Organisation of Tissues</h2> construct, >but using expat, I end up with the closing </h2> tag at the line >marked *2* above. I think expat is doing exactly what you asked it to do: turning all of the section element's content into <h2>. One way to fix it might be to turn the title and sg_title attributes into full-blown child elements of the section element, and enclose them in something like a titleinfo wrapper to which you can apply your desired class attribute. Something like this: <section> <titleinfo class="section"> <title>Core Content Organisation of Tissues ... This seems to be a good illustration of one argument in favor of using elements vs. attributes: when you want the content to be easily displayed. Will be interested to see others' replies, if any. ================================================= John E. Simpson simpson@flixml.org http://www.flixml.org Just XML - Now available from Prentice-Hall xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Sat Jan 23 16:41:32 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:00 2004 Subject: Translating XML -> HTML & RTF Message-ID: <003b01be46ee$fdabad40$2aacdccf@ix.netcom.com> Hi, If you change your XML file as follows and ask expat to change *section-title* to H1 you should get the desired result. The way you have it you are making everything in Section a part of H1, and it should inherit section's formating in HTML
'Core Content' This part of the course.... Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) ----- Original Message ----- From: Tony McDonald To: Sent: Saturday, January 23, 1999 10:12 AM Subject: Translating XML -> HTML & RTF xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcdowella at mcdowella.demon.co.uk Sat Jan 23 20:23:19 1999 From: mcdowella at mcdowella.demon.co.uk (A. G. McDowell) Date: Mon Jun 7 17:08:00 2004 Subject: Translation between DTDs, schemas, UML, and the like Message-ID: <20JjQCAP9iq2Ew1H@mcdowella.demon.co.uk> There seem to be a large number of languages devoted to listing (for instance) the fields that make up a customer order and describing their data types. To comprehend a (hypothetical) ecommerce system I might have to follow a relational schema for the underlying database, a UML model of the application classes and logic, and a schema or DTD for the XML used to exchange data with its customers. Is there any hope of a product that could be used to automatically generate some part of this? My chosen format would be UML, but I'm open to reasons why not. There are already drawing tools out there that can generate C++ or Java code from suitably annotated diagrams, and keep the annotations from making the diagrams unreadable: XML DTDs or schemas should just be one more output format. The work on exchange of UML between repositories already seems to involve auto-generating some sort of schema from a description of UML (albeit not couched in UML itself, but in a simpler metalanguage). Finally, there are a lot of people out there who have already decided they need to know UML for the application logic anyway. On the other hand I don't know anywhere I can go to buy a UML -> DTD Rational Rose plugin, complete with round trip functionality and a free mouse mat, so maybe there's some good reason why all this is rubbish. Is anybody planning to convert all the systems analysts to model in XML schemas? Is the gap between exchangeable data, open to the world, and encapsulated objects, observable only via their methods, just too large? I have to admit that I personally have no great desire to write all my Java via Rational Rose. Should I also find a burning desire to hand- craft DTDs? -- A. G. McDowell xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From support at bigriverinfotech.com Sat Jan 23 20:26:37 1999 From: support at bigriverinfotech.com (Ray) Date: Mon Jun 7 17:08:00 2004 Subject: ODI eXcelon and XML Message-ID: <36AA2F42.E60F5C89@bigriverinfotech.com> I will be evaluating Object Design's eXcelon XML Data Server for a period of 90 days on behalf of an organization of the US Government. Should the initial evaluation prove successful, the evaluation will be extended for an additional 180 days. Our intent is to replace traditional relational databases (oracle, sybase, etc.) with an object based XML repository that can manage primitive and complex data types as follows: 1) Persistent storage of Word, Excel, PowerPoint, JPEG, MicroStation and Acrobat documents as complex types. 2) Subsequent conversion of Word and WordPerfect documents to XML documents. 3) Traditional database operations and navigation utilizing primitive types. 4) Subsequent replacement of word processing documents with XML documents and style sheets. Any input on eXcelon and XML for this evaluation would be greatly appreciated. Please respond to both this address and: ray.miller@faa.dot.gov Thanks in advance. Ray xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sat Jan 23 21:02:38 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:00 2004 Subject: Are PI targets arbitrary? In-Reply-To: <028401be46cd$5cd73400$0300000a@othniel.cygnus.uwa.edu.au> from "James Tauber" at Jan 23, 99 08:38:57 pm Message-ID: <199901232148.QAA25758@locke.ccil.org> James Tauber scripsit: > What do people think? I think it is a fine idea, and a good reason why notations are a fully fledged part of XML. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sun Jan 24 03:45:57 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:00 2004 Subject: SAX: Next Round (Namespace support) References: <199901202122.QAA00962@megginson.com> Message-ID: <36AA8C12.BE8A4B22@jclark.com> david@megginson.com wrote: > public interface NamespaceParser > { > public void enableNamespaceProcessing (boolean flag); > public void setSeparator (String sep); > } This looks good, but I don't see the need for two functions. Just void setNamespaceSeparator(String sep); seems to me to be enough: null means disable namespace processing (the default); non-null means expand names using the specified separator. However, I wonder whether it's really a good idea to allow apps to choose the separator. It makes it harder to chain together SAX processes using things like the Filter. If one DocumentHandler expects names separated by # and another expects them separated by !, then they can't work together without some additional glue. I think consideration should be given to mandating a specific separator character. It's not obvious to me what the right answer is here. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sun Jan 24 03:46:15 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:00 2004 Subject: SAX: Next Round References: <199901202122.QAA00962@megginson.com> <36A65A55.E5445A28@locke.ccil.org> Message-ID: <36AA9103.A4ED462B@jclark.com> John Cowan wrote: > Parser filters are > just parsers that have a "parser(Parser)" constructor. This makes a lot of sense to me. With the setParent(Parser parser) idea, what's a filter supposed to do if the app fails to call setParent()? A filter has to have a parent Parser. Your suggestion captures this nicely. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sun Jan 24 03:49:32 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:00 2004 Subject: SAX: Next Round (Lexical Event Handler) References: <199901202122.QAA00962@megginson.com> Message-ID: <36AA93F3.B98FAE05@jclark.com> david@megginson.com wrote: > public interface LexicalHandler > { > public void startDTD (String name, String pubid, String sysid) > throws SAXException; > public void endDTD (String name); > public void startExternalEntity (String name, String pubid, String sysid) > throws SAXException; > public void endExternalEntity (String name) throws SAXException; > public void startCDATA () throws SAXException; > public void endCDATA () throws SAXException; > public void comment (String data) throws SAXException; > } > > I haven't checked, but I think that this gives us everything we need > for DOM level one. I wonder whether LexicalHandler ought to extend DocumentHandler. The events it reports are synchronous with the events reported by DocumentHandler. It seems to me that applications are always going to want to implement either DocumentHandler or both DocumentHandler and LexicalHandler. I would prefer different callbacks for external general and external parameter entities, or at least a parameter to say whether it's general or external. This information can be inferred from start/endDTD, but that's seems unnecessarily obtuse. I think users will be surprised to find both general and parameter entities getting reporting by start/endExternalEntity with no distinction. Doesn't the DOM allow access to internal entities as well? This would be tough to support because internal entities can be referenced in attribute values. What's the point of reporting just external entities? What is the thinking behind giving endExternalEntity() a single name argument (as opposed to, say, no arguments, three arguments, or a single sysid argument)? Similarily for endDTD()? What's the point of the pubid and sysid arguments to startDTD()? This information will be provided via the call to startExternalEntity() for the reference to the external subset. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Jan 24 05:14:04 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:00 2004 Subject: Word and XML (was: XML standards coherency and so forth) Message-ID: <008101be4758$975162a0$5ef96d8c@NT.JELLIFFE.COM.AU> From: Biron,Paul V >Word 97 also produced several well-formedness violations when doing anything >more than simple nested lists. Dave Ragget's program "tidy" is excellent for fixing up badly formed HTML and making it valid (it figures out which HTML DTD the document is valid according to, and generates the appropriate DOCTYPE for it). It also is great for converting to HTML-in-XML (e.g. our website www.ascc.net/xml/ uses it). The program is available at http://www.w3.org/People/Raggett/tidy/ I think website developers should consider making tidy a standard part of website maintenance. Each HTML editing program can do strange things to markup; using tidy on the maintenance fileset and then updating the website fileset is a good way to keep a WF site. without forcing you to give up non-WF tools. Rick xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jonathan at texcel.no Sun Jan 24 12:45:21 1999 From: jonathan at texcel.no (Jonathan Robie) Date: Mon Jun 7 17:08:00 2004 Subject: XML Position at Thesaurus Linguae Graecae Message-ID: <3.0.3.32.19990125074619.00f5ee60@pop.mindspring.com> Forwarded on behalf of the undersigned, to whom responses and inquiries should be directed. Subject: Programming Position at the TLG Project The Thesaurus Linguae Graecae Project (TLG) at the University of California, Irvine seeks to hire a Programmer/Analyst. The successful candidate will be primarily responsible for the development of a Web-based system to structure, search and retrieve the bibliographical, lexical and textual materials comprising the TLG digital library. He/she must have excellent programming skills and experience in relational databases and WWW development tools, preferably in a Unix environment. Experience or at least conceptual knowledge of text encoding methods and standards (particularly SGML/XML and Unicode) is highly desirable. Knowledge of Greek will be a plus. The University of California offers competitive salaries and an attractive benefits package. Position open until filled. UCI is an Equal Opportunity Employer committed to excellence through diversity. For further information and instructions on how to apply, please contact: Professor Maria Pantelia Thesaurus Linguae Graecae University of California Irvine 3450 Berkeley Place Irvine, CA 92697-5550 e-mail: mcpantel@uci.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Sun Jan 24 15:06:13 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:08:00 2004 Subject: Question on ANY (its use in RDF) Message-ID: <990124100534.2262@mail11.mitre.org.0> I have a question about the ANY type. It is my understanding that an element defined to be of type ANY can contain any element that is defined *within* the DTD (i.e., it cannot use elements that are not defined in the DTD). Correct? Consider the RDF.dtd (at bottom). It defines an element rdf:Description that is of type ANY. Here is an example RDF XML document: How can rdf:Description contain the element cat:tables? It is not defined in rdf.dtd. I thought that ANY says that the element can contain any elements defined *within* the DTD? /Roger Here is RDF.dtd: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Sun Jan 24 15:09:16 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:08:00 2004 Subject: Running XSL in IE5B2 (a check list of what changes to make?) Message-ID: <990124100800.2262@mail11.mitre.org.0> Hi Folks, I am trying to understand how I must alter my XSL document to enable it to run in IE5B2. I have added the two default template rules to my xsl documents: That seems to help. Could someone explain what the following error message means: Expected token '||' found 'NAME'. Title -->|<-- Author | Date | ISBN | Publisher Here is the corresponding xsl: What is it complaining about? Has someone compiled a list of things that must be done to make an XSL document work in IE5B2? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Sun Jan 24 15:35:41 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:00 2004 Subject: SAX: Next Round Message-ID: <001201be47ae$9cdf15e0$c9a8a8c0@thing2> From: James Clark >> Parser filters are >> just parsers that have a "parser(Parser)" constructor. > >This makes a lot of sense to me. > >With the setParent(Parser parser) idea, what's a filter supposed to do >if the app fails to call setParent()? A filter has to have a parent >Parser. Your suggestion captures this nicely. Its a problem for MDSAX, which constructs ParserFilters in the other direction, Sink to Source, rather than Source to Sink. On the other hand, as long as a ParserFilter can be constructed with a null Parser, it can be subclassed to subsequently set the parent. The interface MDSAX in now using is public interface MDFilter extends Parser, DocumentHandler, DTDHandler, EntityResolver, ErrorHandler { public void setParser(Parser eventSource); } All of the filters in MDSAX subclass org.ccil.cowan.sax.ParserFilter, but depend on being able to pass a null Parser parameter in the constructor. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jarle.stabell at dokpro.uio.no Sun Jan 24 16:19:19 1999 From: jarle.stabell at dokpro.uio.no (Jarle Stabell) Date: Mon Jun 7 17:08:00 2004 Subject: Translation between DTDs, schemas, UML, and the like Message-ID: <01BE47BE.24202F80.jarle.stabell@dokpro.uio.no> A. G. McDowell wrote: > There seem to be a large number of languages devoted to listing (for > instance) the fields that make up a customer order and describing their > data types. To comprehend a (hypothetical) ecommerce system I might have > to follow a relational schema for the underlying database, a UML model > of the application classes and logic, and a schema or DTD for the XML > used to exchange data with its customers. > > Is there any hope of a product that could be used to automatically > generate some part of this? I suspect such a product will eventually be available. The major analysis work required to do a relational schema, object model and a schema/DTD for XML seems to be the same, finding the entities/classes/elements/components/concepts (or whatever your favourite vocabulary/method calls them) and their relations (and some of the constraints of the relations, multiplicity typically being the most important) When doing object models, you have many more choices for optimalization/design of the implemented structure towards your specific needs/applications than with the relational model. With XML, you unfortunately(?) at some point need to choose whether you should implement a concept as an element or an attribute (most DB/OO design tools forces you to take this similar decision "too early"), and whether you should implement/codify a relation using the tree-structure of XML (child elements), or whether to use IDs and IDREFs type of mechanisms. I believe the major work in designing DTDs/schemas for XML, relational schemas and analysis/high level OO class diagrams could use the same tool/formalism, but that you at some level need to add some extra information/decisions dependent upon the "output format". Cheers, Jarle Stabell Digital Logikk AS xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Jan 24 17:37:31 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:00 2004 Subject: Using XSL as a Validation Language Message-ID: <001801be47c0$584bad00$31f96d8c@NT.JELLIFFE.COM.AU> XSL can act as an XML validation language. The W3C schema effort is tackling something much more ambitious than simple validation it seems, but they won't be ready for a time, so some people might find a more immediate addition to their validation tools useful. Attached is a note in HTML about this, including the XSL templates. Rick Jelliffe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990124/fc340368/XSLasvalidator.htm From paul at prescod.net Sun Jan 24 17:41:09 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:01 2004 Subject: Why informal specs usually win References: <5F052F2A01FBD11184F00008C7A4A80001136A7A@eukbant101.ericsson.se> <36A7E76E.70FDD698@prescod.net> <13992.31871.489850.774574@localhost.localdomain> Message-ID: <36AB589A.3E4E246F@prescod.net> david@megginson.com wrote: > > Informal specs fit into the Worse-is-Better pattern [1]: a less formal > spec that many people can understand easily will generally be adopted > and implemented much more successfully than a more formal spec that > fewer people can understand, despite the disadvantage that the less > formal spec probably contains ambiguities, inconsistencies and > omissions. This is all true, but it isn't complete: formal + hard-to-understand = low adoption, few bugs informal + easy-to-understand = high adoption, many bugs What about: formal + easy-to-understand? Let's not forget that formalisms are educational tools. They help us to understand things. Nobody argues that XML should throw out its BNF or that XML-based languages should throw away their DTDs (or other schemas). In other words, formalisms help you to understand *if you know the formalism*. Prose would be easier to understand than BNF for someone who didn't know BNF, at first, but over the long term, it would be harder to follow. This implies that the responsibility of the W3C is not to avoid formality, but to educate people on a few, well-designed, easy-to-learn formalisms which can serve to increase understanding. In other words, this is one of those short-term/long-term decisions that drive everything. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jarle.stabell at dokpro.uio.no Sun Jan 24 21:29:08 1999 From: jarle.stabell at dokpro.uio.no (Jarle Stabell) Date: Mon Jun 7 17:08:01 2004 Subject: How to use xml:lang? (was: DDML Documentation Capabilities) Message-ID: <01BE47E9.804DB180.jarle.stabell@dokpro.uio.no> David Megginson wrote: > You might even want to get fancy and allow , <Desc>, and > <DDML:Doc> to be repeated with different values for xml:lang. > Obviously, the information for (2) and (3) can be included in > <DDML:Doc>, but since it has no standard structure, it is difficult to > automatically generate menus, help-files, etc. for DTDs from a DDML > description. I agree that this information would be great for tools to have available. One question (not about DDML in particular) regarding how to best use xml:lang: Should the DDML look something like: <Title xml:lang="de"> Title in german Description in german Title in english Description in english etc... or should one use something similar to: <if xml:lang="de">Title in german</if><if xml:lang="en">Title in english</if>.... Description in germanDescription in english The latter seems in a sense "cleaner" to me, as the first one seems to have a somewhat "bad influence" upon the DTD (enabling multiple Title elements etc when it "logically" only should contain a single one, or does what seems the most "logical" depend upon the perspective/application?) Are there any consensus as to how to best handle this situation? Cheers, Jarle Stabell Digital Logikk AS xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Sun Jan 24 23:00:48 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:08:01 2004 Subject: XSA 1.0 specification released Message-ID: XSA is an XML-based system that allows anyone who is interested to automatically discover new versions of software products as they are released by polling XML documents describing the products. It is mainly intended to help software index maintainers keep their indexes up to date. I have now finalized the XSA 1.0 specification and XSA is thus ready for use. The accompanying software is still being tested, but will be released as soon as possible, probably in a week or so. I will announce it here when it is ready. What this means is that we now have an XML application for publishing structured information on the web that is ready for use. I am using it (via a cron job on my Linux machine) to keep track of new releases on my XML tools list[1], and I'm confident that other software list maintainers will start using the system as well once I release the software. So, to all you developers of XML software: please make yourself an XSA document and publish it on the web. That way we can both keep the software indexes updated and demonstrate that XML can actually be used. The more people who do this, the more useful the system will be. The XSA site contains both a wizard for making documents, an online validator and a form for registering new XSA documents. --Lars M. [1] xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Sun Jan 24 23:46:04 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:08:01 2004 Subject: Question on ANY (its use in RDF) References: <990124100534.2262@mail11.mitre.org.0> Message-ID: <36ABB066.42B125CD@allette.com.au> Roger L. Costello wrote: > I have a question about the ANY type. It is my understanding > that an element defined to be of type ANY can contain any > element that is defined *within* the DTD (i.e., it cannot use > elements that are not defined in the DTD). Correct? My advice to anyone is never accept a DTD that uses ANY. The only legimate use I have ever seen for it is in an interim DTD during data conversion. It's a sloppy use of a sloppy mechanism - for example, would you really want to support an infinite number of nested rdf:Description elements? There is no preventing this - even the DOCTYPE element can be nested within itself. > How can rdf:Description contain the element cat:tables? It is > not defined in rdf.dtd. I thought that ANY says that the element > can contain any elements defined *within* the DTD? > Here is RDF.dtd: > > ... > > > > > Nor is the element PCDATA, used in the parameter entity named value. If this is supposed to be #PCDATA, it needs to appear before %rdfObj;. Unless we're missing something about extending this DTD, it appears to be a dud. Someone has not been very considerate of your time. -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rschoening at unforgettable.com Mon Jan 25 00:10:13 1999 From: rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:08:01 2004 Subject: SAX: Next Round In-Reply-To: <001201be47ae$9cdf15e0$c9a8a8c0@thing2> Message-ID: <000001be47f7$147579d0$bda8b4d1@yak.ptld.uswest.net> > On the other hand, as long as a ParserFilter can be constructed with a > null Parser, it can be subclassed to subsequently set the parent. I'll second this. It's easy to get boxed in when too much code gets initialized in the constructor. Often I find that code is in the constructor not because it belongs there but because it makes issues of immutability plainly obvious. But this gets difficult when you try to implement a non-trivial inheritance structure. I have found that this can be especially frustrating (at least in Java) since constructor calls to super() must precede all other code in the constructor. Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jan 25 02:10:07 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:08:01 2004 Subject: Why informal specs usually win In-Reply-To: <36AB589A.3E4E246F@prescod.net> References: <5F052F2A01FBD11184F00008C7A4A80001136A7A@eukbant101.ericsson.se> <36A7E76E.70FDD698@prescod.net> <13992.31871.489850.774574@localhost.localdomain> <36AB589A.3E4E246F@prescod.net> Message-ID: <13995.51950.535121.200081@localhost.localdomain> Paul Prescod writes: > david@megginson.com wrote: > > > > Informal specs fit into the Worse-is-Better pattern [1]: a less formal > > spec that many people can understand easily will generally be adopted > > and implemented much more successfully than a more formal spec that > > fewer people can understand, despite the disadvantage that the less > > formal spec probably contains ambiguities, inconsistencies and > > omissions. > > This is all true, but it isn't complete: > > formal + hard-to-understand = low adoption, few bugs > informal + easy-to-understand = high adoption, many bugs > > What about: > > formal + easy-to-understand? It can be done, but it's an enormous task. I cannot easily think of a good example right now, but I might be able to do so if I tried harder. Certainly, the BNF in the XML spec (which Paul points out later in his message) makes things generally better rather than worse, especially given the fact that a primary audience for that spec was parser writers; on the other hand, I find the BNF in the RDF spec rather more confusing than otherwise. > [...] In other words, formalisms help you to understand *if you > know the formalism*. Prose would be easier to understand than BNF > for someone who didn't know BNF, at first, but over the long term, > it would be harder to follow. I would have been able to learn how to pronounce the word "Hoosier" much more quickly if someone had just sent me the IPA (International Phonetic Alphabet) transcription, because I know IPA; nevertheless, the explanation "'who's yer', as in 'who's yer mama?'" will reach many more people. > This implies that the responsibility of the W3C is not to avoid > formality, but to educate people on a few, well-designed, > easy-to-learn formalisms which can serve to increase > understanding. In other words, this is one of those > short-term/long-term decisions that drive everything. There are gradations of formality, and I agree with Paul that purely prose specs are unsuitable both because they are imprecise and because they tend to be unnecessarily verbose. I disagree, however, that the W3C can rely on educating the public to understand a higher degree of formalisms, if only because people will not accept spending the time learning the formalisms until they are already interested enough in the specs. Or, more succinctly, people won't always bother to learn -- this is simply an environmental fact in the industry, like the fact the ships often have to sail on rough seas: figure out where your spec will be sailing and design it appropriately, rather than trying to change the weather. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jan 25 02:49:29 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:01 2004 Subject: SAX: Next Round (Namespace support) In-Reply-To: <36AA8C12.BE8A4B22@jclark.com> from "James Clark" at Jan 24, 99 09:57:22 am Message-ID: <199901250335.WAA22219@locke.ccil.org> James Clark scripsit: > However, I wonder whether it's really a good idea to allow apps to > choose the separator. It makes it harder to chain together SAX processes > using things like the Filter. If one DocumentHandler expects names > separated by # and another expects them separated by !, then they can't > work together without some additional glue. I think consideration should > be given to mandating a specific separator character. It's not obvious > to me what the right answer is here. The criteria I used were: 1) must be ASCII 2) must not be whitespace 3) must not be valid in a URI 4) must not be valid in an NCName 5) must not commonly appear after a URI (#, |) or before an NCName(:). The result? Circumflex. http://www.ccil.org/~cowan/xmlns/foo^bar means foo:bar when xmlns:foo="http://www.ccil.org/~cowan/xmlns". -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Jan 25 07:55:45 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:01 2004 Subject: Understanding RDF Message-ID: <36AC1FD9.89F8789B@prescod.net> I keep thinking I understand RDF and then I look at DCD and think "I guess I don't." DCD is supposed to be an RDF vocabulary, right? I know that it uses some extensions to RDF (argh!), but even so, I don't see how it works. Rdf :: = [ ] description * [] It is odd to me that the RDF wrappers are optional and that not even an RDF identifying attribute or processing instruction is required, but okay let's presume that we "know" that a DCD is an RDF and have just left off the wrapper elements. That means that the root DCD element is a description. description ::= typedNode typedNode ::= property* But DCD says DCD ::= elementDef * (I presume...I can't actually find a grammar in the DCD spec. but I haven't looked hard...it certainly isn't in the table of contents) So what are the properties of the DCD node? Just ElementDef and AttributeDef? Am I to understand that these are vector-valued properties? People complain about SGML minimization, but RDF abbreviation is much more complicated. Perhaps someone can walk me through the expansion of A DCD document into completely described nodes and properties. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Jan 25 07:55:48 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:01 2004 Subject: Translation between DTDs, schemas, UML, and the like References: <20JjQCAP9iq2Ew1H@mcdowella.demon.co.uk> Message-ID: <36AC1FA3.88C12E16@prescod.net> "A. G. McDowell" wrote: > > There seem to be a large number of languages devoted to listing (for > instance) the fields that make up a customer order and describing their > data types. To comprehend a (hypothetical) ecommerce system I might have > to follow a relational schema for the underlying database, a UML model > of the application classes and logic, and a schema or DTD for the XML > used to exchange data with its customers. > > Is there any hope of a product that could be used to automatically > generate some part of this? My chosen format would be UML, but I'm open > to reasons why not. My primary argument would be that AFAIK UML is not a language in the computer-science/chomsky sense! It is a graphical notation. You can't email me the UML code for "a class" (though you could mail me the mutually incompatible output of various UML modeling programs). As I understand it, there are initiatives afoot to make standard serializations for UML diagrams, but those are not UML itself. If my understanding is out of date, perhaps someone could fill me in. Now even if we presume the existence of a standard UML serialization, I am not confident that our goals in DTD creation and object modeling are the same. UML describes how a system functions. Database schemas describe how its data should be persisted. DTDs describe how the data should be interchanged. System function modeling is focussed on increasing reliability, usability and reusability. Persistence modeling is focussed on reducing duplication and providing efficient navigation and querying. Interchange is focused on expressing very careful, very explicit constraints on what is and is not allowed, and in what order. I fear that if you tried to build a single schema to accomplish all of these things, it would have to be very complex and sophisticated. It would need to incorporate features of IDL, SQL, STEP and DTDs. Perhaps it's possible, but I don't think that UML is anywhere close. I fear greatly that this overcomplicated monster is what many participants expect as the result of the W3C XML schema language effort. Also note that XML still has a major role to play in the document world. This implies many usability concerns that would need to be recognized by this UBER-Schema. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Jan 25 09:16:45 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:01 2004 Subject: Why informal specs usually win References: <5F052F2A01FBD11184F00008C7A4A80001136A7A@eukbant101.ericsson.se> <36A7E76E.70FDD698@prescod.net> <13992.31871.489850.774574@localhost.localdomain> <36AB589A.3E4E246F@prescod.net> <13995.51950.535121.200081@localhost.localdomain> Message-ID: <36AC31B5.2B5AF4A2@prescod.net> david@megginson.com wrote: > > I disagree, however, that the > W3C can rely on educating the public to understand a higher degree of > formalisms, if only because people will not accept spending the time > learning the formalisms until they are already interested enough in > the specs. But people usually become interested in standards before they read the specs (if they ever do). Consider SQL. How many people have ever read a SQL spec? People get interested in standards based on what they are told the standard will do for them, not what the spec. looks like. I'm sure it will annoy some people to hear it, but specs are for implementors and very sophisticated users. Joe Average will never read a spec., no matter how "friendly" it is. Specifications are more like laws than they are like novels. The move to informal specs has not decreased the need for "language lawyers" -- it has just made their job harder. It has also made implementors jobs harder, which works AGAINST the popularity of the language. > Or, more succinctly, people won't always bother to learn -- this is > simply an environmental fact in the industry, like the fact the ships > often have to sail on rough seas: figure out where your spec will be > sailing and design it appropriately, rather than trying to change the > weather. It is demonstrably the case that the "weather" can be changed. John Backus and Peter Naur chose to invent BNF. In doing so they fundamentally changed the standardization "climate." Thank God they didn't rely on prose and wait for someone else to figure out the formalism later. "To be precise, most of BNF was introduced by Backus in a report presented at an earlier UNESCO conference on ALGOL 58. Few read the report, but when Peter Naur read it he was surprised at some of the differences he found between his and Backus's interpretation of ALGOL 58. He decided that for the successor to ALGOL, all participants of the first design had come to recognize some weaknesses, should be given in a similar form so that all participants should be aware of what they were agreeing to." "Since then, almost every author of books on new programming languages used it to specify the syntax rules of the language." - http://cuiwww.unige.ch/db-research/Enseignement/analyseinfo/AboutBNF.html Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge. - Grace Hopper xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Mon Jan 25 12:16:21 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:08:01 2004 Subject: Question on ANY (its use in RDF) Message-ID: <990125071525.2262@mail11.mitre.org.0> Marcus Carr wrote: >> Here is RDF.dtd: >> >> ... >> >> >> >> >> > >Nor is the element PCDATA, used in the parameter entity named value. If this is >supposed to be #PCDATA, it needs to appear before %rdfObj;. Unless we're missing >something about extending this DTD, it appears to be a dud. Someone has not been >very considerate of your time. I guess that I should know this, but why would #PCDATA need to come before %rdfObj? I got this RDF.dtd off the IBM alphaworks site. Someone emailed me and said that there is no RDF.dtd. True/false? Back to my original question - if I define an element in a DTD of type ANY, can I create a child element in an instance document that is not in the DTD? /Roger > > >-- >Regards, > >Marcus Carr email: mrc@allette.com.au >___________________________________________________________ ________ >Allette Systems (Australia) www: http://www.allette.com.au >___________________________________________________________ ________ >"Everything should be made as simple as possible, but not simpler." > - Einstein > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Livinsb at rbos.co.uk Mon Jan 25 12:23:40 1999 From: Livinsb at rbos.co.uk (Livingstone, Stephen) Date: Mon Jun 7 17:08:01 2004 Subject: XML pages from Databases Message-ID: <217258E84FF7CF11B4630001FA44B2D5027A6F93@REFROWTECX1> A bit of advice please ! I am looking to implement a system which creates XML pages dynamically from information which we shall store in a database using asp and xsl. This data should be searchable and shall be used in a web application. Does anyone have any advice on the best ways to do this?? Should just the data be stored in the database? Or should the marked-up data be stored in the database? Should we have a combination of these by using structured columns of marked up data? Anybody got any opinions? thanks for responses.. steven Steven Livingstone BSc MSc GradInstP Corporate Systems Development (TCN) Royal Bank Of Scotland. > *: mailto:livinsb@rbos.co.uk > *: +44 0131 523 4354 [x24354] > Networking Technical Associates, Glasgow, Scotland. > *: mailto:ntw_uk@hotmail.com > *: +44 07771-957-280 This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. 'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.' xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Jan 25 14:34:29 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:01 2004 Subject: Why informal specs usually win In-Reply-To: <36AC31B5.2B5AF4A2@prescod.net> References: <5F052F2A01FBD11184F00008C7A4A80001136A7A@eukbant101.ericsson.se> <36A7E76E.70FDD698@prescod.net> <13992.31871.489850.774574@localhost.localdomain> <36AB589A.3E4E246F@prescod.net> <13995.51950.535121.200081@localhost.localdomain> Message-ID: <199901251433.JAA27461@hesketh.net> David Megginson wrote: >>[Paul Prescod] >> What about: >> >> formal + easy-to-understand? > >It can be done, but it's an enormous task. I cannot easily think of a >good example right now, but I might be able to do so if I tried >harder. We attempted this in XSchema; while I can't claim that we did a perfect job, making the spec readable for the largest possible number of readers, from implementors to schema writers, was definitely a key goal. (In large part this was due to the strong reactions I still get when trying to tease out meaning from many parts of the XML 1.0 spec.) The formality is there in the DTD version of the spec; the easy-to-understand is there in the prose and example. Another good case of a highly readable spec is Cascading Style Sheets, Levels 1 and 2. (Especially 2.) CSS is the only recommendation I feel comfortable telling users to read directly, rather than finding a translation in a bookstore. (Yes, I know implementors have grumbled about CSS - but most of the grumbling really does feel like political cover for a job they did poorly in the first place.) At 02:56 AM 1/25/99 -0600, Paul Prescod wrote: >I'm sure it will annoy some people to hear it, but specs are for >implementors and very sophisticated users. Joe Average will never read a >spec., no matter how "friendly" it is. Specifications are more like laws >than they are like novels. The move to informal specs has not decreased >the need for "language lawyers" -- it has just made their job harder. It >has also made implementors jobs harder, which works AGAINST the popularity >of the language. There is no need to limit your audience to implementors and very sophisticated users; if necessary, just provide both the formal and the informal versions, with the formal always having greater priority. Groups that aren't willing to write a friendly version are limiting their audience and demonstrating vividly their lack of interest in real users. (Among other things, it makes it extremely easy for their detractors to paint them as out-of-touch academics - and have people believe them.) Treating 'real users' as second-class citizens is a common habit in the computing community, and one that's done real damage to the widespread use of all of these great ideas. >[David Megginson wrote:] >> Or, more succinctly, people won't always bother to learn -- this is >> simply an environmental fact in the industry, like the fact the ships >> often have to sail on rough seas: figure out where your spec will be >> sailing and design it appropriately, rather than trying to change the >> weather. > >[Paul Prescod] >It is demonstrably the case that the "weather" can be changed. John Backus >and Peter Naur chose to invent BNF. In doing so they fundamentally changed >the standardization "climate." Thank God they didn't rely on prose and >wait for someone else to figure out the formalism later. On this one I'll agree, though I'm very glad that the growth of XML promises to eliminate the use of BNF in document formats. XML, even with its odd syntax for describing document structures and (still) limited vocabulary, has more readability than BNF while still retaining a clean and formal means of expression. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jan 25 15:03:08 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:08:02 2004 Subject: Running XSL in IE5B2 (a check list of what changes to make?) In-Reply-To: <990124100800.2262@mail11.mitre.org.0> (costello@mail11.mitre.org) Message-ID: <199901251501.KAA02313@ruby.ora.com> [Roger L. Costello] > That seems to help. Could someone explain what the following error > message means: > > IE5 doesn't support the | operator in patterns. The best place for XSL questions is the XSL list; information is available at . -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Jan 25 15:08:51 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:02 2004 Subject: namespaces and document structure [Re: Next Round] References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A79026.DF2BF45A@infinet.com> <36A88C91.DFFC9C0C@mecomnet.de> <36A8B7D2.94286B70@infinet.com> Message-ID: <36AC8A01.F7E61C11@mecomnet.de> Tyler Baker wrote: > > james anderson wrote: > > > ... > > > > (When I hear of application which process *prefixes* I'll take this back.) > > You may have content which is processed by multiple applications, some of which are > namespace aware and some which are not. Some applications may want to do their own > namespace processing and will want to know the exact document structure of the original > document. Hey, when I hear of an application which actually uses "Namespaces in XML" I'll > take a lot of things back. It would be nice if some developers here could post examples of > successful uses of "Namespaces in XML" so we have some sort of context to move forward with > intregating "Namespaces in XML" into SAX. We have a rather large application which uses XML as the encoding for data exchange between a mid-tier server and java-base ui-frontends. In itself that's nothing special. There is, however, one aspect which has a bearing on this discussion. The mid-tier-animal is implemented in lisp. Which means that symbols abound. Which means that the efficiency and clarity of the implemention benefits extrordinarily from unambiguous names. Which means it has depended on a "namespace substrate" since before XML was a PR. > > ... > > Plain and simple, each Name belongs to a particular namespace at a given point in time. The > prefix meanings may be volatile, but for applications which want to know "exactly" what the > text of the original document looked like (for example editors), I think exposing namespace > prefixes, or at a minimum the qualified name would be a good thing. > This passage is unclear. The concept "Name" was supplanted in the ns-spec with either 1. "NCName" for that case where either the generic name for a "Prefix" or a "LocalPart" is intended, or 2. "QName" for the case where a "Name" is encoded in a document, or 3. an "universal name", the scope of which "extends beyond the document". It is not clear which of these is the intended meaning of "Name" in the passage above. In any event 1. a "NCName" cannot belong to a namespace. It may be the "LocalPart" of a qualified name - which may be among the names comprised by a namespace 2. a "QName" also does not belong to a namespace, it merely encodes a mapping to a universal name, but does so under specific conditions only 3. an "universal name" is comprised by (or interned in) a namespace, and meets this condition without temporal or lexical restriction. The relation to a content model and or attribute declaration may be restricted. As to the editor question: the application noted includes no code outside of the parser which references a prefix. That's because no application need pay attention to the prefixes which were in effect at the time a universal name was decoded. An application need pay attention to URI's only. In the case of lisp, the application need not pay direct attention to them either, as the lisp reader implements rules analogous to namespace when it parses, so the symbols are simply identical. If one desires, for legibility or vanity reasons, to specify or present a prefix, this can be performed reliably with reference to elements only - not with reference to names, and only as a side-effect of the relation between the name, the URI of the comprising namespace, and a prefix binding effected by the element. If the application is an XML editor, it will not be permitted the luxury of presuming that the prefix which was in effect when an element was decoded is the correct prefix at the point in time where a name is encoded - whether for view, for interpretetation, or for transmission. If it does make this presumption, then it will not be a very powerful editor. That is to say, in the presence of namspeaces, there is no canonical encoding. One can make believe, but the effect won't carry very far. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Jan 25 15:23:17 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:02 2004 Subject: interned names [Re: Next Round] References: <00f401be44e1$3f816e90$2ee044c6@arcot-main> <36A69CC4.1F8A0CF6@infinet.com> <36A75899.9D1CF338@mecomnet.de> <36A78971.C04FB742@locke.ccil.org> <36A88D8B.ECB991E5@mecomnet.de> <36A8A262.911366D1@locke.ccil.org> Message-ID: <36AC8D4A.3B3694B7@mecomnet.de> John Cowan wrote: > > > It suffices to permit the application to process > > names in the parser's dynamic context. To this end it need no explicit access > > to the prefix<->uri map, just to an interface which interns qualified names > > given the parser's dynamic context. > > Probably sufficient; it may be, however, that there is an occasional > need to generate a currently-correct Qname from a URI+NCName. > The only occasion to do this is when encoding the name for serialization. This belongs not "in the application", but rather in the parsing/encoding layer. Even if the application is an editor which serializes for presentation. I would be surprised were editor to run around changing the effective prefixes for qualified names each time an edit operation takes place. It is more likely to ensure that unique prefixes are available either at the document (ie root element) level, or introduce them into elements as required, and then permit an encoding substrate to do its job - in which case the binding specification will not be in the name but in the element. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jan 25 15:27:20 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:08:02 2004 Subject: Question on ANY (its use in RDF) In-Reply-To: <36ABB066.42B125CD@allette.com.au> (message from Marcus Carr on Mon, 25 Jan 1999 10:44:38 +1100) Message-ID: <199901251525.KAA02906@ruby.ora.com> [Marcus Carr] > Roger L. Costello wrote: > > I have a question about the ANY type. It is my understanding that > > an element defined to be of type ANY can contain any element that > > is defined *within* the DTD (i.e., it cannot use elements that are > > not defined in the DTD). Correct? Correct. > My advice to anyone is never accept a DTD that uses ANY. The only > legimate use I have ever seen for it is in an interim DTD during > data conversion. It's a sloppy use of a sloppy mechanism - for > example, would you really want to support an infinite number of > nested rdf:Description elements? There is no preventing this - even > the DOCTYPE element can be nested within itself. However, remember that a document type is composed of its formal specification *and* its prose specification. Moreover, RDF is explicitly intended for use with namespaces. The RDF DTD expresses constraints among RDF elements; using ANY in the content model of its root was a good idea, just like HyTime uses ANY for most of its content models. Though I don't think the spec explicitly says so, RDF is more akin to an architecture than to a document type, but without the ability to rename element types. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Jan 25 15:48:04 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:02 2004 Subject: Are PI targets arbitrary? References: <028401be46cd$5cd73400$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <36AC9334.1B705C2@mecomnet.de> One way in which this differs from namespaces is that it does not provide a mechanism to avoid name conflicts. A consistently applied encoding mechanism for namespaces would have. That is, the ns-spec should well have premitted all names to be qualified names. Since it precludes the name in a notation from being qualified, it is not possible to use notation to this end. I have heard the argument, that the association with a notation and the uri specification for a notation obviates the need for qualification. It didn't understand the claim. I still don't. One really needs to an encoding of the form which together with the binding < ... xmlns:fop="http://www.jtauber.com/fop/" ... > would permit the application to operate with a token of the form ("http://www.jtauber.com/fop/" X "some-command") and be assured that there are no name conflicts. Yes, the present spec would permit this, but does not describe its effect. James Tauber wrote: > > I'm starting to put some options into FOP that are triggered by processing > instructions. My initial thought was use 'fop' as the target. > > But then it occurred to me: PI targets can be associated with a URI via a > NOTATION declaration. This is *a lot* like namespaces. Does that mean PI > targets should be arbitrary proxies? > > Instead of looking for PIs with the target "fop" should I instead be looking > for PIs with the target which is a NOTATION declared with URI > http://www.jtauber.com/fop/ > After all, some other application might use the target "fop" but only mine > would use the NOTATION with URI http://www.jtauber.com/fop/. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Mon Jan 25 15:50:36 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:08:02 2004 Subject: Question on ANY (its use in RDF) In-Reply-To: <199901251525.KAA02906@ruby.ora.com> Message-ID: On Mon, 25 Jan 1999, Chris Maden wrote: > [Marcus Carr] > > Roger L. Costello wrote: > > > I have a question about the ANY type. It is my understanding that > > > an element defined to be of type ANY can contain any element that > > > is defined *within* the DTD (i.e., it cannot use elements that are > > > not defined in the DTD). Correct? > > Correct. > > > My advice to anyone is never accept a DTD that uses ANY. The only > > legimate use I have ever seen for it is in an interim DTD during > > data conversion. It's a sloppy use of a sloppy mechanism - for > > example, would you really want to support an infinite number of > > nested rdf:Description elements? There is no preventing this - even > > the DOCTYPE element can be nested within itself. > > However, remember that a document type is composed of its formal > specification *and* its prose specification. Moreover, RDF is > explicitly intended for use with namespaces. The RDF DTD expresses > constraints among RDF elements; using ANY in the content model of its > root was a good idea, just like HyTime uses ANY for most of its > content models. Though I don't think the spec explicitly says so, RDF > is more akin to an architecture than to a document type, but without > the ability to rename element types. This is probably true, but there is no 'RDF DTD' as such. The rdf.dtd thing is I believe something experimental found on IBM's Alphaworks site and not from the RDF Model and Syntax spec. Dan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jan 25 16:01:58 1999 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:08:02 2004 Subject: Question on ANY (its use in RDF) In-Reply-To: <990125071525.2262@mail11.mitre.org.0> (costello@mail11.mitre.org) Message-ID: <199901251559.KAA04542@ruby.ora.com> [Roger L. Costello] > I guess that I should know this, but why would #PCDATA need to come > before %rdfObj? Because the XML specification says so. Mixed content must have the form: (#PCDATA) or (#PCDATA | elem-type-1 | elem-type-2 ...)* No other option is permitted. It's possible that they really meant an element type called PCDATA, in which case the model is okay, but that would be a very ill-considered choice of element type names. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Jan 25 16:03:56 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:02 2004 Subject: SAX: Next Round (Namespace support) References: <199901250335.WAA22219@locke.ccil.org> Message-ID: <36AC9689.E27957EC@mecomnet.de> I would like to pose the question: "why is this separator necessary?". I am aware, that the tendancy is to drag the URI's around as an immediate part of the universal name. Which leads to the "out-of-band" separator. But... Why is it necessary to catenate the URI with the local part of the name? In other words, if it is a matter of implementation, I wonder why it isn't a really good idea to intern the names into collections which are named by URI. If that happens - whether immediately while parsing or later "within the application", then the intermediate catenated form is unnecessary. At the least, wouldn't it be better to leave this decision (both whether to catenate, and if so with which separator) to a name factory - so long as the resulting instances conform to the interface which yields local, uri, and universal names? John Cowan wrote: > > James Clark scripsit: > > > However, I wonder whether it's really a good idea to allow apps to > > choose the separator. It makes it harder to chain together SAX processes > > using things like the Filter. If one DocumentHandler expects names > > separated by # and another expects them separated by !, then they can't > > work together without some additional glue. I think consideration should > > be given to mandating a specific separator character. It's not obvious > > to me what the right answer is here. > > The criteria I used were: > > 1) must be ASCII > 2) must not be whitespace > 3) must not be valid in a URI > 4) must not be valid in an NCName > 5) must not commonly appear after a URI (#, |) or before an NCName(:). > > The result? Circumflex. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Mon Jan 25 16:15:41 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:08:02 2004 Subject: parsing entity values In-Reply-To: James Tauber's message of Sat, 23 Jan 1999 11:30:07 +0800 Message-ID: <199901251612.QAA02610@cogsci.ed.ac.uk> > > ( 38 = "&" , 39 = "'" ) > > > Right. The replacement text for ap is > > ' Yes. > With msg, the parameter entity is included as part of the replacement text > and so the replacement text of msg is > > he said 'hi!' No. See the table in section 4.4. We have a parameter entity reference in an entity value, so it is "included in literal". 4.4.5 says "[the parameter entity's] replacement text is processed in place of the reference itself as though it were part of the document at the location the reference was recognised, except that a single or double quote character [...] will not terminate the literal". So the ' is processed as if it had occurred directly in the definition of msg. You can't see the difference in this case, but if we had: the replacement text of elt would be <=> not <=> and should be detected as a syntax error if &elt; occurred in the body. Phil suggests that having to keep track of where the quotes are special makes the parsing quite difficult; I don't think this is true, though perhaps it depends on how your parser works. Mine just checks to see whether it read the quote character from the same entity that it read the opening quote from. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jan 25 16:46:07 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:02 2004 Subject: Understanding RDF References: <36AC1FD9.89F8789B@prescod.net> Message-ID: <36AC9F9E.8CAA1F88@locke.ccil.org> Paul Prescod wrote: > I keep thinking I understand RDF and then I look at DCD and think "I > guess I don't." DCD is supposed to be an RDF vocabulary, right? Well, sort of. It is Microsoft RDF, not W3C RDF. :-) > So what are the properties of the DCD node? Just ElementDef and > AttributeDef? > Am I to understand that these are vector-valued properties? Multivalued rather than vector (Sequence, in RDF terms) valued. A property may have more than one value (in current RDF terms, there may be multiple sentences with a common subject and predicate), as you'd expect. > People complain about SGML minimization, but RDF abbreviation is much > more complicated. Perhaps someone can walk me through the expansion of > A DCD document into completely described nodes and properties. I'll try. Here's the example from clause 1.1: Describes an airline reservation LastName FirstInitial SeatRow SeatLetter Departure Class And here's my attempt to make unabbreviated correct RDF: Booking" Elements Closed Describes an airline reservation LastName FirstInitial SeatRow SeatLetter Departure Class SeatRow Data i1 1 72 SeatLetter Data char A K http://www.w3.org/namespaces/DCD#ElementDef Class Data char 1 -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Mon Jan 25 17:29:52 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:08:02 2004 Subject: Forums In-Reply-To: <199901211701.MAA15618@hesketh.net> References: <3.0.1.32.19990121114429.01000360@pop.uunet.ca> <199901211605.LAA14418@hesketh.net> <199901211539.KAA09173@ruby.ora.com> <36A6A449.99A881FE@infinet.com> Message-ID: <3.0.1.32.19990124214323.009c8800@mail.accessone.com> On the one hand, i'd prefer to see the political stuff move to a different forum, on the other, it's an indespensable part of xml development. There is an old saying in warfare that the best plans fail to survive first contact with the enemy. In like vein, the best made standards fail to survive first contact with the implementors. Standardization is a social/political process imho, so it's vital to not only discover how people think a standard ought to be implemented (what I understand to be the overt purpose of xml-dev), and the social/political context in which it's being developed - i.e. what people are thinking about and molding it into. It's this social/political discourse on xml-dev that provides that I think. Dave LeBlanc At 12:04 PM 1/21/99 -0500, Simon St.Laurent wrote: >At 11:44 AM 1/21/99 -0500, Murray Maloney wrote: >>At 11:08 AM 1/21/99 -0500, Simon St.Laurent wrote: >>[...] >>>It's a good idea - but where exactly should we go with the more abstract >>>and political stuff? There isn't a forum, and even if there was, what >>>assurances would there be that the W3C (or anyone else in fact) would be >>>listening? >> >>There are plenty of people who participate in the W3C who are listening. >>There have been numerous occasions when discussions on this list >>have been brought up in W3C WG calls/meetings. This is an incredibly >>useful list, and I think that we would ignore it at our peril. > >Agreed - people do listen to XML-Dev. But would they bother to watch a >forum discussing just the politics? I doubt it, and that's why I don't see >removing the politics from XML-Dev as a good thing for XML. This could >change, of course, if the W3C starts inviting the public as well as >listening, and creates public forums with 'official' standing. > >Simon St.Laurent >XML: A Primer / Building XML Applications (March) >Sharing Bandwidth / Cookies >http://www.simonstl.com > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Mon Jan 25 17:32:10 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:08:02 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: Message-ID: <3.0.1.32.19990124215737.00942430@mail.accessone.com> It's that the generations are so damned fast is a big part of the problem imho. Quality of thought and implementation have given way to the product and "mind share" cycles of Madison Ave (i.e. the marketers). What's the incentive to make net stuff conforming? The bits get moved no matter what the form and it's the receivers that have to adapt (read: kludge) their software to cope with the semi-sortof markup they get. Dave LeBlanc At 01:39 PM 1/21/99 -0600, Robin Cover wrote: >Come to think of it: why should this be "Un*censored*believable" >given that 99% of Net stuff is illegal HTML, despite a couple >generations (years) of HTML DTDs? > >-rcc > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Mon Jan 25 17:32:19 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:08:02 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: <199901212047.PAA20214@hesketh.net> References: <36A78B88.C2C07126@locke.ccil.org> Message-ID: <3.0.1.32.19990124222808.009453c0@mail.accessone.com> I think HTML itself left the door open by allowing ommited tags. Wasn't it one goal of xml to close the loose idea of what what good markup is? I think that xml offers the potential correct things with good tools that enforce adherence to a dtd is a good step towards selling "basic principles"; that is if we stop talking about it so much and develop a bit more . Dave LeBlanc At 03:50 PM 1/21/99 -0500, Simon St.Laurent wrote: >To put it bluntly, 'violating basic SGML principles' isn't something the >vast majority of the HTML community has cared about - ever. Convincing >them that they should care about 'violating basic XML principles' is a lot >easier, partly because there's a lot less to explain, but this stuff isn't >as obvious as a lot of SGML and XML folks would like to think. > >There's a long road ahead, and putting it down to 'violations of basic >principles' isn't going to get us anywhere if we don't figure out how to >sell those principles without sounding like latter-day Puritans. > > >Simon St.Laurent >XML: A Primer / Building XML Applications (March) >Sharing Bandwidth / Cookies >http://www.simonstl.com > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Mon Jan 25 17:32:19 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:08:02 2004 Subject: Word and XML (was: XML standards coherency and so forth) In-Reply-To: References: <36A7796C.93059A91@locke.ccil.org> Message-ID: <3.0.1.32.19990124215011.009cb730@mail.accessone.com> At 02:07 PM 1/21/99 -0500, Adam M Donahue wrote: >> >

This is a test of the emergency broadcast >> > system

>> >> Un*censored*believable. This not only isn't XML, it isn't even >> HTML. What were they thinking of? (I know, I know: $$$$.) >> Microsoft folks, is there any hope of getting this fixed for >> Office 2K? > > We're putting our hopes in these people?? :-) > >Adam > Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Mon Jan 25 18:43:06 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:08:02 2004 Subject: XML pages from Databases Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEE5D@RED-MSG-08> David Livingstone asks for advice on creating XML pages from a database, particularly on how the data should be stored, as tables of data or as marked-up text. It really depends on how you intend to use the data, and what your processing load is. For example, if you want to access the data from a variety of angles, with transactional protection, and a heavy workload, then you need a database and you need to store the data relationally. If you only need to retrieve the marked up text, then you could store that as string fields in a database. Or you can take a hybrid approach, with some parts accessible relationally and others stored as marked-up text. (For some good examples of the latter approach, see the excellent slide show Oracle marketing has prepared at http://www.oracle.com/xml/.) --Andrew Layman xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jan 25 18:43:18 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:03 2004 Subject: Word and XML (was: XML standards coherency and so forth) References: <36A78B88.C2C07126@locke.ccil.org> <3.0.1.32.19990124222808.009453c0@mail.accessone.com> Message-ID: <36ACB112.56A19D8B@locke.ccil.org> David LeBlanc wrote: > I think HTML itself left the door open by allowing ommited tags. Wasn't it > one goal of xml to close the loose idea of what what good markup is? Actually, valid HTML has nothing loose about it. It's the HTML browsers which accept random valid or invalid HTML. Tag omission is a standardized part of HTML: for some elements you can omit end-tags, for others you can't. A few elements (HTML, HEAD, BODY, TBODY in TABLEs) allow both start-tags and end-tags to be omitted; i.e. they are present whether their tags are visible or not. The real difference in this respect between HTML and XML is that XML mandates draconian error processing (refusing to parse un-well-formed documents), and that was put into the spec at the demand of the major browser vendors, who were tired of playing we-can-accept-more-bogus-HTML-than-you games. (Source of this statement: hearsay.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Jan 25 18:58:22 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:03 2004 Subject: Word and XML (was: XML standards coherency and so forth) Message-ID: <3.0.32.19990125105738.00a94cb0@pop.intergate.bc.ca> At 12:59 PM 1/25/99 -0500, John Cowan wrote: >The real difference in this respect between HTML and XML is that >XML mandates draconian error processing (refusing to parse >un-well-formed documents), and that was put into the spec at >the demand of the major browser vendors, who were tired of playing >we-can-accept-more-bogus-HTML-than-you games. (Source of this >statement: hearsay.) I was there & it's true. Both the big boys asked for it. I think it would have been done anyhow, them asking was just reinforcement. Because it's a good idea in & of itself. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Mon Jan 25 19:39:17 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:08:03 2004 Subject: Is XML Extensible? Message-ID: <990125143846.2262@mail11.mitre.org.0> Suppose that I want to have a document of documents, with each document conforming to a schema? Can I do it? How? /Rogre xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Jan 25 20:02:52 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:03 2004 Subject: Understanding RDF References: <36AC1FD9.89F8789B@prescod.net> <36AC9F9E.8CAA1F88@locke.ccil.org> Message-ID: <36ACC88F.4D3A2CFF@prescod.net> > A property may have more than one value (in current RDF terms, > there may be multiple sentences with a common subject and > predicate), as you'd expect. I presume, then, that the values are considered to be unordered. --- > And here's my attempt to make unabbreviated correct RDF: ^^^^^^^ This fills me with a grave sense that RDF should not be going to PR. Few people seem confident of their understanding and the first major use is already asking for an extension! --- You've obviously gone to a lot of work so I'm reluctant to ask you to defend your expansion in terms of the two specifications, but my question is whether you think that it is possible. Are the two specs unambiguous enough that your expansion is something that a generic RDF processor could achieve. For example: > > LastName FirstInitial > SeatRow SeatLetter > Departure Class > Did you decline to expand that? Or is that the expansion? Should I interpret Group as an RDF Seq? The "RDF:Order='Seq'" is confusing because I think that it applies to instances described by the DCD, and not to the DCD document itself. > > > > It isn't clear to me how the RDF:li can go right in an RDF:Description. Where is the containing rdf:Seq, rdf:Bag and rdf:Alt? What abbreviation is this? Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge. - Grace Hopper xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From colds at nwlink.com Mon Jan 25 20:11:44 1999 From: colds at nwlink.com (Chris Olds) Date: Mon Jun 7 17:08:03 2004 Subject: parsing entity values Message-ID: <0a1501be489e$a08f96b0$dc59fcc6@albert.salsa.walldata.com> One nit: Richard Tobin wrote (a helpful explanation, ending with): >[...] but if we had: > > > > > >the replacement text of elt would be > > <=> > >not > > <=> > >and should be detected as a syntax error if &elt; occurred in the >body. Actually, it's already a syntax error - Section 4.3.2 says that "An internal parsed general entity is well-formed if its replacement text matches content." Do any of the available parsers indicate an error if &elt; is not used in the document? /cco xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jan 25 20:18:43 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:03 2004 Subject: Understanding RDF References: <36AC1FD9.89F8789B@prescod.net> <36AC9F9E.8CAA1F88@locke.ccil.org> <36ACC88F.4D3A2CFF@prescod.net> Message-ID: <36ACD178.89813049@locke.ccil.org> Paul Prescod wrote: > > And here's my attempt to make unabbreviated correct RDF: > ^^^^^^^ > > This fills me with a grave sense that RDF should not be going to PR. Few > people seem confident of their understanding and the first major use is > already asking for an extension! Ah, but I have two problems: I need to generate correct unabbreviated RDF that *has the same meaning* as the given DCD. I have every confidence in my ability to generate correct unabbreviated (or abbreviated) RDF on a subject of my own devising. Doing it from the rather poorly specified DCD vocabulary is another matter. It is one thing to write in a (natural) language, quite another to translate another's work into that language with confidence. > You've obviously gone to a lot of work so I'm reluctant to ask you to > defend your expansion in terms of the two specifications, but my question > is whether you think that it is possible. Are the two specs unambiguous > enough that your expansion is something that a generic RDF processor could > achieve. Provided it understood the slightly deviant RDF (with no RDF:li elements) that DCD uses. > For example: > > > > > LastName FirstInitial > > SeatRow SeatLetter > > Departure Class > > > > Did you decline to expand that? Or is that the expansion? Mm, some of each. The RDF Syntax and Schema documents, read together, tell us that RDF schemas can define new kinds of sequence containers by making RDF statements saying that the new container type is a subclass of RDF:Seq. Strictly speaking, that statement is part of a meta-DCD rather than of a DCD instance (part of the meta-meta-document). > Should I > interpret Group as an RDF Seq? The "RDF:Order='Seq'" is confusing because > I think that it applies to instances described by the DCD, and not to the > DCD document itself. Yes, I omitted that attribute in error. It should not belong to the RDF namespace, of course. Group is a subclass of RDF:Seq, but that has nothing to do with the ordering it is *modeling*. > > > > > > > > > > > It isn't clear to me how the RDF:li can go right in an RDF:Description. > Where is the containing rdf:Seq, rdf:Bag and rdf:Alt? What abbreviation is > this? Oops. Chalk it up to defective translation. But that was a mechanical error, not a defect in RDF itself. (I caught another such error, failing to use the "resource" attribute, before I posted; I can't catch everything.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Jan 25 20:27:39 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:03 2004 Subject: WebCGM? Message-ID: <199901252027.PAA03520@hesketh.net> Does anyone know what WebCGM (a new W3C recommendation) is and how it relates to XML? About all I can figure out is that it's a format for describing graphics that has something to do with XML, but the rest isn't clear at all. Section 3.3 includes an XML DTD, but no real guidance on what to do with it, and the examples don't use XML syntax. Any suggestions? It ain't PGML or VML, that's for sure. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jan 25 21:02:01 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:03 2004 Subject: WebCGM? References: <199901252027.PAA03520@hesketh.net> Message-ID: <36ACDBAE.9E3FBCB2@locke.ccil.org> Simon St.Laurent wrote: > Does anyone know what WebCGM (a new W3C recommendation) is and how it > relates to XML? About all I can figure out is that it's a format for > describing graphics that has something to do with XML, but the rest isn't > clear at all. WebCGM is a profile (subset) of CGM, a binary graphics format that describes graphics in terms of how to draw them abstractly. The XML DTD is used solely to explain how some of the CGM objects can appear inside other objects: its relation to real XML is purely conceptual, but if you wrote a CGM-to-XML translator you could use the DTD to validate parts of the resulting XML. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Mon Jan 25 22:14:02 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:03 2004 Subject: mdsax1.0beta1 Message-ID: <001001be48af$76bfa3a0$c9a8a8c0@thing2> MDSAX 1.0 Beta 1 was released today: http://www.jxml.com/download.html There are now three packages: 1. com.jxml.mdsax contains filters which can be used independently of anything else. 2. com.jxml.mdsax.context contains the classes needed to define a parsing context, and filters which depend on that context. 3. com.jxml.mdsax.framework contains various factories which make up the optional mdsax framework. As before, all filters are derived from John Cowan's ParserFilter: The full api for mdsax is available at: http://www.jxml.com/mdsax/api/overview-summary.html A suite of tests are available at: http://www.jxml.com/mdsax/src/com/jxml/mdsax/tests/ These tests exercise the following: test0: A trace of SAX document handler events before and after the element filter, displaying the XPointer for the element when present. test1: A simple exercise of the document router, showing how PIs are queued until the document type is known. test2: A minimalist exercise of the context filter. test3: A simple exercise of the element router, showing which events are routed to specific element filters. test4: Rather than simply filtering events, the ContextFilter is used to create an application-specific result, in this case a simple count of the number of elements found in the document. This is Open Source Software: http://www.jxml.com/License.txt Bill la Forge JXML, Inc. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ajd100 at NAmerica.mot.com Mon Jan 25 22:42:55 1999 From: ajd100 at NAmerica.mot.com (Dutra Juliana-AJD100) Date: Mon Jun 7 17:08:03 2004 Subject: XML pages from Databases Message-ID: <11EF19296147D211A7C100805F312AE77F9C96@s-il06ar.corp.mot.com> I saw a couple of companies in the XML Expo 98 (Nov 98, Chicago) who could read a database (Access, SQL Server, ODBC..) and return the columns as XML tags... I have to dig through my notes to remember specific names but it seemed like a fairly common XML app. Juliana Dutra - E-Business Strategies ===================================== Motorola, Communications Enterprise ===================================== -----Original Message----- From: Livingstone, Stephen [mailto:Livinsb@rbos.co.uk] Sent: Monday, January 25, 1999 6:22 AM To: xml-dev-digest@ic.ac.uk Subject: XML pages from Databases A bit of advice please ! I am looking to implement a system which creates XML pages dynamically from information which we shall store in a database using asp and xsl. This data should be searchable and shall be used in a web application. Does anyone have any advice on the best ways to do this?? Should just the data be stored in the database? Or should the marked-up data be stored in the database? Should we have a combination of these by using structured columns of marked up data? Anybody got any opinions? thanks for responses.. steven Steven Livingstone BSc MSc GradInstP Corporate Systems Development (TCN) Royal Bank Of Scotland. > *: mailto:livinsb@rbos.co.uk > *: +44 0131 523 4354 [x24354] > Networking Technical Associates, Glasgow, Scotland. > *: mailto:ntw_uk@hotmail.com > *: +44 07771-957-280 This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. 'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.' xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hussain at granularity.com Mon Jan 25 22:52:18 1999 From: hussain at granularity.com (G. Hussain Chinoy) Date: Mon Jun 7 17:08:03 2004 Subject: XML pages from Databases In-Reply-To: <11EF19296147D211A7C100805F312AE77F9C96@s-il06ar.corp.mot.com> Message-ID: Currently, we use the WDDX DTD that comes with Allaire's ColdFusion 4.0 to read ODBC available databases (Oracle, Access, MSSQLserver) and convert them to XML (in the WDDX format). I then use an XSL transformation to convert it into a more human readable XML format. More info on ColdFusion: http://www.allaire.com/ More info on WDDX: http://www.wddx.org/ H ----------------------------------------- G. Hussain Chinoy hussain@granularity.com Chief Information Architect, CEO Granularity Information Architecture, Inc. http://www.granularity.com/ On Mon, 25 Jan 1999, Dutra Juliana-AJD100 wrote: > I saw a couple of companies in the XML Expo 98 (Nov 98, Chicago) who could > read a database (Access, SQL Server, ODBC..) and return the columns as XML > tags... > I have to dig through my notes to remember specific names but it seemed like > a fairly common XML app. > > Juliana Dutra - E-Business Strategies > ===================================== > Motorola, Communications Enterprise > ===================================== > > > -----Original Message----- > From: Livingstone, Stephen [mailto:Livinsb@rbos.co.uk] > Sent: Monday, January 25, 1999 6:22 AM > To: xml-dev-digest@ic.ac.uk > Subject: XML pages from Databases > > > A bit of advice please ! > > I am looking to implement a system which creates XML pages dynamically > from information which we shall store in a database using asp and xsl. > This data should be searchable and shall be used in a web application. > > Does anyone have any advice on the best ways to do this?? > > Should just the data be stored in the database? Or should the marked-up > data be stored in the database? Should we have a combination of these by > using structured columns of marked up data? > > Anybody got any opinions? > > thanks for responses.. > > steven > Steven Livingstone BSc MSc GradInstP > Corporate Systems Development (TCN) > Royal Bank Of Scotland. > > *: mailto:livinsb@rbos.co.uk > > *: +44 0131 523 4354 [x24354] > > > Networking Technical Associates, > Glasgow, Scotland. > > *: mailto:ntw_uk@hotmail.com > > *: +44 07771-957-280 > > > This e-mail message is confidential and for use by the addressee only. If > the message is received by anyone other than the addressee, please return > the message to the sender by replying to it and then delete the message from > your computer. > > 'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc > does not accept responsibility for changes made to this message after it was > sent.' > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SMUENCH at us.oracle.com Mon Jan 25 23:06:23 1999 From: SMUENCH at us.oracle.com (Steve Muench) Date: Mon Jun 7 17:08:03 2004 Subject: XML pages from Databases Message-ID: <199901252305.PAA11770@mailsun3> If your database is an Oracle database, try checking out the free PL/SQL utilities for doing just that up on our Website at: http://www.oracle.com/xml The "PLSXML" Utilities and Demos contain sample code for formatting rich SQL statements from a database query. _______________________________________________ Steve Muench, Consulting PM & XML Evangelist Java Business Objects Dev't Team smuench@oracle.com -- http://www.oracle.com/xml -------------- next part -------------- An embedded message was scrubbed... From: Dutra Juliana-AJD100 Subject: RE: XML pages from Databases Date: 25 Jan 99 14:42:28 Size: 5002 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990125/490a1906/attachment.eml From jamesr at steptwo.com.au Tue Jan 26 00:30:35 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:03 2004 Subject: Understanding RDF In-Reply-To: <36ACD178.89813049@locke.ccil.org> References: <36AC1FD9.89F8789B@prescod.net> <36AC9F9E.8CAA1F88@locke.ccil.org> <36ACC88F.4D3A2CFF@prescod.net> Message-ID: <4.1.19990126110014.00c62510@steptwo.com.au> At 06:18 26/01/1999, John Cowan wrote: | > | > > | > > | > > | > > | > | > It isn't clear to me how the RDF:li can go right in an RDF:Description. | > Where is the containing rdf:Seq, rdf:Bag and rdf:Alt? What abbreviation is | > this? | | Oops. Chalk it up to defective translation. But that was a mechanical | error, not a defect in RDF itself. (I caught another such error, | failing to use the "resource" attribute, before I posted; I can't | catch everything.) Doesn't this highlight the shortcomings of any system where you can't programatically validate the correctness of the content against a DTD? If careful work by someone at least as proficient in these things as anyone else can't get the syntax _exactly_ right ... Just my $0.02, J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Tue Jan 26 00:44:14 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:08:03 2004 Subject: parsing entity values In-Reply-To: Chris Olds's message of Mon, 25 Jan 1999 12:09:23 -0800 Message-ID: <4461.199901260043@doyle.cogsci.ed.ac.uk> > Actually, it's already a syntax error - Section 4.3.2 says that "An internal > parsed general entity is well-formed if its replacement text matches > content." Actually that's not quite right. The parsed entity is not well-formed, but that doesn't affect the well-formedness of the document unless the entity is referenced (section 2.1). > Do any of the available parsers indicate an error if &elt; > is not used in the document? Yes - the STG validator at http://www.stg.brown.edu/service/xmlvalid/ -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at goon.stg.brown.edu Tue Jan 26 02:12:31 1999 From: richard at goon.stg.brown.edu (Richard Goerwitz) Date: Mon Jun 7 17:08:04 2004 Subject: parsing entity values References: <4461.199901260043@doyle.cogsci.ed.ac.uk> Message-ID: <36AD2454.C947B5B5@goon.stg.brown.edu> > > Actually, it's already a syntax error - S. 4.3.2 says that "An internal > > parsed general entity is well-formed if its replacement text matches > > content." > > Actually that's not quite right. The parsed entity is not > well-formed, but that doesn't affect the well-formedness of the > document unless the entity is referenced (section 2.1). > > > Do any of the available parsers indicate an error if &elt; > > is not used in the document? > > Yes - the STG validator at http://www.stg.brown.edu/service/xmlvalid/ Here was our rationale: If an entity is defined in such a way that, if used, it will always generate an error, then it makes sense to let the user know about it. Generally this situation reflects a problem with the DTD - in fact, the worst kind of problem in the sense that it results in a DTD that seems to work perfectly fine with some documents, but then suddenly produces errors when somebody writes a document that actually uses the entity in question. It makes the DTD writer think that the error is in the document (which, according to the standard, it is). -- Richard Goerwitz PGP key fingerprint: C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0 For more info (mail, phone, fax no.): finger richard@goon.stg.brown.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ralphc at bellsouth.net Tue Jan 26 05:13:26 1999 From: ralphc at bellsouth.net (Ralph Richard Cook) Date: Mon Jun 7 17:08:04 2004 Subject: Java DOM implementations and cloneNode Message-ID: <36ae4e4a.20393250@mail.atl.bellsouth.net> I'm working on a "pluggable" file load and save (import/export) feature in an application. I'm using the DOM interface as the data format I expose to the pluggable components. Internally, I'm trying both Sun's Project X early access 2 and IBM's XML4J 1.1.9 to build the DOM object. Some of my components will read and write XML, and I'm trying both of the above on that side as well. My problem comes in where I create the DOM object with one of these libraries and create a XML object to save with the other, and have them pass information purely through the DOM interface. I create a TXDocument (for IBM) or a XMLDocument (for Sun) then cast the document to a DOM Document, and populate it purely with DOM interface calls, such as createElement and appendChild. In the export component I create a TXDocument, then cast it to a Document, then try to populate the Document via cloneNode on Elements from the passed-in Document. The most common error is ClassCastException, mentioning one of the classes that implement an interface. Am I expecting too much here? Shouldn't the classes that implement the DOM interfaces be able to copy via cloneNode, which is a DOM interface function? Is this a bug or expected behavior? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Jan 26 08:03:42 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:04 2004 Subject: Java DOM implementations and cloneNode Message-ID: <000801be4902$4164cd40$2ee044c6@arcot-main> >Am I expecting too much here? Shouldn't the classes that implement the >DOM interfaces be able to copy via cloneNode, which is a DOM interface >function? Is this a bug or expected behavior? It is not a well known fact that DOM Level 1 does not dictate inter-document operations or movement of nodes between documents. You will find that following is true: Node node1 = doc1.createElement("boo"); Node node2 = node1.cloneNode(false); if (node1.getOwnerDocument() == node2.getOwnerDocument()) System.out.println("both the original and the clone belongs to same document"); So when you tried to populate the second document with clones of the first document, you were trying to move nodes from one document to another. I am quite sure that some DOM implementations allow you do this although it means your DOM code will no longer work with all DOM implementations. If you are willing to stretch your neck just so, you might give the currently available version 1.0PR3 at www.docuverse.dom/domsdk/ a try. I am fairly certain I added code for this. If not, Docuverse 1.0 Beta 1 definitely will (soon, real soon now). Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jan 26 11:39:30 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:04 2004 Subject: Next Round Message-ID: <93CB64052F94D211BC5D0010A80013310EB29D@WWMESS3> > I agree totally with you except for the fact that namespaces > automatically makes XML no longer dumb or necessarily low-level. The main > reason for this suggestion is that the alternative is for applications to manage > namespace processing themselves or else dump some filter on > top which may add major inefficiencies. Before making any judgement on > this regarding MDSAX or SAXON, I would ask Michael Kay and Bill la Forge > what they think about a Name type and anyone else who has written some > higher-level API's for XML (this includes DOM implementors). I'd like to see a structure that is layered and modular, in which Namespace is an optional module layered above the basic SAX interfaces in the same way that the Namespace standard is an optional layer above XML 1.0. I think MDSAX is heading in this direction. I'm not sure about a Name type. I think I'd prefer to see a filter in which the prefixes chosen by the document author are substituted by prefixes chosen by the application writer, but which otherwise delivers the standard SAX interface. Plus perhaps a helper class to parse the names. (But we also need to think about diagnostics: the application may need access to the original element name as written for use in error messages) We should allow a parser to deliver the "namespace filtered events" in any way it finds most efficient: the layering of a filter on top of a basic parser is one way of providing the service, but not the only way. This reminds me of a requirement omitted from David's list: the need for interrogatives to determine the level of service offered by the parser, or to request a particular level of service (e.g. validation, namespace resolution, etc). Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jan 26 11:47:44 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:04 2004 Subject: Why informal specs usually win Message-ID: <93CB64052F94D211BC5D0010A80013310EB29E@WWMESS3> > > "Since then, almost every author of books on new programming languages > used [BNF] to specify the syntax rules of the language." > The reality, unfortunately, is that almost every author has invented a new variant of BNF to specify the relevant syntax rules. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jan 26 12:01:39 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:04 2004 Subject: Next Round Message-ID: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> > "Namespaces in XML" seems to be going down this path as no > one will admit that it is a massive failure. I agree with you that "Namespaces" is technically inelegant, it also has the problem of being incompatible with a lot of other XML things. Unfortunately, though, I think it is doomed to succeed. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jan 26 12:01:47 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:04 2004 Subject: Ptr to Fast Well-Formed XML parser (Java)? Message-ID: <93CB64052F94D211BC5D0010A80013310EB29C@WWMESS3> > > It so happens I did some recent measurements as follows: > > > > SAX parsers: > > xp 4387 ms > > oracle 7862 ms > > xml4j 7771 ms > > sun 3736 ms > > > > DOM implementations: > > sun 9634 ms > > xml4j 11677 ms > > oracle 9784 ms > > docuverse 10685 ms (using xp parser) > > Thanks. > And what is your bench configuration? > Parser versions, computer, OS, memory, JVM, ...? - Didier Bolf. > You're asking me to do the job properly! I only had half an hour... Computer: Fujitsu Technicl, Intel Pentium II processor (how do I find out which?) OS: Windows NT 4.0 Workstation Memory 64Mb JVM: Sun Java 2 (JDK 1.2) This is a bit irrelevant as the main variable is the data file: any properly-done benchmark would use a public domain data file (or preferably a selection), whereas mine unfortunately was confidential. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Livinsb at rbos.co.uk Tue Jan 26 13:28:12 1999 From: Livinsb at rbos.co.uk (Livingstone, Stephen) Date: Mon Jun 7 17:08:04 2004 Subject: XML pages from Databases Message-ID: <217258E84FF7CF11B4630001FA44B2D5027A6FA3@REFROWTECX1> The marked up data stored relationally is likely the way I we shall go (ie. store structured columns of XML related data). At least as a starting point. I think a combination is best as we shall be looking to seach for keywords and then be more specific using the marked-up data. We may possibly use an SP to do some mark up. All very confusing due to the searching feature which is very important to us (rather than simply marking up stored data from columns in a db). We need the system to be pretty eXtensible (which is whay a solo database structure would probably be out of the question). I'll let you know how we get on.... Thanks for all your responses, Steven Steven Livingstone BSc MSc GradInstP Corporate Systems Development (TCN) Royal Bank Of Sctoland. mailto:livinsb@rbos.co.uk +44 0131 523 4354 [x24354] Networking Technical Associates, Glasgow, Scotland. mailto:ntw_uk@hotmail.com +44 07771-957-280 > -----Original Message----- > From: Andrew Layman [SMTP:andrewl@microsoft.com] > Sent: Monday, January 25, 1999 6:16 PM > To: xml-dev-digest@ic.ac.uk > Subject: RE: XML pages from Databases > > > *** Warning : this message originates from the Internet **** > > David Livingstone asks for advice on creating XML pages from a > database, > particularly on how the data should be stored, as tables of data or as > marked-up text. > > It really depends on how you intend to use the data, and what your > processing load is. For example, if you want to access the data from > a > variety of angles, with transactional protection, and a heavy > workload, then > you need a database and you need to store the data relationally. If > you > only need to retrieve the marked up text, then you could store that as > string fields in a database. Or you can take a hybrid approach, with > some > parts accessible relationally and others stored as marked-up text. > (For some > good examples of the latter approach, see the excellent slide show > Oracle > marketing has prepared at http://www.oracle.com/xml/.) > > --Andrew Layman > > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. 'Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.' xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Tue Jan 26 14:39:06 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:08:04 2004 Subject: Topic Maps Message-ID: <199901261420.IAA04608@bruno.techno.com> A special workshop on T O P I C M A P S (ISO/IEC 13250) Instructors: Michel Biezunski and Steven R. Newcomb (both co-editors of 13250) March 2-3, 1999 GCA Headquarters Alexandria, Virginia, USA (near Washington D.C.) USD $1,400 per participant ----------------------------------------------- Registrations: Ryan Black ryan@isogen.com +1 214 953 0004 x121 See http://www.infoloom.com/workshop.htm for details. ----------------------------------------------- |--------------------------------------------------------- | This special workshop is a collaborative endeavor of | | | | ISOGEN International Corporation | | Infoloom | | TechnoTeacher Inc. | | Graphic Communications Association (GCA) | - ---------------------------------------------------------| -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Tue Jan 26 14:41:12 1999 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:08:04 2004 Subject: ADMIN: CD-ROM Archive of Discussion list Message-ID: A CD-ROM archive of this current to December 18, 1999 will shortly be available via Imperial College Press, http://www.wspc.com.sg/books/bookshop.html (Please don't contact me directly, I have no resources to handling the postage and packing etc). The archive has been fully indexed and is boolean-style searchable, using software from http://www.jobjects.com/, which also happens to support XML and metadata schemes (eg Dublin Core) and is implemented in Java to provide multi-platform support. Highly recommended for indexing HTML (and XML) document collections Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ If my digital email signature is invalid, download a new root at http://www.belsign.be/en/services/receive/install-ca.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cvonsee at onramp.net Tue Jan 26 14:46:50 1999 From: cvonsee at onramp.net (Chris von See) Date: Mon Jun 7 17:08:04 2004 Subject: e-commerce scenario Message-ID: <199901261446.IAA05284@mailhost.onramp.net> From: "Michael S. Brothers" in a response to Joseph Bozzi: > >My only comment to this (which was well presented by the way) concerns >the cost issue you touched on. EDI as you presented it is a scary >looking thing (the real X12 stuff is scarier still!), but a mom and pop >operation willing to spend about $30,000 can buy a software package >such as Mercator to map the data from one form to the other. The >operation would also need to hire someone to use it, so the cost goes >up any more. However, the benefits could be enormous if having this >capability allows the Mom and Pop to get contracts with Wal-Mart or JC >Penneys or other large retailers who will only use suppliers that are >EDI capable. This is, I believe, one of the main reasons that EDI hasn't taken off as much as people would like. Expecting "mom and pop" outlets to spend $30,000 to bet on the *possibility* that they might get a large contract is a real stretch. As was pointed out in earlier postings on this list (I forgot who and when), there are small shops that already have pretty lucrative trading partner relationships that won't spend that kind of money because a) it's a lot of money for a chunk of software, and b) EDI is, as you pointed out, a "scary looking thing", not because of the format of the messages but because of the effort and cost involved in implementing it. I am as big a proponent of XML EDI as anyone else, but what people seem to forget is that the stuff flowing across the wire (XML, X.12 or whatever) is only a small part of the equation. The EDI companies make a ton of money selling tools and services that let people translate the X12 transaction formats to the data model used in their particular shop; that's what takes up so much time in implementing EDI, and that's a big part of what scares small potential EDI users to death. These people aren't "information technology" people, and anything as complicated as mapping X12 fields or XML elements into their data model is going to turn them off EDI pretty fast. Standard DTDs for various business documents help, but only to a point. >The thing that has me excited about XML is the potential to bring >everyone into the EDI world. But, and this like Delta Burke's is a big >but, only if the applications needed to translate the data from XML to >legacy database and vice versa are affordable. Like less than $1500!!. >>From my perspective, I use Office products all the time, but really >balked at spending a mere $376 to upgrade to Office '97. Cost must be >low, and it must also be easy to use. I agree that cost of software is important, but cost of implementation is IMHO even more important. Solve this, and XML-EDI will take off like a shot. Chris von See ------------------------------------ "Beware of all enterprises that require new clothes." -- Thoreau xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jan 26 15:55:40 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:08:04 2004 Subject: Why SAX needs namespace support In-Reply-To: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> Message-ID: <13997.57507.333419.530622@localhost.localdomain> Michael.Kay@icl.com writes: > > "Namespaces in XML" seems to be going down this path as no > > one will admit that it is a massive failure. > > I agree with you that "Namespaces" is technically inelegant, it > also has the problem of being incompatible with a lot of other XML > things. Unfortunately, though, I think it is doomed to succeed. I agree. I also object strongly to the inelegance of attribute-based namespace declarations and to the unnecessary complication of local namespace scoping (which, like optional external-entity expansion in XML 1.0, tries to solve a straw-man problem that turns out not to exist in any serious way anyway). That said, my customers couldn't care less -- they need the ability to provide globally-unique names that their software can disambiguate from other people's names, and for that purpose, XML Namespaces turns out to be useful far beyond initial expectations, warts and all. The nicest part is that the utility of namespaces does not depend on any fancy, yet-to-be-written schema support for compound documents -- for an enormous number of applications, it's enough just to be able to identify a globally-unique name. Despite my initial pessimistic predications (some of you might remember that I also predicted the imminent death of Linux back around 1992 because of its monolithic kernel architecture), I am now confident that namespaces will succeed, and want some kind of namespace support in the next version of SAX. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Jan 26 16:15:35 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:04 2004 Subject: Why SAX needs namespace support In-Reply-To: <13997.57507.333419.530622@localhost.localdomain> References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> Message-ID: <199901261615.LAA21310@hesketh.net> At 10:54 AM 1/26/99 -0500, david@megginson.com wrote: >Despite my initial pessimistic predications (some of you might >remember that I also predicted the imminent death of Linux back around >1992 because of its monolithic kernel architecture), I am now >confident that namespaces will succeed, and want some kind of >namespace support in the next version of SAX. I'd like to see namespace support in SAX; however, I'd prefer not to implement it by piling that functionality into parsers, creating yet another monolith. While the monoliths survive, I think we can do better. For a discussion of how this might work, see my rough essay "Toward A Layered Model for XML", available at http://www.simonstl.com/articles/layering/layered.htm. If you just want a quick look at a picture that adds namespace support to a possible set of layered event-based processes, see http://www.simonstl.com/articles/layering/layered2.gif. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jan 26 16:20:07 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:04 2004 Subject: Does anyone have C headers for DOM? Message-ID: <007a01be4947$efae5d40$62e987cb@NT.JELLIFFE.COM.AU> I cannot find around here any IDL->C compiler. We have plenty of ones which generate CORBA or RPC stubs, but none for straight C. Can anyone email a C (or C++) header for DOM (486 or SPARC would be best). Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jan 26 17:07:09 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:04 2004 Subject: Why informal specs usually win References: <93CB64052F94D211BC5D0010A80013310EB29E@WWMESS3> Message-ID: <36ADD33E.D564484B@prescod.net> Michael.Kay@icl.com wrote: > > > > > "Since then, almost every author of books on new programming languages > > used [BNF] to specify the syntax rules of the language." > > > The reality, unfortunately, is that almost every author has invented a new > variant of BNF to specify the relevant syntax rules. This is not a big problem because people can pick up the new E-BNFs quite easily. If people implemented software by directly pasting the BNF into a parser generator then that would be a bigger deal. Perhaps in the future we will standardize EBNF and people will generate grammars directly. The problem, of course, is that the EBNF in the standard is not optimized for your parser generator's algorithm (and may not even be compatible with it!). Standardizing EBNF would require a standardization of the underlying algorithms. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco So what if one dark midnight less than a year from now, millions of computers around the world suddenly grind to a halt? My computer grinds to a halt several times a day. ... [Forget Y2K] We're ignoring a much bigger bug problem that's hiding, well, right under our noses. Call it the Y-Does-My-Computer-Crash-Three-Times-A-Day Problem. - http://www.upside.com/David_Futrelle/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Jan 26 17:09:00 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:04 2004 Subject: Why SAX needs namespace support Message-ID: <3.0.32.19990126090707.00b46c10@pop.intergate.bc.ca> At 10:54 AM 1/26/99 -0500, david@megginson.com wrote: >Despite my initial pessimistic predications (some of you might >remember that I also predicted the imminent death of Linux back around >1992 because of its monolithic kernel architecture), I am now >confident that namespaces will succeed, and want some kind of >namespace support in the next version of SAX. Hey, that's nothin'. I predicted that the Internet would collapse every year between 1988 and 1993 inclusive. Still looks shaky to me, but you get tired of being wrong all the time. Unlike David, I've decided the declaration-by-attribute with scoping is a win; but whichever of us you agree with on that, he is 100% right that namespaces has loads of applications, it seems like they're crawling out of the woodwork for every one of my customers. For those who are using expat directly or via perl, it's already taken care of. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jan 26 17:14:58 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support In-Reply-To: <199901261615.LAA21310@hesketh.net> References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <199901261615.LAA21310@hesketh.net> Message-ID: <13997.62536.515221.194292@localhost.localdomain> Simon St.Laurent writes: > I'd like to see namespace support in SAX; however, I'd prefer not > to implement it by piling that functionality into parsers, creating > yet another monolith. While the monoliths survive, I think we can > do better. Perl's motto is "there's more than one way to do it"; SAX's should be "we'll try to let you do it any way you want." Many XML parsers either provide or are about to provide native namespace processing, so it would not make sense to force namespace processing to be a separate filter layer; other parsers probably will not provide namespace processing natively, so it makes sense to allow namespace processing to exist in a filter layer. Try this on. First, we create a new exception: public class SAXUnsupportedFeatureException extends SAXException then we add some fun new methods to the extended Parser class public void setNamespaceProcessing (boolean flag) throws SAXUnsupportedFeatureException; public void setValidation (boolean flag) throws SAXUnsupportedFeatureException; public void setEntityExpansion (boolean flag) throws SAXUnsupportedFeatureException; There is no default for any of these -- some SAX drivers may validate or expand entities by default, while others may not -- and drivers are free to throw a SAXUnsupportedFeatureException for any call to any of these. If an application needs to be certain that it is or isn't validating, that it is or isn't getting namespace processing, or that it is or isn't getting external entity expansion, it has to call one of these methods explicitly; if it doesn't care, then it can take whatever the parser wants to give it (the status quo for SAX 1.0). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Tue Jan 26 17:25:02 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> Message-ID: <36ADF924.7832905D@infinet.com> david@megginson.com wrote: > Michael.Kay@icl.com writes: > > > > "Namespaces in XML" seems to be going down this path as no > > > one will admit that it is a massive failure. > > > > I agree with you that "Namespaces" is technically inelegant, it > > also has the problem of being incompatible with a lot of other XML > > things. Unfortunately, though, I think it is doomed to succeed. > > I agree. > > I also object strongly to the inelegance of attribute-based namespace > declarations and to the unnecessary complication of local namespace > scoping (which, like optional external-entity expansion in XML 1.0, > tries to solve a straw-man problem that turns out not to exist in any > serious way anyway). I never quite understood why attributes are used for namespace declarations as well. I also agree with the Implementing namespaces in an XML parser is a trivial task, but dealing with namespaces at the application level is a totally different story, especially with this namespaces scoping stuff. How do you deal with namespaces in the DOM? I mean if you copy a node here, and insert a node there, this entire namespace scoping stuff gets all out of whack. Of course you could say "well the application programmer will just have to deal with that" and then the application programmer would say "why should I deal with it at all". As someone who has written an XML parser, DOM implementation, XSL processor, and a client-oriented application that I consider to be in the "major" category, I find XML to be very useful as an alternative externalization format to Java Object Serialization for Java objects. All of what you might call "business objects" (this is not a business application but a consumer application) can be expressed in Java Object Serialization (I use this for over the wire object state transfer) or XML (I use this format mostly for spitting out object state to a file since XML is simple enough that many of the properties of the objects can be edited manually as well as the fact XML is much more user friendly for other developers to interoperate with than the binary streams which come out of using Java Object Serialization). These "business objects" are not hardcoded in any particular hierarchy and to support building an XML element tree (effectively elements are mapped directly to these business objects) I have had to create my own Java <--> XML architecture because nothing out there is suitable for my needs or the needs of developers who will hopefully be working with this client application. OK the point is, namespaces as they are currently defined I feel make practical use of XML in this regard too difficult for developer novices to deal with. I would not even have wasted a year of my life on XML if I thought that its goals were targeted exclusively for the browser centric world because that world does not apply at all to how I am using XML. XML 1.0 did the job. Namespaces do not. Of course I could just elect not to support namespaces at all in this application environment, but somewhere down the line, developers will need some sort of namespaces mechanism here. I also don't want to have to develop some namespaces mechanism myself or else use a better alternative that someone else has developed hat perhaps I feel is more suitable to component oriented applications and then have to essentially badmouth the W3C by essentially saying "well they have no clue when it comes to the developer community at large". That does not make me look good, but what else can I honestly say when someone says "well why don't you use "Namespaces in XML" for this application environment. I can tell them the truth or I can make something up. Plain and simple "Namespaces in XML" looks ugly, feels ugly, and therefore is not practical at all for lots of applications that need to be simple, yet need some namespaces mechanism nevertheless. In this regard "Namespaces in XML" is already a massive failure because it is limiting the target audience of XML altogether. I am a huge fan of XML like probably everyone else on this list, but "Namespaces in XML" has dampered my enthusiasm for this fledgling technology. > That said, my customers couldn't care less -- they need the ability to > provide globally-unique names that their software can disambiguate > from other people's names, and for that purpose, XML Namespaces turns > out to be useful far beyond initial expectations, warts and all. Yes your customers, but that is in the document world. You are right they probably could care less. Perhaps I should scrap XML support altogether and stick with just Java Object Serialization. I seriously doubt that will ever happen because I can see that XML (minus namespaces) is the perfect solution to storing object state in a human manageable context. XML right now is simple enough that non-programmers can edit an XML file manually. Add in all of these computer-science geekified additions to XML and a lot of people on this list who are authors of XML books will find their book royalties dwindle to nothingness. > The nicest part is that the utility of namespaces does not depend on > any fancy, yet-to-be-written schema support for compound documents -- > for an enormous number of applications, it's enough just to be able to > identify a globally-unique name. Yah, but try and use namespaces with dynamically built DOM trees (or any other object tree implementation that maps to XML). It can be a major pain in the rear if you have multiple components that have no knowledge of each other and whose externalized content is merged into one XML document tree. Just think of the nightmares of managing namespace defaulting if you are merging a lot of abstract content (perhaps E-Commerce transactions which are converted to a DocumentFragment). Of course if I am living in the browser world, then none of this matters because in the browser world everything is one big document and hardcoded into some visual context whether it be HTML or the forthcoming Formatting Objects of XSL. > Despite my initial pessimistic predications (some of you might > remember that I also predicted the imminent death of Linux back around > 1992 because of its monolithic kernel architecture), I am now > confident that namespaces will succeed, and want some kind of > namespace support in the next version of SAX. I agree here, but I think namespaces will only succeed in the browser world. Most people are using XML for just HTML related stuff anyways, so for the short term future "Namespaces in XML" will do the job. Try using XML with namespaces for anything else more sophisticated and you might as well forget it (especially for E-Commerce). But yes, "Namespaces in XML" may in fact flourish in the web browser world. Nevertheless, we need to make sure that support of "Namespaces in XML" is as painless as possible to the application developer. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jan 26 17:37:24 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support In-Reply-To: <36ADF924.7832905D@infinet.com> References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> Message-ID: <13997.64636.594738.255064@localhost.localdomain> Tyler Baker writes: > Yes your customers, but that is in the document world. Actually, the customers who like namespaces are the ones in the data world, especially those in industries that deal heavily with data exchange (like the news industry and e-commerce). Document people don't care all that much yet -- they still have everything they need in SGML. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jan 26 17:46:17 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support Message-ID: <93CB64052F94D211BC5D0010A80013310EB2A8@WWMESS3> > > Try this on. First, we create a new exception: > > public class SAXUnsupportedFeatureException extends SAXException > > then we add some fun new methods to the extended Parser class > > public void setNamespaceProcessing (boolean flag) > throws SAXUnsupportedFeatureException; > > public void setValidation (boolean flag) > throws SAXUnsupportedFeatureException; > > public void setEntityExpansion (boolean flag) > throws SAXUnsupportedFeatureException; > I like it. Perhaps the methods should be able to throw other exceptions, e.g. if you call setValidation() half-way through parsing a document. Perhaps a setOption(option, flag) interface would be more extensible. Perhaps there should also be a getOption() method. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jan 26 18:00:40 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support In-Reply-To: <93CB64052F94D211BC5D0010A80013310EB2A8@WWMESS3> References: <93CB64052F94D211BC5D0010A80013310EB2A8@WWMESS3> Message-ID: <13998.382.143868.329436@localhost.localdomain> Michael.Kay@icl.com writes: > Perhaps a setOption(option, flag) interface would be more extensible. I could live with this, but only if the options were namespace qualified, i.e. try { parser.setOption("http://xml.org/sax/features/validation", true); parser.setOption("http://xml.org/sax/features/namespaces", false); parser.setOption("http://xml.org/sax/features/entity-expansion", true); parser.setOption("http://simonstl.org/ns/sax/xlink", true); } catch (SAXUnsupportedFeatureException e) { System.err.println("This parser ain't up to snuff -- try another!"); } Do people like this? I was almost afraid to suggest it... All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Jan 26 18:09:39 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support Message-ID: <3.0.32.19990126100821.00b56960@pop.intergate.bc.ca> At 12:19 PM 1/26/99 -0500, Tyler Baker wrote: >Implementing namespaces in an XML parser is a trivial task, but dealing with >namespaces at the application level is a totally different story, >especially with this namespaces scoping stuff. How do you deal with >namespaces in the DOM? I don't expect to convince Tyler Baker that namespaces are anything but an alien conspiracy, but I don't think it would be proper to ignore his repeated assertions that namespace *scoping* somehow makes processing more difficult. The scoping is purely a syntactic mechanism in the XML document that can't possibly have any effect at the DOM level. The following two documents are namespace-equivalent: | | | | | | | | A namespace-aware parser, such as expat, makes this clear, allowing you to ascertain that the element whose type is "e" is in the namespace http://a.b.c. True, the DOM is going to have to do something about this, as in add one more method per element and attribute to store/update its namespace. But what on earth makes anyone think that namespaces would be scoped in the DOM? The scoping in XML files is purely a syntactic minimization technique. I.e., if I have a DOM tree modelling the document above (surely everyone agrees that I get the same DOM tree from both instances) and I go stick a new "f" element as a child of the 'e' element, surely it makes no sense to put it in the either the a.b.c or x.y.z namespaces auto-magically. Among other things, it might come from some entirely different namespace. To put this another way, namespaces are merely a syntactic mechanism to allow each element type and attribute name in a document to be qualified by some URI. The DOM should obviously preserve this information, but I can't see why it should be concerned with the syntactic sugar that was used to express it. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Jan 26 18:22:54 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <199901261615.LAA21310@hesketh.net> Message-ID: <36AE08E1.FF963CD7@mecomnet.de> i suspect i stand in a (very small) minority on this issue, but with respect to the diagram (http://www.simonstl.com/articles/layering/layered2.gif.) the "namespace transformation" should appear at least above "attribute defaulting". i fear i stand in an even smaller minority on the second claim - that it belongs above entity resolution. perhaps not in the current spec, but time will tell. Simon St.Laurent wrote: > ... > > For a discussion of how this might work, see my rough essay "Toward A > Layered Model for XML", available at > http://www.simonstl.com/articles/layering/layered.htm. If you just want a > quick look at a picture that adds namespace support to a possible set of > layered event-based processes, see xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From glassbox at wanadoo.fr Tue Jan 26 19:00:27 1999 From: glassbox at wanadoo.fr (Glassbox) Date: Mon Jun 7 17:08:05 2004 Subject: To navigate in an XML graph using XSL Message-ID: <01f301be495d$e12c8510$002010ac@wanadoo.fr> Hi, I'd like to transform an XML tree with an XSL stylesheet. My XML tree might look like this : Essential COM Don Box I would like to find informations about a book stored in the bookstore by using its ? id ?. To do that, I would like to keep it somewhere and get it back later on in order to build an XSL pattern. Is this possible with XSL (I think it isn't). Does someone have a solution ? Many thanks for your help. Guillaume. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From glassbox at wanadoo.fr Tue Jan 26 19:00:29 1999 From: glassbox at wanadoo.fr (Glassbox) Date: Mon Jun 7 17:08:05 2004 Subject: Insert VML dynamically Message-ID: <01f401be495d$e1bda180$002010ac@wanadoo.fr> Hi, I'm trying to manipulate VML tags within a script using IE5 Beta2. I would like to insert VML tags in an HTML page by using the ? innerHTML ? property (or the ? insertAdjacentHTML ? method). But it doesn't work. I thought it was possible with VML as done with HTML, so have I misunderstood something ? Thanks. Guillaume xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From glassbox at wanadoo.fr Tue Jan 26 19:00:32 1999 From: glassbox at wanadoo.fr (Glassbox) Date: Mon Jun 7 17:08:05 2004 Subject: Question about VML and IE5 Message-ID: <01f501be495d$e21c6350$002010ac@wanadoo.fr> Hi, It is possible to attach one HTC component to all VML element instances of one type (such as or ), but is it possible to attach 2 different HTC components to 2 distinct VML element instances of a same type ? Many thanks in advance if you can help. Guillaume xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jan 26 19:04:50 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> <13997.64636.594738.255064@localhost.localdomain> Message-ID: <36AE0D2F.FC2ECDE6@prescod.net> david@megginson.com wrote: > > Tyler Baker writes: > > > Yes your customers, but that is in the document world. > > Actually, the customers who like namespaces are the ones in the data > world, especially those in industries that deal heavily with data > exchange (like the news industry and e-commerce). Document people > don't care all that much yet -- they still have everything they need > in SGML. Namespaces only make sense in a world where you can more or less randomly mix objects from different problem domains. That very seldom happens in the document world. It would require some way to dynamically assemble processing specifications (stylesheets). But the interaction between stylesheet levels is way too complex for this sort of dynamically assembly to be easy. We also know that dynamic assembly of schemas is quite tricky. As far as I know, nobody is doing it yet. So the namespace mechanism strikes me as premature considering that we don't have any infrastructure to take advantage of it. Note that XSL takes advantage of namespaces in the stylesheet by merely dispensing with a schema altogether. As far as I know, XSL has no facility for dynamically assembling stylesheets *based on* namespaces. RDF has a sufficiently simple "processing model" that it makes sense to talk about combining data from various "namespaces" into a single RDF model. But useful applications built on top of RDF (both of them) will not (IMO) usually take advantage of the namespaces mechanism. For instance Netscape's "What's Related" may be RDF-based (I can't remember) but it probably does not support arbitrary namespaces. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco So what if one dark midnight less than a year from now, millions of computers around the world suddenly grind to a halt? My computer grinds to a halt several times a day. ... [Forget Y2K] We're ignoring a much bigger bug problem that's hiding, well, right under our noses. Call it the Y-Does-My-Computer-Crash-Three-Times-A-Day Problem. - http://www.upside.com/David_Futrelle/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Tue Jan 26 19:09:18 1999 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:08:05 2004 Subject: ADMIN: CD-ROM Archive of Discussion list Message-ID: Sorry, as an addendum to my previous posting, the XML-DEV archives are known to the publisher by the name ECHET98 CD-ROM (its not in their catalogues quite yet). Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ If my digital email signature is invalid, download a new root at http://www.belsign.be/en/services/receive/install-ca.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rabin at shore.net Tue Jan 26 19:11:08 1999 From: rabin at shore.net (Paul Rabin) Date: Mon Jun 7 17:08:05 2004 Subject: SAX: Next Round In-Reply-To: <13992.61347.658381.956807@localhost.localdomain> References: <199901202122.QAA00962@megginson.com> <13991.41975.494212.645715@localhost.localdomain> Message-ID: At 04:41 PM 1/22/99 -0500, david@megginson.com wrote: >Paul Rabin writes: > > What SAX extensions would be needed to support multiple event > > stream inputs and outputs? Filters that route events to one or > > more event stream outputs have been implemented. What is the best > > way to register the handlers for multiple event stream outputs? > >The Java-beans-ish way would be to have > > public void addDocumentHandler(DocumentHandler handler); > public removeDocumentHandler(DocumentHandler handler); If the filter is simply copying events to multiple handlers, then this is ok. But if different sets of events are going to different handlers, then there might be an advantage in distinguishing the handlers in some way, other than by the order in which they are added. This could be done either by using separate setFooHandler() methods, or by an additional argument to a single setDocumentHandler() method. > > Support for multiple event stream inputs raises control flow issues. One > > solution is to have a new version of parse() that returns immediately after > > initializing the parse context, but without generating any events, and a > > new getNextEvent() method that causes a single call to the appropriate > > upstream handler to be made before returning. > >I don't want to deal with synchronization issues at the SAX layer -- >the idea is that SAX provides the raw information for higher layers to >work with. As long as SAX gives you the basic information about an >XML document, you can build a rich superstructure for more complex >processing. Suppose you have an application that is merging XML documents, where the semantics of the merge allows serial processing of the inputs. This can't easily be done unless the application can poll for events on each parser. The required synchronization could be implemented in a filter, so that the application doesn't have to worry about multitasking issues. The filter would look like a SAX parser, but with the extensions noted above (or equivalent). Paul xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Jan 26 19:36:55 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:05 2004 Subject: Why SAX needs namespace support In-Reply-To: <36AE08E1.FF963CD7@mecomnet.de> References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <199901261615.LAA21310@hesketh.net> Message-ID: <199901261936.OAA25894@hesketh.net> At 07:27 PM 1/26/99 +0100, james anderson wrote: >i suspect i stand in a (very small) minority on this issue, but with respect >to the diagram (http://www.simonstl.com/articles/layering/layered2.gif.) the >"namespace transformation" should appear at least above "attribute >defaulting". i fear i stand in an even smaller minority on the second claim - >that it belongs above entity resolution. perhaps not in the current spec, but >time will tell. You certainly could put it above attribute defaulting if you liked; part of what I'm proposing is putting that kind of control in the hands of the application developer rather than the parser author. Personally, I use attribute defaults for most of my namespace declarations, but your situation may definitely vary. Time will certainly tell. Hopefully, it will be merciful. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Tue Jan 26 20:24:33 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:05 2004 Subject: Summary of XML schema languages Message-ID: <01BE4971.68759120@grappa.ito.tu-darmstadt.de> I have updated this presentation and tried to remove most of my personal bias (the summary is still blatantly opinionated). In the process, I cleaned up the commentary -- the text is now much more readable and does a better job of summarizing some of the "big picture" stuff, especially with respect to schema reuse and the goals of a schema language. As always, I am open to comments, questions, and general abuse. As before the presentation is available in PowerPoint and HTML formats, accessible from my home page at: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/bourret.htm -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Jan 26 20:27:36 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:06 2004 Subject: Why SAX needs namespace support References: <3.0.32.19990126100821.00b56960@pop.intergate.bc.ca> Message-ID: <36AE2629.F0EA392E@mecomnet.de> Tim Bray wrote: > ... > But what on earth makes anyone think that namespaces would be scoped > in the DOM? The notion arises where one attempts to maintain the prefix information with the DOM element (for example, by virtue of making it available in the interface to the element's identifier). Some people maintain that this, in itself, is a mistake. Others believe that such a feature is indispensible. Were it truly indispensible, it would introduce scoping issues into the DOM model. > The scoping in XML files is purely a syntactic minimization > technique. I.e., if I have a DOM tree modelling the document above > (surely everyone agrees that I get the same DOM tree from both > instances) and I go stick a new "f" element as a child of the 'e' > element, surely it makes no sense to put it in the either the a.b.c > or x.y.z namespaces auto-magically. Among other things, it might > come from some entirely different namespace. > The key is that one can no longer think of it as sticking 'a new "f" element' anywhere. One is permitted to add only "a.b.c:f" elements, or the like. That is, unless one recognizes the legitimacy of the "null" namespace and the intent is to add an element of which the identifier is "in" that namespace. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jan 26 21:22:44 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:06 2004 Subject: ANN: "media-types.dtd" References: <199812041929.LAA01765@mehitabel.eng.sun.com> Message-ID: <36AE31FC.D4F1209@locke.ccil.org> Murray Altheim complained about my "media-types.dtd" document thus: > You've used the IETF ownerid, but > I see no authorization to create a work within their namespace. Is there > some IETF document (I-D, RFC, etc.) to justify this usage? [...] You're > inappropriately assigning names within another organization's namespace. After much reflection, I have rewritten the document not to use public identifiers, IETF or otherwise, because it's true that the IETF might assign different public identifiers to the referenced documents, or assign the given public identifiers to something else. > If you had used '-//Sun Microsystems//' I can guarantee you'd be talking > to our lawyers. You're representing a document you authored as that of > the IETF, a recognized organization, and it's not an IETF document. But I cannot let this charge stand. I did not write a document and give it an IETF public id. I wrote a document which *refers* to other documents that are written or published by the IETF, using "plausible" (a.k.a. "Sears catalogue") public ids for them. The new version uses only system IDs, namely the URLs of the media-types explanations at http://www.isi.edu/in-notes/iana/assignments/media-types . > This document should not have been posted, and it is appropriate that > you either remove it from circulation or alter the ownerid's to one for > which you have authority, such as '-//JCowan//'. If I used that, the well-known singer John Cowan (http://www.johncowan.com) would probably be down on me instead. 1/2 :-) So, from the top: The DTD fragment http://www.ccil.org/~cowan/XML/media-types.dtd contains XML notation declarations for all the recognized MIME media types such as text/plain, audio/basic, and application/postscript. The notation names are derived by mapping "/" to "_" and making a few other changes documented in the DTD fragment. In accordance with the conventions of XML notations, each notation has an external identifier which refers to an English-language description of the format named by the notation. So now if you want to have an XML element that refers to a Microsoft Project file, you can incorporate "media-types.dtd" and then declare it as: -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rohit at mink.mt.att.com Tue Jan 26 21:47:58 1999 From: rohit at mink.mt.att.com (Rohit Jain) Date: Mon Jun 7 17:08:06 2004 Subject: No subject Message-ID: <36AE37F5.EED52B52@mink.mt.att.com> unsubscribe xml-dev rohit@mink.mt.att.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lauzon at us.ibm.com Tue Jan 26 22:02:40 1999 From: lauzon at us.ibm.com (lauzon@us.ibm.com) Date: Mon Jun 7 17:08:06 2004 Subject: Translation between DTDs, schemas, UML, and the like Message-ID: <85256705.0078F91D.00@D51MTA10.pok.ibm.com> XMI is a submission to the OMG for a way to interchange UML data between different modeling tools. For more information on this, you should take a look at: http://www.omg.org/archives/orbos/msg00702.html >From what I've seen it seems pretty complex, but that's because it's attempting to describe all of UML (class diagrams, state diagrams, etc etc). I'm working on a tool for schema mapping between objects and databases, and looked at this as a way to describe objects using XML. For now we are just using a DTD that our team whipped up from scratch that describes a single class, but for more intelligent schema mapping we are going to need a more complete model. XMI may be what we will use in the future for this. Shawn Lauzon Department MMB - San Francisco Database Persistence http://www.ibm.com/Java/Sanfrancisco/ email: lauzon@us.ibm.com "A. G. McDowell" on 01/23/99 02:21:35 PM Please respond to "A. G. McDowell" To: xml-dev@ic.ac.uk cc: (bcc: Shawn Lauzon/Rochester/IBM) Subject: Translation between DTDs, schemas, UML, and the like There seem to be a large number of languages devoted to listing (for instance) the fields that make up a customer order and describing their data types. To comprehend a (hypothetical) ecommerce system I might have to follow a relational schema for the underlying database, a UML model of the application classes and logic, and a schema or DTD for the XML used to exchange data with its customers. Is there any hope of a product that could be used to automatically generate some part of this? My chosen format would be UML, but I'm open to reasons why not. There are already drawing tools out there that can generate C++ or Java code from suitably annotated diagrams, and keep the annotations from making the diagrams unreadable: XML DTDs or schemas should just be one more output format. The work on exchange of UML between repositories already seems to involve auto-generating some sort of schema from a description of UML (albeit not couched in UML itself, but in a simpler metalanguage). Finally, there are a lot of people out there who have already decided they need to know UML for the application logic anyway. On the other hand I don't know anywhere I can go to buy a UML -> DTD Rational Rose plugin, complete with round trip functionality and a free mouse mat, so maybe there's some good reason why all this is rubbish. Is anybody planning to convert all the systems analysts to model in XML schemas? Is the gap between exchangeable data, open to the world, and encapsulated objects, observable only via their methods, just too large? I have to admit that I personally have no great desire to write all my Java via Rational Rose. Should I also find a burning desire to hand- craft DTDs? -- A. G. McDowell xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jan 26 22:22:46 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:08:06 2004 Subject: Why SAX needs namespace support In-Reply-To: <36AE0D2F.FC2ECDE6@prescod.net> References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> <13997.64636.594738.255064@localhost.localdomain> <36AE0D2F.FC2ECDE6@prescod.net> Message-ID: <13998.15960.356614.433592@localhost.localdomain> Paul Prescod writes: > Namespaces only make sense in a world where you can more or less > randomly mix objects from different problem domains. That very > seldom happens in the document world. It would require some way to > dynamically assemble processing specifications (stylesheets). Or, at a minimum, it would require application-specific rules for dealing with unknown elements and attributes, similar to those in the architectural forms spec. For unknown attributes, it will almost always make sense to ignore them; for unknown elements, there are three useful options (other than choke-and-die or determine-parent-type-from-a-schema): 1. Ignore the element and all of its descendants. 2. Ignore the element boundaries and process the content as if it were part of the parent element. 3. Ignore the element boundaries and character content, but resume processing for any recognised descendant element. As Paul points out, the RDF case is simple because (1) can be applied universally; a technical manual or a web page is not so simple. That said, not all document processing has to do with rendering and publishing, even outside of the data world. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Wed Jan 27 00:31:35 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:08:06 2004 Subject: Why SAX needs namespace support In-Reply-To: <36AE0D2F.FC2ECDE6@prescod.net> References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> <13997.64636.594738.255064@localhost.localdomain> Message-ID: <3.0.1.32.19990126161631.02591280@mail.accessone.com> I can, off the top of my head, think of lots of times where mixing elements from other dtds would make sense. A few that sprang to mind: Any kind of fiction (include a poem, recipe, formula etc). News articles (ditto above). Linguistics (include a fragment of text in a foreign language). Dictionary. Encyclopedia. I know this isn't quite what Mr. Prescod had in mind (I think), but it seems like a useful thing to be able to do. Why, if you include a "poem.dtd" in another kind of document, couldn't you process the fragment of the document (the poem or poems) in the "process space" (namespace?) of that dtd or stylesheet or whatever? Sincerely, Dave LeBlanc At 12:45 PM 1/26/99 -0600, Paul Prescod wrote: >Namespaces only make sense in a world where you can more or less randomly >mix objects from different problem domains. That very seldom happens in >the document world. It would require some way to dynamically assemble >processing specifications (stylesheets). But the interaction between >stylesheet levels is way too complex for this sort of dynamically assembly >to be easy. We also know that dynamic assembly of schemas is quite tricky. >As far as I know, nobody is doing it yet. So the namespace mechanism >strikes me as premature considering that we don't have any infrastructure >to take advantage of it. > > Paul Prescod - ISOGEN Consulting Engineer speaking for only himself > http://itrc.uwaterloo.ca/~papresco > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Wed Jan 27 00:32:27 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:08:06 2004 Subject: ANN: "media-types.dtd" In-Reply-To: <36AE31FC.D4F1209@locke.ccil.org> References: <199812041929.LAA01765@mehitabel.eng.sun.com> Message-ID: <3.0.1.32.19990126160608.0258e550@mail.accessone.com> Amazing, I didn't get the original post. This looks like a really nice useful piece of work. Wish I had the first copy. The Lawyer remark was out of line and probably a violation of the canon of ethics. tsk tsk. This message was not prepared by any tool, document or other reference to -//Sun Microsystems//. Gerbils where not duct taped, fondled or held in any sort of bondage. David LeBlanc At 04:22 PM 1/26/99 -0500, John Cowan wrote: >Murray Altheim complained about my "media-types.dtd" document thus: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jan 27 00:54:43 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:06 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> <13997.64636.594738.255064@localhost.localdomain> <3.0.1.32.19990126161631.02591280@mail.accessone.com> Message-ID: <36AE61A7.E89848ED@prescod.net> David LeBlanc wrote: > > I can, off the top of my head, think of lots of times where mixing elements > from other dtds would make sense. A few that sprang to mind: > Any kind of fiction (include a poem, recipe, formula etc). > News articles (ditto above). > Linguistics (include a fragment of text in a foreign language). > Dictionary. > Encyclopedia. > > I know this isn't quite what Mr. Prescod had in mind (I think), but it > seems like a useful thing to be able to do. I define all of those things as single document types for purposes of processing. Here's why: I must make a stylesheet that handles ALL element types from ALL of the included components. And, in general, I must make that stylesheet by hand. Therefore, integrating a poem "fragment" into an encyclopedia is a fairly intricate, complex job. Deciding how to combine the two schemas is similarly tricky. In existing schema languages it has to be done by hand also. While I am doing this integration effort, I can go in and fix up any clashing names. The point is: * name clashes are a minor problem * compared to the schema and stylesheet merging. Many people from the SGML world are skeptical of namespaces because we wonder about the benefits of solving the simple problem first. I can see how namespaces solve problems in RDF, but that just pushes the problem up a level: what problems does RDF solve? And can those problems really be solved by blindly combining components from various problem domains? > Why, if you include a > "poem.dtd" in another kind of document, couldn't you process the fragment > of the document (the poem or poems) in the "process space" (namespace?) of > that dtd or stylesheet or whatever? I don't know what that means. I *do* know that a poem in a newspaper typically looks a hell of a lot different than a poem in the Encyclopedia Brittanica which looks a lot different than a poem in a poetry book. So the poem's stylesheet has to be massively context-sensitive. *That* is the hard part. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco So what if one dark midnight less than a year from now, millions of computers around the world suddenly grind to a halt? My computer grinds to a halt several times a day. ... [Forget Y2K] We're ignoring a much bigger bug problem that's hiding, well, right under our noses. Call it the Y-Does-My-Computer-Crash-Three-Times-A-Day Problem. - http://www.upside.com/David_Futrelle/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Wed Jan 27 01:02:59 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:08:06 2004 Subject: Questions about processing X*L Message-ID: <3.0.1.32.19990126170558.01153310@mail.accessone.com> I have often thought that an important use of dtds (or schemas etc.) would be/could be to include processing information about the documents that conform to them. What I mean is that an element declaration would have an attribute of type (for example) "script" that would contain code that the receiving processor (i.e. browser) could use to process the following document(s) in whatever way that was desired, not just for stylistic/presentation purposes. I actually thought that was why XSL included the script/ecmascript construct in the first place. This might imply a definition cache as well where the latest "document definition" (however specified) would be kept. Another question: is it possible, using the existing standards, for a dtd or document to infer the existance of more then one document definition? It would be interesting to create families/hierarchies of document definitions usable for different purposes (perhaps through an inheritance mechanism?). Thus, I could have a root document definition "MyDocDef" and derived document definitions "MyDocDef-Process", "MydocDef-Transform-HTML" (implying a root "MyDocDef-Transform" rooted on "MyDocDef") and "MyDocDef-Style". (Maybe architectural forms is an approach to this?) Sorry if i'm reinventing the wheel here... Thoughts or comments anyone? Sincerely, Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From BPosert at filenet.com Wed Jan 27 01:52:12 1999 From: BPosert at filenet.com (Posert, Bob) Date: Mon Jun 7 17:08:06 2004 Subject: Possible error string bug in expat1.0.2 Message-ID: I sent this to James, but it bounced back: Hi James. Can't say how much I like expat. While copying the error strings into a resource file (for localization), I noticed what looks like a problem in xmlparse.c: In XML_ErrorString, the string "unclosed token" is repeated twice. From the defines in xmlparse.h, it looks like the second occurrence should be "partial character." --Bob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bugman at cre.co.kr Wed Jan 27 03:34:47 1999 From: bugman at cre.co.kr (ÀÌÅÂÈñ) Date: Mon Jun 7 17:08:06 2004 Subject: unsubscribe Message-ID: <36A92FB4.90216E71@cre.co.kr> unsubscibe xml-dev-digest bugman@cre.co.kr xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pire_bernard at euroclear.com Wed Jan 27 07:45:00 1999 From: pire_bernard at euroclear.com (Bernard Pire) Date: Mon Jun 7 17:08:06 2004 Subject: C++ parser for SAX Message-ID: Does anybody know a parser written in C++ for SAX. I know already a few written in Java. Thank you, Bernard Pire xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Wed Jan 27 09:53:08 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:06 2004 Subject: Why SAX needs namespace support Message-ID: <01BE49E2.5325DF20@grappa.ito.tu-darmstadt.de> David Megginson wrote: > Michael.Kay@icl.com writes: > > > Perhaps a setOption(option, flag) interface would be more extensible. > > I could live with this, but only if the options were namespace > qualified, i.e. > > [examples snipped] > > Do people like this? I was almost afraid to suggest it... I prefer this. Once you start down the options path, there's no telling where it will end, even if you have a very big stick for fighting off all the options people want. set/getOption at least has the virtue of being forward-compatible -- on any option it doesn't recognize, setOption fails and getOption returns false. Also, are all options true/false? If not, the option value should be Object, not Boolean. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed Jan 27 10:21:58 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:06 2004 Subject: Why SAX needs namespace support Message-ID: <93CB64052F94D211BC5D0010A80013310EB2AB@WWMESS3> > To put this another way, namespaces are merely a syntactic mechanism > to allow each element type and attribute name in a document to be > qualified by some URI. The DOM should obviously preserve this > information, but I can't see why it should be concerned with > the syntactic sugar that was used to express it. -Tim Well one minor technicality is that if it didn't preserve the syntactic sugar, it would violate the XML 1.0 spec, which requires that all attribute values be available to the application*. This is all part of the general problem that namespaces don't work as an optional feature layered above XML: they must become core. I will try to avoid using namespaces until they are properly integrated into SAX, DOM, DTDs, and indeed the XML specification itself. Mike Kay *On re-reading, the XML spec doesn't say this very clearly. It suggests it. But that's a different thread... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed Jan 27 10:29:53 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:06 2004 Subject: Why SAX needs namespace support Message-ID: <93CB64052F94D211BC5D0010A80013310EB2AC@WWMESS3> > > Perhaps a setOption(option, flag) interface would be more > extensible. > > I could live with this, but only if the options were namespace > qualified, i.e. > > parser.setOption("http://xml.org/sax/features/validation", true); > parser.setOption("http://xml.org/sax/features/namespaces", false); > I'm all for fully qualified names, but I don't see why we should repeat the error of using "http://" names for things that are not accessible via the HTTP protocol. What's wrong with "org.xml.sax.option.validation"? Or is this overkill anyway? Why not just say that names beginning with "sax:" are reserved? Mike xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jan 27 11:56:19 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:08:06 2004 Subject: Why SAX needs namespace support In-Reply-To: <93CB64052F94D211BC5D0010A80013310EB2AC@WWMESS3> References: <93CB64052F94D211BC5D0010A80013310EB2AC@WWMESS3> Message-ID: <13998.65120.41094.362958@localhost.localdomain> Michael.Kay@icl.com writes: > > > Perhaps a setOption(option, flag) interface would be more > > extensible. > > > > I could live with this, but only if the options were namespace > > qualified, i.e. > > > > parser.setOption("http://xml.org/sax/features/validation", true); > > parser.setOption("http://xml.org/sax/features/namespaces", false); > > > I'm all for fully qualified names, but I don't see why we should repeat the > error of using "http://" names for things that are not accessible via the > HTTP protocol. What's wrong with > "org.xml.sax.option.validation"? That's fine for Java, but since it's based on DNS anyway, why develop a general solution that uses a slightly different notation? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed Jan 27 12:19:33 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support In-Reply-To: <93CB64052F94D211BC5D0010A80013310EB2AC@WWMESS3> Message-ID: <000001be49ee$a1811cf0$d3228018@jabr.ne.mediaone.net> Jonathan Borden JABR Technology Corp. http://jabr.ne.mediaone.net > > > I'm all for fully qualified names, but I don't see why we should > repeat the > error of using "http://" names for things that are not accessible via the > HTTP protocol. What's wrong with > "org.xml.sax.option.validation"? > > Or is this overkill anyway? Why not just say that names beginning with > "sax:" are reserved? > uris aren't required to the http: prefix, nor are they required to employ DNS for name resolution. for example: "urn:org:sax:option:validation" and "urn:org:sax" are both perfectly acceptable namespace uris. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Wed Jan 27 12:37:05 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support In-Reply-To: <13998.65120.41094.362958@localhost.localdomain> Message-ID: On Wed, 27 Jan 1999 david@megginson.com wrote: > Michael.Kay@icl.com writes: > > > > Perhaps a setOption(option, flag) interface would be more > > > extensible. > > > > > > I could live with this, but only if the options were namespace > > > qualified, i.e. > > > > > > parser.setOption("http://xml.org/sax/features/validation", true); > > > parser.setOption("http://xml.org/sax/features/namespaces", false); > > > > > I'm all for fully qualified names, but I don't see why we should repeat the > > error of using "http://" names for things that are not accessible via the > > HTTP protocol. What's wrong with > > "org.xml.sax.option.validation"? > > That's fine for Java, but since it's based on DNS anyway, why develop > a general solution that uses a slightly different notation? Yep. Why not just say that these properties are identified with URIs and leave it at that? http: URLs could then happily co-exist with URNs, uuid URLs etc etc without changing the basic architecture. URI ref: Uniform Resource Identifiers (URI): Generic Syntax; Berners-Lee, Fielding, Masinter, Internet Draft Standard August, 1998; RFC2396. (available from http://www.isi.edu/in-notes/rfc2396.txt) Dan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Jan 27 13:34:02 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support Message-ID: <003001be49f8$f5a06840$c9a8a8c0@thing2> >Yep. Why not just say that these properties are identified with URIs and >leave it at that? http: URLs could then happily co-exist with URNs, >uuid URLs etc etc without changing the basic architecture. Well, I think we'd want to go the extra step and define some common option names. And since these need not be implemented, it would be good to define a moderately comprehensive set of standard option names. The one proviso should be that any names that are defined should have clear meaning, though its always a guess at to what will remain clear over time. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Wed Jan 27 15:22:46 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB2AC@WWMESS3> Message-ID: <36AF2E58.B6CA90D3@infinet.com> Michael.Kay@icl.com wrote: > > > Perhaps a setOption(option, flag) interface would be more > > extensible. > > > > I could live with this, but only if the options were namespace > > qualified, i.e. > > > > parser.setOption("http://xml.org/sax/features/validation", true); > > parser.setOption("http://xml.org/sax/features/namespaces", false); > > > I'm all for fully qualified names, but I don't see why we should repeat the > error of using "http://" names for things that are not accessible via the > HTTP protocol. What's wrong with > "org.xml.sax.option.validation"? > > Or is this overkill anyway? Why not just say that names beginning with > "sax:" are reserved? This got me to thinking that you could have the best of both world's here from those people who want support for validation, namespaces, and the like to be through filters, and those who quite simply want direct native interfaces to the parser. To make this work you would need to do several things: (1) Change the ParserFactory class to not return a parser but a ParserGenerator object (in this case you might want to change the name "ParserFactory" to "ParserGeneratorFactory"). You would then have an interface named ParserGenerator which would be reponsible for constructing Parser types (such as parsers which do namespace processing). Really I think we only need two Parser types right now and then do the rest of the option stuff the way Mr. Megginson had suggested which I feel is simple and to the point. For a particular XML Parser package it would supply support for SAX by returning a ParserGenerator implementation in a manner similiar to how ParserFactory returns a Parser object (by using a system property). The structure of the ParserGenerator interface would be something pretty simple like this in Java: package org.xml.sax; public interface ParserGenerator { Parser createParser(InputSource source); Parser createParser(InputSource source, boolean validating, boolean entitesExpanded); NamespaceParser createNamespaceParser(InputSource source); NamespaceParser createNamespaceParser(InputSource source, boolean validating, boolean entitesExpanded); } If for some reason someone needed to use namespaces but the XML Parser implementation had no direct support for it or otherwise had no way of supporting the NamespaceParser interface, you could then use a standard filter that will come with the SAX Package to achieve this need. Michael Kay's SAXON package is a great start here. So if you did something like: ////////////////////////////////////////////////////////////////////// ParserGenerator parserGenerator = ParserGeneratorFactory.createParserGenerator(); NamespaceParser parser = null; try { parser = parserGenerator.createNamespaceParser(); } catch (UnsupportedParserException e) { parser = new NamespaceParserFilter(parserGenerator.createParser()); } parser.parse(new InputSource("http://www.foo.org/xml")); ///////////////////////////////////////////////////////////////////// NamespaceParserFilter would implement all of the methods of NamespaceParser and simply be a utility class for filtering out handled events from the standard SAX parser and then presenting them to the application. Not so sure here if this is exactly "Simple" (I am one of the people here who like SAX for its simplicity), but it does have some advantages in that you could easily have namespaces support even if the underlying XML parser does not support namespaces directly. Plus, I doubt "Namespaces in XML" will have any widespread use in the future by the great majority of XML Applications, so application programmers who want to deal with the very populous simple SAX Parser interface, won't have to eat the complexity of handling the namespace interface in their applications. Last but not least, we can talk about having specialized Name types for the NamespaceParser interface without having to worry about messing with the core XML parser interface. What do you folks think here? Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rick at clb.com Wed Jan 27 15:27:01 1999 From: rick at clb.com (Rick Labs) Date: Mon Jun 7 17:08:07 2004 Subject: XML Standards for Footwear Message-ID: <4.1.19990127101319.00a40930@204.249.121.41> XML EDI'ers and Developers, O.K. I know you don't really consider footwear a bleeding edge industry but we at least we are very international. Here is a release that is hitting the general news wires today regarding setting up XML standards for footwear. I realize this way out on the edge of interest for most XML developers but I send it to you fishing for people who might be interested in getting in on the ground floor. Will not send anything else to the developers list after this. Thanks. Rick Labs (PS - the release is for a very general audience so try to laugh too much when you read it. Also we are cutting over to a cable modem and going through an IP number change so please so be patient bare with us.) GROUP FORMED TO SET INTERNET DATA STANDARDS FOR FOOTWEAR INDUSTRY DOLGEVILLE, NEW YORK...January 22, 1999...Daniel Green Company (NASDAQ: DAGR) initiated a collaborative effort to develop new, open standards for data exchange among footwear suppliers, retailers, web sites, sourcing and distribution. These new standards are intended for use with the increasingly popular “eXtensible Mark-up Language” (XML). According to Daniel Green President, Greg Tunney, “The opportunity for establishing standards for the interchange of footwear data is substantial. Everyone will enjoy reduced cost and greater efficiencies. Eventually, these economies will extend all way through the footwear supply chain. If we can come together as an industry for this standard effort right now as XML first becomes established, everyone will save a great deal of time, money and hassles down the road. This working group will function in a all-volunteer, democratic fashion to develop free, open standards. The benefit will be substantial.” Rick Labs, Webmaster for Daniel Green Company, added, “The next versions of Internet Explorer and Netscape Navigator will ship this year with native support for XML. Based on the groundswell of international support for this new technology, we look forward to those in the footwear industry soon modifying their web sites and EDI systems to exploit its benefits.” The working group will include representatives from a broad cross-section of the footwear industry, such as athletic, shoes, boots, women’s fashion, retail and Internet outlets. “We also want to tie into the work being done by Federal Express, United Parcel Service, ISO, ANSI, other standards bodies, certain trade organizations and leading technology vendors,” Labs said. Initial plans call for the working group to define standard terms and design basic document object models that are expected to have a far-reaching impact on transaction productivity within the footwear industry. Ultimate goals include reduced inventories and waste as well as lower costs and greater variety for consumers. The standards task force is timed to coincide with ongoing technology efforts throughout the industry relative to increased Internet usage and Year 2000 compliance issues. Qualified industry representatives are invited to participate in the group’s first informal meeting during the Western Shoe Associates show held February 9-12 at the Sands Expo Center, Las Vegas, Nevada. For more information, contact Daniel Green Webmaster, Rick Labs (phone: 315-637-0915, e-mail: rick@clb.com) or to gain some background on XML, visit the special section of the company’s web site at www.DanielGreenCo.com/xml. . . . . . . . . . . . . . . . . . . . Rick Labs 315-637-0915 . . CL&B, Inc. 315-637-4297 Fax . . 527 E Genesee St. . . Fayetteville, NY 13066-1536 rick@clb.com . . . . . . . . . . . . . . . . . . . xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed Jan 27 15:56:43 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:07 2004 Subject: XML Standards for Footwear Message-ID: <93CB64052F94D211BC5D0010A80013310EB2B2@WWMESS3> How I wish I could spend more time reading about ladies shoes and less about parser filter generator factory stacks! Mike xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Jan 27 15:59:07 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support Message-ID: <001901be4a0d$5d43b060$c9a8a8c0@thing2> >... Last but not least, we can talk about having specialized Name >types for the NamespaceParser interface without having to worry about messing >with the core XML parser interface. This sure would make it tougher to build an api on top of SAX. Not that the big guys would have a problem. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 27 16:35:23 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <199901261615.LAA21310@hesketh.net> <199901261936.OAA25894@hesketh.net> Message-ID: <36AF415C.57B1AA0C@mecomnet.de> The qualification on my claim was on the number of its promoters, not on its necessity. It is not possible to guarantee an unambiguous attribute default - or type, or anything about it, unless the attribute name is mapped to its equivalent universal identifier. One may claim that the qualified name suffices, but a) that is not complete, b) in some situations where it succeeds, it already effectively enforces half of the specified namespace mapping (true, the redundant half) as soon as it performs the name resolution relative to the element identifier for names without prefixes. Simon St.Laurent wrote: > > At 07:27 PM 1/26/99 +0100, james anderson wrote: > >i suspect i stand in a (very small) minority on this issue, but with respect > >to the diagram (http://www.simonstl.com/articles/layering/layered2.gif.) the > >"namespace transformation" should appear at least above "attribute > >defaulting". i fear i stand in an even smaller minority on the second claim - > >that it belongs above entity resolution. perhaps not in the current spec, but > >time will tell. > > You certainly could put it above attribute defaulting if you liked; part of > what I'm proposing is putting that kind of control in the hands of the > application developer rather than the parser author. Personally, I use > attribute defaults for most of my namespace declarations, but your > situation may definitely vary. > It's not a matter of the situation. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 27 16:35:47 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> Message-ID: <36AF4168.E013778B@mecomnet.de> Tyler Baker wrote: > > ... > > Implementing namespaces in an XML parser is a trivial task, but dealing with > namespaces at the application level is a totally different story, especially with > this namespaces scoping stuff. How do you deal with namespaces in the DOM? I > mean if you copy a node here, and insert a node there, this entire namespace > scoping stuff gets all out of whack. It gets out of whack only if one models it incorrectly. Does anyone here even know what the "upward funarg" problem is?. In any case, it has yet to be shown that it is necessary to handle the scoping in the DOM at all, as the identifiers in the DOM should be universal names. > Of course you could say "well the > application programmer will just have to deal with that" and then the application > programmer would say "why should I deal with it at all". No. The better implementation is intrinsic in the parser. Then the problem does not exist on the application level. . > ... I have had to create my own Java <--> XML architecture > because nothing out there is suitable for my needs or the needs of developers who > will hopefully be working with this client application. You need only ensure that all identifiers you use are universal names. It is unfortunate that current parsers still model identifiers as strings. I would hope that this will change. As long as the serializer does the inversion mapping to that which the parser did, the application has nothing to do with scoping issues. > > OK the point is, namespaces as they are currently defined I feel make practical > use of XML in this regard too difficult for developer novices to deal with. I > would not even have wasted a year of my life on XML if I thought that its goals > were targeted exclusively for the browser centric world because that world does > not apply at all to how I am using XML. XML 1.0 did the job. Namespaces do > not. If namespaces do not do the job, then the application presumes an inadequate model for universal names. Which has nothing directly to do with their encoding in XML. > Plain and simple "Namespaces in XML" looks ugly, You are correct on this one point. > ... feels ugly, and therefore is not > practical at all for lots of applications that need to be simple, yet need some > namespaces mechanism nevertheless. > > Yes your customers, but that is in the document world. You are right they > probably could care less. Perhaps I should scrap XML support altogether and > stick with just Java Object Serialization. The problem of uniquely identifying names does not disappear if you take this approach. The serialization form changes. That is all. The requirement, that you model them adequately in the application, does not. > > Yah, but try and use namespaces with dynamically built DOM trees (or any other > object tree implementation that maps to XML). Go back and look at the note which I posted just before Christmas on "External DTD & namespaces". The DOM manipulation and the serialization are the easy part. > ... It can be a major pain in the rear > if you have multiple components that have no knowledge of each other and whose > externalized content is merged into one XML document tree. This claim is not correct. The serialization is actually the easiest part of the problem. Yes, the proposed serialization form for prefix bindings is convoluted. The distinctions between kinds of namespaces is baroque. These things do not matter to an application. It is the job of the parser to get these right and to map the qualified names to easily managed internal representations for universal names. Once that is accomplished, there need be no special coding in the application to accommodate namespaces. > ... Just think of the > nightmares of managing namespace defaulting if you are merging a lot of abstract > content (perhaps E-Commerce transactions which are converted to a > DocumentFragment). I would not expect any. Modulo the provision for a null namespace, the PR-specified encoding assures that, if an identifier has an universal equivalent in isolation, it will retain the same equivalent in any context. It does permit identifers which do not have an "intrinsic equivalent" to be captured upon reference, but also provides the means to specify the mapping. Where's the prospective nightmare? > > ... Try using XML with namespaces > for anything else more sophisticated and you might as well forget it (especially > for E-Commerce). But yes, "Namespaces in XML" may in fact flourish in the web I have tried. I do use it. One would not be able to do "anything else more sophisticated" than a browser without it. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed Jan 27 16:40:18 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support Message-ID: <93CB64052F94D211BC5D0010A80013310EB2B3@WWMESS3> Tyler Baker: > To make this work you would need to do several things: > > (1) Change the ParserFactory class to not return a parser but > a ParserGenerator > object (in this case you might want to change the name > "ParserFactory" to "ParserGeneratorFactory"). > I do think it would be useful for SAX to include a helper class for parser selection. This proposal, though, seems a little too abstract for most users to stomach (like telling someone who wants to watch News at Ten that he needs to start by instantiating a television factory generator). I'd suggest something more along the lines of the ParserManager in SAXON (which was inspired by the ODBC Driver Manager). It currently: - maintains a list of available parsers, known by familiar product names (e.g. "xp", "oracle") - maintains a preference order - allows an application to load a parser, scanning the preference list till it finds one suitable. I've considered for a long time maintaining separate lists of validating and non-validating parsers so you could choose one from either list: one could extend this idea to selecting a parser based on all its properties. The "parser" could also be a composite consisting of a parser plus one or more filters. We could then have a simple (static) interface ParserManager.loadParser(properties) that returns a parser matching the stated application requirements. There could also be an interface allowing parsers to register themselves: ParserManager.registerParser(this); this would call back to get information about the parser's properties. I think users could cope with that. Mike xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 27 16:43:08 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB2A8@WWMESS3> <13998.382.143868.329436@localhost.localdomain> Message-ID: <36AF4297.1C2EB3CB@mecomnet.de> Why not permit the application to bind an instance to perform the respective operations. It's more powerful and no harder to implement or to use? david@megginson.com wrote: > > Michael.Kay@icl.com writes: > > > Perhaps a setOption(option, flag) interface would be more extensible. > > I could live with this, but only if the options were namespace > qualified, i.e. > > try { > parser.setOption("http://xml.org/sax/features/validation", true); > parser.setOption("http://xml.org/sax/features/namespaces", false); > parser.setOption("http://xml.org/sax/features/entity-expansion", true); > parser.setOption("http://simonstl.org/ns/sax/xlink", true); > } catch (SAXUnsupportedFeatureException e) { > System.err.println("This parser ain't up to snuff -- try another!"); > } > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 27 16:51:25 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB2AB@WWMESS3> Message-ID: <36AF450A.A1C88CEA@mecomnet.de> As long as names are modeled in the DOM in their universal form, then is nothing to prevent the DOM from carrying the namespace attributes verbatim. The only artifact which would ever be required would be to introduce a namespace attribute for a case where an element contained an identifer (whether the GI or an attribute name) for the URI of which there was, as a consequence of a mutation, no lexically apparent binding at the point of serialization. This artifactual attribute could well appear in the serialization only, or it could actually be interned into the respective element. In the former case, there is no spec violation: the spec makes no claims about reserialization. Michael.Kay@icl.com wrote: > > > To put this another way, namespaces are merely a syntactic mechanism > > to allow each element type and attribute name in a document to be > > qualified by some URI. The DOM should obviously preserve this > > information, but I can't see why it should be concerned with > > the syntactic sugar that was used to express it. -Tim > > Well one minor technicality is that if it didn't preserve the syntactic > sugar, it would violate the XML 1.0 spec, which requires that all attribute > values be available to the application*. This is all part of the general > problem that namespaces don't work as an optional feature layered above XML: > they must become core. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Jan 27 17:05:45 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support Message-ID: <001901be4a16$a83f28c0$c9a8a8c0@thing2> >Why not permit the application to bind an instance to perform the respective >operations. It's more powerful and no harder to implement or to use? At one level, that's what we are doing with filters in MDSAX. But it gets awkward to use at the next level up. It seems more reasonable to have a parser factory object which can be configured just the way you want the parser to work. Then you can make as many instances of the parser as you want/need. In single-threaded applications, you just need one global parser. Possibly. But its important in a large XML application to be able to say, hey, get me a parser to use, at various points in the program without having to worry about setting the locale and all. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Wed Jan 27 17:42:40 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:07 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> <36AF4168.E013778B@mecomnet.de> Message-ID: <36AF4E3D.B403BC22@infinet.com> james anderson wrote: > Tyler Baker wrote: > > > > ... > > > > Implementing namespaces in an XML parser is a trivial task, but dealing with > > namespaces at the application level is a totally different story, especially with > > this namespaces scoping stuff. How do you deal with namespaces in the DOM? I > > mean if you copy a node here, and insert a node there, this entire namespace > > scoping stuff gets all out of whack. > > It gets out of whack only if one models it incorrectly. Does anyone here even > know what the "upward funarg" problem is?. In any case, it has yet to be shown > that it is necessary to handle the scoping in the DOM at all, as the > identifiers in the DOM should be universal names. Well then when you are building a DOM tree, should you pretend that namespace attributes are not really attributes, but are really pseudo-attributes which really are not part of the document structure but are only there temporarily in the serialized form of an XML file, or else should attributes be copied into the DOM tree like all other attributes. Attributes whether they are xml:space, xmlns: , or whatever are fundamental parts of the document as of XML 1.0. Should we assume that namespace nodes (as they are called in XSL) should be automatically generated as necessary when writing out a DOM document as well? By doing this, you really make things sloppy as the application programmer now has any direct control upon the actual output of writing a DOM document to a file. A direct transformation of one XML document built into a DOM tree to another XML document that represents that DOM tree may produce strikingly different results. > > Of course you could say "well the > > application programmer will just have to deal with that" and then the application > > programmer would say "why should I deal with it at all". > > No. The better implementation is intrinsic in the parser. Then the problem > does not exist on the application level. If all you care about is reading XML with namespaces and that is it, then great, namespaces don't matter because once you are done doing whatever you did with the document, you basically throw it away. But what if you are modeling object state using XML for a component based application. When you have components nested inside other components, things can get very sloppy very fast. > > ... I have had to create my own Java <--> XML architecture > > because nothing out there is suitable for my needs or the needs of developers who > > will hopefully be working with this client application. > > You need only ensure that all identifiers you use are universal names. It is > unfortunate that current parsers still model identifiers as strings. I would > hope that this will change. As long as the serializer does the inversion > mapping to that which the parser did, the application has nothing to do with > scoping issues. Alah the need for a Name type. > > > > OK the point is, namespaces as they are currently defined I feel make practical > > use of XML in this regard too difficult for developer novices to deal with. I > > would not even have wasted a year of my life on XML if I thought that its goals > > were targeted exclusively for the browser centric world because that world does > > not apply at all to how I am using XML. XML 1.0 did the job. Namespaces do > > not. > > If namespaces do not do the job, then the application presumes an inadequate > model for universal names. Which has nothing directly to do with their > encoding in XML. I am just saying that when you read an XML file into memory and then spit it back out as a document, the document structure should not change aside from maybe stripping comments and pretty printing issues. If people don't feel this is important, then I have a fundamental disagreement here in XML's direction. The design goals for XML are: 1.XML shall be straightforwardly usable over the Internet. 2.XML shall support a wide variety of applications. 3.XML shall be compatible with SGML. 4.It shall be easy to write programs which process XML documents. 5.The number of optional features in XML is to be kept to the absolute minimum, ideally zero. 6.XML documents should be human-legible and reasonably clear. 7.The XML design should be prepared quickly. 8.The design of XML shall be formal and concise. 9.XML documents shall be easy to create. 10.Terseness in XML markup is of minimal importance. I suppose there perhaps should of been a #11 which said "XML shall be usable by people without CS degrees". Sorry for the sarcasm but it seems like a lot of people debating this issue are victims of their own intelligence. Did the W3C Namespaces WG actually do any sort of research among average users on XML? Of course not because these drafts and recommendations are all done in secret among the "best and the brightest" without any outside opinion whatsoever. Does this mean the people that make up the "Namespaces in XML" WG are stupid? Not at all. It just means that the process that the W3C uses is stupid. Of course I suppose I am being "master of the obvious here" but the W3C still just does not get it that "end-users matter". > > Plain and simple "Namespaces in XML" looks ugly, > > You are correct on this one point. > > > ... feels ugly, and therefore is not > > practical at all for lots of applications that need to be simple, yet need some > > namespaces mechanism nevertheless. > > > > Yes your customers, but that is in the document world. You are right they > > probably could care less. Perhaps I should scrap XML support altogether and > > stick with just Java Object Serialization. > > The problem of uniquely identifying names does not disappear if you take this > approach. The serialization form changes. That is all. The requirement, that > you model them adequately in the application, does not. Well, if we go down the path that XML will only be generated automatically and modified automatically directly by applications, then why on earth not just use a binary format which is more compact, lightweight, and does not require some fancy XML parser to handle things. HTML was successful because just about any computer novice could create an HTML file in Microsoft Windows Notepad and then upload it to their ISP's web server. Am I a lone wolf here in my belief that XML should be simple enough for use as configuration files, user profile data (that may be edited manually), or simple object state. So the basic question here is XML supposed to be broadly adopted or just another niche specification? Niche specifications don't excite me, broadly adopted specifications do. > > > > Yah, but try and use namespaces with dynamically built DOM trees (or any other > > object tree implementation that maps to XML). > > Go back and look at the note which I posted just before Christmas on "External > DTD & namespaces". The DOM manipulation and the serialization are the easy part. > > > ... It can be a major pain in the rear > > if you have multiple components that have no knowledge of each other and whose > > externalized content is merged into one XML document tree. > > This claim is not correct. The serialization is actually the easiest part of > the problem. > Yes, the proposed serialization form for prefix bindings is convoluted. The > distinctions between kinds of namespaces is baroque. These things do not > matter to an application. It is the job of the parser to get these right and > to map the qualified names to easily managed internal representations for > universal names. Once that is accomplished, there need be no special coding in > the application to accommodate namespaces. Very true iff you don't care about end-users doing anything with XML files. I have much more faith in the average computer user than it seems a lot of people do here. I actually believe normal human beings are capable of making simple changes to XML documents manually if they need to. Ideally, applications will be generating XML files most of the time, but there are situations where people will want and need direct control. If you could assume that applications generate and process all of the markup all of the time, you could eliminate validation, do tag minimization, eliminate line number counting, and plenty of other optimizations that bear significant overhead and are only there to support robust error reporting. Also the last time I checked, in XSL pretty much 99.9% of people out there are building stylesheets manually. Since people will be generating XML documents manually such as in the case with XML stylesheets, forcing them to deal with this namespaces issue when the argument here is that "the tools will take care of the job" is rather contradictory. Tim Bray mentioned a quote along the lines that the two hardest things in computer science are namespaces and document caching (I think I am wrong about the latter). What is the purpose of sticking in namespaces at all if it is one of the most complicated issues in computer science? Sticking one of the most complicated issues in computer science into XML does not lend well to the argument that "XML documents shall be easy to create." Last but not least, XML has a lot of potential in the EDI space. EDI though ugly has no concept of namespaces and for years people have gotten by without them. If you make dealing with XML more of a pain than dealing with EDI, then why on earth would anyone want to make the switch other than because they heard that "XML is cool and the best new thing since sliced bread"? Sooner or later the hype will die down and actually usability will become an issue when companies and application developers decide whether to support XML. After all no one wants to support technologies that bring in lots of tech support calls. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Wed Jan 27 17:44:15 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:08 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB2B3@WWMESS3> Message-ID: <36AF4F2F.62C60227@infinet.com> Michael.Kay@icl.com wrote: > Tyler Baker: > > To make this work you would need to do several things: > > > > (1) Change the ParserFactory class to not return a parser but > > a ParserGenerator > > object (in this case you might want to change the name > > "ParserFactory" to "ParserGeneratorFactory"). > > > I do think it would be useful for SAX to include a helper class for parser > selection. This proposal, though, seems a little too abstract for most users > to stomach (like telling someone who wants to watch News at Ten that he > needs to start by instantiating a television factory generator). I'd suggest > something more along the lines of the ParserManager in SAXON (which was > inspired by the ODBC Driver Manager). It currently: I kind of agree here. Sometimes you just have to throw enough stuff at the wall and see what sticks. I guess this idea may not be sticking (-: > - maintains a list of available parsers, known by familiar product names > (e.g. "xp", "oracle") > - maintains a preference order > - allows an application to load a parser, scanning the preference list till > it finds one suitable. > > I've considered for a long time maintaining separate lists of validating and > non-validating parsers so you could choose one from either list: one could > extend this idea to selecting a parser based on all its properties. The > "parser" could also be a composite consisting of a parser plus one or more > filters. Seems like a good idea. > We could then have a simple (static) interface > ParserManager.loadParser(properties) that returns a parser matching the > stated application requirements. This would allow people to extend SAX and provide optional support for features in the future that we can't really predict at this time without cluttering up the interfaces. > There could also be an interface allowing parsers to register themselves: > ParserManager.registerParser(this); this would call back to get information > about the parser's properties. > > I think users could cope with that. Seems pretty simple and straightforward to me. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jan 27 17:54:51 1999 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:08:08 2004 Subject: Specifying options in SAX In-Reply-To: <36AF4297.1C2EB3CB@mecomnet.de> References: <93CB64052F94D211BC5D0010A80013310EB2A8@WWMESS3> <13998.382.143868.329436@localhost.localdomain> <36AF4297.1C2EB3CB@mecomnet.de> Message-ID: <13999.20429.782902.538450@localhost.localdomain> james anderson writes: > Why not permit the application to bind an instance to perform the > respective operations. It's more powerful and no harder to > implement or to use? I love it, but I don't think we should do it. James's proposal, as I understand it, is an excellent design pattern: // This is how Java can do a strongly-typed enumeration... public final class Response { public final static int DONTCARE = new Response(); public final static int YES = new Response(); public final static int NO = new Response(); private OptionResponse () {} } public interface OptionManager { public abstract Response wantValidation (); public abstract Response wantNamespaces (); public abstract Response wantEntityExpansion (); } public interface XParser extends Parser { // ... public void setOptionManager (OptionManager manager); } Unfortunately, SAX doesn't generally swing this way: note that there is not a separate interface/class for each SAX event type either, despite the fact that their absence makes the interface much more brittle. Ironically, elegant and extensible design tends to steepen the learning curve by multiplying interfaces and classes (how many people ever learned SP's native interface?), and SAX's target audience has not all read Gamma/Helm/Johnson/Vlissides. Think of SAX as a low-level device driver -- it's ugly, but you can build beautiful things on top of it (as many people on this list have). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Wed Jan 27 18:00:47 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:08:08 2004 Subject: Compound Documents - necessary for success? Message-ID: <990127124724.1254@mail11.mitre.org.0> Could we discuss the pros and cons of compound documents? First let me define what I mean by "compound document": compound-document ::= (compound-document | valid-document) valid-document ::= In words, a compound document is a "document of documents", where each document conforms to a schema; i.e, a nested document conforms to a schema as well as does its parent document. I will use the term composition and compound document interchangeably. I would like to make two assertions: (1) Compound documents are necessary for the success of XML. (2) Focusing on inheritance is of lesser importance than focusing on composition. I base these assertions upon an analogy to objects in programming languages. Suppose that we consider a document to be analogous to a programming object. Clearly, programming objects can be composed of objects; i.e., objects within objects. Object composition enables separation of concerns, extensibility, all the "ilities". Each (well-written) object is independent, with a well defined interface, and verifiable (with a compiler). Programming languages that did not support object composition would be intolerable. Analogously, documents should be composable, where each document is independently verifiable. Also the object community has come to the consensus that composition (black box reuse) enables more robust development than does inheritance (white box reuse). Analogously, I would assert that the focus in XML should be on enabling compound documents rather than on enabling inheritance. Thoughts/discussion? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamsden at us.ibm.com Wed Jan 27 18:49:09 1999 From: jamsden at us.ibm.com (jamsden@us.ibm.com) Date: Mon Jun 7 17:08:08 2004 Subject: Compound Documents - necessary for success? Message-ID: <85256706.006732A8.00@d54mta03.raleigh.ibm.com> Your comments are well placed, but there are a few considerations that could be added. First, XML is about data interchange, not object models. Objects encapsulate state and behavior while XML only describes document structure. So the analogy with objects is only partial. Encapsulation achieves its greatest benefit by separating interface from implementation through methods. XML exposes the implementation in the structure of the document. Hence the many arguments about attributes vs. content model. This wouldn't exist for an object model that hides the implementation. Generalization and specialization (inheritance) also achieve their greatest benefit with behavior, not state. A specialization would never want to override data in its superclass, only the implementation of a method, or adding a new method. There is nothing that corresponds to this in XML. The second consideration is to think about a document not just as an object, but as the persistent state of a collection of linked, collaborating objects. Of course this is an object too, but it plays an interesting role that may be exploited with respect to compound documents. The collaborating objects are the elements in the document. The state of the object is captured in the element's attributes and content model. The potential for collaboration is provided by relationships between elements. XML supports composed relationships with the content model of an element, and general associations through XLink and XPointer. So one way to think about composite documents is to think of them as a collection of collaborating objects (collaborations in UML) and how they might interact. One way to view this is to treat each document as a domain of interest where the collaborating objects contained in it enable some useful and related set of activities. Then composing documents hooks these collaborations together to enable some larger, composite set of activities. By enabling activities, I mean providing state that can be manipulated through DOM. Finally, there is a difference between inheritance vs. delegation models, and composition. Delegation can be done without composition by using a link. Again, methods are needed to know what is being delegated through the composition. XML only specifies the structure of valid data, not its meaning. So by itself, it can only structure the composition, not say what its for. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 27 19:05:47 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:08 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> <36AF4168.E013778B@mecomnet.de> Message-ID: <36AF6370.7BCA1E39@locke.ccil.org> james anderson wrote: > It gets out of whack only if one models it incorrectly. Does anyone here even > know what the "upward funarg" problem is? *sigh*. Yes, I do. What of it? > In any case, it has yet to be shown > that it is necessary to handle the scoping in the DOM at all, as the > identifiers in the DOM should be universal names. Should be, but aren't yet, and show no signs of becoming so. Alas. > You need only ensure that all identifiers you use are universal names. It is > unfortunate that current parsers still model identifiers as strings. I would > hope that this will change. As long as the serializer does the inversion > mapping to that which the parser did, the application has nothing to do with > scoping issues. You still are not acknowledging my point: the application must have access to the currently-in-scope mappings, because it may need to convert to universal format a QName that the parser cannot detect as such (because it appears as an attribute value or as character data). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jan 27 19:29:56 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:08 2004 Subject: ANN: "media-types.dtd" References: <199901270413.UAA01227@mehitabel.eng.sun.com> Message-ID: <36AF6912.7CEE7D70@locke.ccil.org> Murray Altheim scripsit: > > But I cannot let this charge stand. I did not write a document > > and give it an IETF public id. I wrote a document which *refers* to > > other documents that are written or published by the IETF, using > > "plausible" (a.k.a. "Sears catalogue") public ids for them. > > This is incorrect. You did give it an IETF public id. If "it" means my document whose systemid is "http://www.ccil.org/~cowan/XML/media-types.dtd", I did not assign to "it" an IETF public id or any other public id. > All of your FPIs did > use an "IETF" ownerid, as in this portion of your media-types.dtd: True. But those FPIs refer to IETF-published documents, not to documents written or published by me. I agree that it was inappropriate to assign them, as you state: > This would mislead people into believing that these were FPIs created > by the IETF. Just so. > Recognize I'm not trying to slap you around. Luckily for me. :-) > DocBook > has used empty SYSTEM ids, string SYSTEM ids matching the DOS-like file > extension (eg., "GIF", "PS", "TIFF"), etc. These are of course defective URIs and as such not valid XML system ids, but are (I suppose) valid SGML system ids. (Technically "GIF" etc. would be valid relative URIs, but that's hardly the intended use.) > mostly I think because it's simply not correct to > label things as a product of someone else. I labeled an IETF product (publication) as being by the IETF, using a public ID that could plausibly have been assigned by the IETF but wasn't. The error is similar to that of assigning an ISBN to a work that didn't have one, using the correct prefix for the actual publisher. Definitely not the Right Thing. > Of course, everyone I've talked to has a different opinion on the value > of notation identifiers. I think there are only two opinions: "worthless" and "pearl of great price". > But now, after that ye have known God, or rather are known of God, > how turn ye again to the weak and beggarly elements, whereunto ye > desire again to be in bondage? -- Galatians 4:9 Hmm. And who would the "weak and beggarly elements" be in this case? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ajd100 at NAmerica.mot.com Wed Jan 27 19:34:54 1999 From: ajd100 at NAmerica.mot.com (Dutra Juliana-AJD100) Date: Mon Jun 7 17:08:08 2004 Subject: XML pages from Databases Message-ID: <11EF19296147D211A7C100805F312AE7C017F3@s-il06ar.corp.mot.com> Good article about whether to do XML from an RDBMS or an Object Oriented data server XML poses data-architecture debate (Source: InfoWorld Electric) Experts disagree: Is XML a database feature, or the next middleware? http://www.idg.net/go.cgi?id=48699 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 27 20:19:44 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:08 2004 Subject: the "upwards funarg" problem. References: <199901202122.QAA00962@megginson.com> <13991.41975.494212.645715@localhost.localdomain> Message-ID: <36AF75D2.D1CD64EA@mecomnet.de> The notion would appear to abound on this list, that the matter of universal names, the modeling of same and techniques for syntactic minimization in serialization are somehow uncharted waters. The behaviour of qualified name prefixes in the DOM is but one example. Is it a problem to associate prefixes with names in the DOM? If so, then under which circumstances, and how is the problem resolved? The answer to each question is clear. Not only that, it would appear that the answers have been known for close to forty years. As I have noted in previous posts, this is an instance of the "upwards funarg" problem. Since I was curious about the history of this concept, I launched a request (http://www.hotbot.com/?MT=upwards+funarg&SM=phrase&DV=0&LG=any&DC=25&DE=2&submit=SEARCH&_v=2&OPs=MDRTP) which yielded only two results. as chance would have it, they were two quite pertinent results. the first reference was (http://www.stanford.edu/class/cs242/Autumn1997/outlines-95/funarg.html) it describes succinctly the issues which one needs address when referring to non-local, but lexically apparent, variable bindings in systems which permit first class functions. this is the "upwards funarg" problem. if the term means nothing to you, that note will explain enough for you to recognize the problem in the prefix<->URI bindings which may appear in DOM elements. The key is to note that the prefix acts as a lexically apparent binding for a URI over which a child element closes whenever it comprises a name which is qualified by the given prefix. (Should the duality between closures and objects be a missing link here, then take note of graham's exposition in chapter 17 of "ansi common lisp", in which he demonstrates how to model objects with closures, and invert it.) Given this analogy, when one transplants in the DOM an element which "closes over" some prefix binding, one is performing an operation analogous to passing a first class function upwards through an invocation stack. If one does not model this operation correctly this can lead to unintended results. (see ms Fisher's description at the location noted above for the synopsis.) As noted before, there are some who believe that such closures never come into existence, as the prefix stands in no direct relation to the respective names, but if one insists on such a model for names, then one must handle this problem. the second reference was to a chance note in comp.compilers (http://cuisg11.unige.ch/OSG/people/jvitek/Compilers/Year95/msg00974.html) which indirectly cites what would appear to be the first publication of the mechanisms for modelling problems of this sort: an article in Communications of the ACM, from 1973. The comp.compilers note also makes the point that, although this article constituted a publication milestone, the issue was addressed in implmentations which dated much earlier. Among them is Lisp 1.5. I somehow had dated Lisp 1.5 to the late sixties. When I looked further, I noted that for which the prorgammers's manual was published in 1961 and, as described in (http://www8.informatik.uni-erlangen.de/html/lisp/mcc91.html) the initial work on it - including the funarg problem is described in memos from the MIT AI-Lab from as early as 1959. ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 27 20:37:48 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:08 2004 Subject: Why SAX needs namespace support References: <93CB64052F94D211BC5D0010A80013310EB29B@WWMESS3> <13997.57507.333419.530622@localhost.localdomain> <36ADF924.7832905D@infinet.com> <36AF4168.E013778B@mecomnet.de> <36AF6370.7BCA1E39@locke.ccil.org> Message-ID: <36AF7A33.FCE994E6@mecomnet.de> John Cowan wrote: > > You still are not acknowledging my point: the application must have > access to the currently-in-scope mappings, because it may need to > convert to universal format a QName that the parser cannot detect > as such (because it appears as an attribute value or as character data). > I have acknowledged it. My answers may well have been burried in much to convoluted responses. I have suggested that either a) the application be permitted to perform these tasks in the parser's dynamic context, or b) the DOM designers have to recognize that they're dealing with an instance of the "upwards funarg" problem. There are known mechanism to manage the latter. My experience is that the former is much more effective. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jan 27 20:47:50 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:08 2004 Subject: Why SAX needs namespace support References: <001901be4a16$a83f28c0$c9a8a8c0@thing2> Message-ID: <36AF7C8F.4BD8045F@mecomnet.de> Bill la Forge wrote: > > >Why not permit the application to bind an instance to perform the respective > >operations. It's more powerful and no harder to implement or to use? > > At one level, that's what we are doing with filters in MDSAX. But it gets awkward > to use at the next level up. I undersand this. I don't understand the advantage which expressing the effective delegation indirectly through symbolic options values has over expressing it directly through explicit delegates. If one wants to delay the binding or turn that over to the factory, then pass class names instead of instances. ? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mda at discerning.com Wed Jan 27 22:43:18 1999 From: mda at discerning.com (Mark D. Anderson) Date: Mon Jun 7 17:08:08 2004 Subject: infoworld article on xml Message-ID: <01ef01be4a46$4e4c4520$0200a8c0@mdaxke.mediacity.com> interesting article regarding xml and databases.... http://www.infoworld.com/cgi-bin/displayStory.pl?/features/990125xml.htm -mda xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Jan 27 22:50:25 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:08 2004 Subject: Why SAX needs namespace support Message-ID: <001201be4a46$5d3e9060$c9a8a8c0@thing2> >I undersand this. I don't understand the advantage which expressing the >effective delegation indirectly through symbolic options values has over >expressing it directly through explicit delegates. If one wants to delay the >binding or turn that over to the factory, then pass class names instead of >instances. ? The advantage of using instances over class names is configurability. This becomes particularly important when the configuration is data driven, rather than hard-coded. (Guess I'm just a wantabe Lisp programmer. But I'm doin' it with Java and XML, so the distinction between code and data becomes important. And class names preclude all this.) So what I'm leaning towards, for the production release of MDSAX, is the use of configurable parser factories. It was left out of the beta, because everyone seems to have their favorate way to create parsers (SAXON, SAX, Coins). I want to provide a mechanism, but without precluding alternatives. And I didn't want it to be a barrior to the early adoptors for MDSAX. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pvelikho at cs.ucsd.edu Wed Jan 27 23:23:11 1999 From: pvelikho at cs.ucsd.edu (Pavel Velikhov) Date: Mon Jun 7 17:08:08 2004 Subject: Distributed DOM implementations References: <01ef01be4a46$4e4c4520$0200a8c0@mdaxke.mediacity.com> Message-ID: <36AF99F7.EEC3079F@cs.ucsd.edu> Hi, I would like to find out if there are any known distributed implementations of DOM (and free). What I mean by this is an ability to access remote XML documents through a DOM interface but not by downloading and parsing them locally. Instead I need a parser or whatever (e.g. OODB wrapper) on the other end to give me result of the DOM commands only. Thank you, Pavel Velikhov UCSD Database Lab pvelikho@cs.ucsd.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Wed Jan 27 23:46:06 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:08 2004 Subject: Distributed DOM implementations In-Reply-To: <36AF99F7.EEC3079F@cs.ucsd.edu> References: <01ef01be4a46$4e4c4520$0200a8c0@mdaxke.mediacity.com> Message-ID: <3.0.6.32.19990127154906.0095bc10@scripting.com> That's a very interesting idea! If we (UserLand) did this, it would not be free, but it could be very high level and quite powerful. Flip a switch and all of a sudden your code is working against data on the server. Can you say what kind of application you have in mind for this? Dave At 02:57 PM 1/27/99 -0800, you wrote: >Hi, > > I would like to find out if there are any known distributed >implementations of DOM (and free). What I mean by this is an ability to >access remote XML documents through a DOM interface but not by >downloading and parsing them locally. Instead I need a parser or >whatever (e.g. OODB wrapper) on the other end to give me result of the >DOM commands only. > >Thank you, >Pavel Velikhov >UCSD Database Lab >pvelikho@cs.ucsd.edu > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu Jan 28 00:08:24 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:08 2004 Subject: Distributed DOM implementations In-Reply-To: <36AF99F7.EEC3079F@cs.ucsd.edu> Message-ID: <000001be4a51$b6c85020$d3228018@jabr.ne.mediaone.net> Yes there are. MSXML implements the DOM on COM interfaces and hence can be remotely accessed via DCOM. Similarly Jade has a COM/Automation interface and can be accessed remotely via DCOM. You could also get a Java DOM implementation remoted via RMI. > > I would like to find out if there are any known distributed > implementations of DOM (and free). What I mean by this is an ability to > access remote XML documents through a DOM interface but not by > downloading and parsing them locally. Instead I need a parser or > whatever (e.g. OODB wrapper) on the other end to give me result of the > DOM commands only. > Jonathan Borden JABR Technology Corp. http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ralphc at bellsouth.net Thu Jan 28 00:17:25 1999 From: ralphc at bellsouth.net (Ralph Richard Cook) Date: Mon Jun 7 17:08:08 2004 Subject: Java DOM implementations and cloneNode In-Reply-To: <000801be4902$4164cd40$2ee044c6@arcot-main> References: <000801be4902$4164cd40$2ee044c6@arcot-main> Message-ID: <36afac0e.1893856@mail.atl.bellsouth.net> On Tue, 26 Jan 1999 00:02:39 -0800, you wrote: >>Am I expecting too much here? Shouldn't the classes that implement the >>DOM interfaces be able to copy via cloneNode, which is a DOM interface >>function? Is this a bug or expected behavior? > > >It is not a well known fact that DOM Level 1 does not dictate inter-document >operations or movement of nodes between documents. You will find that >following is true: > From looking at XML4J's source code (kudos, IBM) that the TXDocument, TXElement, etc classes do actual copies of things. From observing the behavior of Sun's Project X, since they don't supply source code (raspberries, Sun) it looks like they don't. I guess I'll try traversing the document and re-create it item by item. Thanks. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pvelikho at cs.ucsd.edu Thu Jan 28 00:45:00 1999 From: pvelikho at cs.ucsd.edu (Pavel Velikhov) Date: Mon Jun 7 17:08:08 2004 Subject: Distributed DOM implementations References: <01ef01be4a46$4e4c4520$0200a8c0@mdaxke.mediacity.com> <3.0.6.32.19990127154906.0095bc10@scripting.com> Message-ID: <36AFAD3B.C4769C4D@cs.ucsd.edu> Dave Winer wrote: > > That's a very interesting idea! If we (UserLand) did this, it would not be > free, but it could be very high level and quite powerful. Flip a switch and > all of a sudden your code is working against data on the server. Can you > say what kind of application you have in mind for this? Dave I have build a prototype of an XML database system, but I have found out that the XML parser is the chief performance bottleneck (DOM is my "storage model"). I.e. to query a document I have to parse all of it, even though the query may concern only a tiny fragment of it. Instead, if the document is pre-parsed and stored in some efficient representation (either main memory tree or some hierarchial representation on disk) and is available via DOM commands, I would save a lot of time. > At 02:57 PM 1/27/99 -0800, you wrote: > >Hi, > > > > I would like to find out if there are any known distributed > >implementations of DOM (and free). What I mean by this is an ability to > >access remote XML documents through a DOM interface but not by > >downloading and parsing them locally. Instead I need a parser or > >whatever (e.g. OODB wrapper) on the other end to give me result of the > >DOM commands only. > > > >Thank you, > >Pavel Velikhov > >UCSD Database Lab > >pvelikho@cs.ucsd.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pvelikho at cs.ucsd.edu Thu Jan 28 00:49:26 1999 From: pvelikho at cs.ucsd.edu (Pavel Velikhov) Date: Mon Jun 7 17:08:09 2004 Subject: Distributed DOM implementations References: <000001be4a51$b6c85020$d3228018@jabr.ne.mediaone.net> Message-ID: <36AFAE39.79F3A415@cs.ucsd.edu> Borden, Jonathan wrote: > > Yes there are. MSXML implements the DOM on COM interfaces and hence can be > remotely accessed via DCOM. Similarly Jade has a COM/Automation interface > and can be accessed remotely via DCOM. I would like to have a pure Java implementation that would run on both wintels and unix boxes. > You could also get a Java DOM implementation remoted via RMI. > This is a good idea! I think I will try that (if it takes reasonable time of course). Thanks for the input. Pavel Velikhov pvelikho@cs.ucsd.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Jan 28 00:52:52 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:08:09 2004 Subject: Why SAX needs namespace support References: <3.0.32.19990126090707.00b46c10@pop.intergate.bc.ca> Message-ID: <36AFB42B.1876@hiwaay.net> Tim Bray wrote: > > Hey, that's nothin'. I predicted that the Internet would collapse > every year between 1988 and 1993 inclusive. Still looks shaky to me, > but you get tired of being wrong all the time. Nyet. Piddlin'. I'm on record for predicting the death of HTML by lack of extensibility and failing to stick to known standards. So, I lost at least six windingss in my poobah turban and the jewel too. For me, the immediate usefulness of the namespace was apparent when I was writing a script to populate treeviews and realized the dang thing actually does give me a "uniquefier" for sorting. Not XML, but if it works in both applications, tres bien. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 28 01:59:54 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:09 2004 Subject: Why SAX needs namespace support In-Reply-To: <36AFB42B.1876@hiwaay.net> References: <3.0.32.19990126090707.00b46c10@pop.intergate.bc.ca> <36AFB42B.1876@hiwaay.net> Message-ID: <13999.49959.505725.502168@localhost.localdomain> len bullard writes: > Here are some, off the top of my head: 1. Need to work outside of a closed system. 2. Need to work across different hardware and software platforms. 3. Need to capture and save information snapshots. 4. Need to pass hierarchical information among components. 5. Need to have control over granularity of information. 6. Need to use information for different purposes. 7. Need to develop a single hub format for conversion. 8. Need to generate and test data easily (look how clear-text protocols like SMTP and HTTP won the world). 9. Want that cool web buzz. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Jan 28 02:08:20 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:09 2004 Subject: Distributed DOM implementations References: <01ef01be4a46$4e4c4520$0200a8c0@mdaxke.mediacity.com> <3.0.6.32.19990127154906.0095bc10@scripting.com> Message-ID: <36AFC5A4.382196F8@infinet.com> Dave Winer wrote: > That's a very interesting idea! If we (UserLand) did this, it would not be > free, but it could be very high level and quite powerful. Flip a switch and > all of a sudden your code is working against data on the server. Can you > say what kind of application you have in mind for this? Dave > > At 02:57 PM 1/27/99 -0800, you wrote: > >Hi, > > > > I would like to find out if there are any known distributed > >implementations of DOM (and free). What I mean by this is an ability to > >access remote XML documents through a DOM interface but not by > >downloading and parsing them locally. Instead I need a parser or > >whatever (e.g. OODB wrapper) on the other end to give me result of the > >DOM commands only. > > A company called ObjectSpace that I am sure many people here are familiar with has a product called Voyager that has an architecture that is ideal for a distributed DOM implementation. The proxies to the remote objects are generated dynamically and for the most part the concept of a remote object and a local object is transparent. I have heard that ObjectSpace will be riding the XML wave like everyone else, so perhaps you should ask these folks what their plans are. As many people know ObjectSpace wrote the JGL (Java Generic Library which is now officially known by some other name because SUN had some trademark squabbles) which is inherently distributed when used within Voyager. For them to write a distributed DOM implementation would be pretty simple. In fact, for anyone to write a distributed DOM implementation using Voyager would probably be pretty painless as well. Tyler P.S. - I have no affiliation whatsoever with ObjectSpace so these are purely my objective opinions. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu Jan 28 02:42:39 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:09 2004 Subject: ANN: XMOP Source C++/java up Message-ID: <000101be4a67$49b88930$d3228018@jabr.ne.mediaone.net> I'd like to announce that I've posted an early version of the XML MetaData Object Persistence source. See http://jabr.ne.mediaone.net/xmop/signup.htm This is an open source, free project. The C++ source is based on the IE4 msxml parser. Since the release of this parser, the DOM has been finalized and hence this parser is not DOM compliant. XMOP is being rewritten to employ msxml 5.x, hence this code is for instructional purposes only. Comments are welcome. XMOP provides persistence and marshalling support to COM objects (that have typelibraries!). This project uses the ObjectSpace STL library http://www.objectspace.com (free). I also use Keith Brown's delegator to dynamically wrap objects (via the XMOPFactory object). This version I used is from October 98 ... with some modifications. The latest version is at: http://www.develop.com/KBROWN I've also stolen code from Mike Nelson et al.s OLEVIEW typelibrary viewer. The wire format is XML as described in http://jabr.ne.mediaone.net/documents/xmop.dtd This project used to be called MBXML (marshal-by XML) hence the source code names. enjoy. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Thu Jan 28 04:39:12 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:08:09 2004 Subject: Compound Documents - necessary for success? References: <990127124724.1254@mail11.mitre.org.0> Message-ID: <36AFE9A7.5C3E8DCF@allette.com.au> Roger L. Costello wrote: > Could we discuss the pros and cons of compound documents? First let me > define what I mean by "compound document": > > compound-document ::= (compound-document | valid-document) > valid-document ::= I would love to discuss compound documents - having grappled with the same problems in SGML implementations with very little success, I'm curious as to how it will work with XML. > In words, a compound document is a "document of documents", where each > document conforms to a schema; i.e, a nested document conforms to a schema > as well as does its parent document. I will use the term composition and > compound document interchangeably. One problem that I've seen in the past is the issue of multiple levels of nesting, often with the same DTD being used. In legal case reports for example, it's not uncommon to see the judge include a fragment from another case report that includes a fragment from a third report. (In a legal system based on precedence, this is entirely reasonable.) What I don't understand is whether these fragments would use the same namespace as the parent document does. They do use the same DTD, but they're part of a different document. If they do use the same namespace, does this not introduce difficulty in the creation of an XSL stylesheet? After all, you may need to format the elements differently based on their ancestry, but also perhaps indenting the text further to reflect the fact that these documents are nested. It's not realistic to suggest that I just allow the documents to exist in the DTD, eliminating the need for calling this a compound document - the data logically lives in other structured documents and besides, it would make the DTD so loose as to be useless for any other purpose. Also, what would prevent someone from putting together a compound document constructed entirely of valid fragments? To the naked eye it would look like an invalid document, but the fact that the fragments themselves were valid and existed in a location that allowed them would mean that the document was parsable without error. I'm not suggesting this would be a common way of producing documents, but nor do I think it's a good idea that you could conceivably create a class of documents between well-formed and valid. Along similar lines, how would I include, say, two paragraphs of a judge's speech? Does a compound document imply a single doctype element? Would I have to wrap the two paragraphs in some artificial element just to make it a complete document? What would direct a user to this solution over adding each paragraph as a separate document? It seems that much effort has been spent in accomodating compound documents, but to the untrained eye, it seems that the support has been built prior to the problem being fully understood (by me, at least...:-). It appears that the 'XML Fragment Interchange Requirements' is being designed to address the management of fragments - is it anticipated that this will complement or obviate the need for namespaces in compound documents? -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Jan 28 08:58:52 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:09 2004 Subject: Why SAX needs namespace support References: <3.0.32.19990126100821.00b56960@pop.intergate.bc.ca> Message-ID: <36B027E7.AFA5478C@mecomnet.de> I reread this note today and have a rather basic question about it: Tim Bray wrote: > > ... The following two documents are namespace-equivalent: > > | | xmlns:X='http://x.y.z'> > | > | > | > | > | > | > | > > ... > (surely everyone agrees that I get the same DOM tree from both > instances) I would have thought that the respective "a", "http://a.b.c::b", and "http://x.y.z::d" elements comprised different attributes. ? Is there something in the intent of the recommendation which I have overlooked? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Jan 28 09:01:57 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:09 2004 Subject: namespace partitions Message-ID: <36B0288D.6510FA20@mecomnet.de> Could someone else who has implemented support for namespaces comment on the "workings" of namespace partitions. When they first appeared over the summer, they merely struck me as unnecessarily baroque. Now that they are still included in the recommended standard (although downgraded to "non-normative"), I'm wondering what consequence they have in implemented parsers and DOMs. I'm wondering why they appear in the spec at all. Do they offer any advantages for binding attribute declarations? ... for a validation algorithm? Maybe I need to go over to the XSL list and enquire about their effect on pattern formulation. I pose the question since, despite a careful reading of the section on the "internal structure" of namespaces, I can understand them only as conflating the identity of a name with the mechanism used to bind an attribute definition to the name. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From erich_nachbar at ctp.com Thu Jan 28 09:26:27 1999 From: erich_nachbar at ctp.com (Erich Nachbar) Date: Mon Jun 7 17:08:09 2004 Subject: function to quote/escape special chars Message-ID: <539050D218A4D211BF7D00A0C9DAEF180B313E@aalener.munich.ctp.com> Hi, we're using msxml from ie5 b2 with some C++ classes. We have here some pretty simple 'flat' data and want to produce an XML string with C++ couts. Is there a function in msxml or a C++ class or C function which converts a normal string to an escaped string? Any help apprechiated! Bye. -Erich xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mlamb at roinet.com Thu Jan 28 15:06:07 1999 From: mlamb at roinet.com (mlamb@roinet.com) Date: Mon Jun 7 17:08:09 2004 Subject: BNF operator precedence in XML spec Message-ID: <85256707.0052D110.00@roinet.com> I've been working on an XML processor that I wish to base directly upon the BNF in the XML spec. I've reached an obstacle in that the operator precedence is not outlined in this spec, and after searching the Internet for more information, I was only able to find a posting to this group with the same question. For example, should "A B | C" in the BNF be parsed as "(A B) | C" or "A (B | C)" ? Any information would be appreciated. - Marty Lamb xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Thu Jan 28 15:11:54 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:08:09 2004 Subject: Compound Documents - necessary for success? Message-ID: <990128101133.1254@mail11.mitre.org.0> Marcus Carr wrote: >Also, what would prevent someone from putting together a compound document >constructed entirely of valid fragments? Yes, this is exactly what is desired! >To the naked eye it would look like an >invalid document, but the fact that the fragments themselves were valid and >existed in a location that allowed them would mean that the document was parsable >without error. I'm not suggesting this would be a common way of producing >documents, but nor do I think it's a good idea that you could conceivably create >a class of documents between well-formed and valid. Is it not enough to verify that the fragments are valid and that the document as a whole is well-formed? > >Along similar lines, how would I include, say, two paragraphs of a judge's >speech? Does a compound document imply a single doctype element? Would I have to >wrap the two paragraphs in some artificial element just to make it a complete >document? I would like to assert that an XML parser *should* be able to validate each document fragment against their respective DTDs. Perhaps all the DTDs that are referenced by the fragments should be listed in multiple DOCTYPEs at the top of the document? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jan 28 15:20:52 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:09 2004 Subject: How to use xml:lang? (was: DDML Documentation Capabilities) In-Reply-To: <01BE47E9.804DB180.jarle.stabell@dokpro.uio.no> References: <01BE47E9.804DB180.jarle.stabell@dokpro.uio.no> Message-ID: <14000.32378.940818.358122@localhost.localdomain> [sorry for the late reply] Jarle Stabell writes: > One question (not about DDML in particular) regarding how to best use > xml:lang: > > Should the DDML look something like: > > > Title in german > > > Description in german > > > Title in english > > > Description in english > This is passable, if a little ugly -- it keeps things simple enough that it's probably what DDML needs. > or should one use something similar to: > > > <if xml:lang="de">Title in german</if><if xml:lang="en">Title in > english</if>.... > > > Description in germanDescription > in english > You certainly shouldn't use this one -- it looks too much like procedural code rather than descriptive markup. Here's a clean and elegant (but verbose) way to handle it descriptively: <text xml:lang="es">Pedido</text> <text xml:lang="en">Order</text> <text xml:lang="de">Order</text> The question is whether you always want to require a subelement. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From skshirsa at nortelnetworks.com Thu Jan 28 15:39:40 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:08:09 2004 Subject: BNF operator precedence in XML spec Message-ID: <3.0.32.19990128103733.006ea1d8@bl-mail2.corpeast.baynetworks.com> Hi, I tried to find the examples of ambiguity in the grammar for XML spec, couldn't find too many. One of the example is : PubidLiteral ::= '"' PubidChar* '"' | "'" (PubidChar - "'")* "'" I'm sure the expected precedence rules here are : PubidLiteral ::= ('"' PubidChar* '"') | ("'" (PubidChar - "'")* "'") And so if it is consistent, it looks like that AB | C should be parsed as (AB) | C. Thanks & Regards, Shekhar Kshirsagar Nortel Networks At 10:08 AM 1/28/99 -0500, mlamb@roinet.com wrote: > > I've been working on an XML processor that I > wish to base directly upon the BNF in the XML spec. > I've reached an obstacle in that the operator precedence > is not outlined in this spec, and after searching the > Internet for more information, I was only able to find > a posting to this group with the same question. For > example, should "A B | C" in the BNF be parsed as > "(A B) | C" or "A (B | C)" ? > > Any information would be appreciated. > >- Marty Lamb > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ti64877 at imcnam.sbi.com Thu Jan 28 15:55:02 1999 From: ti64877 at imcnam.sbi.com (Ingargiola, Tito) Date: Mon Jun 7 17:08:09 2004 Subject: Distributed DOM implementations Message-ID: <3994C79D0211D211A99F00805FE6DEE249BF5D@exchny15.corp.smb.com> Hi, Given that the DOM has an IDL mapping, writing distributed implementations of it should be easy. Due to some of the choices made in that mapping, however, it's a little less clean than one might hope. Specifically, the IDL and Java mappings are incompatible. I had brought this up before in both this and the DOM mailing lists. Stephen McConnell from the OSM (http://www.osm.net) was kind enough to explain why this was the case and what was being done to address it. In the meanwhile, out of curiosity, I wrote a set of adapters that provide a "bridge" between these inconsistencies in the Java & IDL mappings. I've used these adapters to remotely manipulate DOM objects using the stripped-down CORBA implementation that comes with JDK1.2. My experience is that you're not likely to be too pleased with the performance characteristics of such an effort, but it's pretty interesting to play with, and for some uses the performance characteristics may be acceptable. If anyone is interested, I'll be happy to send them a copy of these (extremely rough!) adapters. Regards, Tito. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sawhneya at ms.com Thu Jan 28 16:01:05 1999 From: sawhneya at ms.com (Avneet Sawhney) Date: Mon Jun 7 17:08:09 2004 Subject: Compound Documents - necessary for success? References: <990127124724.1254@mail11.mitre.org.0> Message-ID: <36B0898A.BF339A93@ms.com> Hi, There are some interesting thoughts here, and I think your assertions are based on the common belief which says "use composition when you can, use inheritance when you have to". While I have no dispute with this, I'm wondering if you are saying that you only need one and not the other. Specifically, I do not think that only using compound documents can solve issues of customization which have been previously discussed. My concern is, given an industry standard schema, how do I use this internally when I know I will have to augment the standard schema with information specific to my company, dept., and application. Certainly, not all players will be using the standard schema as is. Some customization will be necessary. I am not talking about fragments here either, so perhaps we have different issues if your focus on composition is based on the use of fragments. Thanks, -Avneet Roger L. Costello wrote: > I would like to make two assertions: > > (1) Compound documents are necessary for the success of XML. > > (2) Focusing on inheritance is of lesser importance than focusing on > composition. > > Also the object community has come to the consensus that composition (black > box reuse) enables more robust development than does inheritance (white box > reuse). Analogously, I would assert that the focus in XML should be on > enabling compound documents rather than on enabling inheritance. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eddie.sheffield at enterworks.com Thu Jan 28 16:29:26 1999 From: eddie.sheffield at enterworks.com (Eddie Sheffield) Date: Mon Jun 7 17:08:10 2004 Subject: Distributed DOM implementations References: <3994C79D0211D211A99F00805FE6DEE249BF5D@exchny15.corp.smb.com> Message-ID: <36B08E99.95560C9D@enterworks.com> Hello, I've been considering the possibilities of such a system myself. One approach might be to use intelligent stubs on the client side ("stubs" being the client side objects that you interact with that in turn forward calls to the actual server-side objects) that provide some caching and prefetching support. This would require a lot more work, including probably hand-mangling the generated classes, but could be a useful compromise. For example, when you first get a reference to the root of the DOM tree, the stub goes ahead and fetches all the root's attributes and direct childen. If you then refer to one of those child nodes it's already available locally and so no server call is necessary. There would need to be some kind of policy in place for dumping cached objects and selecting which objects to cache to prevent the entire DOM from ultimately being present in the client (might be a huge document and client resources might be tight). Any ideas? I'm tempted to take this notion to the CORBA lists as it's more a distributed processing problem than XML. Eddie Sheffield "Ingargiola, Tito" wrote: > Hi, > > Given that the DOM has an IDL mapping, writing distributed implementations > of it should be easy. Due to some of the choices made in that mapping, > however, it's a little less clean than one might hope. Specifically, the > IDL and Java mappings are incompatible. I had brought this up before in > both this and the DOM mailing lists. Stephen McConnell from the OSM > (http://www.osm.net) was kind enough to explain why this was the case and > what was being done to address it. > > In the meanwhile, out of curiosity, I wrote a set of adapters that provide a > "bridge" between these inconsistencies in the Java & IDL mappings. I've > used these adapters to remotely manipulate DOM objects using the > stripped-down CORBA implementation that comes with JDK1.2. My experience is > that you're not likely to be too pleased with the performance > characteristics of such an effort, but it's pretty interesting to play with, > and for some uses the performance characteristics may be acceptable. > > If anyone is interested, I'll be happy to send them a copy of these > (extremely rough!) adapters. Regards, > > Tito. > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elfering at medicaldataservice.de Thu Jan 28 16:51:24 1999 From: elfering at medicaldataservice.de (Ingo Elfering) Date: Mon Jun 7 17:08:10 2004 Subject: Distributed DOM implementations In-Reply-To: <36B08E99.95560C9D@enterworks.com> Message-ID: We have such a system working (if I understand your question right). It?s a DCOM (!) object that is used from a client via a browser to manage patient healthcare data. The DCOM objects handles all logic like access permissions, where to the other side it uses the IE 5 Beta2 DOM/XML/XSL object to handle XML data. It runs under MTS and actually stores the data in a SQL DB. The system is in pilot installations running. The client sees pre-parsed data, partly as properties, partly as a XML stream. Caching is handled via a client side COM object that uses this data DCOM obj. Run's fine ! Not too difficult too build... Anything I can answer ? Mit freundlichem Gru?/Best Regards Ingo Elfering www.MedicalDataService.de >-----Original Message----- >From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of >Eddie Sheffield >Sent: Donnerstag, 28. Januar 1999 16:22 >To: XML-DEV >Subject: Re: Distributed DOM implementations > > >Hello, > >I've been considering the possibilities of such a system myself. >One approach >might be to use intelligent stubs on the client side ("stubs" >being the client >side objects that you interact with that in turn forward calls to >the actual >server-side objects) that provide some caching and prefetching >support. This >would require a lot more work, including probably hand-mangling >the generated >classes, but could be a useful compromise. For example, when you >first get a >reference to the root of the DOM tree, the stub goes ahead and >fetches all the >root's attributes and direct childen. If you then refer to one of >those child >nodes it's already available locally and so no server call is >necessary. There >would need to be some kind of policy in place for dumping cached >objects and >selecting which objects to cache to prevent the entire DOM from >ultimately being >present in the client (might be a huge document and client >resources might be >tight). > >Any ideas? I'm tempted to take this notion to the CORBA lists as >it's more a >distributed processing problem than XML. > >Eddie Sheffield > >"Ingargiola, Tito" wrote: > >> Hi, >> >> Given that the DOM has an IDL mapping, writing distributed >implementations >> of it should be easy. Due to some of the choices made in that mapping, >> however, it's a little less clean than one might hope. Specifically, the >> IDL and Java mappings are incompatible. I had brought this up before in >> both this and the DOM mailing lists. Stephen McConnell from the OSM >> (http://www.osm.net) was kind enough to explain why this was the case and >> what was being done to address it. >> >> In the meanwhile, out of curiosity, I wrote a set of adapters >that provide a >> "bridge" between these inconsistencies in the Java & IDL mappings. I've >> used these adapters to remotely manipulate DOM objects using the >> stripped-down CORBA implementation that comes with JDK1.2. My >experience is >> that you're not likely to be too pleased with the performance >> characteristics of such an effort, but it's pretty interesting >to play with, >> and for some uses the performance characteristics may be acceptable. >> >> If anyone is interested, I'll be happy to send them a copy of these >> (extremely rough!) adapters. Regards, >> >> Tito. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wunder at infoseek.com Thu Jan 28 16:53:45 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:08:10 2004 Subject: Why SAX needs namespace support In-Reply-To: <36AFB42B.1876@hiwaay.net> References: <3.0.32.19990126090707.00b46c10@pop.intergate.bc.ca> Message-ID: <3.0.5.32.19990128084557.00b5f2d0@corp> At 06:49 PM 1/27/99 -0600, len bullard wrote: > Since I've done this recently, here is why I did it. Ultraseek Server CCE uses XML in two different ways. The private format is to store the topic definitions and transmit them to other servers in a distributed search network. I used XML there because I didn't feel like wasting my time spec'ing a new format, then writing and maintaining a parser for it. With XML, I just needed to spec a DTD. A straight productivity win. The public use is to parse XML documents so they can be searched. Actually, I have a third use here in the lab, but not released -- delivering query results in XML. The justification is similar to the first one, that is, I don't feel like writing another file format and spec and forcing our users to write and maintain special-purpose parsers. Right now, the query results have an inline DTD, and even though that costs 1.5 kbytes per result, the files are still smaller than a corresponding HTML result. Note, this is with everything as elements -- no silly "abbreviated format" like RDF. wunder Walter R. Underwood wunder@infoseek.com wunder@best.com (home) http://software.infoseek.com/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Thu Jan 28 17:40:59 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:10 2004 Subject: Will XML eat the web? Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> XML is potentially a web "killer application" in more ways than one. Let's examine 2 scenarios - server based XML processing and client based XML processing. Server based XML processing Here we process XML on the server to produce HTML. This will be where the majority of XML processing occurs for web applications, since reliance on the 5.0 web browsers is going to be low for a long time. XML processing is a resource hog. There's not really much you can do about it. Sure, you can use DCOM or Corba to distribute processing your XML across several servers - that's throwing hardware at the problem - not always the best solution. You can use a persistent parsed structure like a DOM maintained in memory, but for some applications such as a rapidly changing XML database this isn't always feasible (or is it?). Currently our web based XML system processes about 5 files per second (very subjective figures) - and it's at max CPU (it's only a Pii266). This is using expat. Not a good situation since I could probably build a much faster application using an RDBMS - but I'm looking to the future when I can send the raw XML to the client. Processing XML on the client This is a much better option, but an option that doesn't always exist. However if I'm sending XML to the client, for example a large database of products, wouldn't the client machine then get bogged down processing the XML? (I don't know - we haven't got that far yet). Anyway, I'd like to hear people's comments on solving this potential issue, and whether they think choosing XML for the web was a good choice at this stage in browser development. (please note: I'm a big fan of XML - it has huge potential, and I would appreciate any help I can get in making this application faster) Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ R+++ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From timm at channelpoint.com Thu Jan 28 17:58:51 1999 From: timm at channelpoint.com (Tim McCune) Date: Mon Jun 7 17:08:10 2004 Subject: Will XML eat the web? Message-ID: <8A24EC12044FD21195E200600895E0B387D11D@goat.channelpoint.com> Whenever you run into processing bottlenecks, cache and distribute. The most obvious thing to cache is the result of applying the XSL to the XML, for as long as you can. Caching DOMs also helps. If your DOM is very dynamic, you can also exercise more fine-grained control by caching individual elements, or caching the objects that create these elements. You can also cache stylesheets. We did all of this on the Java Lobby, and it gave us more of a speed boost than anything else. As far as bottlenecks on the browser go, I once worked on a project where we had a tiny applet run when the user first enters the site that measures its resources such as CPU speed. This gets stored in the client's session so that the server can then shift processing to the client (sending it XML/XSL) or keep it on the server (sending the client HTML), whichever gives the client the fastest response. This is a perfect fit with XML/XSL processing. -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Matthew Sergeant (EML) Sent: Thursday, January 28, 1999 10:46 AM To: 'xml-dev@ic.ac.uk' Subject: Will XML eat the web? XML is potentially a web "killer application" in more ways than one. Let's examine 2 scenarios - server based XML processing and client based XML processing. Server based XML processing Here we process XML on the server to produce HTML. This will be where the majority of XML processing occurs for web applications, since reliance on the 5.0 web browsers is going to be low for a long time. XML processing is a resource hog. There's not really much you can do about it. Sure, you can use DCOM or Corba to distribute processing your XML across several servers - that's throwing hardware at the problem - not always the best solution. You can use a persistent parsed structure like a DOM maintained in memory, but for some applications such as a rapidly changing XML database this isn't always feasible (or is it?). Currently our web based XML system processes about 5 files per second (very subjective figures) - and it's at max CPU (it's only a Pii266). This is using expat. Not a good situation since I could probably build a much faster application using an RDBMS - but I'm looking to the future when I can send the raw XML to the client. Processing XML on the client This is a much better option, but an option that doesn't always exist. However if I'm sending XML to the client, for example a large database of products, wouldn't the client machine then get bogged down processing the XML? (I don't know - we haven't got that far yet). Anyway, I'd like to hear people's comments on solving this potential issue, and whether they think choosing XML for the web was a good choice at this stage in browser development. (please note: I'm a big fan of XML - it has huge potential, and I would appreciate any help I can get in making this application faster) Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ R+++ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmcdonou at library.berkeley.edu Thu Jan 28 18:00:28 1999 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:08:10 2004 Subject: Distributed DOM implementations In-Reply-To: <36AFAD3B.C4769C4D@cs.ucsd.edu> References: <01ef01be4a46$4e4c4520$0200a8c0@mdaxke.mediacity.com> <3.0.6.32.19990127154906.0095bc10@scripting.com> Message-ID: <3.0.5.32.19990128095111.0122db20@library.berkeley.edu> At 04:20 PM 1/27/1999 -0800, Pavel Velikhov wrote: > I have build a prototype of an XML database system, but I have found >out that >the XML parser is the chief performance bottleneck (DOM is my "storage >model"). >I.e. to query a document I have to parse all of it, even though the >query may >concern only a tiny fragment of it. Instead, if the document is >pre-parsed and >stored in some efficient representation (either main memory tree or some >hierarchial >representation on disk) and is available via DOM commands, I would save >a lot of >time. > This is very similar to the approach we're taking to distributing archival documents in the Making of America II project at Berkeley; we pre-parse the documents and extract information from them using DOM into Java objects which are then serialized and written to disk. The objects provide a somewhat higher level interface for delivering information to clients that want to interact with the objects. It does indeed make things a good deal faster. Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......) Library Systems Office, 386 Doe, U.C. Berkeley | \ * * / Berkeley, CA 94720-6000 (510) 642-5168 | \ <> / "Well, it looks easy enough...." | \ -- / SGNORMPF!!! -- From the Famous Last Words file | |||| xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jan 28 18:30:40 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:10 2004 Subject: Will XML eat the web? In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericss on.se> Message-ID: <199901281830.NAA32763@hesketh.net> At 06:40 PM 1/28/99 +0100, Matthew Sergeant (EML) wrote: >XML is potentially a web "killer application" in more ways than one. Let's >examine 2 scenarios - server based XML processing and client based XML >processing. >Processing XML on the client > >This is a much better option, but an option that doesn't always exist. >However if I'm sending XML to the client, for example a large database of >products, wouldn't the client machine then get bogged down processing the >XML? (I don't know - we haven't got that far yet). > >Anyway, I'd like to hear people's comments on solving this potential issue, >and whether they think choosing XML for the web was a good choice at this >stage in browser development. I think document fragments and well-organized information are going to be key to avoiding bogging down clients. For some (old) suggestions on what an architecture implementing this might look like, you could try my essay 'Building the File System Into the File' at http://www.simonstl.com/articles/filesyst.htm, though I should warn you in advance that its pretty speculative, and key technologies (especially XLink/XPointer, querying, and fragment handling) haven't hardened yet. Overall, I don't think we'll inevitable overwhelm ourselves in a sea of information, though it's going to take a lot of work structuring both information and applications to process it. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Jan 28 19:42:18 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:10 2004 Subject: Will XML eat the web? References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> Message-ID: <36B0BA28.47849E39@prescod.net> "Matthew Sergeant (EML)" wrote: > > You > can use a persistent parsed structure like a DOM maintained in memory, but > for some applications such as a rapidly changing XML database this isn't > always feasible (or is it?). You could continually update the DOMs based on changes in the XML. What exactly are your concerns about this architecture. > Currently our web based XML system processes > about 5 files per second (very subjective figures) - and it's at max CPU > (it's only a Pii266). This is using expat. Not a good situation since I > could probably build a much faster application using an RDBMS - but I'm > looking to the future when I can send the raw XML to the client. You need to store data that is efficiently maintained relationally. You need to *transmit* XML. Why not use a relational database and create XML when you need it. > Anyway, I'd like to hear people's comments on solving this potential issue, > and whether they think choosing XML for the web was a good choice at this > stage in browser development. I don't follow the question. The longer we wait, the longer it takes browsers to support it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco So what if one dark midnight less than a year from now, millions of computers around the world suddenly grind to a halt? My computer grinds to a halt several times a day. ... [Forget Y2K] We're ignoring a much bigger bug problem that's hiding, well, right under our noses. Call it the Y-Does-My-Computer-Crash-Three-Times-A-Day Problem. - http://www.upside.com/David_Futrelle/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Jan 28 20:37:58 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:10 2004 Subject: XTech'99 - schedule posted Message-ID: <3.0.32.19990128123641.00c07670@pop.intergate.bc.ca> The program for XTech'99 is now available at http://www.gca.org/conf/xtech99/xtecindx.htm With Sun, IBM, and Microsoft co-sponsoring, the turnout should be massive. The quality of the submissions was awesome and gave Jon and I some serious headaches pulling things together. We have an especially interesting keynote from David Siegel (although some my find the new technologies from Microsoft, IBM, Oracle, Adobe, Netscape, and so on of equal interest). See you in San Jose in March. Cheers, Tim Bray (Co-Chair) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pvelikho at cs.ucsd.edu Thu Jan 28 21:19:56 1999 From: pvelikho at cs.ucsd.edu (Pavel Velikhov) Date: Mon Jun 7 17:08:10 2004 Subject: Will XML eat the web? References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> <36B0BA28.47849E39@prescod.net> Message-ID: <36B0CE96.4AAEDF97@cs.ucsd.edu> Paul Prescod wrote: > > You need to store data that is efficiently maintained relationally. You > need to *transmit* XML. Why not use a relational database and create XML > when you need it. > Transmitting XML in a textual representation is not always a good idea. When the user does the 'select *' query on an XML database, sending him a 20 megabyte XML file that he will need to parse, apply an xsl stylesheet to and display in the browser is not the best solution. IMHO, the result of the query should be shipped on demand, when the user is actually 'looking' at a piece of an XML file. Pavel Velikhov xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From JeremyP at clbooks.com Thu Jan 28 21:21:31 1999 From: JeremyP at clbooks.com (Jeremy Pascual) Date: Mon Jun 7 17:08:10 2004 Subject: msxml parser question Message-ID: <073841B11720D2119E6200104B2474FB010C4822@CLBEXCHANGE.cbooks.com> hi, i was just wondering if anyone knew if msxml parser can strings, opposed to urls? or if there was an activex component to allow msxml to accept strings? thanks, jeremy --------------------------------------------- jeremy pascual computerliteracy (bookshops+online) http://www.clbooks.com Corporate Office 1308 orleans drive sunnyvale, ca 94089 email: jeremyp@clbooks.com phone: 408 541-2020 x170 fax1: 408-752-9919 (Better Choice) fax2: 408-752-9917 --------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Alice.Portillo at PSS.Boeing.com Thu Jan 28 21:53:32 1999 From: Alice.Portillo at PSS.Boeing.com (Portillo, Christina) Date: Mon Jun 7 17:08:10 2004 Subject: WebCGM? Message-ID: <715FA307208BD211AE640008C7A43BB91C1256@xch-rtn-02.ca.boeing.com> The CGM standard allows for what it calls "intelligent graphics". The Web Application Protocol provides a DTD fragment which you can embed in your DTD to addressing the graphic and aligning the graphic to the page much as you had with the tag in the HTML DTD. The WebCGM Protocol provides the way of indentifying regions within the graphic which may be of interests for further linking and addressing. This is like hotspotting and is the "intelligence" talked about. So now you can jump from the XML to view a specific graphic or portion of the graphic. Which is great when you can zoom to really small regions without loss of viewing quality. The CGM graphic itself can be used the graphic to navigate to another graphic or portion of XML text. This is pretty much what is currently seen when using raster based graphics like gif and hotspotting to navigate from text to graphic and graphic to text. This WebCGM AP provides this same functionality for the CGM 2D vector graphic. Again the big benefit is to zoom in on fine detail without loss of detail. CGM 2D graphics is a much better method (vs raster) to make available complex diagrams and schematics. Some of these are quite large or very detailed and need the support the navigation and addressing capability this WebCGM AP provide. Christina Portillo Product Definition and Image Technology The Boeing Company Phone: 425.237.3351 PO Box 3707 M/S 6H-AF Fax: 425.237.3428 Seattle, WA 98124-2207 christina.portillo@boeing.com > ---------- > From: John Cowan[SMTP:cowan@locke.ccil.org] > Reply To: John Cowan > Sent: Monday, January 25, 1999 1:01 PM > To: XML Dev > Subject: Re: WebCGM? > > Simon St.Laurent wrote: > > > Does anyone know what WebCGM (a new W3C recommendation) is and how it > > relates to XML? About all I can figure out is that it's a format for > > describing graphics that has something to do with XML, but the rest isn't > > clear at all. > > WebCGM is a profile (subset) of CGM, a binary graphics format > that describes graphics in terms of how to draw them abstractly. > The XML DTD is used solely to explain how some of the CGM > objects can appear inside other objects: its relation to real > XML is purely conceptual, but if you wrote a CGM-to-XML > translator you could use the DTD to validate parts of the > resulting XML. > > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > You tollerday donsk? N. You tolkatiff scowegian? Nn. > You spigotty anglease? Nnn. You phonio saxo? Nnnn. > Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Jan 28 22:13:47 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:10 2004 Subject: Will XML eat the web? References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> <36B0BA28.47849E39@prescod.net> <36B0CE96.4AAEDF97@cs.ucsd.edu> Message-ID: <36B0DCCA.29285B0@prescod.net> Pavel Velikhov wrote: > > Paul Prescod wrote: > > > > You need to store data that is efficiently maintained relationally. You > > need to *transmit* XML. Why not use a relational database and create XML > > when you need it. > > > > Transmitting XML in a textual representation is not always a good idea. I don't follow you. XML is, by definition, textual. > When the user does the 'select *' query on an XML database, sending him > a 20 megabyte XML file that he will need to parse, apply an xsl > stylesheet > to and display in the browser is not the best solution. IMHO, the result > of the query should be shipped on demand, when the user is actually > 'looking' > at a piece of an XML file. I don't think I said anything to contradict this, though I would say that by the time you have a "20 megabyte XML file" you've probably already done something wrong. There is almost never a good reason to generate files that large. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Fri Jan 29 00:15:02 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:08:11 2004 Subject: Compound Documents - necessary for success? References: <990128101133.1254@mail11.mitre.org.0> Message-ID: <36B0FD52.F6521B1D@allette.com.au> Roger L. Costello wrote: > >Also, what would prevent someone from putting together a compound document > >constructed entirely of valid fragments? > > Yes, this is exactly what is desired! Sorry, maybe I didn't make myself clear - given the following DTD: ]> If a user wants to create a compound document, they might do something like: This is c This is b This is a with the elements "c", "b" and "a" being documents in their own right and namespace. The editing application presumably allows the elements to occur without interfering with the content model for "doc", since they're existing in their own namespace - is this the case? If the three elements use the same DTD as element doc (and assuming this means that they share the same namespace), then presumably the creation of a DTD and the normalisation of the instance would result in something like: ]> This is c This is b This is a If the three elements were to be regarded as being part of the same document as the doc element, the processor would generate an error. If the three elements are regarded as being documents in their own right, it would presumably not, but the use of namespace has initiated undesireable modification of the DTD in order to support this instance. Is this example fundamentally flawed? Was the fact that namespaces might overlap within a document one reason that a namespaces isn't required to resolve to a DTD or schema? > Is it not enough to verify that the fragments are valid and that the > document as a whole is well-formed? No, you also want to respect the original intention of the DTD, unless a really good reason exists not to. > I would like to assert that an XML parser *should* be able to validate each > document fragment against their respective DTDs. Perhaps all the DTDs that > are referenced by the fragments should be listed in multiple DOCTYPEs at > the top of the document? In this example, the issue is that all of the fragments use the same DTD, but I still don't know if I should be creating different namespaces that (conceptually) resolve to the same DTD. -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SMUENCH at us.oracle.com Fri Jan 29 00:28:22 1999 From: SMUENCH at us.oracle.com (Steve Muench) Date: Mon Jun 7 17:08:11 2004 Subject: msxml parser question Message-ID: <199901290028.QAA25059@mailsun3> Use the loadXML() method of DOMDocument to load the XML from a string. the load() method loads from an URL. ____________________________________________ Steve Muench, Consulting PM & XML Evangelist Java Business Objects Dev't Team http://www.oracle.com/xml -------------- next part -------------- An embedded message was scrubbed... From: Jeremy Pascual Subject: msxml parser question Date: 28 Jan 99 13:15:52 Size: 2719 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990129/907acbc9/attachment.eml From pvelikho at cs.ucsd.edu Fri Jan 29 00:31:35 1999 From: pvelikho at cs.ucsd.edu (Pavel Velikhov) Date: Mon Jun 7 17:08:11 2004 Subject: Will XML eat the web? References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> <36B0BA28.47849E39@prescod.net> <36B0CE96.4AAEDF97@cs.ucsd.edu> <36B0DCCA.29285B0@prescod.net> Message-ID: <36B0FB78.8F3E327D@cs.ucsd.edu> Paul Prescod wrote: > > Pavel Velikhov wrote: > > > > Paul Prescod wrote: > > > > > > You need to store data that is efficiently maintained relationally. You > > > need to *transmit* XML. Why not use a relational database and create XML > > > when you need it. > > > > Transmitting XML in a textual representation is not always a good idea. > > I don't follow you. XML is, by definition, textual. I would like to view XML as a logical data model. I hope the actual storage model will be transparent in the future. I.e. the next generation xml "parser" that implements a DOM interface should be able to talk to an xml source that physically is say an OODB and fetch small pieces of the document as they are requested by the application. > > When the user does the 'select *' query on an XML database, sending him > > a 20 megabyte XML file that he will need to parse, apply an xsl > > stylesheet > > to and display in the browser is not the best solution. IMHO, the result > > of the query should be shipped on demand, when the user is actually > > 'looking' > > at a piece of an XML file. > > I don't think I said anything to contradict this, though I would say that > by the time you have a "20 megabyte XML file" you've probably already done > something wrong. There is almost never a good reason to generate files > that large. I agree, generating 20Mb XML files is bad. However it will happen. If you make a lot of data available in XML by wrapping a relational database for instance users/applications will be able to request large XML files. Pavel Velikhov xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Jan 29 01:10:45 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:11 2004 Subject: Will XML eat the web? References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> <36B0BA28.47849E39@prescod.net> <36B0CE96.4AAEDF97@cs.ucsd.edu> <36B0DCCA.29285B0@prescod.net> <36B0FB78.8F3E327D@cs.ucsd.edu> Message-ID: <36B109C7.1D7BE70C@infinet.com> Pavel Velikhov wrote: > Paul Prescod wrote: > > > > Pavel Velikhov wrote: > > > > > > Paul Prescod wrote: > > > > > > > > You need to store data that is efficiently maintained relationally. You > > > > need to *transmit* XML. Why not use a relational database and create XML > > > > when you need it. > > > > > > Transmitting XML in a textual representation is not always a good idea. > > > > I don't follow you. XML is, by definition, textual. > > I would like to view XML as a logical data model. I hope the actual > storage model > will be transparent in the future. I.e. the next generation xml "parser" > that > implements a DOM interface should be able to talk to an xml source that > physically > is say an OODB and fetch small pieces of the document as they are > requested by > the application. This gets down to the whole argument of what should XML be _primarily_ used for? The great majority of enterprise/e-commerce applications seem to want to use XML merely as an object protocol for use in returning query data and passing transactions. The internet crowd wants to use XML for presentation content. I personally agree with you here that the XML spec is merely a standard serialization format for XML Documents. In fact you could argue that XML is just a standard serialization format for any sort of tree based data structure that has become familiar because of its almost identical syntax to HTML. If XML did not have such a familiar syntax, I doubt XML would have the level of interest it commands today. > > > When the user does the 'select *' query on an XML database, sending him > > > a 20 megabyte XML file that he will need to parse, apply an xsl > > > stylesheet > > > to and display in the browser is not the best solution. IMHO, the result > > > of the query should be shipped on demand, when the user is actually > > > 'looking' > > > at a piece of an XML file. > > > > I don't think I said anything to contradict this, though I would say that > > by the time you have a "20 megabyte XML file" you've probably already done > > something wrong. There is almost never a good reason to generate files > > that large. > > I agree, generating 20Mb XML files is bad. However it will happen. If > you make > a lot of data available in XML by wrapping a relational database for > instance > users/applications will be able to request large XML files. Yes it may happen for reasons we cannot predict. But I think the real problem here is that the DOM itself is just a tree based structure in and of itself. Databases rarely only model data that can be expressed in a tree, but rather model data that is a set of complex graphs which XML and the DOM is not geared towards (minus creative uses of XPointer). Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amd0978 at acf3.nyu.edu Fri Jan 29 01:41:12 1999 From: amd0978 at acf3.nyu.edu (Adam M Donahue) Date: Mon Jun 7 17:08:11 2004 Subject: Will XML eat the web? In-Reply-To: <36B109C7.1D7BE70C@infinet.com> Message-ID: > This gets down to the whole argument of what should XML be _primarily_ used for? > The great majority of enterprise/e-commerce applications seem to want to use XML > merely as an object protocol for use in returning query data and passing > transactions. The internet crowd wants to use XML for presentation content. I think there's a third use for XML as an RPC format. (See XML-RPC, for example.) But as to the Internet crowd wanting to use XML for presentation content, I'm not sure what you mean. Isn't XML's goal in part to separate the presentation from the data. It's HTML that's given us so many browser incompatibility problems today as it is. Certainly XML+XSL (or CSS, or whatever) could be the best of both worlds, but I don't think many Web designers want XML merely for its presentation's sake. A standardized HTML, perhaps, but XML should be more than that, and I think even the most free-wheeling HTML "hacker" can see the benefits of XML beyond merely standardizing presentation. > Yes it may happen for reasons we cannot predict. But I think the real problem > here is that the DOM itself is just a tree based structure in and of itself. > Databases rarely only model data that can be expressed in a tree, but rather model > data that is a set of complex graphs which XML and the DOM is not geared towards > (minus creative uses of XPointer). Is there any work in this area? Actually, is there work toward an XML extension that would more tightly couple it with the graphs you suggest? Adam xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 29 01:51:50 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:11 2004 Subject: Will XML eat the web? In-Reply-To: <36B0FB78.8F3E327D@cs.ucsd.edu> References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> <36B0BA28.47849E39@prescod.net> <36B0CE96.4AAEDF97@cs.ucsd.edu> <36B0DCCA.29285B0@prescod.net> <36B0FB78.8F3E327D@cs.ucsd.edu> Message-ID: <14001.4925.767057.108162@localhost.localdomain> Pavel Velikhov writes: > I agree, generating 20Mb XML files is bad. However it will > happen. If you make a lot of data available in XML by wrapping a > relational database for instance users/applications will be able to > request large XML files. In general, this is probably the wrong place for XML -- it fits much more nicely in the object layer than in the raw data layer of a multi-tier application. Of course, XML can be very useful in the raw data layer for database import/export and persistence, but that generally will be done directly on the server rather than through a web client. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Fri Jan 29 02:24:34 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:08:11 2004 Subject: Why SAX needs namespace support References: <3.0.32.19990126090707.00b46c10@pop.intergate.bc.ca> <36AFB42B.1876@hiwaay.net> <13999.49959.505725.502168@localhost.localdomain> Message-ID: <36B11B3A.23ED@hiwaay.net> David Megginson wrote: > > len bullard writes: > > > > > Here are some, off the top of my head: > > 1. Need to work outside of a closed system. > 2. Need to work across different hardware and software platforms. > 3. Need to capture and save information snapshots. > 4. Need to pass hierarchical information among components. > 5. Need to have control over granularity of information. > 6. Need to use information for different purposes. > 7. Need to develop a single hub format for conversion. > 8. Need to generate and test data easily (look how clear-text > protocols like SMTP and HTTP won the world). > 9. Want that cool web buzz. Cool. A few more which are variations but important particularly where you find all or most of them in one or a family of applications: 1. Data needs an archival form that survives obsolescence (eg, health care, public safety). 2. Data exists in a pipeline that moves up and between multiple organizations (eg, health care, public safety). 3. Data exists in a pipeline where the rate of accrual/population is high (eg, health care, public safety). 4. Data is created in a process that expands in scope and aggregates by unanticipated discovery of new relationships (eg. health care, public safety). After two decades of SGML, I am still astounded by how little information owners know or understand about the effects of the processes by which they create, maintain and disseminate information, and how much they pay others to know that for them. >From top to bottom of the US Government, for example, they still buy relational data by the ream and can't figure out why validatible deliveries cost so freaking much, or why the vendor charges so much for data conversion, they decline to purchase the service (which is PRECISELY the vendor's point). Only an idiot signs up for this kind of task knowing that there aren't any enforceable data standards and what awaits them is an ASCII-delimited dump of partially matching fields and datatypes. Even at high consulting rates, it is a loser. I was sitting in a West Coast manager's office of Unisys a few years ago discussing WHY one might want a true SGML-aware browser (BeforeXML). The counter argument of the day was "HTML does it all and MS will provide anything we need". When I presented the argument that validatible object properties minus behaviors was an attainable goal, he stopped in mid sentence and said; "Damm. We've tried for years to make money off of object-oriented stuff and lost our shirts. You say this works better than objects or relational dbs?" "No," I said. "It simply doesn't care which one you use, who sells it to you, or if they go out of business or want you to." That he bought. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Jan 29 02:50:54 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:11 2004 Subject: Will XML eat the web? References: Message-ID: <36B12103.B2ED8312@infinet.com> Adam M Donahue wrote: > > This gets down to the whole argument of what should XML be _primarily_ used for? > > The great majority of enterprise/e-commerce applications seem to want to use XML > > merely as an object protocol for use in returning query data and passing > > transactions. The internet crowd wants to use XML for presentation content. > > I think there's a third use for XML as an RPC format. (See XML-RPC, for > example.) But as to the Internet crowd wanting to use XML for > presentation content, I'm not sure what you mean. Isn't XML's goal in > part to separate the presentation from the data. It's HTML that's given > us so many browser incompatibility problems today as it is. Certainly > XML+XSL (or CSS, or whatever) could be the best of both worlds, but I This was in general what I was referring to. > don't think many Web designers want XML merely for its presentation's > sake. A standardized HTML, perhaps, but XML should be more than that, and > I think even the most free-wheeling HTML "hacker" can see the benefits of > XML beyond merely standardizing presentation. Well, you can define XML to be any presentation format you like. Whether you transform an XML document to another document format via XSL is not the issue. The idea here is that XML is used as a document format (such as HTML). > > Yes it may happen for reasons we cannot predict. But I think the real problem > > here is that the DOM itself is just a tree based structure in and of itself. > > Databases rarely only model data that can be expressed in a tree, but rather model > > data that is a set of complex graphs which XML and the DOM is not geared towards > > (minus creative uses of XPointer). > > Is there any work in this area? Actually, is there work toward an XML > extension that would more tightly couple it with the graphs you suggest? Not that I am aware of. As I said you could creatively use XPointer to get the desired results. After all the world wide web itself could be considered a giant graph of documents in and of themselves. With respect to using XML as an alternative serialization format for Java, the big limitation here is that things really break down whenever you try and externalize Java objects that are not structured in tree form. Solving this problem is not impossible, but it certainly is difficult. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jp at ncfocus.com Fri Jan 29 02:54:16 1999 From: jp at ncfocus.com (JP Morgenthal) Date: Mon Jun 7 17:08:11 2004 Subject: Distributed DOM Message-ID: <006901be4b32$84c7fee0$120000c7@Grouper> I have an entire chapter in my book "Manager's Guide to Distributed Environments" that discuss the options of building a SDO (Shared Document Object) this allows multiple users to access the same DOM tree as a remote entity. The best way to implement this today would be as an Enterprise Java Bean that has an EJBHome object that is effectively the remote version of a Node. JP ------------------------------------------------------------------ JP Morgenthal President & Dir. Resesearch NC.Focus jp@ncfocus.com (516) 792-0997 F:(516) 792-0996 www.ncfocus.com ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990129/0b98dc59/attachment.htm From jp at ncfocus.com Fri Jan 29 03:08:36 1999 From: jp at ncfocus.com (JP Morgenthal) Date: Mon Jun 7 17:08:11 2004 Subject: '99 Message-ID: <00a501be4b34$8d93aa40$120000c7@Grouper> ATTENTION: This message is for parties interested in attending an XML seminar focused on using XML for business solutions. XMLU.com will be presenting '99 West on February 8-10 in Santa Clara, California co-sponsored by Microsoft. This conference will be co-chaired by myself and Brian Travis of XMLU.com. The Web site for the conference is www.tag99.com and has information regarding sessions and registration. In additon to seminar sessions, there will be a number of half-day tutorials held on Monday, Feb 8. Additional Information: Santa Clara Convention Center 5001 Great America Parkway Santa Clara CA 95054 +1-408-748-7000 Regards, JP ------------------------------------------------------------------ JP Morgenthal President & Dir. Resesearch NC.Focus jp@ncfocus.com (516) 792-0997 F:(516) 792-0996 www.ncfocus.com ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990129/649fe87f/attachment.htm From GDAustin at aol.com Fri Jan 29 03:21:25 1999 From: GDAustin at aol.com (GDAustin@aol.com) Date: Mon Jun 7 17:08:11 2004 Subject: unsubscribe xml-dev Message-ID: <6d139785.36b1287e@aol.com> unsubscribe xml-dev gdaustin@aol.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri Jan 29 08:52:27 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:11 2004 Subject: Will XML eat the web? Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136ACB@eukbant101.ericsson.se> > -----Original Message----- > From: Paul Prescod [SMTP:paul@prescod.net] > > "Matthew Sergeant (EML)" wrote: > > > > You > > can use a persistent parsed structure like a DOM maintained in memory, > but > > for some applications such as a rapidly changing XML database this isn't > > always feasible (or is it?). > > You could continually update the DOMs based on changes in the XML. What > exactly are your concerns about this architecture. > Not everyone (ourselves included) uses DOM. We started that way but found it too resource intensive (large amounts of both processing and memory). We switched to a simple expat parser and built our own query language based on XQL paths. This gave a huge speed up and drop in resource usages, but I still have concerns. > > Currently our web based XML system processes > > about 5 files per second (very subjective figures) - and it's at max CPU > > (it's only a Pii266). This is using expat. Not a good situation since I > > could probably build a much faster application using an RDBMS - but I'm > > looking to the future when I can send the raw XML to the client. > > You need to store data that is efficiently maintained relationally. You > need to *transmit* XML. Why not use a relational database and create XML > when you need it. > That's not always the best (or possible) solution either. For example we may ultimately allow people to edit the XML directly on the server. Also, what gain would we then get from transmitting XML? Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri Jan 29 13:41:27 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:11 2004 Subject: Will XML eat the web? Message-ID: <93CB64052F94D211BC5D0010A80013310EB2CB@WWMESS3> > From: Matthew Sergeant (EML) [mailto:Matthew.Sergeant@eml.ericsson.se] > > Server based XML processing > > XML processing is a > resource hog. There's not really much you can do about it. > Sure, you can use DCOM or Corba to distribute processing your XML across > several servers - that's throwing hardware at the problem - not always the best > solution. You can use a persistent parsed structure like a DOM maintained > in memory, but for some applications such as a rapidly changing XML database > this isn't always feasible (or is it?). Currently our web based XML > system processes about 5 files per second (very subjective figures)... How big are your XML files? My experience is that provided you split the data up into "page-sized chunks" and only parse the data the user wants to see, you can get much higher performance than this. Also, I've found that an XML-to-HTML conversion that works in a serial pass using a SAX parser (with SAXON, of course) is faster than anything that involves using a DOM or de-serialising Java objects, and is negligible compared with the cost of reading the XML from a relational database or interpreting an ASP script. But of course, what's true with 2Kb XML files may not be true with 200Kb. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dante at mstirling.gsfc.nasa.gov Fri Jan 29 13:44:41 1999 From: dante at mstirling.gsfc.nasa.gov (Dante Lee) Date: Mon Jun 7 17:08:11 2004 Subject: Textboxes and others Message-ID: Does anyone know how to input boxes and others into the xml document that IE 5.0 will parse? If so, can you tell me and send some examples. Thanks. Dante M. Lee Code 588 NASA/GSFC Greenbelt MD 20771 Voice = 301-521-1077 Bldg = 23 Rm = W415 Email = dante@mstirling.gsfc.nasa.gov dante4@hotmail.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 29 13:57:08 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:12 2004 Subject: Will XML eat the web? References: <5F052F2A01FBD11184F00008C7A4A80001136ACB@eukbant101.ericsson.se> Message-ID: <36B1BB43.6A15C4B5@prescod.net> "Matthew Sergeant (EML)" wrote: > > > You could continually update the DOMs based on changes in the XML. What > > exactly are your concerns about this architecture. > > > Not everyone (ourselves included) uses DOM. We started that way but > found it too resource intensive (large amounts of both processing and > memory). We switched to a simple expat parser and built our own query > language based on XQL paths. This gave a huge speed up and drop in resource > usages, but I still have concerns. I don't see how you can, in general, implement something like XQL without having random-access to the element tree. Anyhow, I don't care if you use the *DOM* in particular. It's a particular, poorly thought-out specification for the more general case of random-access tree structures. If you do need random access tree structures then you might as well store those structures persistently instead of regenerating them from source each time. Even if you only need stream-based access, there are much more efficient (time and space) encodings for a stream of XML text than XML itself. Of course if XML is the editable source then the encoded versions are merely optimized reflections, not definative archival source. > > You need to store data that is efficiently maintained relationally. You > > need to *transmit* XML. Why not use a relational database and create XML > > when you need it. > > > That's not always the best (or possible) solution either. I didn't claim it was. You cited a particular case where the data was naturally relational. I said: "then use a relational database." There is no universal architecture. You must choose the best one for your application. If the data is relational, store it in a relational database. > For > example we may ultimately allow people to edit the XML directly on the > server. If people want to edit it directly then the data is probably not naturally relational. Most people do not have a burning urge to load up a multi-megabyte file that looks like: in "vi" or "emacs." On the other hand, if the data looks like a document that people want to edit, then it probably is not efficiently stored or served by a relational database (unless you apply some tricky levels of object orientation on top). That's a different situation and requires a different architecture. > Also, what gain would we then get from transmitting XML? You said that you wanted to be ready when XML became available on the client. I pointed out that when the time comes it is trivial to generate that data from a relational database. If your problem today is generating HTML from a rows and columns dataset and your question today is "how does XML fit in" my answer would be: "it probably does not." XML is cool but it doesn't fit every system. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From keshlam at us.ibm.com Fri Jan 29 14:08:52 1999 From: keshlam at us.ibm.com (keshlam@us.ibm.com) Date: Mon Jun 7 17:08:12 2004 Subject: Compound Documents - necessary for success? Message-ID: <85256708.004D8A68.00@D51MTA03.pok.ibm.com> Just to state the alternative to a "document of documents": a meta-document structure can address many of the same needs, at some loss of locality-of-reference. Consider the direction that Xlink is taking, where in addition to documents being able to specify links to each other -- including links that essentially function as "import" or "include" requests -- it's possible to write a separate document that builds associations between two documents that are completely unaware of this higher-level structure. Hyperlinking and metadata aren't a 100% overlap with the document-of-documents concept; there obviously are times when you really do want all the information to be bundled together (for digital signature of the composite, perhaps, if it's to be treated as a single legal document). But this may be another case where the simple solution handles 90% of the problem for 10% of the effort. ______________________________________ Joe Kesselman / IBM Research Unless stated otherwise, all opinions are solely those of the author. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 29 14:12:39 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:12 2004 Subject: XML for Java serialization References: <36B12103.B2ED8312@infinet.com> Message-ID: <36B1BC5D.7D5055CC@prescod.net> Tyler Baker wrote: > > With respect to using XML as an alternative serialization format for Java, the big > limitation here is that things really break down whenever you try and externalize Java > objects that are not structured in tree form. Solving this problem is not impossible, > but it certainly is difficult. I don't think that this problem is particularly hard. Java has references, XML has ID references. You can easily model one with the other. The only probably is that Java objects serialized as documents are going to be . Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 29 14:17:13 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:12 2004 Subject: Will XML eat the web? References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> <36B0BA28.47849E39@prescod.net> <36B0CE96.4AAEDF97@cs.ucsd.edu> <36B0DCCA.29285B0@prescod.net> <36B0FB78.8F3E327D@cs.ucsd.edu> Message-ID: <36B1BE71.6EFBFF9@prescod.net> Pavel Velikhov wrote: > > I would like to view XML as a logical data model. I hope the actual > storage model > will be transparent in the future. I.e. the next generation xml "parser" > that > implements a DOM interface should be able to talk to an xml source that > physically > is say an OODB and fetch small pieces of the document as they are > requested by > the application. This isn't really "next generation" and it also isn't a "parser." Applications such as this have existed for many years. Examples include GroveMinder, Astoria, Texcel Information Manager, etc. These things aren't parsers because they don't parse anything. In ISO terminology they are "grove providers." In Web terminology they are persistent DOM implementations. > I agree, generating 20Mb XML files is bad. However it will happen. If > you make > a lot of data available in XML by wrapping a relational database for > instance > users/applications will be able to request large XML files. If you design your system correctly then you can just send the user a table of contents that *represents* the large data set, or a page of data at a time. This thread is confusing to me because people keep sliding back and forth between a) relational storage, b) human-created document archiving, c) human-requested query results, as if there were no architectural difference. But there is. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From keshlam at us.ibm.com Fri Jan 29 14:38:00 1999 From: keshlam at us.ibm.com (keshlam@us.ibm.com) Date: Mon Jun 7 17:08:12 2004 Subject: xml-dev Digest V1 #230 Message-ID: <85256708.005035BA.00@D51MTA03.pok.ibm.com> I would like to view XML as a logical data model. I hope the actual storage model will be transparent in the future. I.e. the next generation xml "parser" that implements a DOM interface should be able to talk to an xml source that physically is say an OODB and fetch small pieces of the document as they are requested by the application. I think you may be confusing "XML" and "document". The DOM API could certainly be used to wrapper documents originally expressed in formats other than XML, and I think everyone expects this to happen. That makes exporting and importing XML easier -- but it doesn't make the document XML, it just provides XML compatability. If you're using an XML parser, you're talking about XML syntax. If you want to generate a DOM (or a SAX stream) for some other format, you'll use a parser for that format. If you want to read the data from an OODB, you'll use an OODB query operation. That may return the data as XML (which you'll then put through a standard XML parser) or might return it directly as DOM or SAX. The XML world is interesting because it's generating a whole cluster of interrelated standards and conventions and tools based upon them. You don't have to use all of those together for them to be individually valuable. ______________________________________ Joe Kesselman / IBM Research Unless stated otherwise, all opinions are solely those of the author. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 29 14:47:32 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:12 2004 Subject: XML for Java serialization Message-ID: <000a01be4b95$9b2d4c40$c9a8a8c0@thing2> >> With respect to using XML as an alternative serialization format for Java, the big >> limitation here is that things really break down whenever you try and externalize Java >> objects that are not structured in tree form. Solving this problem is not impossible, >> but it certainly is difficult. > >I don't think that this problem is particularly hard. Java has references, >XML has ID references. You can easily model one with the other. > >The only probably is that Java objects serialized as documents are going >to be . Sometimes restrictions can lead to exciting results. Coins has evolved into the idea of using a DOM to hold an arbitrary set of beans, with a one-to-one relationship between DOM elements and application objects. This is a close cousin to serialization. The document is centric, the application objects representing one use of that document. Now the document is concise, but the internal representation is LARGE. The large size of that internal representation is one of the reasons for emphasizing MDSAX. It is lighter weight and should be used when possible instead of Coins. But its strength is also its weakness--it doesn't model the entire document. (Work on Coins will resume after the production release of MDSAX.) Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri Jan 29 14:50:17 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:12 2004 Subject: Will XML eat the web? Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> > -----Original Message----- > From: Paul Prescod [SMTP:paul@prescod.net] > > "Matthew Sergeant (EML)" wrote: > > > > > You need to store data that is efficiently maintained relationally. > You > > > need to *transmit* XML. Why not use a relational database and create > XML > > > when you need it. > > > > > That's not always the best (or possible) solution either. > > I didn't claim it was. You cited a particular case where the data was > naturally relational. I said: "then use a relational database." > > There is no universal architecture. You must choose the best one for your > application. If the data is relational, store it in a relational database. > Oh - that's a lesson that's learned in the first few days of application development. The issue wasn't that the data is strictly relational, it's just that my experience with relational databases makes me think this would be faster using an RDBMS. (or and OODBMS, or object serialization, or... you get the picture?) The point is - XML fits our problem domain perfectly well. It's just not fast when parsing directly. Ultimately we may have to turn the architecture on it's head - store in a database (relational or OO) and transmit XML to the client. If they want to edit the XML by hand, transmit some to them, and parse the results back into the database. This will be a disappointment to me, but not the end of the world. Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Jan 29 15:37:01 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:12 2004 Subject: XML for Java serialization References: <36B12103.B2ED8312@infinet.com> <36B1BC5D.7D5055CC@prescod.net> Message-ID: <36B1D438.626FB6F0@infinet.com> Paul Prescod wrote: > Tyler Baker wrote: > > > > With respect to using XML as an alternative serialization format for Java, the big > > limitation here is that things really break down whenever you try and externalize Java > > objects that are not structured in tree form. Solving this problem is not impossible, > > but it certainly is difficult. > > I don't think that this problem is particularly hard. Java has references, > XML has ID references. You can easily model one with the other. > > The only probably is that Java objects serialized as documents are going > to be . Well it is pretty simple to say IDs are the answer. They are indeed a possibility. Try coming up with an implementation which resolves circular references and can be rebuilt back into its original in-memory data structure. Implementation is not as simple as it sounds... Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 29 15:40:06 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:12 2004 Subject: Spitting out XML (was RE: Will XML eat the web?) In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> Message-ID: <14001.53248.140057.872484@localhost.localdomain> Matthew Sergeant (EML) writes: > The point is - XML fits our problem domain perfectly > well. It's just not fast when parsing directly. Ultimately we may > have to turn the architecture on it's head - store in a database > (relational or OO) and transmit XML to the client. If they want to > edit the XML by hand, transmit some to them, and parse the results > back into the database. This will be a disappointment to me, but > not the end of the world. Why would you be disappointed if you were following best practice? This is *exactly* the right way to use XML, at least in the data world. XML is designed to be an exchange format that allows different systems to talk to each other; it does not dictate how those systems should deal with the information internally. Or, in DB speak, an XML document will usually represent a view of a database rather than the database itself (unless you're doing a dump and restore or a long-term archival backup). Sometimes XML can represent the database itself if the database is very small (i.e. it would traditionally be stored as a flat ASCII file and batch-processed with Perl rather being stored in an RDBM): that's not really what sales wonks would call an enterprise-strength solution, but I (for example) use it for my own record-keeping. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Bckman at ix.netcom.com Fri Jan 29 15:46:55 1999 From: Bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:12 2004 Subject: Textboxes and others Message-ID: <003e01be4860$f1b9d2a0$13d6bacd@bckman> Does anyone know how to input boxes and others into the xml document that >IE 5.0 will parse Use the html namespace on the root element and prefix the input tag.eg To: W3C XML Developers Sent: Friday, January 29, 1999 9:28 AM Subject: Textboxes and others >Does anyone know how to input boxes and others into the xml document that >IE 5.0 will parse? If so, can you tell me and send some examples. >Thanks. > > > Dante M. Lee Code 588 > NASA/GSFC Greenbelt MD 20771 > Voice = 301-521-1077 Bldg = 23 Rm = W415 > Email = dante@mstirling.gsfc.nasa.gov > dante4@hotmail.com > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pqueirel at questel.fr Fri Jan 29 16:06:58 1999 From: pqueirel at questel.fr (Pascal Queirel) Date: Mon Jun 7 17:08:12 2004 Subject: No subject Message-ID: <41CAE980F0E4D111AC4F4000000040193D07FC@H019.questel.fr> well, i'm just started to work with XML, after reading the FAQ and a lot of documents, i would want to know, if IE 5 or another browser can parse XML and how i can visualize the result ? I must build an html page or put directly my .xml in the browser? thank you Pascal Queirel Questel Orbit Sophia Antipolis France pqueirel@questel.fr xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 29 16:11:03 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:12 2004 Subject: XML for Java serialization Message-ID: <001201be4ba1$574c7940$c9a8a8c0@thing2> >Well it is pretty simple to say IDs are the answer. They are indeed a possibility. Try >coming up with an implementation which resolves circular references and can be rebuilt back >into its original in-memory data structure. Implementation is not as simple as it sounds... Aren't we forgetting about KOMA??? http://www.inria.fr/koala/XML/serialization/ Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Jan 29 17:22:10 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:12 2004 Subject: Spitting out XML (was RE: Will XML eat the web?) Message-ID: <001b01be4bab$471e2000$c9a8a8c0@thing2> >Sometimes XML can represent the database itself if the database is >very small (i.e. it would traditionally be stored as a flat ASCII file >and batch-processed with Perl rather being stored in an RDBM): that's >not really what sales wonks would call an enterprise-strength >solution, but I (for example) use it for my own record-keeping. If the XML is broken into subtrees, might that then add to the scalability of this aproach? Think about b-trees for a bit. Couldn't we develop analogous algorithms for transparently managing the size of a fragment? Anyone interested in doing a native-XML database? This would be a great project for Open Source Software development! Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 29 17:26:55 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:12 2004 Subject: XML for Java serialization References: <36B12103.B2ED8312@infinet.com> <36B1BC5D.7D5055CC@prescod.net> <36B1D438.626FB6F0@infinet.com> Message-ID: <36B1EA09.25CC54D6@prescod.net> Tyler Baker wrote: > > Well it is pretty simple to say IDs are the answer. They are indeed a possibility. Try > coming up with an implementation which resolves circular references and can be rebuilt back > into its original in-memory data structure. Implementation is not as simple as it sounds... Circular references are no more or less tricky than in binary serialization. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From uche.ogbuji at fourthought.com Fri Jan 29 17:32:50 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:12 2004 Subject: Distributed DOM implementations In-Reply-To: Your message of "Wed, 27 Jan 1999 14:57:59 PST." <36AF99F7.EEC3079F@cs.ucsd.edu> Message-ID: <199901291734.KAA11909@malatesta.local> > I would like to find out if there are any known distributed > implementations of DOM (and free). What I mean by this is an ability to > access remote XML documents through a DOM interface but not by > downloading and parsing them locally. Instead I need a parser or > whatever (e.g. OODB wrapper) on the other end to give me result of the > DOM commands only. We distribute 4DOM (http://www.fourthought.com/opentech/projects/4DOM/), an open-source DOM implementation in Python with CORBA support. Its Makefile can configure 4DOM for two ORBs: one open-source (ILU) and one free for non-commercial use (Fnorb). If you run one of these on the server, you can connect to it with any other ORB using IIOP. We are planning direct support for more ORBs in future. If you're intersted, however, I suggest you wait until next week when 4DOM 0.7 will be released, with so many improvements as to be practically a re-write. We are writing a BBS/WebForum system with it, and it works very well so far in distributed context. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Jan 29 18:05:40 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:13 2004 Subject: XML for Java serialization References: <36B12103.B2ED8312@infinet.com> <36B1BC5D.7D5055CC@prescod.net> <36B1D438.626FB6F0@infinet.com> <36B1EA09.25CC54D6@prescod.net> Message-ID: <36B1F763.CA8DA267@infinet.com> Paul Prescod wrote: > Tyler Baker wrote: > > > > Well it is pretty simple to say IDs are the answer. They are indeed a possibility. Try > > coming up with an implementation which resolves circular references and can be rebuilt back > > into its original in-memory data structure. Implementation is not as simple as it sounds... > > Circular references are no more or less tricky than in binary > serialization. I guess we are arguing the definition of "simple" which is pretty pointless IMHO. Most decent programmers I think would have a problem implementing serialization in binary format, not to mention something like XML. I never said writing this kind of code was insurmountable, just that it is difficult and doing an efficient implementation is more difficult. If you look at the source code to the java.io.ObjectInputStream and java.io.ObjectOutputStream classes you will see that it looks pretty messy, which is probably because just getting things to work is hard enough as well as the likelihood that these folks were probably a lot more concerned about performance than elegance. On a related note, the KOML package I looked at a long time ago and I was not impressed. I just had a look see at KOML a few moments ago and found something much more impressive (JDK 1.2 I believe has made custom serialization a bit easier to implement now). It would be interesting if the Koala folks could release some numbers of KOML serialization vs. standard Java Object Serialization. Right now Java Object Serialization is better than in JDK 1.1, but it is still very heavyweight. Some open-standards XML Serialization approach would be a great alternative to Java's built in serialization, especially for my own current needs in a few apps I have been working on. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 29 18:13:11 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> Message-ID: <36B1F4D9.2B1EFA6@prescod.net> David Megginson wrote: > > Why would you be disappointed if you were following best practice? > This is *exactly* the right way to use XML, at least in the data > world. XML is designed to be an exchange format that allows different > systems to talk to each other; it does not dictate how those systems > should deal with the information internally. I've noticed a very unfortunate trend among my customers. They want to replace relational databases with XML. They want to replace purpose-built query languages with XSL. They want to replace object models and UML with DTDs and "XML Schemas". People are also talking about using the DOM as the interface to data of all sorts. This trend is very worrisome and will likely lead to a backlash against XML. I'm working in the opposite direction. I wonder: * Isn't OQL pretty close to an XML query language? * Aren't STEP and ODL pretty close to being XML object model schema languages? * Wouldn't it be nice to have more formal mechanisms for characterizing languages (like XQL, XPointer, URLs, JavaScript) that do NOT use angle-bracket syntax? Another worrisome trend is that people creating the XML standards would rather invent rather than learn about things that already exist. "NI@theW3C" syndrome? Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mail11.mitre.org Fri Jan 29 18:18:33 1999 From: costello at mail11.mitre.org (Roger L. Costello) Date: Mon Jun 7 17:08:13 2004 Subject: Compound Documents - necessary for success? Message-ID: <990129131754.1254@mail11.mitre.org.0> Marcus Carr wrote: >Sorry, maybe I didn't make myself clear - given the following DTD: > > > > > >]> > >If a user wants to create a compound document, they might do something like: > > > This is c > This is b > This is a > > This presupposes that (a) we know apriori what documents we want to nest within , and (b) what order the nested documents are to be in, etc. It assumes everything is static. I was thinking along the lines of a much more dynamic system in which a document is generated from assembling together data from a number of different data sources dynamically. For example, suppose that you have a number of different meteorological sensors that generate periodic, transient data. Each sensor transmits its data in accordance to its sensor.dtd. Each sensor has a different DTD. We would like to collect together data from some (or all) of the sensors and create a single (composite) document from this dynamic, transient data. So, here are the features that I see a composite XML document may have: (1) The sources of the data may be transient. The composite document itself may be transient. (2) The data is assembled "on the fly". Which data is selected, the order of the selected documents is entirely dynamic. (3) Each data source may conform to a different DTD (grammar). Consequences: (1) There can be no DTD for the composite document, unless it is dynamically created. > >> Is it not enough to verify that the fragments are valid and that the >> document as a whole is well-formed? > >No, you also want to respect the original intention of the DTD, unless a really >good reason exists not to. What does it buy you to validate the document as a whole when each piece (fragment) has been validated? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 29 18:46:48 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? In-Reply-To: <36B1F4D9.2B1EFA6@prescod.net> References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> Message-ID: <199901291845.NAA21477@hesketh.net> At 11:50 AM 1/29/99 -0600, Paul Prescod wrote: >I've noticed a very unfortunate trend among my customers. They want to >replace relational databases with XML. They want to replace purpose-built >query languages with XSL. They want to replace object models and UML with >DTDs and "XML Schemas". People are also talking about using the DOM as the >interface to data of all sorts. This trend is very worrisome and will >likely lead to a backlash against XML. I've noticed a very unfortunate trend among certain members of the XML community. Whenever someone proposes using XML in any way that goes beyond interchange and documents, they become very concerned that the system proposed won't work and that the sky will fall in on XML. They see backlash lurking in every corner, with hordes of journalists waiting for XML to collapse so they can proclaim it the next OS/2. (Apologies to any diehard OS/2 folks out there.) XML is many things to many people. It is simple enough and generic enough that if you try hard enough, you can stretch it to fit just about any problem in computing. It may not always be the optimal approach, but it fits many problems very well. XML is not just a file format any more, or an interchange format. XML describes a set of structures that are extremely generic, and which map very well to a wide variety of structures used in data processing. Some people look at an XML document and see the markup; others see the structures; others see a transformation of those structures, into program data, a program, or nicely formatted programs for an opera. XML has, in many ways, left behind its roots as a document format and become something else, a generic set of tools for manipulating information. Tools that work for XML will work on data across an enormous number of domains, and if those tools follow similarly generic standards, they may even work across implementations from an enormous number of vendors using very different technology. I don't feel that we've achieved nirvana, but for the first time we may actually have an opportunity to genuinely move toward interoperable computing without having to all be using the same languages and platforms, and that's a big step. Why does XML have an opportunity, when SGML had the same tools and more? Because it's simple enough for neophytes to walk up to and explore, and because processing it isn't very hard. Two good things that lower the cost of development significantly. >I'm working in the opposite direction. I wonder: > > * Isn't OQL pretty close to an XML query language? > > * Aren't STEP and ODL pretty close to being XML object model schema >languages? > > * Wouldn't it be nice to have more formal mechanisms for characterizing >languages (like XQL, XPointer, URLs, JavaScript) that do NOT use >angle-bracket syntax? You can wander back into the woods if you like, but don't expect everyone to follow you. Heading back to implementation-specific standards is necessary for some applications, but it isn't going to work across the board. Your last point about formal mechanisms is worth considering, though I'm not sure it's 'the opposite direction' at all. >Another worrisome trend is that people creating the XML standards would >rather invent rather than learn about things that already exist. >"NI@theW3C" syndrome? What, like XSL? Building a whole new formatting vocabulary when CSS already exists? I suppose. The W3C does have the key responsibility of building things _for the Web_, and if that happens to spill over into other fields, great. But I'd rather see the W3C invent something new that works on the Web than leave us with older tools that don't work well on the Web. I'd like to see the W3C open its process a lot more, but apart from that I don't have too many problems with their mandate. What's XML for? Anything you like. Build it, and see if people come. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Fri Jan 29 18:54:35 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? In-Reply-To: <199901291845.NAA21477@hesketh.net> References: <36B1F4D9.2B1EFA6@prescod.net> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> Message-ID: <3.0.6.32.19990129105746.00a0b9a0@scripting.com> >>it's simple enough for neophytes to walk up to and explore You gotta be kidding! Listen, go where you want, but to me, XML is an interchange format. I never signed on to W3C as the new platform vendor to end all platform vendors. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 29 19:13:09 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? In-Reply-To: <199901291845.NAA21477@hesketh.net> References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <36B1F4D9.2B1EFA6@prescod.net> <199901291845.NAA21477@hesketh.net> Message-ID: <14002.1409.406341.233078@localhost.localdomain> Simon St.Laurent writes: > XML is not just a file format any more, or an interchange format. > XML describes a set of structures that are extremely generic, and > which map very well to a wide variety of structures used in data > processing. Actually, strictly speaking, XML 1.0 *is* just a file format, or more accurately, a meta-format. As soon as an XML document is converted into SAX events or a DOM tree or SQL tables or persistent objects or anything else, it's not XML anymore (though it can, perhaps, be written back out as XML, depending on the application). The question that we're discussing is not whether the rich recursive and hierarchical structures that XML can model are useful (I know from eight years' experience that they are), but rather, whether XML itself -- that is, text files conforming to XML 1.0 -- should be used as the primary storage medium for large applications. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 29 19:16:45 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? In-Reply-To: <3.0.6.32.19990129105746.00a0b9a0@scripting.com> References: <199901291845.NAA21477@hesketh.net> <36B1F4D9.2B1EFA6@prescod.net> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> Message-ID: <199901291916.OAA22040@hesketh.net> At 10:57 AM 1/29/99 -0800, Dave Winer wrote: >>>it's simple enough for neophytes to walk up to and explore > >You gotta be kidding! I'm not kidding, not at all, though I can definitely understand why you'd think that. The < > syntax is familiar to anyone who's ever used HTML. Basic element and attribute structures aren't that hard to learn. Validation, as long as you stick to describing element and attribute structures, really isn't that hard either. The more subtle parts of XML are awfully damn hard, certainly - I think pretty much everyone is still learning. But the basic syntax, the material you really need to know to apply it to a very large core set of problems, isn't very hard. The standard certainly obfuscates it, but basic XML really isn't that complicated. 'XML in a Day' isn't an impossible dream by any means, as long as you start with the friendly part, not the complicated bits. And how many people really want to use the complicated bits anyway? There's a long learning curve ahead of users as far as best practices, but I don't think XML itself should be very scary. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 29 19:37:45 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? In-Reply-To: <14002.1409.406341.233078@localhost.localdomain> References: <199901291845.NAA21477@hesketh.net> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <36B1F4D9.2B1EFA6@prescod.net> <199901291845.NAA21477@hesketh.net> Message-ID: <199901291937.OAA22384@hesketh.net> At 02:11 PM 1/29/99 -0500, David Megginson wrote: >Simon St.Laurent writes: > > > XML is not just a file format any more, or an interchange format. > > XML describes a set of structures that are extremely generic, and > > which map very well to a wide variety of structures used in data > > processing. > >Actually, strictly speaking, XML 1.0 *is* just a file format, or more >accurately, a meta-format. As soon as an XML document is converted >into SAX events or a DOM tree or SQL tables or persistent objects or >anything else, it's not XML anymore (though it can, perhaps, be >written back out as XML, depending on the application). We're speaking past each other here, with David and a number of others trying to keep the XML genie in the file format bottle, while I'm saying XML, not strictly speaking, is a gateway to a lot of other possibilities. >The question that we're discussing is not whether the rich recursive >and hierarchical structures that XML can model are useful (I know from >eight years' experience that they are), but rather, whether XML itself >-- that is, text files conforming to XML 1.0 -- should be used as the >primary storage medium for large applications. That may be what you're hearing, but I think your assumption that XML is a simple file format - that XML documents must be stored in enormously long serial text files - is limiting your perspective too much. XML opens the doors to a lot of possibilities for more sophisticated storage (in object stores, for instance) than the simple crappy file systems we all know and hate. The problem isn't that XML files are inappropriate, but that the structures we've used in the past to store them aren't very flexible. Providing a reliable set of structures within a document, as XML does, opens the door to lots of new possibilities. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Fri Jan 29 19:53:24 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? In-Reply-To: <199901291937.OAA22384@hesketh.net> References: <14002.1409.406341.233078@localhost.localdomain> <199901291845.NAA21477@hesketh.net> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <36B1F4D9.2B1EFA6@prescod.net> <199901291845.NAA21477@hesketh.net> Message-ID: <3.0.6.32.19990129115703.009833a0@scripting.com> >>XML opens the doors to a lot of possibilities for more sophisticated storage (in object stores, for instance) than the simple crappy file systems we all know and hate. We have one of those object storage systems. I agree that it's far more powerful a way to program than storing data in individual files, and can do lots of things that would be very awkward or inefficient in an RDBMS (like hierarchic content management). However, no matter how much work we put into a procedural XML-based programming interface, it's still more efficient and easier to work with the data using the native programming interface. After a year of working with XML as a database storage environment, we now have gravitated to using it as an interchange format. It's just too inefficient to use it any other way. To do it procedurally would be just so we could say "we're cool because we do everything in XML." Coolness just isn't that important. BTW, I support Simon's effort to keep the whining grandmas at bay (with apologies to grandmas). The sky isn't falling. Don't worry be happy. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 29 20:28:33 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? In-Reply-To: <199901291937.OAA22384@hesketh.net> References: <199901291845.NAA21477@hesketh.net> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <36B1F4D9.2B1EFA6@prescod.net> <14002.1409.406341.233078@localhost.localdomain> <199901291937.OAA22384@hesketh.net> Message-ID: <14002.5293.597089.856281@localhost.localdomain> Simon St.Laurent writes: > >The question that we're discussing is not whether the rich > >recursive and hierarchical structures that XML can model are > >useful (I know from eight years' experience that they are), but > >rather, whether XML itself -- that is, text files conforming to > >XML 1.0 -- should be used as the primary storage medium for large > >applications. > > That may be what you're hearing, but I think your assumption that > XML is a simple file format - that XML documents must be stored in > enormously long serial text files - is limiting your perspective > too much. We're just mixing up terms. XML documents *are* serial text files -- that's all that they can be. As soon as you slurp them up into alternative storage, they're not XML documents any more. They're just as important, just as interesting, and just as useful, but they are no longer in a format defined by the XML 1.0 specification, so literally speaking, they're not XML. In general, few high-speed, large-scale applications can afford repeated passes through serial text files (or even random access through reverse indices), so using XML (in the literal sense) for primary storage is impractical; there are, of course, exceptions -- for example, small bits of XML can be stored as blobs in relational databases. Paul's point, however, is that what's exciting about XML is what's exciting about working with recursive, hierarchical data structures in general. When people talk about non-textual XML, that's usually what they're really talking about. Personally, I have a strong LISP background going back to 1987 and an SGML background going back to 1991. I share Simon's excitement very much -- the world is a fascinating place when we let our data break out of tables. Here, for example, is a simplified natural language parse tree as a LISP list (the kind of thing we were playing with 12 years ago): (sentence (noun-phrase (modifier "The") (modifier "old") (noun "man")) (verb-phrase (verb "sat") (adverb-phrase (preposition "on") (noun-phrase (modifier "the") (noun "bench"))))) The AI movement in the 1970's and 1980's lived and breathed this stuff. It's easy to see how XML can provide an excelling language- and system-independent representation of this structure, but the idea of modelling information this way does not originate with XML, any more than it originated with SGML or with LISP. What Simon is saying, I think, is that he likes working with this kind of information, and that he would like to refer to the general idea of recursive, hierarchical data as "XML". I suppose it's OK -- I still want to call it "LISP" sometimes, but I'm afraid that people will laugh. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From db at Eng.Sun.COM Fri Jan 29 20:32:14 1999 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:08:13 2004 Subject: SAX: Next Round (Lexical Event Handler) References: <199901202122.QAA00962@megginson.com> <36AA93F3.B98FAE05@jclark.com> Message-ID: <36B21948.5F74CEED@eng.sun.com> Glad to see this SAX discussion! James Clark wrote: > > david@megginson.com wrote: > > > public interface LexicalHandler > > { > > public void startDTD (String name, String pubid, String sysid) > > throws SAXException; > > public void endDTD (String name); > > public void startExternalEntity (String name, String pubid, String sysid) > > throws SAXException; > > public void endExternalEntity (String name) throws SAXException; > > public void startCDATA () throws SAXException; > > public void endCDATA () throws SAXException; > > public void comment (String data) throws SAXException; > > } > > > > I haven't checked, but I think that this gives us everything we need > > for DOM level one. Doesn't quite ... there's some more DTD information needed to: * ensure that PIs within the DTD (e.g. internal subset) don't show up anywhere in the DOM tree (ugh); * see declarations of external general entities; * expose values of defaults so that the DOM can ensure that defaulted attributes always have values; * distinguish attributes which were defaulted from those that were explicitly in the document. See "com.sun.xml.parser.AttributeListEx" and, in the same package, "DtdEventListener" for that additional info. (An upcoming version supports full recreation of the declaration, which a number of users have needed.) (In addition the above, if XML namespaces are to be layerable over a normal XML 1.0 parser, declarations of all other entities need to be exposed so they can be examined for conformance: they must not contain colons!) > I wonder whether LexicalHandler ought to extend DocumentHandler. The > events it reports are synchronous with the events reported by > DocumentHandler. It seems to me that applications are always going to > want to implement either DocumentHandler or both DocumentHandler and > LexicalHandler. That's my logic, and have done it for the extended DTD event reporting provided in Sun's parser (to support DOM and a few other features that folk have persuaded me are important). > I would prefer different callbacks for external general and external > parameter entities, or at least a parameter to say whether it's general > or external. This information can be inferred from start/endDTD, but > that's seems unnecessarily obtuse. I think users will be surprised to > find both general and parameter entities getting reporting by > start/endExternalEntity with no distinction. Actually, I would rather not expose parameter entities at all, but am certainly open to them being useful. I'd rather just see a single callback for the general entities, passing only the name (the ID info was provided already through the DTD handler, doesn't need repeating). > Doesn't the DOM allow access to internal entities as well? This would > be tough to support because internal entities can be referenced in > attribute values. What's the point of reporting just external entities? DOM allows but does not require this stuff (both internal and external). - Dave > What is the thinking behind giving endExternalEntity() a single name > argument (as opposed to, say, no arguments, three arguments, or a single > sysid argument)? Similarily for endDTD()? > > What's the point of the pubid and sysid arguments to startDTD()? This > information will be provided via the call to startExternalEntity() for > the reference to the external subset. > > James > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 29 20:35:12 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> Message-ID: <36B214B0.CAEA9D2B@prescod.net> "Simon St.Laurent" wrote: > > I've noticed a very unfortunate trend among certain members of the XML > community. Whenever someone proposes using XML in any way that goes beyond > interchange and documents, they become very concerned that the system > proposed won't work and that the sky will fall in on XML. Perhaps that's because we've seen many of these systems not work. > XML is many things to many people. It is simple enough and generic enough > that if you try hard enough, you can stretch it to fit just about any > problem in computing. That's exactly what I'm afraid of! You can also stretch a screwdriver into hammering nails, but that doesn't mean it is a good idea. > It may not always be the optimal approach, but it > fits many problems very well. I agree. XML is the perfect solution to many interchange and archiving problems. > ... > XML has, in > many ways, left behind its roots as a document format and become something > else, a generic set of tools for manipulating information. The problem is that when you add a level of "XML" to your system, you add complexity. Here are examples from my customers: * they could use STEP EXPRESS or ODL to model objects in a system. Instead they want to use DTDs. Now I have to figure out the mapping from elements to objects. They've added complexity and inefficiency to the system. They either have to serialize the objects to verify their conformance or build a "DOM" interface over the existing object model. Why bother? * they want to use XSL as their "object search" technology instead of OQL. Now they have to map their logical object searches into tree-searches, cross-pointer searches into hyperlink-traversing searches, and so forth. Once again, they've got an extra layer that they don't need. Now here's the sad thing: I choose to help them with these projects because I realize that the tools that they really need are not properly deployed, so they must use XML-centric technologies as a proxy. EXPRESS is not implemented in object databases (AFAIK!!!). There are no free OQL implementations (AFAIK!!!). Using XML as a proxy for robust object technologies is a hack, but it works. (serializing Java objects as XML elements makes perfect sense *if* you are going to do something with those objects that you couldn't otherwise do (i.e. load them into a C++ program). i.e. XML is GREAT at interchange. It is also very good for working with documents, where the XML representation is created by a human and "is" the object as far as the computer is concerned.) [OQL] http://www.jcc.com/sql_odmg_convergence.html ftp://ftp.omg.org/pub/docs/1995/95-01-01.ps [Express] http://www.steptools.com/projects/express-x/homepage.html (one problem with these languages is that their web-presence is not good) > Tools that work for XML will work on data across an enormous number of > domains, and if those tools follow similarly generic standards, they may > even work across implementations from an enormous number of vendors using > very different technology. I don't feel that we've achieved nirvana, but > for the first time we may actually have an opportunity to genuinely move > toward interoperable computing without having to all be using the same > languages and platforms, and that's a big step. I don't see how that paragraph applies uniquely to XML. I could say the same things about Unicode, Java, SQL or TCP/IP. They also *could* apply to STEP/Express and OQL if it weren't for the fact that the XML hype is obscuring their existence. > Why does XML have an opportunity, when SGML had the same tools and more? > Because it's simple enough for neophytes to walk up to and explore, and > because processing it isn't very hard. Two good things that lower the cost > of development significantly. What XML has is hype. The reason it has hype is because it comes from the W3C and it is easy enough to make a parser for it that programmers feel like they could do it "if they had to" even if a small minority choose to. Neophytes have been walking up to and exploring SGML since the first free parser became available a decade ago. > > * Isn't OQL pretty close to an XML query language? > > > > * Aren't STEP and ODL ... > > > > You can wander back into the woods if you like, but don't expect everyone > to follow you. Heading back to implementation-specific standards is > necessary for some applications, but it isn't going to work across the > board. In what sense is OQL more "implementation specific" than XSL or XQL? In what sense is ODL more "implementation specific" than DTDs or XSchema. You need an implementation of any of them, sure, but they can be implemented in any language just as XML or SQL can be. > > * Wouldn't it be nice to have more formal mechanisms for characterizing > >languages (like XQL, XPointer, URLs, JavaScript) that do NOT use > >angle-bracket syntax? > Your last point about formal mechanisms is worth considering, though I'm > not sure it's 'the opposite direction' at all. It's the "opposite direction" (in some sense) if it allows us to abandon angle brackets in favor of more human-friendly notations when they are more convenient. > ... > But I'd rather see the W3C invent something new that works > on the Web than leave us with older tools that don't work well on the Web. We don't know whether they work on the Web because nobody has ever tried to adapt them for the Web. We're reinventing things first and "asking questions" later. > ... > What's XML for? Anything you like. Build it, and see if people come. You can say that about anything. That doesn't mean that every tool is equally good for every job. It is possible to abuse XML just as you can abuse a screwdriver. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Jan 29 20:38:31 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? Message-ID: <3.0.32.19990129123647.00bba920@pop.intergate.bc.ca> At 03:27 PM 1/29/99 -0500, David Megginson wrote: >In general, few high-speed, large-scale applications can afford >repeated passes through serial text files (or even random access >through reverse indices), so using XML (in the literal sense) for >primary storage is impractical; there are, of course, exceptions -- >for example, small bits of XML can be stored as blobs in relational >databases. Well, I'm not sure. Perhaps it's just because my perceptions were formed by working on the 500-MB deeply recursive Oxford English Dictionary text; but I think that a high-performance repository that could accurately mimic the data structures observed in XML would very useful in many (not all, obviously) applications. I think I hear both Megginson and Winer expressing doubt on that front. I'm surprised. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Jan 29 20:46:32 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? References: <199901291845.NAA21477@hesketh.net> <36B1F4D9.2B1EFA6@prescod.net> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291916.OAA22040@hesketh.net> Message-ID: <36B21D20.F78B91B3@infinet.com> "Simon St.Laurent" wrote: > At 10:57 AM 1/29/99 -0800, Dave Winer wrote: > >>>it's simple enough for neophytes to walk up to and explore > > > >You gotta be kidding! > > I'm not kidding, not at all, though I can definitely understand why you'd > think that. > > The < > syntax is familiar to anyone who's ever used HTML. Basic element > and attribute structures aren't that hard to learn. Validation, as long as > you stick to describing element and attribute structures, really isn't that > hard either. > > The more subtle parts of XML are awfully damn hard, certainly - I think > pretty much everyone is still learning. But the basic syntax, the material > you really need to know to apply it to a very large core set of problems, > isn't very hard. > > The standard certainly obfuscates it, but basic XML really isn't that > complicated. 'XML in a Day' isn't an impossible dream by any means, as > long as you start with the friendly part, not the complicated bits. And > how many people really want to use the complicated bits anyway? > > There's a long learning curve ahead of users as far as best practices, but > I don't think XML itself should be very scary. I really wish that everybody had this sort of attitude in evangelizing XML, in fact I share this opinion deeply and would not be using XML in the first place if I did not feel that XML is "simple enough for neophytes to walk up to and explore". But then again, I am in the minority of programmers out there who think that computer related topics should be understandable by others than just the gods of computerdom so now I will crawl back into my little shell (-: Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jan 29 20:53:32 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:13 2004 Subject: What is XML for? In-Reply-To: <36B214B0.CAEA9D2B@prescod.net> References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> Message-ID: <199901292053.PAA23618@hesketh.net> At 02:06 PM 1/29/99 -0600, Paul Prescod wrote: >[...much grumbling about using screwdrivers as hammers...] > >> Why does XML have an opportunity, when SGML had the same tools and more? >> Because it's simple enough for neophytes to walk up to and explore, and >> because processing it isn't very hard. Two good things that lower the cost >> of development significantly. > >What XML has is hype. The reason it has hype is because it comes from the >W3C and it is easy enough to make a parser for it that programmers feel >like they could do it "if they had to" even if a small minority choose to. >Neophytes have been walking up to and exploring SGML since the first free >parser became available a decade ago. You can dismiss it as hype if you like, but I'd prefer to call it enthusiasm. I think we have an opportunity here to recover a lot of the neophytes who walked up to SGML and ran away screaming - I was one myself, once. Not only that, but we can bring in people who never explored SGML because of its reputed focus on documents. Java has hype as well. And I use Java all the time to do some very interesting things, many of which have to do with XML. Hype on top of hype? Works great for me. >> ... >> But I'd rather see the W3C invent something new that works >> on the Web than leave us with older tools that don't work well on the Web. > >We don't know whether they work on the Web because nobody has ever tried >to adapt them for the Web. We're reinventing things first and "asking >questions" later. Especially with XSL, it seems, though I know it's rude to say that. Remember that the W3C is about the Web, and not necessarily about whatever was happening before. If isn't appropriate, people will go elsewhere. If the older ways work better, people will use them. >> ... >> What's XML for? Anything you like. Build it, and see if people come. > >You can say that about anything. That doesn't mean that every tool is >equally good for every job. It is possible to abuse XML just as you can >abuse a screwdriver. Bartender - get me another screwdriver! I'm waiting to see if people will use my projects, and I might as well have a drink or two or three or four! Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dante at mstirling.gsfc.nasa.gov Fri Jan 29 21:00:57 1999 From: dante at mstirling.gsfc.nasa.gov (Dante Lee) Date: Mon Jun 7 17:08:14 2004 Subject: CML and the MML of XML Message-ID: Where can I find the CML (Chemical Mark-up Language) standard DTD or the MML (mathematical Mark-up language) standard? Dante M. Lee Code 588 NASA/GSFC Greenbelt MD 20771 Voice = 301-521-1077 Bldg = 23 Rm = W415 Email = dante@mstirling.gsfc.nasa.gov dante4@hotmail.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pvelikho at cs.ucsd.edu Fri Jan 29 21:20:30 1999 From: pvelikho at cs.ucsd.edu (Pavel Velikhov) Date: Mon Jun 7 17:08:14 2004 Subject: Will XML eat the web? References: <5F052F2A01FBD11184F00008C7A4A80001136ACB@eukbant101.ericsson.se> Message-ID: <36B22026.4BAE5A4@cs.ucsd.edu> Matthew Sergeant (EML) wrote: > > > -----Original Message----- > > From: Paul Prescod [SMTP:paul@prescod.net] > > > > "Matthew Sergeant (EML)" wrote: > > > > > > You > > > can use a persistent parsed structure like a DOM maintained in memory, > > but > > > for some applications such as a rapidly changing XML database this isn't > > > always feasible (or is it?). > > > > You could continually update the DOMs based on changes in the XML. What > > exactly are your concerns about this architecture. > > > Not everyone (ourselves included) uses DOM. We started that way but > found it too resource intensive (large amounts of both processing and > memory). We switched to a simple expat parser and built our own query > language based on XQL paths. This gave a huge speed up and drop in resource > usages, but I still have concerns. XQL has pretty serious limitations as compared to other XML query languages. If you want to build a query language comparable in power to OQL then DOM seems like a better alternative. Also DOM should not such a resource hog as it is now. Pavel Velikhov xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amd0978 at acf3.nyu.edu Fri Jan 29 21:27:11 1999 From: amd0978 at acf3.nyu.edu (Adam M Donahue) Date: Mon Jun 7 17:08:14 2004 Subject: namespace question In-Reply-To: <14002.1409.406341.233078@localhost.localdomain> Message-ID: If I have the following: Title Hello World The html:body is in the namespace http://namespaceplace.com/html2.dtd, correct? Adam xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amd0978 at acf3.nyu.edu Fri Jan 29 21:32:55 1999 From: amd0978 at acf3.nyu.edu (Adam M Donahue) Date: Mon Jun 7 17:08:14 2004 Subject: Namespaces doc. Message-ID: In the XML Namespaces specification, section 5.2: If the URI reference in a default namespace declaration is empty, then unprefixed elements in the scope of the declaration are not considered to be in any namespace. Then, a few lines below: The default namespace can be set to the empty string. This has the same effect, within the scope of the declaration, of there being no default namespace. Is not the second sentence redundant? I know this is a trivial point, but I'm used to specs being concise without much repeating information. I'm wondering if I'm missing some point of difference between these two sentences. Adam xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 29 21:35:38 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:14 2004 Subject: What is XML for? In-Reply-To: <3.0.32.19990129123647.00bba920@pop.intergate.bc.ca> References: <3.0.32.19990129123647.00bba920@pop.intergate.bc.ca> Message-ID: <14002.9850.394821.198027@localhost.localdomain> Tim Bray writes: > At 03:27 PM 1/29/99 -0500, David Megginson wrote: > >In general, few high-speed, large-scale applications can afford > >repeated passes through serial text files (or even random access > >through reverse indices), so using XML (in the literal sense) for > >primary storage is impractical; there are, of course, exceptions -- > >for example, small bits of XML can be stored as blobs in relational > >databases. > > Well, I'm not sure. Perhaps it's just because my perceptions were > formed by working on the 500-MB deeply recursive Oxford English > Dictionary text; but I think that a high-performance repository > that could accurately mimic the data structures observed in XML > would very useful in many (not all, obviously) applications. I > think I hear both Megginson and Winer expressing doubt on that > front. I'm surprised. -Tim No need for surprise; in fact, I agree with Tim: a high-performance repository would be a Very Good Thing. Either this thread or another, closely-related one started with a complaint that parsing an XML file over and over again for each request put too heavy a load on a server; there was then a suggestion that the XML could be precompiled into memory, or even stored in an RDBM, at which last point a participant expressed regret that it was no longer a pure XML solution. My point, and (I think) Paul's, is that XML defines an external representation for hierarchical information, not (except in very small systems) an internal representation, but that many people are now trying to use XML internally in inappropriate ways (such as parsing the same static file several times each second). My second point is that the problem of storing, searching, and retrieving hierarchical information long predates SGML and XML and is not XML-specific (though it can come in an XML flavour if desired). A high-performance, XML-aware repository would be a good thing, because it could round-trip generic XML without significant loss. So there. All the best, David p.s. I followed the OED work from Waterloo very closely in the late 1980's (Frank Tompa might remember me) while I was programming the search engine for the 30MB Dictionary of Old English corpus, an hour away in Toronto; I even went to the point of trying to write some of my own optimised Patricia-tree implementations using the OED's algorithm -- nice idea for static repositories, but very brittle otherwise. -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 29 21:40:03 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:14 2004 Subject: namespace question In-Reply-To: References: <14002.1409.406341.233078@localhost.localdomain> Message-ID: <14002.10687.945765.817274@localhost.localdomain> Adam M Donahue writes: > If I have the following: > > > > Title > > Hello World > > > > The html:body is in the namespace http://namespaceplace.com/html2.dtd, > correct? Correct. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Fri Jan 29 21:41:26 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:14 2004 Subject: Will XML eat the web? Message-ID: > Also DOM should not such a resource hog as it is > now. Not sure if we should be so hard on it! It is only a parser, and it's up to you what you do with it. For example, I could imagine a model where you have a number of instantiations of DOM as sort of caches. You then read and write data to a relational database, converting to and from nodes in the XML tree as required. Your searching and selection algorithms would have to retrieve from the database, not inside DOM - which is no way going to be optimised enough, anyway. Of course there's loads of ways you could implement this, but eventually someone will give us a nice black box, and away we go. In the meantime, give DOM a break! Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 e: Mark.Birbeck@iedigital.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amd0978 at acf3.nyu.edu Fri Jan 29 21:41:38 1999 From: amd0978 at acf3.nyu.edu (Adam M Donahue) Date: Mon Jun 7 17:08:14 2004 Subject: Another errata? Message-ID: 5.3 Uniqueness of Attributes "no tag may contain two attributes" Is "element" intended instead of tag? All right, this is picky. I'm just now reading the spec fully, is all. Another question. Default namespaces do not apply directly to attributes according to the specification. So if I have: then body is part of the http://namespaceplace.com/html.dtd namespace, but its attribute bgcolor is not? (bgcolor belongs to no namespace) Adam xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jan 29 21:48:59 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:14 2004 Subject: Another errata? References: Message-ID: <36B22DD3.D941E96B@locke.ccil.org> Adam M Donahue wrote: > "no tag may contain two attributes" > > Is "element" intended instead of tag? > > All right, this is picky. I'm just now reading the spec fully, is all. Either will do: given that end-tags cannot contain attributes, and that an element has exactly one start-tag (not true of SGML, BTW), an element contains two conflicting attributes iff its start-tag does. > Another question. Default namespaces do not apply directly to attributes > according to the specification. So if I have: > > > > > > > then body is part of the http://namespaceplace.com/html.dtd namespace, but > its attribute bgcolor is not? (bgcolor belongs to no namespace) No. An attribute not explicitly labeled with a prefix belongs to the same namespace as its element. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 29 21:58:41 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:14 2004 Subject: What is XML for? References: <3.0.32.19990129123647.00bba920@pop.intergate.bc.ca> Message-ID: <36B21EC6.1A54E0C1@prescod.net> Tim Bray wrote: > > Well, I'm not sure. Perhaps it's just because my perceptions were > formed by working on the 500-MB deeply recursive Oxford English > Dictionary text; but I think that a high-performance repository > that could accurately mimic the data structures observed in XML > would very useful in many (not all, obviously) applications. I > think I hear both Megginson and Winer expressing doubt on that > front. I'm surprised. -Tim I'm completely lost and that worries me. The data structures observed in XML are "annotated tree with second-class links." This can be used to model "annotated directed graph" and even just "annotated graph" if you pretend that the links are first-class. "Annotated graphs" are the basic structures used by object databases. So you seem to be saying that it would be really nice if there were high-performance object databases. That seems to me to be exactly what Dave and David are promoting. So who am I misunderstanding? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Jan 29 22:02:30 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:15 2004 Subject: Is XML for the peons or the gods? (was What is XML for?) References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> <36B214B0.CAEA9D2B@prescod.net> Message-ID: <36B22EF2.6143DF8E@infinet.com> This last thread is very interesting because it brings up an entire debate which if not resolved could really dilute the momentum XML has today and bring it to the state of technologies like CORBA. A few years ago I like many other people were suckered into thinking that CORBA was the greatest thing since sliced bread. It even got dumped into the JDK (bad, bad, bad decision by JavaSoft). All of the technology pundits were preaching that it could be used for just about everything, pretty much the same list of items that people are preaching XML to be used for. In the end I scrapped use of CORBA for use as a dumb messaging layer in an application I had (using CORBA in the first place wasn't one of the most intelligent decisions I have made in my programming life but I was told by all of these "experts" that is was super hihg-performance and all of this other great stuff). That is not to say CORBA is a bad technology, but I was using it for all of the wrong reasons. CORBA now for all intensive purposes is dead in terms of momentum and most people I know of have totally lost interest in it altogether. The main CORBA list I am subscribed to which used to see the volume this list receives gets one or two messages posted to it a month (a good sign in my books that things are not going well for a technology). I am a little bit smarter now and see the same things happening to XML that happened with CORBA. I like XML for its simplicity and I wish it was a lot simpler and had some so-called "features" removed. The fact that XML was made to be SGML compatible I don't think does the world any favors since most people are planning on using XML for things which are the farthest removed from SGML. I do think you could do wonderful complex things on top of XML if you keep the standard spec simple (namespaces are something that is really a contradiction to simplicity, especially since all of the people to date that are defending namespaces cannot explain how to use namespaces in simple English). Then there is the camp who thinks that adding garbage like "Namespaces to XML" and other complicated issues directly into the XML spec is necessary because the most complicated computer science issues cannot be solved without them. In the end, all of these additions make supporting XML more difficult and far less useful to the "masses". So it basically boils down to is XML for a few really complicated tasks that require "gods" to implement, or is XML for a large set of general tasks that even "peons" can implement. No developer including myself wants to spend a ton of time learning and doing things with a technology that is going to die because the leaders of that technology are not sensitive to the needs of the underlings who actually use it. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Jan 29 22:05:23 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:15 2004 Subject: Namespaces doc. Message-ID: <3.0.32.19990129135853.00ba54b0@pop.intergate.bc.ca> At 04:32 PM 1/29/99 -0500, Adam M Donahue wrote: >In the XML Namespaces specification, section 5.2: > > If the URI reference in a default namespace declaration is empty, > then unprefixed elements in the scope of the declaration are not > considered to be in any namespace. > >Then, a few lines below: > > The default namespace can be set to the empty string. This has > the same effect, within the scope of the declaration, of there > being no default namespace. > >Is not the second sentence redundant? Looks that way to me. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Jan 29 22:05:24 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:15 2004 Subject: Another errata? Message-ID: <3.0.32.19990129140138.00ba7210@pop.intergate.bc.ca> At 04:39 PM 1/29/99 -0500, Adam M Donahue wrote: >5.3 Uniqueness of Attributes > >"no tag may contain two attributes" > >Is "element" intended instead of tag? No, not at all. Tag is exactly what's meant. E.g., in then the "a" element arguably contains two foo:bar attributes; but the a element's start tag contains only one, so everything's OK. >Another question. Default namespaces do not apply directly to attributes >according to the specification. So if I have: > > > > > > >then body is part of the http://namespaceplace.com/html.dtd namespace, but >its attribute bgcolor is not? (bgcolor belongs to no namespace) That is correct. This is kind of like Euclid's 5th axiom; you get a consistent world-view either way, but this way on balance seems to cause fewer problems. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Jan 29 22:11:51 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:15 2004 Subject: Another errata? Message-ID: <3.0.32.19990129141044.00ba6140@pop.intergate.bc.ca> At 04:53 PM 1/29/99 -0500, John Cowan wrote: >> >> >> >> then body is part of the http://namespaceplace.com/html.dtd namespace, but >> its attribute bgcolor is not? (bgcolor belongs to no namespace) > >No. An attribute not explicitly labeled with a prefix belongs to the >same namespace as its element. No. Adam Donahue is correct on this one. The spec says explicitly, and then belabors the point with examples; defaults don't apply to attributes. The only attribute that has a namespace is one that has a prefix. Now clearly, an application processing an unprefixed attribute will know the namespace (if any) of the element to which it's attached, and may well use that information. For example, in an HTML processor may (& probably should) choose to process that href attribute in an HTML-ish way; BUT, the href attribute is not, in the formal terminology of the spec, in the html or any other namespace. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Jan 29 22:18:19 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:15 2004 Subject: What is XML for? Message-ID: <3.0.32.19990129141703.00b96260@pop.intergate.bc.ca> At 02:49 PM 1/29/99 -0600, Paul Prescod wrote: >The data structures observed in XML are "annotated tree with second-class >links." This can be used to model "annotated directed graph" and even just >"annotated graph" if you pretend that the links are first-class. >"Annotated graphs" are the basic structures used by object databases. So >you seem to be saying that it would be really nice if there were >high-performance object databases. I'm saying: I want a database that can do XML, by which I mean infinite levels of attributed nested sequenced constructs. You're saying: since this is the basic structure used by object databases, what you really want is an object database. Maybe. The hypothesis that object databases are a good basis for general-purpose high-performance XML repositories is one that's plausible on the face of it, but I have yet to see existence proof that it really truly works. I also know about other groups working hard building native XML repositories on a technology basis that has nothing to do with OODBMS, and their hypotheses look equally plausible to me. And I haven't seen their stuff proved in action either. What was really worrying me was what I thought was an assertion that a repository that directly models XML document structures on a large scale wasn't interesting; I think it is. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jan 29 22:27:27 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:08:15 2004 Subject: XML for Java serialization In-Reply-To: <36B1D438.626FB6F0@infinet.com> References: <36B12103.B2ED8312@infinet.com> <36B1BC5D.7D5055CC@prescod.net> <36B1D438.626FB6F0@infinet.com> Message-ID: * Tyler Baker | | Well it is pretty simple to say IDs are the answer. They are indeed | a possibility. Try coming up with an implementation which resolves | circular references and can be rebuilt back into its original | in-memory data structure. Implementation is not as simple as it | sounds... I did a pilot for my MSc thesis last fall and when I gave up trying to make Java serialization work with CORBA object structures (all the objects were in one JVM) I wrote my own XML-based serialization. It keeps track of circular references and all that and I did it in one day, so the implementation isn't all that difficult. The hard part is making the interface easily useable, which I didn't bother with, since I just wanted something for my pilot system. And, yes, it is verbose. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jan 29 22:31:07 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:08:15 2004 Subject: CML and the MML of XML In-Reply-To: References: Message-ID: * Dante Lee | | Where can I find the CML (Chemical Mark-up Language) standard DTD or | the MML (mathematical Mark-up language) standard? --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jan 29 22:46:33 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:08:15 2004 Subject: What is XML for? In-Reply-To: <199901292053.PAA23618@hesketh.net> References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> <199901292053.PAA23618@hesketh.net> Message-ID: * Simon St.Laurent | | You can dismiss it as hype if you like, but I'd prefer to call it | enthusiasm. I guess it starts out as enthusiasm and still is with most people on this list, but a lot of people get all excited about it without really knowing what it's really good for. This, IMHO, is when the hype sets in and we get effects like the ones Paul described. | Java has hype as well. And I use Java all the time to do some very | interesting things, many of which have to do with XML. Hype on top of | hype? Works great for me. Sure, but like Paul points out all this hype/enthusiasm makes users forget about a lot of other useful things. It seems that there's only room for one technology in the limelight at once, which is a pity. Sure, Java is much better than C++ for most projects, but what about Eiffel, Ada95 and Common Lisp? These three are in many respects far better than Java. What they're lacking is mainly hype (and in the case of Common Lisp: good implementations). | If the older ways work better, people will use them. This is the real problem: they won't, they'll be too busy running after the next silver bullet. I think if I could have one wish about the computer industry fulfilled it would be that we would suddenly have knowledgeable users. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 29 22:49:09 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:15 2004 Subject: Is XML for the peons or the gods? (was What is XML for?) In-Reply-To: <36B22EF2.6143DF8E@infinet.com> References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> <36B214B0.CAEA9D2B@prescod.net> <36B22EF2.6143DF8E@infinet.com> Message-ID: <14002.13658.695869.594216@localhost.localdomain> Tyler Baker writes: [on CORBA] > All of the technology pundits were preaching that it could be used > for just about everything, pretty much the same list of items that > people are preaching XML to be used for. In the end I scrapped use > of CORBA for use as a dumb messaging layer in an application I had > (using CORBA in the first place wasn't one of the most intelligent > decisions I have made in my programming life but I was told by all > of these "experts" that is was super hihg-performance and all of > this other great stuff). That is not to say CORBA is a bad > technology, but I was using it for all of the wrong reasons. This is a very good example of the "Golden Hammer" antipattern in software system design. CORBA showed (and still shows) great promise for solving a large set of problems, but CORBA specialists suddenly started to see *every* problem in terms of CORBA even when it wasn't the best fit. Let's not do this with XML (that's all we old grannies are asking). [snip] > CORBA now for all intensive purposes is dead in terms of momentum > and most people I know of have totally lost interest in it > altogether. Nah, CORBA's still alive in the enterprise (it's very successfully used by a customer of mine who happens to be in the Fortune 50, for example), and it's certainly showing more of a pulse than DCOM as far as I can tell. On the light-weight side, Gnu's Gnome desktop environment is heavily CORBA-based, using a tiny, fast ORB called "Orbit" (I'm running Gnome right now and it isn't causing any problems). CORBA's a nice idea, if a rather clunky implementation in the specs (not specifying the communication between the stubs and the ORB was a brain-dead choice, since compiled CORBA clients were, as a result, not binary-compatible across ORB vendors -- I heard they fixed that for Java). [snip] > So it basically boils down to is XML for a few really complicated > tasks that require "gods" to implement, or is XML for a large set > of general tasks that even "peons" can implement. Yes and yes. XML scales nicely, and I can do a lot of useful things with under 100 lines of Perl code (including keeping all of my company's books to meet the nasty reporting requirements of a Federally-incorporated Canadian company). It happens that we understand the simple stuff pretty well now, so we're starting to try to figure out how to do the hard stuff -- please don't take that as a slight against the simple stuff, which is really the backbone of XML (just as handwritten HTML pages and Perl-based CGIs are still the backbone of the Web). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jan 29 22:54:24 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:15 2004 Subject: What is XML for? In-Reply-To: <3.0.32.19990129141703.00b96260@pop.intergate.bc.ca> References: <3.0.32.19990129141703.00b96260@pop.intergate.bc.ca> Message-ID: <14002.14987.955916.770584@localhost.localdomain> Tim Bray writes: > What was really worrying me was what I thought was an assertion that > a repository that directly models XML document structures on a large > scale wasn't interesting; I think it is. -T. I think it is, too. That said, I wouldn't like such a repository to be too closely tied to XML syntax (though it could implement an XML look-and-feel on top). There's lots of tagged hierarchical information (LaTeX, RTF, NROFF, etc.) that doesn't happen to be XML but still shares many of its structural properties. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Fri Jan 29 23:06:30 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:15 2004 Subject: Is XML for the peons or the gods? (was What is XML for?) In-Reply-To: <14002.13658.695869.594216@localhost.localdomain> References: <36B22EF2.6143DF8E@infinet.com> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> <36B214B0.CAEA9D2B@prescod.net> <36B22EF2.6143DF8E@infinet.com> Message-ID: <3.0.5.32.19990129170804.009dbe40@amati.techno.com> At 05:46 PM 1/29/99 -0500, David Megginson wrote: > > And Paul's only a kid, for crying out loud, not a hagged out oldster like me and David. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Jan 29 23:57:34 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:15 2004 Subject: Is XML for the peons or the gods? (was What is XML for?) References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> <36B214B0.CAEA9D2B@prescod.net> <36B22EF2.6143DF8E@infinet.com> <14002.13658.695869.594216@localhost.localdomain> Message-ID: <36B24616.374995C9@prescod.net> David Megginson wrote: > > Beatles? Is that like a music group? Remember the heady days of the mid-80s when we revoloutionaries would posit that SGML was sophisticated enough to be the serialization format for all of the world's textual data? It occurs to me that compared both to those "early" days and to my modern-day Python mailing list, we take things much too seriously in XML-DEV. It's a good place to learn and contribute, for sure. But I think that the crowd that gathers around a victorious instead of conquering technology is necessarily less unified and communal. It is also a little bit discouraging that here and everywhere else the needs of document processing have been shoved together with the needs of Java object serialization and remote RPC. That's nobody's fault, but eventually we have to figure out how to get back to advancing the state of the art in document processing. (love those long NAMELENs) Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jan 30 00:08:44 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:15 2004 Subject: What is XML for? References: <3.0.32.19990129141703.00b96260@pop.intergate.bc.ca> Message-ID: <36B24BAE.D7046F1D@prescod.net> Tim Bray wrote: > > I'm saying: I want a database that can do XML, by which I mean infinite > levels of attributed nested sequenced constructs. Please don't stop there! Like many of our "tools vendors" you've forgotten about (or chosen not to support) links. My worry about non-OO technologies is that I wonder how they support links (and queries on links) and RDF (and queries on RDF models) and topic maps (and queries on topic relationships). I suppose you could represent all of these as relations in a relational database. I just hope that these "other groups" are planning to deal with these issues instead of pretending that XML documents don't have links (which is what most current vendors do). Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Ed at dega.com Sat Jan 30 00:34:59 1999 From: Ed at dega.com (Ed Howland) Date: Mon Jun 7 17:08:15 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? Message-ID: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> Look, being a relative newcomer to the group and XML in general I did appreciate this thread because it provided some insight into my current problem. Having hyped XML to management, I must now deliver a solution. Our first experiments were very positive. As far as proof of concept goes, its been proven. But what worries me is the long term performance objectives of our product. Since it is e-commerce, I think traffic will just increase rapidly over time. I still haven't figured out the best way to store our data in XML and do high-performance lookups on it. I don't even know if I should have one massive file or split it into logical groups of files and directories. Or store it in text BLOBs in an RDBMS or use some kind of OODBMS based scheme. There is even some talk here of XML-like structured repositories. I don't have the time or resources to investigate each particular strategy to find the closest fit to our problem. So by June I have to come up with a XML-based approach that fits our performance models by year's end. It seems I might have been a little naive. Perhaps storing the data in XML (or some part of it anyway) isn't the right way to go. Is XML best suited (for now) as only an interchange format? That would be too bad because all the strengths of XML match our data model to a tee. I am aware of others who have implemented XML based e-commerce solutions. I only know of one actual methodology that seems to work for one of them. They store the data in XML but use an RDBMS to index it to some level. Then they parse the final file (or files) and merge them into a resultant XML stream. This is then formatted with CSS (XSL presumably not yet ready for prime-time) for presentation. Until I can find a better solution, this is the short term fix I'm going for. Ed ed@dega.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Sat Jan 30 00:51:09 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:15 2004 Subject: Is XML for the peons or the gods? (was What is XML for?) References: <36B22EF2.6143DF8E@infinet.com> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> <36B214B0.CAEA9D2B@prescod.net> <36B22EF2.6143DF8E@infinet.com> <3.0.5.32.19990129170804.009dbe40@amati.techno.com> Message-ID: <36B25641.687E7B0F@infinet.com> "W. Eliot Kimber" wrote: > At 05:46 PM 1/29/99 -0500, David Megginson wrote: > > > > > > And Paul's only a kid, for crying out loud, not a hagged out oldster like > me and David. I don't know how old Paul is, but I would surmise he is at least 5-10 years older than I (just a guess). What does that make me (-: Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sat Jan 30 00:54:02 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:16 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) Message-ID: <3.0.5.32.19990129184928.00a9ac50@amati.techno.com> At 02:17 PM 1/29/99 -0800, Tim Bray wrote: >At 02:49 PM 1/29/99 -0600, Paul Prescod wrote: >>The data structures observed in XML are "annotated tree with second-class >>links." This can be used to model "annotated directed graph" and even just >>"annotated graph" if you pretend that the links are first-class. >>"Annotated graphs" are the basic structures used by object databases. So >>you seem to be saying that it would be really nice if there were >>high-performance object databases. [...] >What was really worrying me was what I thought was an assertion that >a repository that directly models XML document structures on a large >scale wasn't interesting; I think it is. -T. But aren't XML document structures just one instance of a more general class of data that is composed of lots of little fiddly bits organized into complex hierarchies and graphs? Other instances include vector graphics, descriptions of power plants, models of human enterprises, etc. Doesn't this suggest that rather than trying to use XML's abstract data model as a base for then modeling other kinds of data, that we should develop a more general data model, develop supporting technologies around it, and then apply that to XML? If the result can handle XML at scale, it should be able to handle the result. Thus, I agree with Tim, but probably for a different reason (notwithstanding that my main job is explicitly to help people handle documents, and not powerplants). In other words, there seems to be a bit of poor reasoning at work in a lot of quarters that goes like this [not that I'm accusing Tim of this--he just provided a convenient seque for the following rant]: 1. I have data that doesn't fit into a relational database 2. XML lets me represent this data using an easy-to-see and easy-to-create-and-use data format. 3. I can use "XML tools" to manage this data and it will be cheap and effective. Unfortunately, the jump from 2 to 3 is not justified. That's because at point 2 you are working in the *syntactic domain*. XML works very well for serializing complex data structures because its hierarchy provides rich organizational facilities and its robust definition helps ensure transmission fidelity. But, the XML data model, that is, the abstract model for the *serialization* is not the same as the abstract model of the data being serialized. That is, the representation is not the thing. Thus, when you move from the syntactic domain back to the abstract domain, the abstration you get is not the abstaction you started with--it's the abstraction of an XML document serialization of the abstraction you started with. There's another step you have to perform before you get back your original abstraction, which is to translate the serialization back into the original abstraction. For example, I start with the following abstact model (using EXPRESS syntax just because I happen to know it and it doesn't get out much, so why not--also I've been working on the XML serialization grammar for EXPRESS and EXPRESS-driven data, so it's fresh in my mind): TYPE gender ENUM; male; female; unknown; END_TYPE: ENTITY person SUBTYPE OF being; name : STRING; sex : gender; employer : OPTIONAL enterprise; END_ENTITY; ENTITY enterprise; name : STRING; address : STRING; END_ENTITY; Now I create some instance data (using lisp syntax to represent the in-memory abstractions): (person (oid 1) (name "Eliot") (sex male) (employer (oid-ref 2))) (enterprise (oid 2) (name "ISOGEN International Corp") (address "Dallas, TX") (derived::employs (oid-ref 1))) Here is one possible (of an infinite number of possible) XML serialization: business objects schema person name Eliot sex male employer i0001 enterprise name ISOGEN International Corp. address Dallas, TX If you now parse this document into an abstraction conforming to the DOM, SGML Property Set, or similar rational abstract data model for XML documents, you'll get something like this: (xml-document (prolog (pi xml version="1.0") (doctype-decl)) (document-element (gi data-serialization) (content (element (gi schema-ref) (content (literal "business objects schema"))) (element (gi data-instances) (content ...))))) You get the idea--clearly the in-memory abstraction of the document bears no direct relationship to the in-memory abstraction of the original data. Even if you do an early-bound abstraction where you take the element types as node types, you still get something that is not the abstraction: (xml-document (prolog (pi xml version="1.0") (doctype-decl)) (data-serialization (schema-ref (literal "business objects schema")) (data-instances (entity-instance (types "person") (attributes (attribute (attname "name") (attval "Eliot")) ....)))) You get the idea. Even in this early-bound form, the abstraction is still reflecting the structure of the serialization, not the original abstraction. To get the original abstraction back, I have to apply the reverse of the original serialization algorithm. I might do this literally or I might do it by providing a set of query functions over my document that does it (e.g., translates the query "select person where name is 'Eliot'" to a more complex XML-specific query defined in terms of the semantics and structure of the serialization structure). Either way, the mapping has to be defined and implemented. Whether doing it literally (that is, importing the database back into some "non-XML" repository) or doing it virtually on top of an "XML repository" is an implementation/optimization choice. Thus, even saying "XML means the data abstraction you get from XML syntax" isn't very helpful. Because the resulting abstraction isn't really what you want. However, the characteristics of the XML in-memory abstraction *as a class of data* are very much similar to the characteristics of other abstractions. For example, the abstract data objects that describe a power plant are very much like the abstract data objects that describe a document: - There are a lot of them (every pipe, valve, pump, joint, etc., represents at least one node, with many relationships to other nodes) - Each node has lots of properties (position, identifier, operating characteristics, geometry, status, age, etc.) - The nodes exist in both a hierarchy reflecting their physical structure (plant-unit-assembly-subassembly-part) and a graph representing their connected nature to other parts (valve one must be closed before valve two can be opened) - They are equally static and dynamic, that is, a large part of the data never changes, a large part of it is constantly changing. - I want to ask a lot of questions about the data and I can't predict what sort of questions I might want to ask - If something is wrong in the data, bad things may happen This suggests that the technology that can handle documents at large scale can also handle powerplants at large scale (or ships or airplanes or buildings or electronic components or enterprises or governments or ...). This, I think, leads to an excitement about XML and its application to managing large data stores because it provides an easy-to-understand entry into the problem space and an easy-to-get-started place to start stressing and testing the technology. This is all good, but we have to be careful not to lose sight of the fact that the goal shouldn't be to shoe-horn all complex structures into XML's abstract data model, it should be to develop data management technologies that will handle documents well, because if we do, they will also handle powerplants and airplanes well. And the reverse is true as well--if I have a database that can handle a powerplant or an aircraft, chances are it will handle documents at scale too. Near as I can tell from my work in the STEP world and in the document world, the technology to manage data of this sort at the scales we need simply doesn't yet exist. I don't know if this is a hardware problem or a science problem, but I suspect it's a bit of both. I suspect that the solution requires an entirely new way of thinking about storing little fiddly bits of data that is neither relational nor object nor object-relational, but is entirely else (or at least significantly enough else to be something different). Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Sat Jan 30 00:57:51 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:08:16 2004 Subject: What is XML for? In-Reply-To: <199901291916.OAA22040@hesketh.net> References: <3.0.6.32.19990129105746.00a0b9a0@scripting.com> <199901291845.NAA21477@hesketh.net> <36B1F4D9.2B1EFA6@prescod.net> <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> Message-ID: <3.0.1.32.19990129164729.02520470@mail.accessone.com> Hi; I would *really* like to know what are considered the more subtle parts of XML - seriously! Sincerely, Dave LeBlanc At 02:19 PM 1/29/99 -0500, Simon St.Laurent wrote: >The more subtle parts of XML are awfully damn hard, certainly >Simon St.Laurent >XML: A Primer / Building XML Applications (March) >Sharing Bandwidth / Cookies >http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Bckman at ix.netcom.com Sat Jan 30 00:58:08 1999 From: Bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:16 2004 Subject: What is XML for? Message-ID: <003901be48ad$bcc93e80$72e86dd1@bckman> >>but rather, whether XML itself -- that is, text files conforming to XML 1.0 -- should be used as the primary storage medium for large applications<< Perhaps not the primary storage medium, but certainly as the backup medium. Frank Frank Boumphrey Style and XML information http://www.hypermedic.com/style/index.htm Author: Professional Style Sheets for HTML and XML http:// www.wrox.com ----- Original Message ----- From: David Megginson To: XML Developers' List Sent: Friday, January 29, 1999 2:11 PM Subject: Re: What is XML for? >Simon St.Laurent writes: > > > XML is not just a file format any more, or an interchange format. > > XML describes a set of structures that are extremely generic, and > > which map very well to a wide variety of structures used in data > > processing. > >Actually, strictly speaking, XML 1.0 *is* just a file format, or more >accurately, a meta-format. As soon as an XML document is converted >into SAX events or a DOM tree or SQL tables or persistent objects or >anything else, it's not XML anymore (though it can, perhaps, be >written back out as XML, depending on the application). > >The question that we're discussing is not whether the rich recursive >and hierarchical structures that XML can model are useful (I know from >eight years' experience that they are), but rather, whether XML itself >-- that is, text files conforming to XML 1.0 -- should be used as the >primary storage medium for large applications. > > >All the best, > > >David > >-- >David Megginson david@megginson.com > http://www.megginson.com/ > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Bckman at ix.netcom.com Sat Jan 30 00:59:31 1999 From: Bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:16 2004 Subject: What is XML for? Message-ID: <003801be48ad$ba330340$72e86dd1@bckman> Paul Prescod wrote: >>I've noticed a very unfortunate trend among my customers. They want to replace relational databases with XML. They want to replace purpose-built query languages with XSL.<< What wouldn't I give for your customers. My customers eyes start to glaze over when I start talking about XML!! Frank Frank Boumphrey Style and XML information http://www.hypermedic.com/style/index.htm Author: Professional Style Sheets for HTML and XML http:// www.wrox.com ----- Original Message ----- From: Paul Prescod To: Sent: Friday, January 29, 1999 12:50 PM Subject: What is XML for? >David Megginson wrote: >> >> Why would you be disappointed if you were following best practice? >> This is *exactly* the right way to use XML, at least in the data >> world. XML is designed to be an exchange format that allows different >> systems to talk to each other; it does not dictate how those systems >> should deal with the information internally. > >I've noticed a very unfortunate trend among my customers. They want to >replace relational databases with XML. They want to replace purpose-built >query languages with XSL. They want to replace object models and UML with >DTDs and "XML Schemas". People are also talking about using the DOM as the >interface to data of all sorts. This trend is very worrisome and will >likely lead to a backlash against XML. > >I'm working in the opposite direction. I wonder: > > * Isn't OQL pretty close to an XML query language? > > * Aren't STEP and ODL pretty close to being XML object model schema >languages? > > * Wouldn't it be nice to have more formal mechanisms for characterizing >languages (like XQL, XPointer, URLs, JavaScript) that do NOT use >angle-bracket syntax? > >Another worrisome trend is that people creating the XML standards would >rather invent rather than learn about things that already exist. >"NI@theW3C" syndrome? > > Paul Prescod - ISOGEN Consulting Engineer speaking for only himself > http://itrc.uwaterloo.ca/~papresco > >Don't you know that the smart bombs are so clever, they only kill >bad people." > - http://www.boingo.com/lyrics/WarAgain.html > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Jan 30 01:07:39 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:16 2004 Subject: What is XML for? In-Reply-To: <003901be48ad$bcc93e80$72e86dd1@bckman> Message-ID: <3.0.6.32.19990129171016.00999470@scripting.com> >>Perhaps not the primary storage medium, but certainly as the backup medium. Exactly right. We have our content management system archive every change and every new message to a folder containing XML files as backup against a crash of the odb and to allow easy synchronization with other databases that understand XML. This is a totally appropriate use of XML. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sat Jan 30 06:58:50 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:16 2004 Subject: What is XML for? Message-ID: <009101be4c1e$36a3b1e0$5ef96d8c@NT.JELLIFFE.COM.AU> From: Paul Prescod Tim Bray wrote: >> >> I'm saying: I want a database that can do XML, by which I mean infinite >> levels of attributed nested sequenced constructs. > >Please don't stop there! Like many of our "tools vendors" you've forgotten >about (or chosen not to support) links. My worry about non-OO technologies >is that I wonder how they support links (and queries on links) and RDF >(and queries on RDF models) and topic maps (and queries on topic >relationships). I suppose you could represent all of these as relations in >a relational database. Databases are concerned with access and retrieval: these are issues of entity management. The keys of a record (i.e., an entity) are data attributes (i.e. attributes of entities, not attributes of elements, by definition). XML lacks data attributes but compensates somewhat by forcing entity structure to be synchronous with element structure, so element's attributes can serve as data attributes (e.g., at the root element of an entity.) Which is not to say that the value of a record's keys are always or even usually unrelated to the value of text or data in the element structure: the key can be considered some presentation form of data within the element structure. The more sophisticated the key-recognition or pattern matching on keys that the DBMS provides, the less the need for the key (data attribute) to differ from the key-source (element or attribute values). For small-scale uses of XML, the distinctions between element and entity, key and key-source, are not relevant: just a simple element structure sitting in a file will do. Indeed, one of the strengths of XML is that where there is a strong need for structured data but not for entity management, XML gives a file-system-based alternative to simple databases--look at what can be achieved by OmniMark, Perl, Balise, etc without ever resorting to databases! So the view about which entity management system to use (files, SCCS, RCS, a RDBMS, an OODBMS, a network-structure DBMS, etc) can come to judgements on the relationship between the data's entity structure and its element structure: their nature and the performance requirements of the particular project. For example, if the data is highly regular at the top levels, with free text down at the leaves, it might indicate that you should use a RDBMS with the added convention that all text fields are XML (with fields used as keys constrained to be #PCDATA, perhaps normalized.) On the other hand, if the text is free all the way up and down, and you are not interested in searching or sorting the data, and you need to support multiple versions of documents, you might convert all your elements into entities: helloworld becomes ]> &a1; where the particular values of the entities a1 and b1 are generated by the DBMS (i.e., based on session criteria, such as the version of the document being sought. Entity management is therefore a back-end question. DOM, which lets you access by the element structure, is primarily a middleware or front-end system. For tightly coupled server systems in which the entity structure directly represents the element structure, there is no reason why data has to go DBMS->XML->DOM, it can go DBMS->DOM directly, since DOM is an interface definition. The reason for having a back-end/front-end distinction is that it gives a way to distribute processing, especially into 3-tier architectures: the server is DBMS, the middleware is the XML/DOM, the client is the user interface. The punter is not aware of the entity management system or the element structures. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Sat Jan 30 11:31:11 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:16 2004 Subject: Is XML for the peons or the gods? (was What is XML for?) Message-ID: <01BE4C4B.85B32180@grappa.ito.tu-darmstadt.de> David Megginson wrote: > Good grief. What does that make me? I was in kindergarten when the Beatles *formed*. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Sat Jan 30 11:46:35 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:16 2004 Subject: What is XML for? Message-ID: <01BE4C4D.AD3D48A0@grappa.ito.tu-darmstadt.de> Dave LeBlanc wrote: > I would *really* like to know what are considered the more subtle parts of > XML - seriously! Entities. Not the simple include-this-file or substitute-this-text-kind, but the I'm-going-to-exploit-every-possibility-and-combination-I-can-find kind. In other words, anything where you need to read section 4.4 to figure it out. Subtle, devious, frustrating. Pick the pejorative of your choice. -- Ron xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Jan 30 11:56:54 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:16 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? In-Reply-To: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> References: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> Message-ID: <14002.61730.116185.859085@localhost.localdomain> Ed Howland writes: > But what worries me is the long term performance objectives of our > product. Since it is e-commerce, I think traffic will just > increase rapidly over time. I still haven't figured out the best > way to store our data in XML and do high-performance lookups on > it. I don't even know if I should have one massive file or split it > into logical groups of files and directories. Or store it in text > BLOBs in an RDBMS or use some kind of OODBMS based scheme. There > is even some talk here of XML-like structured repositories. Here's a freebie for you: e-commerce data is generally structured in such a way that it's straight-forward to map it to relational database tables (about the level of difficulty of mapping a typical object model to relational database tables); in particular, truly mixed content (elements and text at the same level) is rare for e-commerce, except perhaps in product-description blurbs. Implementing a tree in a relational DB is annoying, but not excessively difficult; implementing a full XML model in a relational DB is painful. What we need the XML-like structured repositories for is document-like information, like technical manuals, news stories, literature, scientific papers, and other stuff that does *not* have a straight-forward mapping to relational DB tables. No one has a good, scalable solution for this now. In other words, concentrate on your XML exchange formats and use an RDBMS on the backend (or, perhaps, an OODB if your traffic isn't too high). If there ever is an XML repository with such good performance that you want to throw out Oracle or Sybase, then you can redo the backend without causing incompatibilities the frontend. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Jan 30 11:59:25 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:16 2004 Subject: What is XML for? In-Reply-To: <003901be48ad$bcc93e80$72e86dd1@bckman> References: <003901be48ad$bcc93e80$72e86dd1@bckman> Message-ID: <14002.62295.399407.627985@localhost.localdomain> Frank Boumphrey writes: > >>but rather, whether XML itself > -- that is, text files conforming to XML 1.0 -- should be used as the > primary storage medium for large applications<< > > Perhaps not the primary storage medium, but certainly as the backup medium. Exactly -- XML is ideal as a backup medium because it is software- and system-independent. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Jan 30 14:43:55 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:16 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? In-Reply-To: <14002.61730.116185.859085@localhost.localdomain> References: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> Message-ID: <3.0.6.32.19990130064745.013e0620@scripting.com> >>What we need the XML-like structured repositories for is document-like information, like technical manuals, news stories, literature, scientific papers, and other stuff that does *not* have a straight-forward mapping to relational DB tables. No one has a good, scalable solution for this now. We already have this. I hate it when people say things like "No one has a good, scalable solution for this now." We do. Are you supposed to be an expert on this stuff or do you just like to hear yourself talk? http://www.scripting.com/frontier5/xml/code/odb.html You don't even have to pay $0.02 to try it: http://www.userland.com/frontier/trial.html Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Sat Jan 30 15:45:32 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:16 2004 Subject: Another errata? References: <3.0.32.19990129141044.00ba6140@pop.intergate.bc.ca> Message-ID: <36B32A34.1343D6B2@mecomnet.de> Tim Bray wrote: > > No. Adam Donahue is correct on this one. The spec says explicitly, > and then belabors the point with examples; defaults don't apply to > attributes. The only attribute that has a namespace is one that > has a prefix. > ... > Now clearly, an application processing an unprefixed attribute will > know the namespace (if any) of the element to which it's attached, > and may well use that information. For example, in > > > > an HTML processor may (& probably should) choose to process that href > attribute in an HTML-ish way; BUT, the href attribute is not, in the > formal terminology of the spec, in the html or any other namespace. -T. ? If this is true, then what is the "Per-Element-Type Partition" described at great length on the appendix on the "internal structure" of xml namespaces? The spec would appear to assert some form of relation between the namespace which comprises an unqualified attribute name and the namespace of the element identifier. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jan 30 16:22:23 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:16 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? References: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> Message-ID: <36B32EA4.DBA7CB2D@prescod.net> Dave Winer wrote: > > We already have this. I hate it when people say things like "No one has a > good, > scalable solution for this now." We do. Are you supposed to be an expert on > this stuff or do you just like to hear yourself talk? Before I waste (er invest) my time, let's be clear. How high does this solution scale? My customers have XML data on various scales: 50MB, 500 MB, 4GB and 4 terabytes. To which customers should I promote the Frontier database? Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jan 30 16:23:11 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:16 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <3.0.5.32.19990129184928.00a9ac50@amati.techno.com> Message-ID: <36B32FEE.8759D79B@prescod.net> "W. Eliot Kimber" wrote: > > Near as I can tell from my work in the STEP world and in the document > world, the technology to manage data of this sort at the scales we need > simply doesn't yet exist. I don't know if this is a hardware problem or a > science problem, but I suspect it's a bit of both. I suspect that the > solution requires an entirely new way of thinking about storing little > fiddly bits of data that is neither relational nor object nor > object-relational, but is entirely else (or at least significantly enough > else to be something different). I think we have a definitional problem. I call anything that handles "little fiddly graphs of data with links and annotations" an object database. Is there someone in XML-DEV land with a better definition? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Don't you know that the smart bombs are so clever, they only kill bad people." - http://www.boingo.com/lyrics/WarAgain.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Jan 30 16:51:27 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:17 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? In-Reply-To: <36B32EA4.DBA7CB2D@prescod.net> References: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> Message-ID: <3.0.6.32.19990130085512.00999390@scripting.com> Our file size is limited to 4 gigabytes. (31-bit internal address.) 50MB databases are very common. It scales up to 500MB, but few of our customers have databases that large. I wouldn't promote, at this time, our odb being used for a multi-gigabyte application in a single file, but if it can be separated into multiple files, I don't see a problem. We have customers right now building multi-terabyte applications, and we're not hitting any walls. Caveat, there will be performance problems if you try to implement a huge relational database in the object database. If the data is relational use a RDBMS to manage it. Our system is especially appropriate when content management is the application. We've focused primarily on *web* content management: http://www.scripting.com/frontier5/whatIsFrontier.html Other people have built systems in Frontier for scalable content management, for print and web, or whatever, using the XML underpinnings. I highly recommend looking at the XMLTR suite by Paul Howson, he's been leading our community in this direction. http://www.flexi.net.au/~tdg/xmltr/ And thanks for asking! It's important to learn about the practical side of this stuff. I for one, would love to hear how Excelon from Object Design compares, they've been inaccurately claiming to be the first XML object database. This has caused me to be less shy about Frontier 5's capabilities in this area. (Frontier 6 is in the pipe btw.) Dave At 10:09 AM 1/30/99 -0600, you wrote: >Dave Winer wrote: >> >> We already have this. I hate it when people say things like "No one has a >> good, >> scalable solution for this now." We do. Are you supposed to be an expert on >> this stuff or do you just like to hear yourself talk? > >Before I waste (er invest) my time, let's be clear. How high does this >solution scale? My customers have XML data on various scales: >50MB, 500 MB, 4GB and 4 terabytes. To which customers should I promote the >Frontier database? > > Paul Prescod - ISOGEN Consulting Engineer speaking for only himself > http://itrc.uwaterloo.ca/~papresco > >Don't you know that the smart bombs are so clever, they only kill >bad people." > - http://www.boingo.com/lyrics/WarAgain.html > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sat Jan 30 17:02:53 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:17 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <36B32FEE.8759D79B@prescod.net> Message-ID: <000b01be4c71$c091d230$d3228018@jabr.ne.mediaone.net> Paul Prescod wrote: > > > "W. Eliot Kimber" wrote: ... I suspect that the > > solution requires an entirely new way of thinking about storing little > > fiddly bits of data that is neither relational nor object nor > > object-relational, but is entirely else (or at least > significantly enough > > else to be something different). > > I think we have a definitional problem. I call anything that handles > "little fiddly graphs of data with links and annotations" an object > database. Is there someone in XML-DEV land with a better definition? > -- Object databases don't have any particular claim in this area. The current varieties seem more suited to work with particular languages (e.g. c++ or java). Oracle has announced an DOM interface in 8i, ObjectDesign a DOM interface in eXcelon .. so, the only difference is how easy they are to work with and how fast they process specific tasks (oh ... and how much they cost :-) I doubt there is much new under the sun. Back in circa 1981 I was working with a LISP derived language called Grasper (written by Dan Corkill) that was designed to represent and manipulate directed graphs. We used this to write a relational database which was used to process geneological (i.e. tree) data. so there you have it... you can do anything with anything, it just depends on how much work you want to do and how fast you want it to run. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Jan 30 17:16:55 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:17 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? Message-ID: <3.0.32.19990130091208.00b3e750@pop.intergate.bc.ca> At 06:47 AM 1/30/99 -0800, Dave Winer wrote: >We already have this. I hate it when people say things like "No one has a >good, >scalable solution for this now." We do. Are you supposed to be an expert on >this stuff or do you just like to hear yourself talk? Just to be specific; are you claiming that I can pump a terabyte or so of densely structured XML text with mixed content and so on, into Frontier, without having to do all sorts of hand-mapping elements and attributes to native data structures, and then handle many complex-search transactions and a few granular-update transactions per second? Just to make it clear, if Frontier *can* do this, it's the only piece of software in the world that can. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Jan 30 17:16:58 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:17 2004 Subject: Another errata? Message-ID: <3.0.32.19990130091537.00b4ebd0@pop.intergate.bc.ca> At 04:50 PM 1/30/99 +0100, james anderson wrote: >If this is true, then what is the "Per-Element-Type Partition" described at >great length on the appendix on the "internal structure" of xml namespaces? >The spec would appear to assert some form of relation between the namespace >which comprises an unqualified attribute name and the namespace of the element identifier. Right, that is saying exactly that even though an unprefixed attribute is not *in* the namespace of its element, one can easily identify a conventional package of information that provides an unambiguous Id of what kind of attribute this is; the package includes the information about the type and namespace of the attached element, but I repeat: in the sense the spec uses the word namespace, an unprefixed attribute is NOT IN ANY NAMESPACE. That's why the following is legal: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Jan 30 17:24:48 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:17 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <000b01be4c71$c091d230$d3228018@jabr.ne.mediaone.net> References: <36B32FEE.8759D79B@prescod.net> Message-ID: <3.0.6.32.19990130092432.00f5d630@scripting.com> Frontier has four different ways to access XML structures: 1. A native verbset, the xml verbs. http://docserver.userland.com/xml/ 2. An implementation of expat, supporting its own api. http://www.techsoln.com/frontier/blox/index.html 3. A DOM implementation that works with either of the above. http://www.tallent.com/frontier/DOM/default.html 4. XML-RPC, which can plug into Java, Python and Perl applications, with more support on the way. http://www.xmlrpc.com/ Dave At 11:58 AM 1/30/99 -0500, you wrote: >Paul Prescod wrote: > >> >> >> "W. Eliot Kimber" wrote: >... I suspect that the >> > solution requires an entirely new way of thinking about storing little >> > fiddly bits of data that is neither relational nor object nor >> > object-relational, but is entirely else (or at least >> significantly enough >> > else to be something different). >> >> I think we have a definitional problem. I call anything that handles >> "little fiddly graphs of data with links and annotations" an object >> database. Is there someone in XML-DEV land with a better definition? >> -- > Object databases don't have any particular claim in this area. The current >varieties seem more suited to work with particular languages (e.g. c++ or >java). Oracle has announced an DOM interface in 8i, ObjectDesign a DOM >interface in eXcelon .. so, the only difference is how easy they are to work >with and how fast they process specific tasks (oh ... and how much they cost >:-) > > I doubt there is much new under the sun. Back in circa 1981 I was working >with a LISP derived language called Grasper (written by Dan Corkill) that >was designed to represent and manipulate directed graphs. We used this to >write a relational database which was used to process geneological (i.e. >tree) data. so there you have it... you can do anything with anything, it >just depends on how much work you want to do and how fast you want it to >run. > > >Jonathan Borden >http://jabr.ne.mediaone.net > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Jan 30 17:26:56 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:17 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? In-Reply-To: <3.0.32.19990130091208.00b3e750@pop.intergate.bc.ca> Message-ID: <3.0.6.32.19990130092826.00f5d780@scripting.com> Tim, read the subsequent messages re file sizes and scalability. I want to know this as much as you do. We did some very basic work in XML starting in lat 1997, and our community ran with it. We have some very knowledable and hard-working people working on Frontier. Especially look at the Howson site and tell me what you think. We're working up two sides of the same hill. I'm sure of it. I'm also sure we haven't reached the nirvana that you're seeking. But if we're close, and if there's value in what you want, let's go there. Dave At 09:16 AM 1/30/99 -0800, you wrote: >At 06:47 AM 1/30/99 -0800, Dave Winer wrote: >>We already have this. I hate it when people say things like "No one has a >>good, >>scalable solution for this now." We do. Are you supposed to be an expert on >>this stuff or do you just like to hear yourself talk? > >Just to be specific; are you claiming that I can pump a terabyte or >so of densely structured XML text with mixed content and so on, into >Frontier, without having to do all sorts of hand-mapping elements and >attributes to native data structures, and then handle many complex-search >transactions and a few granular-update transactions per second? > >Just to make it clear, if Frontier *can* do this, it's the only piece >of software in the world that can. -Tim > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sat Jan 30 17:33:28 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:17 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? In-Reply-To: <3.0.32.19990130091208.00b3e750@pop.intergate.bc.ca> Message-ID: <000d01be4c76$01d10500$d3228018@jabr.ne.mediaone.net> Tim: > > > At 06:47 AM 1/30/99 -0800, Dave Winer wrote: > >We already have this. I hate it when people say things like "No one has a > >good, > >scalable solution for this now." We do. Are you supposed to be > an expert on > >this stuff or do you just like to hear yourself talk? > > Just to be specific; are you claiming that I can pump a terabyte or > so of densely structured XML text with mixed content and so on, into > Frontier, without having to do all sorts of hand-mapping elements and > attributes to native data structures, and then handle many complex-search > transactions and a few granular-update transactions per second? > > Just to make it clear, if Frontier *can* do this, it's the only piece > of software in the world that can. -Tim > I like your criteria. Does the Internet fulfill this, with say HTML and search engines? The point being that a flatfile system with appropriate indexing, caching and distribution can handle all sorts of information needs (cost wasn't one of your criteria :-) Jonathan Borden xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jan 30 17:40:14 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:17 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <000b01be4c71$c091d230$d3228018@jabr.ne.mediaone.net> Message-ID: <36B33FB6.5AECF4BC@prescod.net> "Borden, Jonathan" wrote: > > > I think we have a definitional problem. I call anything that handles > > "little fiddly graphs of data with links and annotations" an object > > database. Is there someone in XML-DEV land with a better definition? > > -- > Object databases don't have any particular claim in this area. The current > varieties seem more suited to work with particular languages (e.g. c++ or > java). Oracle has announced an DOM interface in 8i, ObjectDesign a DOM > interface in eXcelon .. so, the only difference is how easy they are to work > with and how fast they process specific tasks (oh ... and how much they cost > :-) You didn't really answer my question. If Oracle 8i provides the same support for "graphs of data with links and annotations" that ObjectDesign then in what sense is it NOT an object database. I'm still asking for a definition. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jan 30 17:53:50 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:17 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? References: <000d01be4c76$01d10500$d3228018@jabr.ne.mediaone.net> Message-ID: <36B34547.B70720CE@prescod.net> "Borden, Jonathan" wrote: > > I like your criteria. Does the Internet fulfill this, with say HTML and > search engines? Search engines only do full-text search. When I can upload an XQL, XML-QL or OQL query to AltaVista and get back the results in seconds then I will be impressed both with it scalability and flexibility. Right now I am only impressed with its scalability. > The point being that a flatfile system with appropriate > indexing, caching and distribution can handle all sorts of information needs Fine. But does anyone know how to do the "appropiate indexing, caching and distribution" for the kind of thing I described above? Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Jan 30 17:55:54 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:17 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <3.0.6.32.19990130085512.00999390@scripting.com> References: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <14003.15215.701596.637120@localhost.localdomain> Dave Winer writes: [to me, on scalable XML repositories] > We already have this. I hate it when people say things like "No one > has a good, scalable solution for this now." We do. Are you supposed > to be an expert on this stuff or do you just like to hear yourself > talk? [and to Paul, on size] > 50MB databases are very common. It scales up to 500MB, but few of > our customers have databases that large. I wouldn't promote, at this > time, our odb being used for a multi-gigabyte application in a > single file, but if it can be separated into multiple files, I don't > see a problem. First, I don't claim to be an expert in RDBMS or in document repositories, and I do like to hear myself talk, so I'll take Dave's first comment in a friendly spirit. I said that there is not a good, scalable XML repository available right now. There are at least three attempts built on top of OODB's, including Frontier -- I won't name the other two, but they have consistently failed to scale up for my customers when they've tried them, so they're probably suitable only up to the workgroup level right now (i.e. 20-50 authors working on the same text). The problem, as every one who has tried has reported to me, is that the underlying OODB technology does not scale up to higher levels, though perhaps it's only a matter of time until the technology catches up. I have not heard from anyone who has tested Frontier yet, but until now I have tended to think of it as a web-content management tool rather than a general purpose document repository -- I'll take a close look at the demo release when I have a chance. In the mean time, perhaps Dave can help us by answering a few questions (since even once I've read the Frontier docs, most of the rest of the list will not have). Remember that I was suggesting that there was not yet a scalable XML repository, not that there were no repositories that could manage XML. 1. Frontier as a general Document Repository -------------------------------------------- In my opinion, there are six minimum criteria that a product must meet to call itself a document repository. Note that these must be available out of the box when I install the software -- if the software merely gives me the ability to write the stuff myself, it doesn't count (I can do all of this with Perl and RCS if I want to write it myself). Which of the following do I have immediately when I install Frontier on my computer? 1. version control (perferably by storing deltas rather than complete objects) 2. access control (check-in/check-out, object locking, etc.) 3. hierarchical object management (virtual folders) 4. virtual compound documents 5. where-used and what-uses tracking 6. efficient searching and querying In addition to these, workflow is highly desirable though not absolutely required. Others may want to add criteria that I missed. 2. Frontier as an XML document repository ----------------------------------------- In the original message, we were discussing a repository that could manage XML at the element level. Here are the what I consider the three additional requirements for Frontier to be considered an XML repository -- again, these must be available out of the box to count. (I don't know if these are necessarily good things, but they're what SGML repositories do.) Which of the following do I have immediately when I install Frontier on my computer? 1. manages documents at the element level -- elements can be reused in multiple documents, and branches of an XML document can be checked out and locked independently 2. allows efficient context-sensitive searching and querying, at least to the extent necessary to support the XPointer queries; a lot of indexing will be necessary here 3. provides full Unicode support, both for storage and for collating In addition to these, a DOM interface is highly desirable though not absolutely required (and I take it as a given that non-XML objects can still be managed). Others may want to add criteria that I missed. 3. Frontier as a scalable XML document repository ------------------------------------------------- It's very hard to write a scalable document repository, whether or not XML is involved. Here are what I consider the minimum requirements for scalability. Which of the following do I have immediately when I install Frontier on my computer? 1. no arbitrary limits on object or database size 2. passes the ACID test (the database is always in a consistent state and transactions can be rolled back, even with other users updating the repository concurrently) 3. a single repository may be distributed across multiple servers 4. the repository can incrementally back itself up on another system and ensure that the backup is also in a consistent state, all without going offline 5. the underlying database can deal with *at least* several hundred concurrent requests without noticable delay 6. the query component provides query optimisation for the sake of efficiency, and complex queries do not cause delays for other users The big RDBMS vendors have dealt with these problems by throwing billions of dollars at them, and they still struggle sometimes. Others may want to add criteria that I missed. Thanks again to Dave for pointing out that Frontier can be thought of as a document repository as well as a web-content management tool. I will look forward to learning more about Frontier from his reply. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sat Jan 30 18:01:27 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:17 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <36B33FB6.5AECF4BC@prescod.net> Message-ID: <000e01be4c79$bcffd830$d3228018@jabr.ne.mediaone.net> Paul Prescod wrote: > > You didn't really answer my question. If Oracle 8i provides the same > support for "graphs of data with links and annotations" that ObjectDesign > then in what sense is it NOT an object database. I'm still asking for a > definition. > My point is that you can essentially store anything with any type of database. Certainly you can store objects in a relational database, and you can represent tables in an object database. This issue is one of performance for a particular task. In general, object databases have been designed to efficiently store lots of c++ (or java) objects which contain embedded pointers (or references) and they provide a mechanism to navigate the database using the semantics of a pointer dereference. They are not designed to *efficiently* perform complex queries, especially those that SQL databases excell at. The question is, then, not that you *can* store objects in an object database (because you clearly can store objects in a relational database), nor whether you can query a database, because you can clearly query an object database, rather what is the performance of a particular database for a particular application. I think the term 'object database' has or may have become more of a marketing term than a strict technical term. If you want to call Oracle an object database because it stores objects, or processes directed graphs, then so be it (though that would raise a few eyebrows :-). The real question is: which database efficiently stores, indexes, queries and retrieves XML (or more accurately DOM) datastructures. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sat Jan 30 18:08:49 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:17 2004 Subject: Repositories: From Argument to Architecture In-Reply-To: <3.0.32.19990130091208.00b3e750@pop.intergate.bc.ca> Message-ID: <199901301807.NAA02868@hesketh.net> The What is XML For? and Is XML dead? threads have done a pretty good job (I think, anyway) of advancing us from griping about XML isn't a solution to looking for tools that would make it a better solution - in this case, repositories for document storage. I've downloaded Frontier (returning to my earlier roots in Mac land, to some extent), I've been following Excelon and POET, and I'm reasonably hopeful about the future. Still, my brief explorations (especially brief in the case of Frontier) leave me with as many questions as answers. I'd like to see an XML repository be as Web-like as possible, though I realize not everyone gets quite as enthusiastic about this as I do. Basically, it would mean that I could retrieve XML documents from it using HTTP, using familiar structures like URLs. I'd love to see support for XPointer queries on that same server, allowing me to pull out fragments, and another standardized query language (XQL or whatever) that would let me do more general searches. Ideally, I'd like to be able to add SAX filters and DOM processors between the content and its transmission as a fully-fledged XML document to the outside world, but at its foundation I'd like it to look like a vanilla Web server, whatever magic it's doing internally. When it came time to add documents, I'd like something as simple as FTP: upload file to a certain location, and it's retrievable from that location. The ability to modify and store document fragments would be a significant advance, making management and editing a heck of a lot simpler than it is now. (I love making changes in 350K HTML files and FTPing them to their home again and again.) Versioning and security would be great as well. (Maybe WebDAV is a better framework for this.) The management layer is a whole other set of things to consider, and I think I'll let vendors ponder that, but again, I'd love to see it managed via the Web. 'Repository-in-a-box' is what I'd call this, and I'd love to see the same architecture (with different back ends) implemented in lots of sizes and scales. A lot more standards have to settle before there's much chance of implementing such boxes, but I'd love to see folks discussing what it would take to create such a beast and make it a commodity product, not something that takes an army of programmers and gallons of Jolt Cola. I've been tinkering with this concept when I can find the time, but it's way beyond the capacities of a single author/developer working from home, no matter how many free DB downloads I can scoop up. Tim Bray wrote: >Just to be specific; are you claiming that I can pump a terabyte or >so of densely structured XML text with mixed content and so on, into >Frontier, without having to do all sorts of hand-mapping elements and >attributes to native data structures, and then handle many complex-search >transactions and a few granular-update transactions per second? All of the work I described above would have to be built on something close to what Tim described here. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Jan 30 18:16:17 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:17 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <14003.15215.701596.637120@localhost.localdomain> References: <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.6.32.19990130101944.00f61cd0@scripting.com> OK OK OK, I picked on you. Many apologies, seriously. It reflected a frustration that the "XML Circuit" as I think of it makes grand statements that I often feel are totally unsubstantiated. We come from different worlds. Some of the things you ask for, we have, and have had for many years. As a robust storage system with a deep programming model, we're there. As an XML-storage system, we're there, but as I said in a message a couple of days ago, I think that there's limited value in that. I see XML as a way of specifying content that's best stored in the native format, and emitted as HTML or XML when it needs to be communicated in some way. Yes, we've focused on the web, but others, who know more about document management, have adopted Frontier and taken it into the world you know. I'm going to try to get Paul Howson to join the discussion here. Listen to what he says. He has strong opinions about XSL for example. http://www.flexi.net.au/~tdg/xmltr/index.html If you read one thing about Frontier, I hope you read Howson's site. I believe he comes closest to speaking your language. As I said to Tim, we're not sure what each other is doing. I think there's an intersection, and a lot of stuff that can be done today that you think can't be done. It would be a shame if you didn't incorporate that into your thinking. Anyway, thanks for the list of questions. I'm saving it. It's a design for a website that we should put up. But I don't want to shoot from the hip, we'll put the time in and when we're ready I'll post a pointer here. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at metalab.unc.edu Sat Jan 30 18:20:53 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:08:17 2004 Subject: Real world DTD In-Reply-To: <36B0DCCA.29285B0@prescod.net> References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> <36B0BA28.47849E39@prescod.net> <36B0CE96.4AAEDF97@cs.ucsd.edu> Message-ID: I'm hunting for a large, medium to high complexity DTD for XML for use as an example in a book. Ideally this DTD should be in the public domain. Less ideally, I can use a copyrighted DTD where the owner is willing to sign a permissions agreement allowing me to quote from it extensively and in its entirety. Any suggestions? +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML: Extensible Markup Language (IDG Books 1998) | | http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Jan 30 18:22:46 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:08:18 2004 Subject: Is XML for the peons or the gods? (was What is XML for?) References: <5F052F2A01FBD11184F00008C7A4A80001136AD4@eukbant101.ericsson.se> <14001.53248.140057.872484@localhost.localdomain> <199901291845.NAA21477@hesketh.net> <36B214B0.CAEA9D2B@prescod.net> <36B22EF2.6143DF8E@infinet.com> <14002.13658.695869.594216@localhost.localdomain> Message-ID: <36B34CE5.2675@hiwaay.net> David Megginson wrote: > > ROTFL. I was in high school when they broke up, but who cared. They were passe by then and not yet *legendary*. It is a perrenial in politics, David, and the only thing Internet Time truly makes faster: as the twig is bent, so grows the tree. This one, I hope (those of us who are grannies and still beating this porch with our canes), will remember. Neophytes, regardless of the committee they serve on, or the contract they work on, have to learn the hard way. The net doesn't make everyone or every company equal. Precisely the opposite, actually, but the fellow crying out for smarter customers may get his wish and that may really turn the W3C on its head. May we find having as good as wanting. Remember the view of Beijing during the cultural revolution: all of those fires where every peasant made steel in back yard kilns where their gardens used to be ... while their children starved. Simply the fact that so many developers can find so many ways to use and implement SGML/XML systems is the testament to its success. That is not hype. OTOH, hyping particular implementations and *application standards* is the same business as it was for SGML when the military and aerospaces standards groups were duking it out a few years ago (eg, 28001 vs 87269): the flying phalanx. Twelve years ago, we were spitting SGML out of relational dbs to the Mentor Context system which took the SGML, parameterized it, and spit out bitmaps for a viewer embedded in a MicroVAX. Two years after that, we were sucking the SGML raw into C structs and sending those to the screen as navigable hypertext in a PC. By the mid-90s, TechnoTeacher and others were showing us how to use SGML in OODBMS designs. And so it goes. Last week, I was using memo fields to store fragments of HTML in metadata-configured relational tables to spit out HTML files for a viewer embedded in an Access form while other parts parameterize a treeview. We go round the loop back to the beginning because even if it is old, it became new when the objects in the framework became components. The next advantage to using markup is that the small desktop dbs can pass information to the terabyte dbs without dropping a bit. Sometimes scaling isn't a matter of building a single application that scales well, but fitting the right applications in to the right scales. That is why I side with *file format* argument, but can see why someone would want OOPs. It really depends on what part of the system uses markup how you apply it. (dummy slap to forehead, homer.) Again, the beauty of markup is that it works for all of these, and all of these approaches can be mixed and matched. XML is For What You Need It For. It can't "eat the web"; it can make some applications work better for the purposes for which they are designed. Design well; they work well. Misapply, and a new contractor gets the next contract. No size fits all. Some sizes fit most. Some fit tight. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Jan 30 18:27:13 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:18 2004 Subject: Repositories: From Argument to Architecture In-Reply-To: <199901301807.NAA02868@hesketh.net> References: <3.0.32.19990130091208.00b3e750@pop.intergate.bc.ca> Message-ID: <3.0.6.32.19990130102750.00f4a0d0@scripting.com> Simon, I'm in 100 percent agreement with this! Repository-in-a-box. Very nice. I see the need too. Esp with tools that have File menus that only know how to store stuff in the repository. What goes back and forth between the writer's desktop and the server is XML. When it's time to publish a piece it's just enabled for access thru a public URL and rendered thru the public templates. The writers see very little XML, the editors see a lot, and the readers see whatever is appropriate given the path they take to get to the info. In a nutshell, that's the vision for our next-generation. I think I'm going to stop writing for this morning. I'm concerned that I'm promoting too much here and might outstay my welcome. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Sat Jan 30 18:52:13 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:18 2004 Subject: what is a namespace anyway? [Re: Another errata?] References: <3.0.32.19990130091537.00b4ebd0@pop.intergate.bc.ca> Message-ID: <36B355FE.3BED27B0@mecomnet.de> with due respect, there is something which is rather unclear here. does anybody really understand this stuff? this from REC-xml-names-19990114, appendix A "the internal structure of namespaces", section a.2 "xml namespace partitions" The Per-Element-Type Partitions Each type in the All Element Types Partition has an associated namespace in which appear the names of the unqualified attributes that are provided for that element. This is a traditional namespace because the appearance of duplicate attribute names on an element is forbidden by XML 1.0. The combination of the attribute name with the element's type and namespace name uniquely identifies each unqualified attribute. yet, Tim Bray wrote: > > At 04:50 PM 1/30/99 +0100, james anderson wrote: > >If this is true, then what is the "Per-Element-Type Partition" described at > >great length on the appendix on the "internal structure" of xml namespaces? > >The spec would appear to assert some form of relation between the namespace > >which comprises an unqualified attribute name and the namespace of the element identifier. > > Right, that is saying exactly that even though an unprefixed attribute > is not *in* the namespace of its element, one can easily identify > a conventional package of information that provides an unambiguous > Id of what kind of attribute this is; the package includes the > information about the type and namespace of the attached element, but > I repeat: in the sense the spec uses the word namespace, an unprefixed > attribute is NOT IN ANY NAMESPACE. That's why the following is legal: > > > xmlns="http://www.w3.org" > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sat Jan 30 21:00:54 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:18 2004 Subject: Repositories: From Argument to Architecture In-Reply-To: <3.0.6.32.19990130102750.00f4a0d0@scripting.com> References: <199901301807.NAA02868@hesketh.net> <3.0.32.19990130091208.00b3e750@pop.intergate.bc.ca> Message-ID: <199901302100.QAA04822@hesketh.net> At 10:27 AM 1/30/99 -0800, Dave Winer wrote: >Simon, I'm in 100 percent agreement with this! > >Repository-in-a-box. Very nice. I see the need too. Esp with tools that >have File menus that only know how to store stuff in the repository. I'm glad to see you like it. It seems to me like a good way to integrate XML with current Internet practice, while significantly enhancing that practice. It also seems like a good way to encourage 'XML everywhere' while allowing different developers to do what they think appropriate on the back end to address the scalability issues David Megginson described so eloquently. For my part, I'm pondering one project that I can see growing to terabytes of data, but over at least a decade if not half a century. For now, a few MB of XML data and maybe a gigabyte or two of BLOBbed graphics is plenty. If we can get something up and running, with interfaces people can stand to use, I think we have an opportunity to create a market that may grow large enough to support the enormous amount of work needed to make this stuff genuinely scalable. Departmental-size repository-in-a-box would be a great start. I'd also like to see Respository-in-a-Box be extensible, probably through the provision of server-side SAX and/or DOM interfaces on outgoing and incoming information, which would address a lot of the needs (though not all) that we use CGI for at present. >What goes back and forth between the writer's desktop and the server is >XML. When it's time to publish a piece it's just enabled for access thru a >public URL and rendered thru the public templates. The writers see very >little XML, the editors see a lot, and the readers see whatever is >appropriate given the path they take to get to the info. That's pretty much it, though you'll need a great XML editor as well as an efficient repository to really support that grand vision. The public templates you're mentioning could be done through a SAX or DOM implementation of XSL, or by something else entirely. It seems like a good way to rationalize site management as well as encourage the use of XML. >In a nutshell, that's the vision for our next-generation. > >I think I'm going to stop writing for this morning. I'm concerned that I'm >promoting too much here and might outstay my welcome. You've done a good job; it's hard to be a vendor on a list full of demanding consumers. Let's see where your vision takes your products, and maybe we'll be discussing them in more detail next time, with or without your having to mention them. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sat Jan 30 22:34:19 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:18 2004 Subject: Is XML dead already or what? Was: RE: What is XML for? In-Reply-To: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.deg a.com> Message-ID: <3.0.5.32.19990130163153.009e4770@amati.techno.com> At 04:34 PM 1/29/99 -0800, Ed Howland wrote: >I am aware of others who have implemented XML based e-commerce solutions. I >only know of one actual methodology that seems to work for one of them. They >store the data in XML but use an RDBMS to index it to some level. Then they >parse the final file (or files) and merge them into a resultant XML stream. >This is then formatted with CSS (XSL presumably not yet ready for >prime-time) for presentation. Until I can find a better solution, this is >the short term fix I'm going for. What's wrong with this methodology? It uses each technology for what it's best at: XML for standards-based data representation, RDBMs for high-speed indexing and quering, CSS (or some other style mechanism) for dynamically presenting the result of a query or other process. Until we have a new form of data storage technology that combines the structure optimization of XML and object-oriented databases with the indexing and retrieval speed of relational databases, I don't see any other obvious way to solve the problem of large-scale, high-volume information retrieval. And don't forget the need for full-text indexing, which is yet another technology dimension. I've consistently said, for example, that the best way to manage HyTime-style hyperlinks at scale is using relational databases. HyTime provides an implementation-independent *data model* that, if implemented, ensures a rich and flexible set of linking and addressing information. But because the data model is fundamentally a set of lookup tables, it seems obvious to me that relational databases are, at least today, the best implementation technology. Nothing the in abstract model requires that it be implemented literally (that is, there's no requirement in the standard that you actually hold the hyperlinking information in memory as grove, only that you be able to provide access to it as though it were a grove). I also take it as a given that commercial relational database tools are as optimized as its possible to make them, for the simple reasons that the technology is mature and customer pressure for maximum performance is very high. I've always liked an implementation approach that starts with a very general, hopefully standardized data model and then implementing that model in whatever way is most productive in the short term, secure in the knowledge that by reflecting the more general model, you will be able to re-implement without danger of data or function loss (assuming your new implementation implements at least as much of the general model as your current system). Starting with an implementation-specific data model always runs the risk that you've over optimized somewhere. You can certainly see this in all the commercial SGML databases, where they failed to reflect the general SGML data model and inadvertently made it impossible to add features required by that model without significant rework. Note that I'm *not* saying you have to implement the *entire* model, just that whatever you do implement needs to be consistent with the more general model and provide built-in paths to the larger model. It also can't omit those things that are fundamental to or required by the model. I also believe, and my experience so far supports my belief, that it is in almost all cases better to prefer generality and flexibility of implementation over optimal performance. The only place this doesn't hold is when the short-term performance requirements are so onerous that only a maximally-optimized solution will do. But even then, you can define the and document the gap between the ideal model and what you've actually implemented so that when the technology catches up with the performance requirements, you know which parts are short-term optimization hacks that you can generalize. Generality and flexibility help ensure that the initial integration task of building the system is most efficient and helps ensure that the long-term maintenance costs of the system are minimized, if for no other reason than that the definition of the governing abstract model is explicit and available, rather than being hidden in the code and whatever documentation (if any) the original developers created. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sat Jan 30 23:37:28 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:18 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <14003.15215.701596.637120@localhost.localdomain> References: <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.5.32.19990130171557.007fe6d0@amati.techno.com> At 12:52 PM 1/30/99 -0500, David Megginson wrote: >In addition to these, workflow is highly desirable though not >absolutely required. Others may want to add criteria that I missed. Dependency tracking. I normally work with the following types of dependencies: 1. Storage-object-to-storage-object (e.g., doc-to-doc) 2. Use-by-reference relationships (re-use) 3. Semantic-object-to-semantic-object (e.g, element-to-element) Note that I'm assuming that the repository understands and maintains the storage object organization of the data when it existed outside the repository (external text ("parsed") entities excepted--they are evil and should be expunged from human memory). These requirements are more than a simple where-used requirement, although the facilities you need to satisfy the general where-used requirement can be used to satisfy these requirements. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sat Jan 30 23:37:58 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:18 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <000e01be4c79$bcffd830$d3228018@jabr.ne.mediaone.net> References: <36B33FB6.5AECF4BC@prescod.net> Message-ID: <3.0.5.32.19990130173328.007ff250@amati.techno.com> At 12:55 PM 1/30/99 -0500, Borden, Jonathan wrote: > In general, object databases have been designed to efficiently store lots >of c++ (or java) objects which contain embedded pointers (or references) and >they provide a mechanism to navigate the database using the semantics of a >pointer dereference. They are not designed to *efficiently* perform complex >queries, especially those that SQL databases excell at. If this is the definition of object database, then I don't think it qualifies as a "database" at all--it's just persistent object storage, which is useful, but not very interesting. At least my layman's idea of a "database" is that it is both general and supports queries. Of course, this has always been one of my problems with object-oriented programing in general: it tends to cause people to conflate the data with the processing to the degree that the objects end up becoming primary, rather than things that serve the data. Persistent objects are useful as an optimization technique but they should never be a substitute for standards-based data repositories. As a Certified SGML Paranoid Nutcase (CSPN) I distrust all software implicitly and therefore always prefer solutions in which the data, represented using SGML or XML, is the primary data store, with any other representations being merely transient reflections of that data for purposes of optimization and that sometimes you are forced to trust your software not to screw up your data too badly. Of course I realize that this extreme view can't work for a some use scenarios, but it turns out to work really well for a lot of them, especially high-volume *publishing* scenarios, where the input to the publishing system is the SGML or XML--the cost of reserializing documents stored as objects at production time is orders of magnitude higher than the cost of objectizing them at indexing or editing time, largely because the throughput requirements are different for these different processes. In other words, if the SGML data wasn't the primary format, it would be impossible to meet the production throughput requirements. For one particular customer, even the cost of not having the files directly on the file system is too high, so they have to go around behind the back of their storage manager (which provides access control and file-level versioning). Or said another way: optimizing for one part of the process usually, if not always, deoptimizes for another part. Not news, but it bears repeating once in a while. As an example of the cost of deserialization, we have a client with about 80 Meg of SGML data organized into about 15000 small documents (most documents are less than 2K in length). On a 400mhz Pentium II with 128Meg of memory (running Windows NT) and gigs of free disk space, it takes 21 hours to load this data into the repository (one of the leading SGML element manager databases, implemented on top of a leading object database) and 8-10 hours to export it. And, unless we're doing something wrong, the import process does not include indexing of the data, only objectizing it. This seems a little extreme to me. It may be that this product is particularly poorly implemented or that we have failed to perform some essential tuning action, but still, 21 hours? I hope that this annecdotal evidence is not indicative of other, similar systems, but it's not very encouraging. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Sat Jan 30 23:59:03 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:18 2004 Subject: Is XML dead already or what? In-Reply-To: <14002.61730.116185.859085@localhost.localdomain> References: <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> Message-ID: <4.1.19990131105228.00b8dd60@steptwo.com.au> At 21:55 30/01/1999 , David Megginson wrote: | In other words, concentrate on your XML exchange formats and use an | RDBMS on the backend (or, perhaps, an OODB if your traffic isn't too | high). If there ever is an XML repository with such good performance | that you want to throw out Oracle or Sybase, then you can redo the | backend without causing incompatibilities the frontend. I agree with David. To my mind, XML is the ideal too for achieving that object-oriented goal of "data hiding". That is, it allows me to specify an exact, known interface for talking to the world. Internally then, I can do anything I like, and change it as often as I like, without affecting anyone else. I mean, lets get real here, XML is not the answer to all the world's problems. I like relational databases. (There, I've said it now.) And for all those XML-obsessed people out there: get a life! XML is just another tool in the solution developer's toolkit. Nothing more, nothing less. J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun Jan 31 00:13:50 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:18 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <3.0.5.32.19990130171557.007fe6d0@amati.techno.com> References: <14003.15215.701596.637120@localhost.localdomain> <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.6.32.19990130161719.0099d660@scripting.com> You know, it was news to me that Tim Bray had a specific vision for an XML system wants implemented. Is there a common vision here? If so, it would be great to get together a set of narratives that described the nirvana XML server and a set of user tools for writers and for readers. I'm not talking about building the software, just scenarios. The pie in the sky description, if it's in your respective heads, would be valuable if it were on a website. Dave At 05:15 PM 1/30/99 -0600, W. Eliot Kimber wrote: >At 12:52 PM 1/30/99 -0500, David Megginson wrote: > >>In addition to these, workflow is highly desirable though not >>absolutely required. Others may want to add criteria that I missed. > >Dependency tracking. I normally work with the following types of dependencies: > >1. Storage-object-to-storage-object (e.g., doc-to-doc) >2. Use-by-reference relationships (re-use) >3. Semantic-object-to-semantic-object (e.g, element-to-element) > >Note that I'm assuming that the repository understands and maintains the >storage object organization of the data when it existed outside the >repository (external text ("parsed") entities excepted--they are evil and >should be expunged from human memory). > >These requirements are more than a simple where-used requirement, although >the facilities you need to satisfy the general where-used requirement can >be used to satisfy these requirements. > >Cheers, > >E. > >-- >
>W. Eliot Kimber, Senior Consulting SGML Engineer >ISOGEN International Corp. >2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 >www.isogen.com >
> >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sun Jan 31 01:18:33 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:18 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <14003.15215.701596.637120@localhost.localdomain> References: <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.5.32.19990130192004.009cb100@amati.techno.com> First, I don't want to turn this into a "How do I run Frontier" session, but since David Winer provided the opening, I think it's reasonable to have a bit of "how do I do X" in Frontier as a way of understanding what We want repositories to do and how, as an example of a repository, Frontier does or doesn't do those things (or does or doesn't make it obvious how to do those things). Starting point: I pulled down Frontier, started it up, worked through the little demo exercise in the tutorial. Got a web page. Great. So far, haven't seen anything that I can't do with a bunch of other tools, including DSSSL scripts applied against SGML or XML documents. Pluses: 1. It's all open--they're clear about exposing the internals so you can know exactly what's going on. 2. It didn't crash during the first 5 minutes. 3. The documentation, what I read, was clear and informative. Minuses: 1. It's all open--they're clear about exposing the internals so you can know exactly what's going on. 2. The section on XML told me nothing 3. The scripting language is proprietary. Why aren't the page templates in XML? Why isn't the scripting language Python or Perl (preferably Python, of course) or XSL (not fair--hasn't been defined yet)? 4. It's an object database but all I see are tables. This confuses me because I expect tables to be for relational databases and objects to be for object databases. 5. No obvious way to point to the root of my web site and say "import". Tutorial makes it clear that you can't just do this--have to rework your pages to pull things in. 6. Looks like you have script everything you want it to do. This makes senses for a Web site builder, not so much for a document repository. Here's my how-to question: I have about 80 megabytes of SGML documents that currently live in a repository. How do I do the following: 1. Import them into Frontier 2. Organize them into the organization I want (I have the organization defined) 3. Instantiate and manage hyperlinks among the parts 4. Edit the documents as SGML or XML documents (that is, using an SGML or XML editor) 5. Ensure access control 6. Track and manage changes over time 7. Publish some or all of the documents as an HTML site, as XML, as SGML for CD-ROM, as print (that is, how do I integrate the repository with my existing publishing tools and processes?) 8. Identify versions of documents as being frozen and unchangable. 9. Establish and use use-by-reference relationships I suspect that answer to all these questions is "write a script". It's clear from the tutorial that scripting language provides the facilities to implement some or all of these functions. But of course, as David M. said, I want that out of the box. I'm an integrator, not a developer--I don't want to implement a repository, I want to integrate a repository into my clients' enterprises and business processes. I'm not picking on Frontier here--it's just handy. It's not clear to me, for example, what a "Web site manager" really is or even that tools like Frontier are particularly compelling for Web site management (given that Python and NSGMSL or expat go a long long way, are completely standards based, completely free, and have a large skill pool to draw from). Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Jan 31 01:26:29 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:18 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <3.0.6.32.19990130161719.0099d660@scripting.com> References: <3.0.5.32.19990130171557.007fe6d0@amati.techno.com> <14003.15215.701596.637120@localhost.localdomain> <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <199901310126.UAA07431@hesketh.net> Dave Winer wrote: >The pie in the sky >description, if it's in your respective heads, would be valuable if it were >on a website. I've got two 'pie in the sky' visions posted: Building the File System into the File - http://www.simonstl.com/articles/filesyst.htm (slightly old) and Toward a Layered Model for XML - http://www.simonstl.com/articles/layering/layered.htm (rough draft) These move beyond XML itself to storage (repository possibilities, like have been discussed here) and processing (SAX/DOM/parsing), but it's all driven by possibilities I think XML opens. XML is not the answer to all the world's problems - it creates new problems, that are awfully damn interesting to solve. Sounds like a good reason to be XML-obsessed to me. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun Jan 31 01:40:14 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:18 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <3.0.5.32.19990130192004.009cb100@amati.techno.com> References: <14003.15215.701596.637120@localhost.localdomain> <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.6.32.19990130174359.00f64590@scripting.com> >>4. It's an object database but all I see are tables. This confuses me because I expect tables to be for relational databases and objects to be for object databases. Tables are like hashes in Perl, except they're virtual, don't need to be managed, and are tightly integrated with the scripting language. We give you a choice of scripting language, on Windows you can use Python, or Perl, or JavaScript or VB Script, because we wired into Active Scripting Host, it's just not as deeply integrated as our own language, it can't be, yet, so there are still things that are easier/faster in Frontier's internal language, but I expect over time, with help from Microsoft that this will be less true in the future. We don't fight syntax choice battles, learned that lesson a long time ago. Some of your other conclusions, esp the most broad ones, are not true. Many people use Frontier without writing scripts. I agree with you about what integrators need, and many of the things you ask for are available from other sources, or are part of the next release. You can get a preview of the next release on this site: http://developers.userland.com/ Re processing your SGML docs, we have native support for XML, not SGML. Not sure we can help you with SGML. The site has a section on Frontier 5 and XML, not sure if you came across it. If not, please check it out: http://www.scripting.com/frontier5/xml/ I hope this is the beginning of a lengthy exploration/feedback loop. I think we've done some things right, and there are definitely missing pieces. We want to be a good fit in your world, maybe we can't do everything everyone would want, but we want to learn and do more over time. Thanks.. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun Jan 31 02:32:20 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:18 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <3.0.5.32.19990130192004.009cb100@amati.techno.com> References: <14003.15215.701596.637120@localhost.localdomain> <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.6.32.19990130183556.009fcec0@scripting.com> Quite on topic, here's an XSL interface for Frontier content management: http://www.dstc.edu.au/DDU/staff/lawley/XSL/xsl-server.html It just came on our discussion board in the last couple of hours! It's right on topic in this thread. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Sun Jan 31 04:15:38 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:08:18 2004 Subject: Compound Documents - necessary for success? References: <990129131754.1254@mail11.mitre.org.0> Message-ID: <36B3D806.CA725077@allette.com.au> Roger L. Costello wrote: > This presupposes that (a) we know apriori what documents we want to nest > within , and (b) what order the nested documents are to be in, etc. > It assumes everything is static. I was thinking along the lines of a much... With all due respect Roger, I think that the problem is that we're both asking questions and with few exceptions, nobody's answering. In my own case, I assume that this is due to the fact that: a) creating compound documents with fragments using the same DTD as the parent may cause problems, but that there would always be a better way to handle such documents, b) nobody's sure whether this will be a problem once XLink, XPointer, XML Fragments and X?? have spun their magic, c) I've not clearly explained what I think the problem is, d) I'm missing the point so totally that nobody feels that it even merits a reply, I've raised this twice in the last month and nobody's addressed it in a way that alleviates my wondering. Would someone be so kind as to at least indicate which of the above points might be the most accurate? (I have been called an idiot in a public forum before - I won't be offended as I recall that the sting goes away after a couple of beers...) -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Bckman at ix.netcom.com Sun Jan 31 04:37:19 1999 From: Bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:19 2004 Subject: Real world DTD Message-ID: <000a01be4995$c295bb20$37eb6dd1@bckman> You may want to consider using the XML DTD for HTML being develpoped by the W3 HTML WG. The final version should be ready by the end of this week, and will be obtainable from theW3 web site. I will announce on this list when it is available. Frank Frank Boumphrey Style and XML information http://www.hypermedic.com/style/index.htm Author: Professional Style Sheets for HTML and XML http:// www.wrox.com ----- Original Message ----- From: Elliotte Rusty Harold To: Sent: Saturday, January 30, 1999 12:51 PM Subject: Real world DTD >I'm hunting for a large, medium to high complexity DTD for XML for use as >an example in a book. Ideally this DTD should be in the public domain. Less >ideally, I can use a copyrighted DTD where the owner is willing to sign a >permissions agreement allowing me to quote from it extensively and in its >entirety. Any suggestions? > > >+-----------------------+------------------------+-------------------+ >| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | >+-----------------------+------------------------+-------------------+ >| XML: Extensible Markup Language (IDG Books 1998) | >| http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | >+----------------------------------+---------------------------------+ >| Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | >| Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | >+----------------------------------+---------------------------------+ > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sun Jan 31 04:53:59 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:19 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <3.0.6.32.19990130174359.00f64590@scripting.com> References: <3.0.5.32.19990130192004.009cb100@amati.techno.com> <14003.15215.701596.637120@localhost.localdomain> <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.5.32.19990130225525.009c4580@amati.techno.com> At 05:43 PM 1/30/99 -0800, Dave Winer wrote: >>>4. It's an object database but all I see are tables. This confuses me >because I expect tables to be for relational databases and objects to be >for object databases. > >Tables are like hashes in Perl, except they're virtual, don't need to be >managed, and are tightly integrated with the scripting language. > >We give you a choice of scripting language, on Windows you can use Python, >or Perl, or JavaScript or VB Script, because we wired into Active Scripting >Host, it's just not as deeply integrated as our own language, it can't be, >yet, so there are still things that are easier/faster in Frontier's >internal language, but I expect over time, with help from Microsoft that >this will be less true in the future. We don't fight syntax choice battles, >learned that lesson a long time ago. That's good--but does that apply to templates as well? Let me reiterate that I just went briefly through the tutorial, so I've likely missed important concepts. But part of the test of any new tool is how closely it matches my existing mental model of how a particular task should be modeled and supported in a computer. So far Frontier has not matched very well, or at least not appeared to. This doesn't mean there's necessarily anything wrong with Frontier--after all, my personal models are often very idiosyncratic and there are always a variety of reasonable models for any given task. I'm simply observing a mismatch and reporting that, as a result, it is difficult for me to see how Frontier can be applied to the types of tasks I want to perform. I suspect that this is in large part because the marketing focus of Frontier is on its use as a Web content server and not as a generic document management system. If the marketing focus was on the latter, I'm sure the application would have been made clearer. In other words, I expected to see (and wanted to see) a document management system and instead saw a Web site server. Now that I think about it, I think the difference comes down to simply what is the initial input to the "serve some data" process: the data to be served or the script that generates the data. In my normal model, the data comes first, so I would expect to give a process some data (e.g., a document) and then apply a script to it. The Frontier model, as near as I can tell, is to start with the script and let it get (or generate) the data. Nothing wrong with this second model, but it's not the one I'm used to. Why am I used to my model? Because that's the way a document-centric system works. You start with a document and then process it. I note that Michael Lawley's XSL support for Frontier provides exactly this model: he provides a stub template that effectively runs an XSL script against a document. Which begs the question: why did he have to create the stub template--why doesn't Frontier have a "apply script to document" facility built in? >Some of your other conclusions, esp the most broad ones, are not true. More concrete details please. Remember that my conclusions were based on an initial, and brief, investigation of the tool, so they are likely to be incorrect, or at least inaccurate. Part of this exercise is to determine how accurate a picture of Frontier the initial marketing information provides. This is the way I must evaluate most tools: spend 1/2 hour poking at them and reading the available info. If they pass that gate, then maybe invest some real time in trying to do something realistic. There are too many tools to spend too much time with any one tool. It means that some good tools that are simply poorly presented will be missed, but it means that a lot of bad or inapplicable tools will be quickly eliminated. Many >people use Frontier without writing scripts. Perhaps I'm using the wrong terminology. I think I mean "template" (the "wp" files) when I'm saying "script", now that I think about it. I agree with you about what >integrators need, and many of the things you ask for are available from >other sources, or are part of the next release. You can get a preview of >the next release on this site: The old "it's in the next release" answer... :-) After spending as many years as I have hearing this from vendors, it's very hard not to be cynical about it. >http://developers.userland.com/ > >Re processing your SGML docs, we have native support for XML, not SGML. Not >sure we can help you with SGML. The site has a section on Frontier 5 and >XML, not sure if you came across it. If not, please check it out: I read it--it didn't tell me much, and it didn't make it clear how Frontier helps me manage XML docs (as opposed to how one might serve the XML docs as HTML, which would be through scripts and/or templates (right?)). I'm not trying to be difficult or argumentative--just trying to understand what a particular tool does. But please understand my potential for frustration and my starting point as an integrator and evaluator of tools: I want to be able to spend the least amount of time getting the most accurate picture of a tool possible. Therefore, I want the marketing information to be clear and informative. I want the demo to get me doing things I want to do as quickly and as clearly as possible. Because of my severe time presure, I will cut and run at the first major hurdle to making the demo work or getting an answer to a technical question, simply because there are always more tools to evaluate. So, using my experience with Frontier as an example only (only because David was brave enough and cares enough about his tool to ask us to evaluate it in good faith, which I hope I'm doing), here's what I've got so far: 1. David says "hey, this tool really does these things you want, even though it may not be obvious from how we market it." 2. I say "Ok, I'll take a look--I can always use another tool in the toolkit, and doc managers are sorely needed." 3. I go to the web site. Looks pretty good, informative, easy to navigate, always a good sign. I can download an eval. Super. 4. I download the eval, read the readme, start it up. It works. No intrusive install process. No reboot. Even better. So far the Frontier people have impressed me as not only not being idiots, but as being pretty clever. Another good sign. Press on. 5. I invest the time in reading the tutorial. Chatty style is a little annoying, but probably appropriate for their primary audience, which isn't hardnosed techies who just want to do something. I follow the steps--they work. No obvious difficulties making the thing work or seeing how the system is put together. At this point, so far so good. But - It's still not clear to me how this is anything more than yet another way to do CGI scripts. - The exposing of the innards, while encouraging to the Unix geek part of me, is off putting to the Windows user part of me, who wants the parts I'm supposed to touch to be clearly delineated from the parts I'm not. The Frontier tutorial writer realizes this and puts in a warning about not touching stuff, but that doesn't help me understand the tool by reading the user interface. This suggests that the tool itself is guru territory. - From the tutorial I see a process driven by template doucments in a unique syntax. Not a good sign--I want standardized or well-known syntaxes wherever possible. Also a point at which my model and Frontier's apparent model diverge. 6. I poke around in the online docs some more (more positive points: all the docs on the website and easily downloadable). It's clear that there's more going on here, but the docs don't really help me understand the doc management side of the tool, if there is one. From the turorial, I understand that I can't just suck in my existing Web site and go--that I have to do more work. I don't like that--I want to start with a new tool from where I am now and take advantage of new features only as I need them or have time to apply them. Even a moderate cost of entry can be prohibitive unless the return on investment is significant. I run out of time (actually, a real work problem came to the fore that I had to solve--but that's my day, never enough time to play with new toys). Conclusion: strong marks on basic implementation and packaging. Strong marks on eval friendliness. Implementors are clearly not idiots (remember: implementors who are not idiots is a very small set, at least in my world view). Still not clear how to apply tool as an XML document manager. My person action: Classify as "worthy of further consideration given additional information and/or possitive feedback from other evaluators". Do not delete from hard disk just yet. My response to clients who ask my opinion: Appears to be useful as a Web site system. Worth taking the time to evaluate. Cannot attest to capabilities with respect to scale or performance because I haven't done anything real with it myself. My suggestion to Frontier at this point would be: 1. Enhance the marketing info to provide a "how to use Frontier as a document manager" tutorial. 2. Provide a bit more handholding in the user interface, at least as a demo add-on. There seems to be a mismatch between the target user audience (gurus) and the audience the tutorial is pitched to (non-gurus). Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From liamquin at interlog.com Sun Jan 31 06:18:18 1999 From: liamquin at interlog.com (Liam R. E. Quin) Date: Mon Jun 7 17:08:19 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <14003.15215.701596.637120@localhost.localdomain> Message-ID: On Sat, 30 Jan 1999, David Megginson wrote: > I said that there is not a good, scalable XML repository available > right now. I have been involved in several attempts to build SGML or XML storage systems using databases. Performance is always a big issue. With an rdbms you have the interesting notion that the database understands neither sequence nor containment directly. You also have a difficulty with text retrieval, especially if you need it to span element boundaries and find "element boundaries" twice in this paragraph, yet still treat the "kw" element as a separately indexed object. On the other hand, the relational database vendors have worked very hard at peformance, and you get lots of benefits built in, such as journalling, rollback, backup, standard texts on SQL... the whole bit. Object oriented databases *do* understand sequence and containment, and understand it very well. But they don't have a standard query language. OQL is not implemented very evenly yet, and when it is, it has restrictions. We (at Groveware) found it difficult to represent a query such as find an elementNode with .name = "P" containing a childList containing an object of type elementNode with 'name' = "kw" containing a childList containing an object of type cdata where strcmp(content, "boundaries") == 0 both in OQL and in Object Design's non-OQL query language. One would like to say find

containing containing "boundaries" and have that be efficient, and that's a real challenge. The OLAP people and the text retrieval people are probably best placed to handle large quantities of XML, if the text retrieval people can manage to swallow the word "dynamic" and the OLAP people can get a grip on text retrieval :-) Speaking of which, I am working on my C/Unix text retrieval package (lq-text) again, hoping to add some XML support soon. But I digress. If you haven't seen an OODB system that scaled well, it may be (I am speculating) that the generic systems are too slow because query optimisation is still too hard; the application-specific ones are less visible, and probably perform very well. Lee -- SGML/XML consulatant, Toronto, Canada -- liamquin at interlog.com -- http://www.interlog.com/~liamquin/ also Director of Development, Groveware Inc, http://www.groveware.com/~lee/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Sun Jan 31 10:37:35 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:19 2004 Subject: Fw: XML for Java serialization Message-ID: <012301be4d05$08fff540$5402a8c0@oren.capella.co.il> Tyler Baker wrote: >> I don't think that this problem is particularly hard. Java has references, >> XML has ID references. You can easily model one with the other. >> >> The only probably is that Java objects serialized as documents are going >> to be . > >Well it is pretty simple to say IDs are the answer. They are indeed a possibility. Try >coming up with an implementation which resolves circular references and can be rebuilt back >into its original in-memory data structure. Implementation is not as simple as it sounds... Actually from what I recall about the Java serialization specs it should be pretty easy to override all the relevant methods to produce XML-ized output instead of the current one. One could even easily write a converter from the existing serialized format to an XML-ized one and back. It's pretty well behaved. The problem of IDs is already solved by the existing serialization implementation - you just need to make use of it. This might present an interesting alternative to the Coins approach... Just implement two streams: SerializedToXmlFilterOutputStream and XmlToSerializedFilterInputStream. Otherwise use the built-in Java functionality. I doubt whether that would be more then a week or two of work to implement, for someone familiar with the specs. Have fun, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Sun Jan 31 13:54:40 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:19 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead al ready or what?) Message-ID: Dave WIner wrote: > I'm going to try to get Paul Howson to join the discussion here. > Listen to what > he says. He has strong opinions about XSL for example. > > http://www.flexi.net.au/~tdg/xmltr/index.html > > If you read one thing about Frontier, I hope you read Howson's site. I > believe he comes closest to speaking your language. This makes your case weaker Dave, I'm afraid, if you enlist Paul's 'insights'. Part of his site seems ill-informed to me - criticising XSL for using a 'renamed JavaScript, called ECMCAScript', as if it was XSL that renamed it!! - and part of it sort of misses the point about what is so exciting about storing documents as XML. To set the scene: we are about to launch the online version of a client's magazine that has all the data and articles stored in an object structure, and all input and output is in XML. The stylesheets - in that really complicated XSL format that Paul has 'strong feelings about' :-) - are also stored there, because after all they are just XML. Then you just merge the XML with the XSL to get whatever you want, whether it's Web TV, handheld devices, headlines on GSM phones and pagers, or things as yet uninvented. Well that's not that radical, I'm sure all you XML fans are saying, but Paul's view seems to be way behind this: - For a start, he talks of formatting within the XML document - paragraphs that are bold, etc. - yet to get the most leverage from your data your should add ALL style later, even seemingly obvious innocuous things like 'emphasis'. - More significantly, he talks of leaving the complicated world of formatting to 'other tools', yet we need all this now. How do we get this magazine onto a hundred and one different devices and formats? One final thing is that our client - as many publishers do - creates all of their documents in Quark. We then process them to make XML and then import them. Quark have said that they will use XML in the next release - so our circle is complete! There will be no distinction between the web/handheld/auto PC/print and whatever else versions of the document - they will all be separate stylesheets. For this reason, we NEED XSL in 'all its generality' Paul. Regards, Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 e: Mark.Birbeck@iedigital.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun Jan 31 14:13:23 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:19 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <3.0.5.32.19990130225525.009c4580@amati.techno.com> References: <3.0.6.32.19990130174359.00f64590@scripting.com> <3.0.5.32.19990130192004.009cb100@amati.techno.com> <14003.15215.701596.637120@localhost.localdomain> <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.6.32.19990131061700.00f4bbc0@scripting.com> >>That's good--but does that apply to templates as well? Yes. BTW, Frontier is not primarily even a web server. It's a content management system. Organizations often serve on other systems. I'm sorry I can't handle level of request for feedback at this time. I think you've figured out the reality. We do systems for web content management. That's our focus. In 1997 and 1998 we added a lot of XML support. It hasn't been integrated into our marketing materials. We don't know to talk to people like you. We want to learn. About your cynicism about delivery based on experience, please don't give that to us. We do deliver. This is Frontier 6 in the pipe, not Frontier 2. Frontier has nothing to do with CGI scripts! How could you have gotten that impression? (OK, we can do CGIs, but that isn't what makes us special.) OK, anyway let's try another tack.. Look at this site: http://www.scripting.com/contentserver/ This may be closer to what you're looking for. One final note, thanks for the kind words about the reliability of the software, and the fact that we don't ask you to reboot. We fought hard for that kind of simplicity. We don't show the first-time user everything we can do. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Jan 31 14:32:44 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:19 2004 Subject: XSL/ECMAscript (was RE: Frontier as a scalable XML repository (was Re: Is XML dead already or what?)) In-Reply-To: Message-ID: <199901311432.JAA24115@hesketh.net> At 02:02 PM 1/31/99 +0000, Mark Birbeck wrote: >This makes your case weaker Dave, I'm afraid, if you enlist Paul's >'insights'. Part of his site seems ill-informed to me - criticising XSL >for using a 'renamed JavaScript, called ECMCAScript', as if it was XSL >that renamed it!! - and part of it sort of misses the point about what >is so exciting about storing documents as XML. > >[...much about XSL and ECMAScript...] This thread(s) has proven more capable of shifting subjects than any I've seen in a while - now we have someone on the list debating the ideas of someone it's not even clear is on the list, about something that's been fought over a few thousand times on the XSL mailing list. (And I'm saying this as a long-time thread abuser. Apologies for the crazy-long subject header.) I think at this point most folks who've encountered those discussions are willing to acknowledge that reasonable people can disagree, even violently, about most anything involving XSL, especially ECMAScript and even the need for XSL, without it being a stain on the other ideas they support. These are hotly contested issues - though some people on all sides may firmly believe themselves to be taking the 'right' approach, I don't think opinions on XSL should be used to disqualify someone's opinions about other aspects of XML processing. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun Jan 31 14:59:10 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:19 2004 Subject: XSL/ECMAscript (was RE: Frontier as a scalable XML repository (was Re: Is XML dead already or what?)) In-Reply-To: <199901311432.JAA24115@hesketh.net> References: Message-ID: <3.0.6.32.19990131070257.00990380@scripting.com> Simon, I've been trying to follow those XSL debates and my eyes glaze over. I come from such a different world! To me that's the charm of XML, the people it brings together. I can get a passionate appraisal from Tim Bray that opens my eyes only to the fact that we don't speak the same language, but his words are so intriguing. You say this is a wide-ranging thread, you ain't seen nothin yet! Here goes.. One more thing to point you all to. We've been promoting XML-RPC as a way of building distributed Internet applications. This has been going on since April last year. After Allaire joined the fray, we got a lot of new support and the system has been growing. A sub-item to the XSL processor site, but a much more earthshaping trend is the support we're getting in the Java world for XML-RPC. Some of the most intersting stuff has come from people who are lurking on this list. I would be remiss if I didn't point you all to the XML-RPC site. This is growing right now, and I think it's very significant, esp in the areas we've been touching on. Here's the Java XML-RPC implementation: http://helma.at/hannes/xmlrpc/ And here's the central XML-RPC site with pointers to many of the other sites: http://www.xmlrpc.com/ And here's a DaveNet piece I wrote on Friday that explains where we're going and provides new information on how we got here: http://www.scripting.com/davenet/99/01/microsoftXmlRpc.html Read the part about XML-RPC search engines, and Microsoft and XML-RPC. I know I'm responding to a fire hose with my own fire hose. But between all these hoses I think there's something great happening. Dave At 09:35 AM 1/31/99 -0500, Simon St.Laurent wrote: >At 02:02 PM 1/31/99 +0000, Mark Birbeck wrote: >>This makes your case weaker Dave, I'm afraid, if you enlist Paul's >>'insights'. Part of his site seems ill-informed to me - criticising XSL >>for using a 'renamed JavaScript, called ECMCAScript', as if it was XSL >>that renamed it!! - and part of it sort of misses the point about what >>is so exciting about storing documents as XML. >> >>[...much about XSL and ECMAScript...] > >This thread(s) has proven more capable of shifting subjects than any I've >seen in a while - now we have someone on the list debating the ideas of >someone it's not even clear is on the list, about something that's been >fought over a few thousand times on the XSL mailing list. (And I'm saying >this as a long-time thread abuser. Apologies for the crazy-long subject >header.) > >I think at this point most folks who've encountered those discussions are >willing to acknowledge that reasonable people can disagree, even violently, >about most anything involving XSL, especially ECMAScript and even the need >for XSL, without it being a stain on the other ideas they support. > >These are hotly contested issues - though some people on all sides may >firmly believe themselves to be taking the 'right' approach, I don't think >opinions on XSL should be used to disqualify someone's opinions about other >aspects of XML processing. > >Simon St.Laurent >XML: A Primer / Building XML Applications (March) >Sharing Bandwidth / Cookies >http://www.simonstl.com > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sun Jan 31 15:57:00 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:19 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) In-Reply-To: <3.0.6.32.19990131061700.00f4bbc0@scripting.com> References: <3.0.5.32.19990130225525.009c4580@amati.techno.com> <3.0.6.32.19990130174359.00f64590@scripting.com> <3.0.5.32.19990130192004.009cb100@amati.techno.com> <14003.15215.701596.637120@localhost.localdomain> <3.0.6.32.19990130085512.00999390@scripting.com> <30649320C177D111ADEC00A024E9F297169F26@exchange-server.dega.com> <3.0.6.32.19990130064745.013e0620@scripting.com> <36B32EA4.DBA7CB2D@prescod.net> <3.0.6.32.19990130085512.00999390@scripting.com> Message-ID: <3.0.5.32.19990131095332.00a46cc0@amati.techno.com> At 06:17 AM 1/31/99 -0800, Dave Winer wrote: >>>That's good--but does that apply to templates as well? > >Yes. > >BTW, Frontier is not primarily even a web server. It's a content management >system. Organizations often serve on other systems. You're right--I remember now that the tutorial talks about publishing the Web site out of Frontier and onto the site, which often makes sense, although sometimes it makes more sense to do that publishing dynamically (thus my reference to CGI commented on below). >I'm sorry I can't handle level of request for feedback at this time. I >think you've figured out the reality. We do systems for web content >management. That's our focus. In 1997 and 1998 we added a lot of XML >support. It hasn't been integrated into our marketing materials. We don't >know to talk to people like you. We want to learn. Always encouraging--I hope my feedback has been helpful. As an integrator, I'm always willing to provide constructive feedback on promissing tools in the hopes that I'll be able to provide better solutions for my clients. >About your cynicism about delivery based on experience, please don't give >that to us. We do deliver. This is Frontier 6 in the pipe, not Frontier 2. I was being a bit facetious, but remember too that I've been burned more times than not. It's like being told as a kid for the 10th time that "we'll go to the circus next weekend"--after a while, you stop believing it, no matter how credible the source. My firm policy is "I'll believe it when I see it and no sooner". >Frontier has nothing to do with CGI scripts! How could you have gotten that >impression? (OK, we can do CGIs, but that isn't what makes us special.) I had confused the publish-time scripting Frontier provides with the sever-time scripting CGI provides. But the two are really the same process, just done at different times in the delivery process. Which you choose is entirely a matter of performance optimization (for the most part). Ideally, the server would give you a way to define the generation rules once and manage the binding time transparently. Don't know if that's practically realistic--I suspect it's something that has to be managed by human intelligence. >OK, anyway let's try another tack.. > >Look at this site: > >http://www.scripting.com/contentserver/ > >This may be closer to what you're looking for. Will do. >One final note, thanks for the kind words about the reliability of the >software, and the fact that we don't ask you to reboot. We fought hard for >that kind of simplicity. We don't show the first-time user everything we >can do. Of course not. All general tools have way more capability than can be usefully explained on a Web site. And of course, the developers can never fully appreciate the full potential of the tool, simply because they're too close to it and have too deeply internalized their view of how it can and should be used. This is why users and integrators are so important--they will find new and innovative ways to apply the tool. Cheers, E. --

W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Sun Jan 31 17:34:13 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:20 2004 Subject: Repositories: From Argument to Architecture Message-ID: Given the subject is now 'architecture' I hope the following comments are not deemed 'off topic'. Simon St.Laurent wrote on 30 January 1999 18:10: > Basically, it would mean that I could retrieve XML documents > from it using > HTTP, using familiar structures like URLs. I'd love to see > support for > XPointer queries on that same server, allowing me to pull out > fragments, > and another standardized query language (XQL or whatever) > that would let me > do more general searches. I think this must move from 'nice to have' to 'must have'. If we are to implement the next generation of web applications, as opposed to just document management, then there must be hooks into the data at all levels. For example, at the level of quoting from a magazine article - by including it inline in your own article, with your own formatting - you should be able to do: http://www.mag.com/issue[num=65]/article[num=22]/para[id=7] or whatever syntax becomes standardised. (We have implemented this already, using an XSL-style syntax for now, because it just looks neater (!) than some of the other syntaxes. I don't like the apparent procedural appearance of some of the other proposals - but we'll use whatever everyone else does, of course.) Likewise a portal-type site should be able to pull article information from us, allowing it to create links to the latest articles on our site, without re-coding every week or month, e.g.: http://www.mag.com/issue[num=65]/article[type=promo] Equally, a program should be able to pull figures from our company database, so that it can average them, chart them, or do whatever it wants: http://www.mag.com/company[ticker=MSFT]/economic[year=1998]/turnover And finally, a subscription fulfilment house should be able to retrieve any address changes made by subscribers via the magazine site, and synchronise them with their own databases. No more trying to make two different databases talk directly to each other. However, although we HAVE implemented all of this already, the only way we could get the data out fast enough was to use an indexing server on snapshots of the database. Not ideal, but OK for document-based projects where the output data does not have to change immediately that the database has been changed. > ... but at its > foundation I'd > like it to look like a vanilla Web server, whatever magic it's doing > internally. Definitely. We've done this as described above, but have an interesting issue in relation to pulling out information that requires formatting. Before we used a dot extension: http://www.mag.com/issue/65/article/22.htm http://www.mag.com/issue/65/article/22.xml But this looks 'wrong' in our new syntax: http://www.mag.com/issue[num=65]/article[num=22].htm http://www.mag.com/issue[num=65]/article[num=22].xml One possibility is to say that the server has a number of roots: http://www.mag.com/xml/issue[num=65]/article[num=22] http://www.mag.com/html/issue[num=65]/article[num=22] and perhaps others (XSL, and so on). I like this myself because it starts to say that the server is some sort of data repository, rather than just a 'web server'. However, it's not really 'correct', because the article is at the same position in the tree, regardless of how you output it. This is an important issue at the moment for us, because we obviously cannot assume that everyone is using XML-aware browsers to view the site, so we have to merge XML and XSL on the server for older browsers. Maybe we should really have: xttp://www.mag.com/issue[num=65]/article[num=22] http://www.mag.com/issue[num=65]/article[num=22] Who knows! Anyway, once all browsers are XML-aware, then we will just export XML - all we then have to do is work out how we tell the browser in what way to display it, without embedding that information in the XML document in the database through an explicit link to an XSL stylesheet. > The ability to modify and store document fragments would be > a significant > advance, making management and editing a heck of a lot > simpler than it is > now. Exactly right. We actually do use a web interface on an object-like database which allows you to drill down to any node in the tree. There's no uploading or downloading, you just edit the node (through a web browser). This brings with it its own problems though, as I will try to explain. To spell out the issues first; say we have something like: You live in North America and eat turkey at Thanksgiving. and I live in Blighty and have a friend in Turkey. This gives us great search potential: - you could just search for the word Turkey, and get both entries - animal and country - you could search for the COUNTRY Turkey and get only the second entry - you could search for "Great Britain" and also find the second entry To achieve the latter, you simply say things like: Great Britain UK United Kingdom U.K. perfidious Albion and so on. Then a search for any of the strings inside the tag, is converted to a search for id="UK". (This is all 'pseudo-XML'. We actually use a more generalised link syntax.) So, to return to the problem, we can only achieve this at the moment by the user actually typing these tags into the database. It's not a bad solution - and is a lot better than manipulating 350K files in a text editor - but what we really want is to be able to highlight a word or expression and then apply a tag from a list of available ones. In other words, to achieve what we really want, the user-interface is going to be a major project in itself. For example, we also want to be able to automate tagging of certain obvious connections, especially useful for converting large quantities of legacy data. > (I love making changes in 350K HTML files and FTPing > them to their > home again and again.) As said, thankfully we don't do that. > Versioning and security would be > great as well. I don't think this is all that difficult. As far as security goes, our system has that on every node already. It's quite cute really, because two people can request the same document, and certain nodes can be denied to one and granted to the other, appearing to present two different documents. As to versioning, these issues are not new, and the technology is out there. Even with our relatively crude system, we could easily retain all historical versions of a node, and even apply labelling and commenting, like SourceSafe and PVCS do. Since we create our documents on the fly from the database then you could re-create any document from any time, and even search them. It would be more of a step for us to store these as deltas, but the expertise is around. > The management layer is a whole other set of things to consider, and I > think I'll let vendors ponder that, but again, I'd love to > see it managed > via the Web. I agree. Our current interface is all in JavaScript, and doesn't need the DOM. It has a tree structure that allows you to navigate through the nodes in the database. All data is edited by opening a node, and new nodes can be added at certain points dependent on whether they are allowed. An important next step is being able to work offline and then batch submit changes, whether just a few nodes or Tim's gigabytes of documents. For that we will need to work out some tracking mechanism to see if a node have been removed, altered, or whatever, but that isn't that difficult really, and may well just be a simple use of a syntax like XML-RPC. (I'm not trying to trivialise this stage; I know the software will have to, for example, respond in a reasonable way when someone tries to add data that might contain a node that they have no rights to, conflicts must be resolved, and so on, but it isn't really the most baffling of tasks.) The structure of the objects is also defined through this tool, but here I think is where we will need to do the most work. The ideal scenario is for there to be a very close relationship between the DTD and the storage structure. At the moment we can do it one way round - use the database structure to 'create' a DTD, which is handy, but what if we don't control the definition of the DTD? Just as you can 'import' your XML files, we want to 'import' other people's DTDs and presto, have our database structure. And more excitingly, there are certain types of changes that could happen to that DTD which could be immediately reflected by changes in the database. A dynamic database like that would be very useful. > 'Repository-in-a-box' is what I'd call this ... Mmm - snappy :-) > A lot more standards have to settle before there's > much chance of > implementing such boxes I don't know - I think we can already go a long way. We've already managed to alter our stuff easily to keep up with the changes in XSL, for example, and can't see much looking forward that will throw us out provided we plan carefully (and pay attention to this discussion forum, of course). >From our side the issues are more to do with performance and resilience, the same old issues we've always faced when building large distributed applications. In the short-term we need to build on something like Microsoft Transaction Server, for example, to ensure that everything is industrial-strength. But that is an implementation - not a theoretical - question. > what it would > take to create such a beast and make it a commodity product Less than I think everyone thinks. To summarise, I think there is a lot of mileage in merging the right existing technologies together, rather than completely starting from scratch. There are a lot of developments out there that when put together create far more of what you are after than may at first sight be obvious. Regards, Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 e: Mark.Birbeck@iedigital.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sun Jan 31 17:51:11 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:20 2004 Subject: XSL/ECMAscript In-Reply-To: <3.0.6.32.19990131070257.00990380@scripting.com> Message-ID: <001501be4d41$ae521320$d3228018@jabr.ne.mediaone.net> My apologies, but I'm totally lost here... what are the implications of XML-RPC on XSL and ECMAScript? Aren't these totally different issues? Jonathan Borden http://jabr.ne.mediaone.net > > Simon, I've been trying to follow those XSL debates and my eyes > glaze over. > I come from such a different world! To me that's the charm of XML, the > people it brings together. I can get a passionate appraisal from Tim Bray > that opens my eyes only to the fact that we don't speak the same language, > but his words are so intriguing. > > You say this is a wide-ranging thread, you ain't seen nothin yet! > Here goes.. > > One more thing to point you all to. We've been promoting XML-RPC as a way > of building distributed Internet applications. This has been > going on since > April last year. After Allaire joined the fray, we got a lot of > new support > and the system has been growing. A sub-item to the XSL processor site, but > a much more earthshaping trend is the support we're getting in the Java > world for XML-RPC. > > Some of the most intersting stuff has come from people who are lurking on > this list. I would be remiss if I didn't point you all to the > XML-RPC site. > This is growing right now, and I think it's very significant, esp in the > areas we've been touching on. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Sun Jan 31 17:55:48 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:20 2004 Subject: Is XML for the peons or the gods? (was What is XML for?) Message-ID: > I do think you could do wonderful complex things on top of XML if > you keep the > standard spec simple I think it is pretty simple. It is very impressive in that it doesn't try to do everything - like some sort of ADA or something. It must have been tempting to try and put XLink/XSchema/XPointer/XSL-type features into the original spec, and then it would never have seen the light of day. > (namespaces are something that is really > a contradiction to > simplicity An important issue, as far as I understand it, is how do I build on other people's work? If someone else builds a great DTD for financial transactions, and I want a DTD for selling fish-tanks on the web, surely I should devise a DTD just for specifying fish-tank sizes, and then use a namespace for the financial parts? Evolution then becomes incredibly rapid, as we all build on each other's work. It's a bit like the productivity gains you got in the old days when decent, affordable compilers (and assemblers!) emerged, and you began to write your code quicker by building on other's developments. > In the end, > all of these additions make supporting XML more difficult and > far less useful to > the "masses". Not sure whether 'the masses' are actually programming computers anyway. Perhaps within the software world you may be distinguishing between 'hobbyists' and 'professionals'. Whatever. I think that the less experienced developer has plenty to get their teeth into. For example, if they were to write their own video-tape library program today, they might use Access or some such. The changes we are seeing are that if they were to write their program so that it understood XML, then they could download film titles from some site somewhere that had a complete catalogue of all films - or whatever. In other words, if you want to increase the possibilities of your software talking to loads of other software in the future - in ways you haven't yet thought of - then use XML. And this goes for the 'Gods' too. Office 2000 is to use XML, as is Shockwave and QuarkXPress. Now in one sense, you could say these big guys gain nothing, because for their applications it is simply a case of using a different file format - this week its proprietary, next week its a bit more accessible. But actually what happens is they become part of whatever other innovations take place; when the new generation of search engines are implemented that tidily cope with XML, for example, all of their documents immediately become searchable, on fields like author, last modified, project name, etc. This is not so with their own secret formats. > No developer including myself wants to spend a ton of time > learning and doing > things with a technology that is going to die because the > leaders of that > technology are not sensitive to the needs of the underlings > who actually use it. That's a different question. You seem to think it's someone else's job to ensure that you don't take a wrong turn when implementing your projects. I moved from assembler to C, to C++, and from Unix to Windows 3.0, to NT, and I don't remember anyone at any of those key junctures knowing for sure which way was right! Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 e: Mark.Birbeck@iedigital.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sun Jan 31 18:22:37 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:20 2004 Subject: Storing Lots of Fiddly Bits In-Reply-To: <3.0.5.32.19990130173328.007ff250@amati.techno.com> Message-ID: <001601be4d46$0b548310$d3228018@jabr.ne.mediaone.net> W. Eliot Kimber wrote: > > > At 12:55 PM 1/30/99 -0500, Borden, Jonathan wrote: > > > In general, object databases have been designed to > efficiently store lots > >of c++ (or java) objects which contain embedded pointers (or > references) and > >they provide a mechanism to navigate the database using the > semantics of a > >pointer dereference. They are not designed to *efficiently* > perform complex > >queries, especially those that SQL databases excell at. > > If this is the definition of object database, then I don't think it > qualifies as a "database" at all--it's just persistent object storage, > which is useful, but not very interesting. At least my layman's idea of a > "database" is that it is both general and supports queries. Many object databases do provide query capability, e.g. OQL. The point is not that they aren't capable of handling queries, rather that relational databases excel at queries. The question is not one of ability, rather efficiency (and scalability). > > Of course, this has always been one of my problems with object-oriented > programing in general: it tends to cause people to conflate the data with > the processing to the degree that the objects end up becoming primary, > rather than things that serve the data. Persistent objects are useful as > an optimization technique but they should never be a substitute for > standards-based data repositories. exactly! (from an oo guy:-) > ... > > As an example of the cost of deserialization, we have a client with about > 80 Meg of SGML data organized into about 15000 small documents (most > documents are less than 2K in length). On a 400mhz Pentium II with 128Meg > of memory (running Windows NT) and gigs of free disk space, it takes 21 > hours to load this data into the repository (one of the leading SGML > element manager databases, implemented on top of a leading object > database) > and 8-10 hours to export it. And, unless we're doing something wrong, the > import process does not include indexing of the data, only objectizing it. > This seems a little extreme to me. It may be that this product is > particularly poorly implemented or that we have failed to perform some > essential tuning action, but still, 21 hours? I hope that this annecdotal > evidence is not indicative of other, similar systems, but it's not very > encouraging. > scary isn't it. the problem is this: suppost we wish to use XQL as a query "language", now suppose the documents are stored as XML in files. What would an index look like and how would the processor efficiently represent containment etc. This is where SQL has trouble. For example, select href from documents where tagname = 'p' is a piece of cake, but selectSingleNode("/repository/*//*/chapter/*//*p"); (or something like that :-)) makes things a bit more difficult in SQL. the approach I believe might make most sense would be to store the documents in an in-memory DOM or grove format (which isn't far off from what an object database essentially is). The cost of doing so ought not be too far off from building the DOM parse tree in the first place. I can hear many people choking at this point about efficiency, memory, swapping etc. but this approach is essentially exactly how object databases work. This issue is disk and swap space. 32 bit architectures are limited to about 4 gb (2^32) but 64 bit architectures are limited to 2^64 bytes which does require a large RAID farm. so 21 hours to process 80 mb of information is grossly out-of-whack and points to a very poorly designed system (a 128 mb machine should be able to process 80 mb of data in memory give or take a few 10s of mb). For example, with as small a system as you are talking about, I'd slap a swapfile on Jade and be done with it. You ought to be able to run an XSL query directly. The system I work with scales to terabytes, employs SQL indexes, and files which aggregate individual objects into 20-80 mb chunks. This hooks into a HSM for essentially unlimited storage capability and accepts information at ~1 mb/sec on a 10base-t network with a 180 MHz pentium pro and 64 Mb memory. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Sun Jan 31 18:37:40 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:20 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) Message-ID: I know this thread has progressed but one of the original points has not been addressed so I'd like to re-raise it. W. Eliot Kimber wrote on 30 January 1999 00:49 > But, the XML data model, that is, the abstract model for the > *serialization* is not the same as the abstract model of the > data being > serialized. [and] > Here is one possible (of an infinite number of possible) XML > serialization: > > > > business objects schema > > > > person > > > name > Eliot > [etc.] [and] > You get the idea--clearly the in-memory abstraction of the > document bears > no direct relationship to the in-memory abstraction of the > original data. All this is true, but I wonder if you are not comparing like with like. The model for your data should be more like: Eliot male ISOGEN International Corp
Dallas, TX
Although you are right to say there are 'an infinite number' of possible mappings, if you use a representation that relies on a completely different DTD to represent the data, you shouldn't then be surprised if your XML no longer mirrors that original data. Nothing says my mapping is right, but at least it is based on the same schema that you introduced at the beginning of your message, namely: > TYPE gender ENUM; > male; > female; > unknown; > END_TYPE: > ENTITY person SUBTYPE OF being; > name : STRING; > sex : gender; > employer : OPTIONAL enterprise; > END_ENTITY; [etc.] I think, if we are to use object databases - and of course the jury is still out - the issue is how do we import and export XML files, using the relevant DTD to control the process. This is different to importing and exporting using a 'serialisation DTD', which expresses nothing but meta-data - not the original data. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 e: Mark.Birbeck@iedigital.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sun Jan 31 18:39:31 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:20 2004 Subject: XML query engines: was RE: Is XML dead already or what? In-Reply-To: <36B34547.B70720CE@prescod.net> Message-ID: <001701be4d48$3e3d6e70$d3228018@jabr.ne.mediaone.net> Paul Prescod wrote: > > "Borden, Jonathan" wrote: > > > > I like your criteria. Does the Internet fulfill this, > with say HTML and > > search engines? > > Search engines only do full-text search. Err no. some do, others don't. For example, some engines index meta tags, others full text and others can index arbitrary tags. some engines might require a DTD and/or schema others not. This is the heart of the question: what is the best way to index XML? When I can upload an XQL, XML-QL > or OQL query to AltaVista and get back the results in seconds then I will > be impressed both with it scalability and flexibility. Right now I am only > impressed with its scalability. > > > The point being that a flatfile system with appropriate > > indexing, caching and distribution can handle all sorts of > information needs > > Fine. But does anyone know how to do the "appropiate indexing, caching and > distribution" for the kind of thing I described above? > This is the billion dollar question. The point that I am trying to make on the "Storing lots of Fiddly bits" thread is that it is not *how* the data is stored e.g. flatfile, object or relational database that is the issue, rather *what* you wish to do that is the important issue. If we define the problem as the ability to run an XQL query against an index of XML documents and return a result in a matter of seconds this imposes specific requirements on a system. Let's go further and assume for the moment that we have already converted all HTML documents on the Web into Vogager (i.e. HTML as XML). Now suppose that we want to be able to run an XQL query against the entire Web. Has anyone done this? Clearly no. If anyone capable of doing this today. Probably not. Are there people working on this? Yes. So lets hear what strategies are best used in this situation. My personal opinion is that it is a hybrid relational and 'object' database approach. The problem with a straight relational approach is that we need to model containment and heirarchies... in SQL terms this means joins, perhaps multilevel joins when documents are deep. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jarle.stabell at dokpro.uio.no Sun Jan 31 19:45:19 1999 From: jarle.stabell at dokpro.uio.no (Jarle Stabell) Date: Mon Jun 7 17:08:20 2004 Subject: XML query engines: was RE: Is XML dead already or what? Message-ID: <01BE4D5B.4367EE80.jarle.stabell@dokpro.uio.no> Borden, Jonathan wrote: > The problem with a straight relational approach is that we need to model > containment and heirarchies... in SQL terms this means joins, perhaps > multilevel joins when documents are deep. There exists a neat trick which enables simple SQL-Select queries answering for two given nodes, whether one is a subnode of the other, and also how many levels deep, in constant time, assuming you do some simple preprocessing on the structure. (Assigning two integers to each node in the tree). I don't know who "invented" this trick, but I know that Joe Celko has written about it, perhaps he first described it. Cheers, Jarle Stabell Digital Logikk AS xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sun Jan 31 20:32:38 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:20 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: Message-ID: <3.0.5.32.19990131143311.009fd620@amati.techno.com> At 06:45 PM 1/31/99 -0000, Mark Birbeck wrote: >I know this thread has progressed but one of the original points has not >been addressed so I'd like to re-raise it. >All this is true, but I wonder if you are not comparing like with like. >The model for your data should be more like: > > > Eliot > male > > > > > ISOGEN International Corp >
Dallas, TX
> >
> >Although you are right to say there are 'an infinite number' of possible >mappings, if you use a representation that relies on a completely >different DTD to represent the data, you shouldn't then be surprised if >your XML no longer mirrors that original data. Nothing says my mapping >is right, but at least it is based on the same schema that you >introduced at the beginning of your message, namely: But you've not solved my problem, because the in-memory abstraction of the *document* is still: (xml-document (data-instances (element (gi "person") (content (element (gi "name") (content (literal "Eliot"))))))) So, while the result is closer to the abstraction of the data, it is still not the original abstraction. And note that my example is trivial, so the mapping from one possible DTD for the serialization document to the abstract schema is both obvious and possible, but in a real-world example, neither are likely to be (for example, there's no way to represent the results of having class hierachies using a DTD alone--you have to have specialized markup constructs to bind instance attributes to the class or superclass that defines them). And note that even for an early-bound form, there are still infinitely many ways to construct it, and at least three reasonable ways (attribute-primary, content primary, mix of attributes and content). Another tricky design choice: how is redundancy represented--use by reference? data copying? Do you use your own addressing scheme or use XLink (or HyTime or ID/IDREF or ...)? There are too many design choices when defining an early-bound serialization to be able to make general predictions about any given such format or to impose general conventions or constraints. So no matter how you slice it, there will always be a disjoint between the abstraction of the serialization form and the abstraction of the data objects being serialized, which means that a query onto the abstraction of the serialization will not be the same as a query onto the abstraction of the data that has been serialized. The gap might be bigger or smaller, but there will always be a gap. Of course, for any given binding of abstract schema to serialization, one can define query functions that implement the de-serialization algorithm, but these bindings must be defined on a per-schema or per-schema-mechanism basis, so there's no potential generalization or standardization benefit there. Which begs the question: if the abstraction of the document is not the abstraction of the data, why bother to create and store the abstraction of the document when you can just as easily create and store the abstraction of the data? Note that for the EXPRESS language (part of the STEP family of standards, ISO 10303, see ), we are in the process of defining an XML-based serialization format, which will include an algorithm for going from any EXPRESS schema and its data instances to their late-bound serialization and back again. Given that, you can then, of course, write queries in XML-specific systems (DSSSL, XSL, XQL, GroveMinder, DOM, etc.) that will implement the deserializations and treat the documents as though they were the original data instances. This will be useful, because you'll be able to turn existing (and largely free) document-processing tools into EXPRESS-based data access tools, but that is simply a side effect of using XML as the serialization format--it is not our primary motivation for using XML. In a production environment, you would not normally introduce an additional layer of indirection between the request for data and the data itself when that layer adds no additional value over saving a few Euros on software. Our primary motivation for using XML is that, as a serialization syntax it does a better job of enabling reliable interchange than the current serialization format for EXPRESS-driven data. Note that I'm making a distinction between the motivation for standardized, industrial-scale solutions and one-off, small-scale solutions. In the latter case, using document-processing tools to do database-like things off the serialization format can be a big win, believe, me, I'm depending on that myself. But for large-system implementation, it would not be the right thing to do. One of the things we quickly realized as we thought through our design principles, requirements, and goals was that we *cannot* and *should not* define the standard *early bound* form of the serialization, because there are simply too many useful ways to do it. Rather, we will provide a general mechanism for mapping from early-bound serialization syntaxes to the standardized late-bound syntax (we will almost certaintly use SGML architectures for this--name spaces do not help in this case, because the whole point is to let the designer of the early-bound syntax define their own element and attribute names). Cheers, Eliot --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sun Jan 31 21:19:20 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:20 2004 Subject: Another errata? In-Reply-To: <3.0.32.19990129141044.00ba6140@pop.intergate.bc.ca> from "Tim Bray" at Jan 29, 99 02:10:46 pm Message-ID: <199901312207.RAA05290@locke.ccil.org> Scripsi: > >No. An attribute not explicitly labeled with a prefix belongs to the > >same namespace as its element. Et Timothaeus Bray responsit: > No. Adam Donahue is correct on this one. The spec says explicitly, > and then belabors the point with examples; defaults don't apply to > attributes. The only attribute that has a namespace is one that > has a prefix. Quite right. This distinction was introduced into xml-names between the August and September working drafts; the latter is the first which contains the examples in question in the new clause 5.3. Earlier drafts said "The namespace of an unprefixed attribute is a function of the type of the element to which it is attached, and to the namespace (if any) of that element." Context suggests that the function in question is the identity function, but it is not explicitly specified. But this is now moot. I will have to fix my NamespaceFilter. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sun Jan 31 21:27:54 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:08:20 2004 Subject: XML query engines: was RE: Is XML dead already or what? References: <001701be4d48$3e3d6e70$d3228018@jabr.ne.mediaone.net> Message-ID: <36B4CA38.2FC8@hiwaay.net> Borden, Jonathan wrote: > >My personal opinion is > that it is a hybrid relational and 'object' database approach. I don't think this could be disputed easily or without resort to specialized application requirements. It has been done like this in many apps for many years. That is why these threads look odd to me. IOW, it is already best practice. I don't think there is a rule, but a rule of thumb is to manage fragments relationally and even author that way, and to package in objects for distribution. It is also very very cheap and works right now with cheap COTS products and no reeducation of the production staff or the users. I guess what is in question is if object management stands up well on the production and server side. Otherwise, packaging and sending SQL queries and getting links, objects or files back is already effective. It might be more interesting to know what requirements there are for more than that. > The problem with a straight relational approach is that we need to model > containment and heirarchies... in SQL terms this means joins, perhaps > multilevel joins when documents are deep. True. HTML works remarkably well for assembling fragments precisely because it is so flat. Let me compare this to a DTD that was deeply nested, recursive, etc. MIL-D-87269 - IETM DB. When delivered out of a relational db, it was quite a chore to reuse it outside the viewer designed for the delivery. The problem was chasing the references to work out how to assemble it. It was doable but it took negotiation of the commuicating parties above and beyond the 87269 spec. That was why the US Navy MID project was done: to create a view package for deliverables. Modeling the hierachies and containment isn't that hard. Typically, filtering it back into a relational db and using SQL works. That is my point about the rough symmetry of functionality between queries, script logic, and DTDs. Which would you rather manage or try to standardize for an enterprise? len bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sun Jan 31 21:30:56 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:20 2004 Subject: SAX: Next Round (Lexical Event Handler) In-Reply-To: <36B21948.5F74CEED@eng.sun.com> References: <199901202122.QAA00962@megginson.com> <36AA93F3.B98FAE05@jclark.com> <36B21948.5F74CEED@eng.sun.com> Message-ID: <14004.51695.816155.975439@localhost.localdomain> David Brownell writes: > > > I haven't checked, but I think that this gives us everything we need > > > for DOM level one. > > Doesn't quite ... there's some more DTD information needed to: > > * ensure that PIs within the DTD (e.g. internal subset) > don't show up anywhere in the DOM tree (ugh); You can determine this using the start/end DTD events and start/end entity events, I think. > * see declarations of external general entities; Do we need the declarations, or just the boundaries -- or, in other words, do we need to provide information about declared but unused external parsed entities? Sorry I'm too lazy to puzzle this out from the spec right now. > * expose values of defaults so that the DOM can ensure > that defaulted attributes always have values; The parser should take care of this. > * distinguish attributes which were defaulted from those > that were explicitly in the document. Yes, this is necessary, as a few others have also pointed out (grumble, grumble). > (In addition the above, if XML namespaces are to be layerable over > a normal XML 1.0 parser, declarations of all other entities need to > be exposed so they can be examined for conformance: they must not > contain colons!) This is probably overkill for SAX -- if someone wants to layer namespaces on top of SAX, they'll have to miss this one. > > I wonder whether LexicalHandler ought to extend DocumentHandler. The > > events it reports are synchronous with the events reported by > > DocumentHandler. It seems to me that applications are always going to > > want to implement either DocumentHandler or both DocumentHandler and > > LexicalHandler. Probably -- the problem is that if we extend Parser then we'll have both a setDocumentHandler and a setLexicalDocumentHandler event, and that causes some funny problems that I'd rather punt. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sun Jan 31 21:36:54 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:20 2004 Subject: What is XML for? In-Reply-To: <009101be4c1e$36a3b1e0$5ef96d8c@NT.JELLIFFE.COM.AU> from "Rick Jelliffe" at Jan 30, 99 06:00:21 pm Message-ID: <199901312225.RAA06172@locke.ccil.org> Rick Jelliffe scripsit: > XML lacks data attributes but compensates somewhat by > forcing entity structure to be synchronous with element structure, so > element's attributes can serve as data attributes (e.g., at the root > element of an entity.) This seems to be a common misconception. External entities which are not document entities need only match the production "content", so they can contain multiple roots or none at all (they can consist solely of PIs, for example). Synchronousness only require that entities contain either all of an element/PI or none. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From glassbox at wanadoo.fr Sun Jan 31 21:48:19 1999 From: glassbox at wanadoo.fr (Glassbox) Date: Mon Jun 7 17:08:20 2004 Subject: XML query engines: was RE: Is XML dead already or what? Message-ID: <001501be4d63$2e4de330$002010ac@wanadoo.fr> >There exists a neat trick which enables simple SQL-Select queries answering >for two given nodes, whether one is a subnode of the other, and also how >many levels deep, in constant time, assuming you do some simple >preprocessing on the structure. (Assigning two integers to each node in the >tree). Can you please explain it precisely ? Thanks, Guillaume xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Sun Jan 31 23:10:33 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:08:21 2004 Subject: Real world DTD In-Reply-To: References: <5F052F2A01FBD11184F00008C7A4A80001136AC8@eukbant101.ericsson.se> <36B0BA28.47849E39@prescod.net> <36B0CE96.4AAEDF97@cs.ucsd.edu> Message-ID: * Elliotte Rusty Harold | | I'm hunting for a large, medium to high complexity DTD for XML for | use as an example in a book. Ideally this DTD should be in the | public domain. Less ideally, I can use a copyrighted DTD where the | owner is willing to sign a permissions agreement allowing me to | quote from it extensively and in its entirety. Any suggestions? Maybe the TEI Lite DTD, which you can find here: Copyright issues seem a little murky, but should be possible to sort out, methinks. Or one step up in size, DocBook 3.1 in XML: David Megginson has already included the SGML version of this one on a CD-ROM with his 'Structuring XML Documents', so there should be hope for you as well. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Sun Jan 31 23:12:41 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:08:21 2004 Subject: Another errata? Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEEC7@RED-MSG-08> Speaking of the idea that unqualified attributes do not have an association with a 'default' namespace, John Cowan wrote "This distinction was introduced into xml-names between the August and September working drafts." That is correct. To be absolutely precise, the technical distinction was recognized by members of the WG substantially before September, but it took until the September draft to get agreement that the current wording best expressed the preferred relationahip. --Andrew xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)