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 na