From db at Eng.Sun.COM Thu Oct 1 00:10:50 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:18 2004 Subject: Sun XML early access References: <199809251348.JAA10494@hesketh.com> <360BA810.8595E905@infinet.com> Message-ID: <3612AB7E.9A237E7@eng.sun.com> Tyler Baker wrote: > > When parsing Jon Bosak's ot.xml I get out of memory errors on the second try, > even after trying to reclaim memory from the first try (I had to write my own > benchmarks as the there were none supplied.). For the record, even when using the program Tyler sent, we were not able to reproduce any memory problems. That suggests some sort of configuration-specific problem. - 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 db at Eng.Sun.COM Thu Oct 1 00:24:23 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:19 2004 Subject: Sun XML early access References: <026501bde8dd$e7132550$2ee044c6@arcot-main> Message-ID: <3612AEA4.15F483D@eng.sun.com> Don Park wrote: > > I have looked at the DOM implementation only and found that: > > 1. sibling-based navigation is considerablly slower than index-based > navigation. This issue was listed in the release notes; as Don noted, easily fixed. > 2. getElementsByTagName is not efficient. Or rather, actually _using_ the result can cost. "Liveness" for this stuff wasn't universally liked, since the indices are not stable. (Two calls to item[i] can return different values.) This is another case of an optimization that could be kicked in sometime if it matters. There is a fast alternative available. > 3. Output needs more design work. > > One needs to subclass to override output and there is no built in support > for conversion to other formats. For example, you can not write out a DOM > Document as HTML without some serious patching or overriding. Actually, it's easy to write out a DOM document as HTML if you have a bean to address the different handling of EMPTY tags (for the "HR", "BR", etc) in HTML. We've had plenty of cause to do so ... ;-) There's nothing preventing writing out in any format whatever, though the write(Writer) method on all nodes could clearly be renamed to be more suggestive of writing XML !! > 4. XML Bean concept is a little disappointing for what it does. > > I am afraid I can not go into details about this due to Docuverse's own work > in this area but Sun needs to broaden their view of what a bean is. Sun has some very broad notions of what beans are; we did coin the term, and do have ongoing work in that area! THIS kind of bean was only there to address a common solution to a common problem. As other discussion has noted, there are quite a few ways to use Beans with XML. We're open to suggestions. - 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 srn at techno.com Thu Oct 1 02:20:50 1998 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:05:19 2004 Subject: Ownership of Names (was Re: Public identifiers and topic maps) In-Reply-To: <36126C05.271C6471@nina.snohomish.wa.gov> (message from Frank Blau on Wed, 30 Sep 1998 10:36:05 -0700) References: <3.0.5.32.19980926140208.0095fc10@dns.isogen.com> <360C0929.A4DC3C69@locke.ccil.org> <360C0929.A4DC3C69@locke.ccil.org> <3.0.5.32.19980926140208.0095fc10@dns.isogen.com> <3.0.5.32.19980928103117.00966620@dns.isogen.com> <3.0.5.32.19980928135613.00993d70@dns.isogen.com> <3.0.5.32.19980928171700.00958ba0@dns.isogen.com> <3.0.5.32.19980929104734.008fd660@dns.isogen.com> <3.0.5.32.19980929121602.0096b100@dns.isogen.com> <361269E1.6069227E@locke.ccil.org> <36126C05.271C6471@nina.snohomish.wa.gov> Message-ID: <199810010019.TAA02291@bruno.techno.com> [Frank Blau:] > Can we stop arguing about what are essentially personal, political > and/or philosophical positions and get back to xml development > issues? I can't believe I'm reading about whether or not > "acceptation" is "sui generis"... I was surprised to learn that this discussion had no bearing on XML development issues. I have long thought that a necessary part of understanding a problem is touring its perimeter. Of course, one man's perimeter is another man's outlands. Perhaps, Frank, you'll enlighten us as to the issues that, when they are discussed in this forum, will meet with your approval. Please make sure your list will not allow anyone to tread on any personal, political and/or philosophical positions, and don't forget to clarify exactly where the perimeter is. -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 smith at interlog.com Thu Oct 1 06:34:40 1998 From: smith at interlog.com (Chris Smith) Date: Mon Jun 7 17:05:19 2004 Subject: Binary Data in XML (a first pass?) In-Reply-To: <3.0.32.19980930090817.00b61210@pop.intergate.bc.ca> Message-ID: On Wed, 30 Sep 1998, Tim Bray wrote: > From: Tim Bray > Subject: Re: Binary Data in XML > > Suppose I wrote up a NOTE, should occupy less than one page, proposing > a reserved attribute xml:packed with, for the moment, only two > allowed values, "none" and "base64". The default value is "none". > If an element has xml:packed="base64" this means that > > (a) the content of the element to which this is attached must be > pure #PCDATA, no child elements and no references, and > (b) the content is encoded in base64, leading and trailing spaces allowed If I may be so bold -- this was addressed in the development of Open Trading Protocol, and we simmered it down to a concise form. Don Park and Gavin McKenzie helped sift out an standalone form, which then went *back* into the OTP group. The result is summarized below, minus most of the document surrounds. Use of this internally in OTP has allowed for encapsulation and a framework structure without a lot of development overhead. ---------------------------------------------------------------- XML Packaging Basic Goals It is suggested that you read the entire document, since there are some forward references in the Goals section that may only make sense after reading through the whole thing. 1) Inclusion of a variety of items This variety of items can potentially be defined dynamically by the groups/parties/systems involved. Some systems will be "static" implementations - not driven directly by the DTD, but using a parser and embedding the understanding of the DTD in the system itself. It is for this reason that parameter entities are not used. Some people will only develop their system from the DTD, not run their system using it. 2) Simplest possible inclusion of plain text items This means so simple that it should look like PCDATA. More to the point, XML can already handle the plain text case, so we should not have to step out to something else (MIME or otherwise) to handle plain text. 3) Easy inclusion of graphic or other binary entities. This is for the cases where most groups would agree what is desired (ie a GIF or JPEG), but XML does not allow for direct embedding. This is the target for the MIME:mimetype allowance. Data can be directly converted using standard BASE64 routines, and no generation or checking of headers needs to be done. 4) Leverage MIME power! This is the origin of the generalized MIME allowance. In particular, MIME:mimetype simply can?t work with multipart types. 5) Allow for private customization. This is a somewhat contentious inclusion. It can be argued that private customization can already be achieved using the MIME application/x-private notation, so why duplicate that capability? However, there is a growing body of XML ?private customization?, and it would be preferable not to have to go through MIME in order to get to it. The XML content provides a straightforward indication that the content, likely straight PCDATA (not transformed), is an embedded XML document, perhaps XML/EDI. I also think this is wise, since those doing there work in XML may not provide a standardized private MIME label for their work. For exactly the same reasons, the general MIME availability should be kept as well. If a group has a reasonably standardized MIME label for a private custom format, then we need the full MIME capability to support it. Finally, the x-ddd:usercode version has already proven useful where different parts of a system may communicate using this mechanism, because it?s easier than trying to communicate through a (non-existent!) private channel. 6) To be used in place of ANY ANY content is understandably difficult to parse. There may or may not be guidelines to help you. It is preferable to match extensibility with a little more structure. DTD For Package This then leads to a very compact DTD item (more definitions below). Note that any special details, especially custom attributes, must be represented at a higher level. For example: Detailed interpretations of the attributes follow: Attribute: content The content attribute defaults the the value "PCDATA", to imply that the content consists only of legal PCDATA characters for XML. When used in this manner, the content of the Package element effectively substitutes for a simple #PCDATA content in the parent element. Attribute value for "content": PCDATA The content of Package can be treated as PCDATA with no further processing. Attribute value for "content": MIME The content of Package is a complete MIME item. Processing should include looking for MIME headers inside the Package content. Attribute value for "content": MIME:mimetype The content of Package is MIME content, with the following headers implied: Content-Type: mimetype Although it is possible to have MIME:mimetype with transform="NONE", it is far more likely to have transform="BASE64". Note that if transform="NONE" is used, then the entire content must still conform to PCDATA. Some characters will need to be encoded either as the XML default entities, or as numeric character entities. Attribute value for "content": XML The content of Package can be treated as an XML document. This document may include an XML declaration, and it may refer to a different DTD than that of the enclosing document. Character entities and CDATA sections, or transform="BASE64", must be used to ensure that the Package contents are legitimate PCDATA. Enclosing a raw XML document will cause parsing errors while attempting to parse the enclosing document. The well-formedness or validity of the document inside the Package has no effect on the parsing of the enclosing document. Obviously, a non-well-formed or invalid inclusion may still cause errors within an application. However, for some reasons, such as user support, there are legitimate reasons to enclose XML documents that are not well-formed. Attribute value for "content": x-ddd:usercode The content is private, where ddd represents a domain name of a user, and usercode represents a particular content format defined by that user. The guidelines around a x-ddd are very loose. Given company FFGGHH Inc, all of x-www.ffgghh.com, x-ffgghh.com and x-ffgghh are legitmate examples. However, only one should be the correct format, as defined by FFGGHH Inc. The usercode mechanism is intended to reduce the possibility of content attribute collisions, not to provide a mechanism that can eliminate them entirely. Attribute: transform Attribute value for "transform": NONE The PCDATA content of Package is the correct representation of the data. Note that entity expansion must occur first (ie replacement of & and ) before the data is examined. CDATA sections may legimately occur in a Package marked transform="NONE". Attribute value for "transform": BASE64 The PCDATA content of Package represents a BASE64 encoding of the actual content. Although entity expansion must occur before decoding of the Base 64 stream, it is not expected that this will happen under normal circumstances. ...Chris Smith ...Don Park ...Gavin McKenzie --------------------------------------------------------------------------- Chris Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Oct 1 07:13:52 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:19 2004 Subject: Web server logs in XML? Message-ID: <017601bdecfa$396b89d0$2ee044c6@arcot-main> Dave Winer wrote: >Bill, thanks for the link, here's where I found the spec: > >http://www.docuverse.com/xlf/NOTE-XLF-19980721-all.html > >But it's not much of a spec. Certainly not ready to be implemented from. > >I'd love to see an example XML log file. Or a pointer to one. Dave, You are right about the first draft of the XLF spec being not much of a spec but a list of ideas and promises (you were always good at cutting through the bull#$!@). If you want an example, you will have to make one up yourself because there isn't one except for the fragments found in various XLF documents, proposals, and the archived messages. The XLF Initiative is currently in a limbo because I was too busy to lead it properly. Alex Sirota of Everyware volunteered to be the new Chair and we will see some forward movement soon. At last count, the XLF Initiative had about 60 members so once the spec is done, we can expect swift adoption by the industry. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ax at href.com Thu Oct 1 08:18:11 1998 From: ax at href.com (Michael Ax) Date: Mon Jun 7 17:05:19 2004 Subject: Web server logs in XML? In-Reply-To: <017601bdecfa$396b89d0$2ee044c6@arcot-main> Message-ID: <199810010617.XAA02845@sub.sonic.net> Hello. Please pardon my chiming in... I try, but I'm not quite up to speed with everything that's going on here and I have the nagging suspicion that I am missing something big. Could someone please explain to me the difference why one would want to, oh, lets be conservative, quadrupple the amount of data to be processed by logging XML-enties rather than using XML to describe the structure of the data? It makes a lot of sense to me to think about each log-entry as an XML entity, but I have a hard time fathoming that anyone would want to go to the extreme which I understand is being discussed here. I have close to 10gb of web-server logs from the last 2 yrs and while this is theoretically appealing I, perhaps short-sightedly, have read everything that goes on here with an eye toward using XML as a, well, markup language used for universal exchange, not as the be-all & end all of native data-storage. But perhaps I've ignorantly assumed that there would be something like a log/data file and an XML description of the data which I could use as inputs to filters that would have the ability to let me seek through and utilize such data and which might perhaps have the smarts to translate/copy/move contents from one meta-data-structure to another. .. sort-of, kind-of like an object-oriented file-system might. e.g. what's the benefit of this crazy seeming thread-subject, and why don't I get it? So, can somebody please elaborate or point me to more info about how XML and Meta-Data are supposed to co-exist these days or to whatever happened to the great database debate? Did someone kill the DBAs? Who's keeping score? I have no question that XML will grow to rule the world, but I'm trembling at the thought that somebody might take all of the science discussed here a bit to literally and force me to get another 5 or 6 10gb drives and make me keep my logs in raw xml. Many thanks, Best Regards, Michael Ax p.s. the log file business if doubly scary in light of my experiences that 3NF typically nets a 16:1 compression. Am I misreading something? Is XML trying to describe a storage or a representation/exchange format? are there proposals for middle-layers/ translation filters? os-plug-ins? At 10:11 PM 9/30/98 , Don Park wrote: >You are right about the first draft of the XLF spec being not much of a spec >but a list of ideas and promises (you were always good at cutting through >the bull#$!@). If you want an example, you will have to make one up >yourself because there isn't one except for the fragments found in various >XLF documents, proposals, and the archived messages. .. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Thu Oct 1 10:39:46 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:05:19 2004 Subject: LISTADMIN. Archives and List errors Message-ID: Two list admin items 1) I have archived the list up to September on http://emily.ch.ic.ac.uk/listarch/xml-dev/index.html This is a direct link to the CD-ROM image, that will be mastered shortly. The collection has been indexed to mid September, and I will re-index to end of Sept shortly. Any comments, offers of extra materials etc must be sent within THREE days, or forever hold your peace! 2) The "decay rate" for registered accounts on this list that no longer work continues at about 10 per week. This is often because a) local email handling at the user's end is changed/reconfigured, and the email account which the user uses to post changes slightly. For example, john.doe@somewhere.com changes to jd@somewhere.com, or perhaps jd@machine.somewhere.com changes to jd@somewhere.com. Changes like this will result in the user being unable to post to the list, resulting in confusion for them, and time needed by Peter, myself and others to analyse and suggest fixes to the problem. b) The user leaves their organisation, but does not unsubscribe their xml-dev registration, or expects us to "track" their changed email details. c) Changes in a number of email handling programs can mean that only DNS registered clients can now post to eg POP servers. This happened to us a few weeks ago, and its amazing how many unregistered computers were flushed out of the system (some people assume that an IP address can be assigned arbitrarily out of a range of 256 numbers). This causes us to receive "we do not relay" messages. I repeat again that when we receive what looks like "hard" errors, I will unsubscribe these unilaterally. Much as I would like to eg contact the postermaster at the remote site and sort things out, I just do not have the time and resources to do this. Increasingly also, I am beginning to take a less generous view of mailboxes that report "quota exceeded" for 1 week at a time. Any mailbox that is over quota for more than a few days we assume is moribund. So if you find yourself suddenly not receiving mail, please do not assume sinister actions on our part. Chances are it may be due to local changes at your end, or apparent hard errors at our end resulting in unsubscription. A simple resubscription, using the mode mailto:majordomo@ic.ac.uk with the message subscribe xml-dev (or) subscribe xml-dev-digest should resume service for you. It is my fervent wish that we will shortly move to a much superior list handling system (perhaps Lyris) with much improved service. However, the timescale for this is entirely out of my hands. Best wishes (and apologies for the long message) Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ If my digital email signature is invalid, download a new root at http://www.belsign.be/en/services/receive/install-ca.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amitr at abinfosys.com Thu Oct 1 11:19:05 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:19 2004 Subject: Confusion regarding notation processing Message-ID: <01b001bded1c$b3fab0a0$0101a8c0@server.abinfosys.com> Hello, After having read about the purpose/declaration of NOTATIONS in XML from the spec. I had a ques. :- I have a sample xml file :- ]> When a VALIDATING xml processor will start processing the above, will it only pass * Notation name (MyFormat in above case) * Notation System Identifier (MyFormatProcessor.exe) * Entity systm. identifier (MyFormatData.txt) to the application (on behalf of which the xml processor is validating) , or is it also expected to pass the non XML data file(MyFormatData.txt) to it's related process (MyFormatProcessor.exe) and initiate the processing? Thanks in advance, AMIT REKHI xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Oct 1 11:33:55 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:19 2004 Subject: Web server logs in XML? Message-ID: <000c01bded1e$8ee5d270$2ee044c6@arcot-main> Michael, >I have no question that XML will grow to rule the world, but I'm trembling >at the thought that somebody might take all of the science discussed here a >bit to literally and force me to get another 5 or 6 10gb drives and make me >keep my logs in raw xml. 1. Using XML just for describing the structure of the data makes no sense because you can not use generic XML tools to process the data. 2. Compression reduces file size difference to 10%-30%. 3. Cost of 10 Gig drives will be considerablly less by the time server vendors stop supporting legacy log formats. 4. Due to the Y2K problem, concerns for compactness is equated with shortsightedness these days. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ax at href.com Thu Oct 1 11:59:28 1998 From: ax at href.com (Michael Ax) Date: Mon Jun 7 17:05:19 2004 Subject: Web server logs in XML? In-Reply-To: <000c01bded1e$8ee5d270$2ee044c6@arcot-main> Message-ID: <199810010959.CAA29299@sub.sonic.net> Hi Don, thanks for trying, but I don't think you're really speaking to my questions here! >1. Using XML just for describing the structure of the data makes no sense >because you can not use generic XML tools to process the data. hence my observations re filters and oo file systems. >2. Compression reduces file size difference to 10%-30%. 3rd nf reduces log files by 16:1 without compression. >3. Cost of 10 Gig drives will be considerablly less by the time server >vendors stop supporting legacy log formats. n* 4++ will still be far more >4. Due to the Y2K problem, concerns for compactness is equated with >shortsightedness these days. by whom? - Cheers, Michael xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 1 13:01:41 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:19 2004 Subject: Ownership of Names In-Reply-To: <199810010019.TAA02291@bruno.techno.com> References: <36126C05.271C6471@nina.snohomish.wa.gov> <3.0.5.32.19980926140208.0095fc10@dns.isogen.com> <360C0929.A4DC3C69@locke.ccil.org> <360C0929.A4DC3C69@locke.ccil.org> <3.0.5.32.19980926140208.0095fc10@dns.isogen.com> <3.0.5.32.19980928103117.00966620@dns.isogen.com> <3.0.5.32.19980928135613.00993d70@dns.isogen.com> <3.0.5.32.19980928171700.00958ba0@dns.isogen.com> <3.0.5.32.19980929104734.008fd660@dns.isogen.com> <3.0.5.32.19980929121602.0096b100@dns.isogen.com> <361269E1.6069227E@locke.ccil.org> <36126C05.271C6471@nina.snohomish.wa.gov> Message-ID: <3.0.1.16.19981001114226.722f1484@pop3.demon.co.uk> At 19:19 30/09/98 -0500, Steven R. Newcomb wrote: >[Frank Blau:] >>When I talk to people about XML, one of the "problems" I identify is the >>overabundance of navel-gazing academic esoterica in the standards >>committees... >>This list provides more examples of that than anything else (short of >>Dilbert)... The conception of XML-DEV was that it should act as a medium for people to develop and support XML, primarily through the contribution of code (especially OpenSource) and other resources (designs, protocols, examples, tutorials, etc.) I would contend that it has been extremely successful in this and that it has held fairly closely to this main track. The most obvious example is SAX - virtual conductor David Megginson with 100-strong orchestra - but XSchema is a worthy successor. The very recent discussion on xml:encoded/packed/content also shows how a simple but critical idea can be discussed quickly and taken forward. I am hoping very much that something comes out of the current discussion on Objects. And there is a constant stream of announcements of resources. >> Can we stop arguing about what are essentially personal, political >> and/or philosophical positions and get back to xml development >> issues? I can't believe I'm reading about whether or not >> "acceptation" is "sui generis"... > >I was surprised to learn that this discussion had no bearing on XML >development issues. I have long thought that a necessary part of >understanding a problem is touring its perimeter. Of course, one >man's perimeter is another man's outlands. > In the early days of the list I occasionally gently suggested that 'discussion' - as opposed to action - should be limited. But I have taken a more relaxed view recently. Personally I would like to see more *action* on name management - I don't believe that FPIs will be very much use in XML unless something provides a way of them working. We have already had an initiative on this list to develop Catalogs for XML and that would be extremely useful. Software for processing and normalising FPIs would also be welcome (since the syntax is still opaque to me). So - although *I'm* an academic - most of the members of this list aren't and most (including me) have to justify the time they spend on it. I think you'll find that for a voluntary virtual community with no real-life organisation other than Henry Rzepa, me and a 'free' list-serv the productivity is very high. A general phenomenon is that *names* and *classifications* are extremely likely to cause differences of opinion - not just here, anywhere. These can get very heated. My next posting will be a concrete proposal for the creation of an API for element-oriented programming. I'm optimistic we shall make progress... 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 amitr at abinfosys.com Thu Oct 1 13:09:16 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:20 2004 Subject: NOTATION Example (was Re: Binary Data in XML) Message-ID: <01f201bded2c$bd8fe530$0101a8c0@server.abinfosys.com> James, >others are unparsed entities and PI targets which I can also give examples of if anyone would like. Could you pass on some examples of notation use with PI targets? > > > I was wondering what these system identifiers contain. Are they validation routines that would check syntax of the content of elements with which they are attached. (provided the notations are used in attributes as you suggested in your example) eg. would the system identifier http://www.schema.net/usdate.not check the element content with which it is attached for USDATE syntax? 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 peter at ursus.demon.co.uk Thu Oct 1 13:18:09 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:20 2004 Subject: SOX: was Re: XML and Objects In-Reply-To: <36111763.8EC60A9A@eng.sun.com> Message-ID: <3.0.1.16.19981001121803.744fdd8c@pop3.demon.co.uk> I'd very much like us to explore how we can produce an interface/protocol for element/object-oriented programming. This has been catalysed by the early release of the SUN code (many thanks) and the discussion over the last week. As noted, the DOM provides an excellent basis for this but it doesn't go far enough. Since SUN, Steve Withall, coins, JUMBO, et al. have all gone a little way down this road it seems critical that we investigate what common ground we have before we have needless bifurcation. I'll use the code SOX for this idea (unless people prefer Simple Element-oriented XML). This is a very brief outline. When a Document is created in the DOM the elements are of identical class (ElementNode?). SUN and JUMBO add a layer where subclassed objects are generated according to the elementName (and possibly other criteria). These objects may have further methods for display and non-display purposes. If we are going to have interoperable software then this is an area we should regularise ASAP. To contrast SUN and JUMBO2. SUN has an XmlDocumentBuilder which is passed a list of props. These come from a *.props file where elementNames are mapped onto classes. The XmlDocumentBuilder (I don't have the code) creates new Instances of each subclassed object when SAX processes the event. Additional element-specific operations can be added through a doneParse(URI) method which a subclass can override. JUMBO (which was started pre-DOM and old namespaces) uses a PI to map namespaces onto code - a legacy of the src= attribute. It's not pretty but it works. It has a method processXML() which is called from SAX when an endElement event is encountered. [I suspect it's very similar to doneParse().] When I create MoleculeNode I endow it with JUMBO methods and therefore it doesn't interoperate with SUN. I would be delighted to agree publicly on how to do this now. If we leave it we shall be too late and we shall have applications-specific )and possibly platform-specific element-oriented programming. This would be very sad. Here are some general points which I think we need to address now. - how do we map elements onto classes. Property file? Regexps in PIs? Stylesheets? or a mixture - what are the *non-graphics* methods for an element , e.g.: doneParse()/processXML() isValid() [i.e. non-XML validation - type, values, etc.] write() - recreate XML or other formats - what are the graphics methods onClick(count) redraw()/resize() etc. Rather than try to list more I'd like to see coordinated discussion a la SAX. In that case David Megginson offered to take XML-DEVers through a series of questions which he then collated and re-offered. The initial pass took only a calendar month (including year-end). But he worked VERY hard. Can we have volunteers for this? It's one of the most critical aspects of XML at present that is not covered by other WG programs (if this is covered by DOM 2.0 can we wait for this? An XML-DEV API could be a valuable creation anyway). 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 dave at userland.com Thu Oct 1 13:26:05 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:05:20 2004 Subject: Web server logs in XML? In-Reply-To: <017601bdecfa$396b89d0$2ee044c6@arcot-main> Message-ID: <3.0.5.32.19981001042002.010b6560@scripting.com> Don, I think this problem is so straightforward, so easy to solve, and so easy to know what the user (a web server sysop) needs. I'll take a stab at producing some XML-formatted logs on one of our servers, probably in the next few days, and send a link to this list so people can review it. This is a good place to attack the chicken-egg problem. I'm glad there are 60 people interested, hopefully some of them write web servers. Dave At 10:11 PM 9/30/98 -0700, you wrote: >Dave Winer wrote: >>Bill, thanks for the link, here's where I found the spec: >> >>http://www.docuverse.com/xlf/NOTE-XLF-19980721-all.html >> >>But it's not much of a spec. Certainly not ready to be implemented from. >> >>I'd love to see an example XML log file. Or a pointer to one. > >Dave, > >You are right about the first draft of the XLF spec being not much of a spec >but a list of ideas and promises (you were always good at cutting through >the bull#$!@). If you want an example, you will have to make one up >yourself because there isn't one except for the fragments found in various >XLF documents, proposals, and the archived messages. > >The XLF Initiative is currently in a limbo because I was too busy to lead it >properly. Alex Sirota of Everyware volunteered to be the new Chair and we >will see some forward movement soon. At last count, the XLF Initiative had >about 60 members so once the spec is done, we can expect swift adoption by >the industry. > >Best, > >Don Park >Docuverse > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > -------------------------------------- http://www.userland.com/directory.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Thu Oct 1 13:26:06 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:05:20 2004 Subject: Web server logs in XML? In-Reply-To: <199810010617.XAA02845@sub.sonic.net> References: <017601bdecfa$396b89d0$2ee044c6@arcot-main> Message-ID: <3.0.5.32.19981001042700.010b5ad0@scripting.com> Michael: Here's what I would do with those XML logs, I'd read them into a database and throw away the tagged text. Even then, the log info in the database probably won't be as compact as a straight ASCII text file, but I'll be able to write scripts that get me more info from them. There's also a certain amount of hunting for the killer app going on. I don't think anyone really knows what it's going to be or if for sure there's going to be one. For example, a lot of people think it's going to be a search engine, or that XML is going to replace HTML, but I see no evidence of that, and neither of these make sense to me. Anyway, the main reason to store log files in XML is so that XML-aware apps can read them and process them. Maybe there's no gold in this here hill, but why not give it a try and see? It's at most two days worth of work. Not a big deal. And those big hard disks are coming down in price, thankfully! Dave At 11:21 PM 9/30/98 -0700, Michael Ax wrote: >Hello. > >Please pardon my chiming in... I try, but I'm not quite up to speed with >everything that's going on here and I have the nagging suspicion that I am >missing something big. > >Could someone please explain to me the difference why one would want to, >oh, lets be conservative, quadrupple the amount of data to be processed by >logging XML-enties rather than using XML to describe the structure of the >data? > >It makes a lot of sense to me to think about each log-entry as an XML >entity, but I have a hard time fathoming that anyone would want to go to >the extreme which I understand is being discussed here. > >I have close to 10gb of web-server logs from the last 2 yrs and while this >is theoretically appealing I, perhaps short-sightedly, have read everything >that goes on here with an eye toward using XML as a, well, markup language >used for universal exchange, not as the be-all & end all of native >data-storage. > >But perhaps I've ignorantly assumed that there would be something like a >log/data file and an XML description of the data which I could use as >inputs to filters that would have the ability to let me seek through and >utilize such data and which might perhaps have the smarts to >translate/copy/move contents from one meta-data-structure to another. .. >sort-of, kind-of like an object-oriented file-system might. > >e.g. what's the benefit of this crazy seeming thread-subject, and why don't >I get it? > >So, can somebody please elaborate or point me to more info about how XML >and Meta-Data are supposed to co-exist these days or to whatever happened >to the great database debate? Did someone kill the DBAs? Who's keeping score? > >I have no question that XML will grow to rule the world, but I'm trembling >at the thought that somebody might take all of the science discussed here a >bit to literally and force me to get another 5 or 6 10gb drives and make me >keep my logs in raw xml. > >Many thanks, > >Best Regards, >Michael Ax > >p.s. the log file business if doubly scary in light of my experiences that >3NF typically nets a 16:1 compression. Am I misreading something? Is XML >trying to describe a storage or a representation/exchange format? are there >proposals for middle-layers/ translation filters? os-plug-ins? > > >At 10:11 PM 9/30/98 , Don Park wrote: >>You are right about the first draft of the XLF spec being not much of a spec >>but a list of ideas and promises (you were always good at cutting through >>the bull#$!@). If you want an example, you will have to make one up >>yourself because there isn't one except for the fragments found in various >>XLF documents, proposals, and the archived messages. >.. > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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.userland.com/directory.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 jtauber at jtauber.com Thu Oct 1 13:44:56 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:05:20 2004 Subject: NOTATION Example (was Re: Binary Data in XML) Message-ID: <013701bded2f$d31bc420$c26118cb@caleb> -----Original Message----- From: Amit Rekhi >Could you pass on some examples of notation use with PI targets? Well, there isn't really much to show. Say I have a processing instruction for my FOP application: I can declare FOP as a NOTATION and associate it with an external entity: >I was wondering what these system identifiers contain. Are they validation >routines that would check syntax of the content of elements with which they >are attached. (provided the notations are used in attributes as you >suggested in your example) eg. would the system identifier >http://www.schema.net/usdate.not check the element content with which it is >attached for USDATE syntax? They really just provide a way of naming notations (which is why a PUBLIC identifier is often used) but it *can* be an actual bit of code, or a human-readable description of the notation. The notation name itself (in the above example "FOP") provides a level of indirection, like a namespace prefix. You might declare FOP to be a different notation to what I do. But if we both declare FOP to be http://www.jtauber.com/fop/ then we are talking about the same notation. In the case of USDATE, we could adopt a convention (and this is partly what schema.net is intended for so send in those notation requests) that dates of the form MM/DD/YYYY have the notation with external id "http://www.schema.net/notations/usdate" (or whatever) The URI needn't point to a meaningful resource, the key is the URI itself, not the resource being referenced (although it would make sense to at least make it a file with a human-readable description of the notation). In this case, the application would need to know the URIs of notations it can handle. The external id could be referring to a Python function, or a Java class implementing a notation interface, either of which might validate the given content. Hope this helps. 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 olivo at iss.nus.edu.sg Thu Oct 1 14:14:22 1998 From: olivo at iss.nus.edu.sg (Olivo Miotto) Date: Mon Jun 7 17:05:20 2004 Subject: Questions on DCD Message-ID: <48256690.0042CEC6.00@iss.nus.edu.sg> Hi all, I've been looking at the DCD submission and the proposed DTD that was posted here a few days ago, and I have a few points to discuss- I thought this would be the best forum. I hope I'm not asking old questions (I've tried to search the archives, but my connection from SE Asia is very slow). I must point out that I am pretty new to XML, coming from the Software Engineering/OO camp. Some of the questions were prompted by a little exercise I'm doing: writing a DCD description of the DCD DTD. I hope to post it soon. 1) First of all, I'm very excited about DCD. I think it really does take XML into a new realm. I'm a little unclear about the long term strategy though: assuming that DCD is approved, is the aim to be an alternative to (or even replace perhaps) DTDs? Or be a mechanism for defining DTDs? In any case, the triangular relationship XML Document <-> DTD <-> DCD needs some clarification for me. 2) I can understand that compatibility with RDF is a noble target, but I think the interchangeability of Elements and Attributes (DCD section 2.1.2) clouds the water, making it more difficult to process DCD files. I would rather the syntax="explicit" form be the only way of specifying DCD. The remainder of my questions assume this form. 3) A philosophical question: has anyone drawn up a clear functional distinction between attributes and elements? DCD astutely refers to both as properties, and indeed they have things in common. Saying they are interchangeable (or at least that attributes can be changed into elements) is however an oversimplification. It seems to me that attributes are modifiers of the functionality of the element they describe, while elements describe its content. I am not able to formalize this very clearly though. Can someone help? 4) Related to 3): DCD allows elements to also have default and fixed values like attributes. Am I correct in thinking that this is lost when producing a DTD from DCD? 5) Elements and attributes have a lot of datatype-related properties with interdependencies. A number of attributes are only applicable to certain datatypes, etc. As an OO programmer, I think this looks error-prone. I wish DCD had a more structured approach to the definition of property data. Related to this, it seems that there is little consistency between what is defined as an attribute and what is defined as an element. A good example is AttributeDef where, if Values is an element, then Default should also be, as it represents one of the above Values. I think it would be quite nice if some of the attributes were moved out into separated tags, perhaps a tag for max/min/default, a for literal values and their default, etc. Even further, we could have , , , or at least some tags for representing classes of datatypes (, , etc.). If someone is interested in taking this further, I could work out some examples or do a sample DTD. 6) I know this is not going to make me popular, but I think that there are too many datatypes, and they mix storage and presentation formats. It seems to me that, in a text-based format, you should not have to care if an integer is i1, ui1 or whatever. Similarly, why have both char and string? And is there a real need for picture, scale and precision? Do we really need length for strings? Maybe I am not seeing the big picture here... 7) The boolean type should be "True" or "False", not "1" or "0". 8) If in your content you have a single optional element, you must put it in a group. Is this correct? 9) I don't really understand why we need ID-role when we have datatypes of id, idref and idrefs 10) I'm not really sure what is meant by open/closed content. How is it different from ANY and Mixed content? 11) The tag has a space-separated list of values. I know this is a good thing to do if values must be an attribute, but from a DTD viewpoint it would be better as a sequence of tags, e.g. Happy Sad Indifferent I'm sorry this has turned out to be a long message- I would really appreciate some wisdom from the rest of you. Thanks and best regards Olivo ----- Olivo Miotto Technology Expert (Distributed Object Computing) Institute of Systems Science, National University of Singapore olivo@iss.nus.edu.sg Tel: +65-772 6644 Fax: +65-778 2571 ----- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Oct 1 14:16:11 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:20 2004 Subject: was Re: XML and Objects Message-ID: <002601bded35$51689560$02000003@thing1.camb.opengroup.org> From: Peter Murray-Rust >To contrast SUN and JUMBO2. > >SUN has an XmlDocumentBuilder which is passed a list of props. These come >from a *.props file where elementNames are mapped onto classes. The >XmlDocumentBuilder (I don't have the code) creates new Instances of each >subclassed object when SAX processes the event. Additional element-specific >operations can be added through a doneParse(URI) method which a subclass >can override. > >JUMBO (which was started pre-DOM and old namespaces) uses a PI to map >namespaces onto code - a legacy of the src= attribute. It's not pretty but >it works. It has a method processXML() which is called from SAX when an >endElement event is encountered. [I suspect it's very similar to doneParse().] > >When I create MoleculeNode I endow it with JUMBO methods and therefore it >doesn't interoperate with SUN. I would be delighted to agree publicly on >how to do this now. If we leave it we shall be too late and we shall have >applications-specific )and possibly platform-specific element-oriented >programming. This would be very sad. Coins uses an XML Bindings file to define the mapping. I just completed the documentation for Bindings, including examples (if not the entire web page): http://www.jxml.com/coins/index.html >Here are some general points which I think we need to address now. > > - how do we map elements onto classes. Property file? Regexps in PIs? >Stylesheets? or a mixture or XML? I would argue that the mapping should be separate, except when doing object serialization > - what are the *non-graphics* methods for an element , e.g.: > doneParse()/processXML() > isValid() [i.e. non-XML validation - type, values, etc.] The SAX interface, DocumentHandler, works rather well for much of this. > write() - recreate XML or other formats If a document carries a reference to its source, and that source is writable, then UPDATE is vital--I explored this in coins v0. > - what are the graphics methods > onClick(count) > redraw()/resize() etc. I've been looking at graphical elements of late and this looks unnecessary. Just use wrapper elements. But the key here is to support references between the wrapped gui objects. >Rather than try to list more I'd like to see coordinated discussion a la >SAX. In that case David Megginson offered to take XML-DEVers through a >series of questions which he then collated and re-offered. The initial pass >took only a calendar month (including year-end). But he worked VERY hard. > >Can we have volunteers for this? It's one of the most critical aspects of >XML at present that is not covered by other WG programs (if this is covered >by DOM 2.0 can we wait for this? An XML-DEV API could be a valuable >creation anyway). I would be delighted to participate, though I should likely not be the one to chair this. 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 graham.moore at dpsl.co.uk Thu Oct 1 14:27:25 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:05:20 2004 Subject: SOX Message-ID: > peter I agree that the mapping issue is of vital importance. In a similar way to the SUN stuff I've developed a domBuilder that can take an XML file which specifies the class mapping (example file below) , or can look in a given package for classes that match element names and an XML file / stream from which to build the structure. I think there are two points to consider: 1) Possinbly we should be using XML to specify the binding. 2) Leaving scope in the biding spec to allow for the declaration of delegation structures. Given that inheritance is a specialisation of delegation perhaps this should happen anyway. In the same way that arbitrary functional mapping is undesirable so is the arbitrary construction of delegation structures. The issue with using inheritance is that the mixin class must inherit from the elementNode / generic data object class used in the domBuilder. Using delegation and dynamic invocation this is not a problem. consider delObject.tell(objectRef, "method", args); which could be wrapped further system.tell(delObject, "tell", args); where are 0 is the method names and 1 - n are the real args. Internally each member of the delegation structure would have to be aware they were in one but this is generically handled by public class delMemeber { private Object outerSelf; public void doit(){ String att val = (String)system.tell(outerSelf, "getAttribute", args); } } So the delmember would not have to subclass any elementNode object, just implement the delMember interface. public interface delegationMember { private Object outerSelf; void setOuterSelf(Object os); } This means that domBuilder writers subscribe to acknowlege the contract of intialising the classes appropriately and class writers can easily write and bind objects. This does require a bit of a mind set change for one thing there is no compile time error generation. But perhaps this is a price worth paying for a more dynamic, open and flexible system. It would be nice if java supported delelgation and dynamic invocation as part of the langauge; writing it on top seems a bit messy. Example functional mixin file: This is very simplistic but illustrates what we could do. I haven't considered the delegation structure in any real depth. What do people think? graham. gdm@dpsl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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.O'Donnell at fmr.com Thu Oct 1 14:30:20 1998 From: Michael.O'Donnell at fmr.com (O'Donnell, Michael) Date: Mon Jun 7 17:05:20 2004 Subject: unsubscribe Message-ID: <199810011227.IAA17927@gw11xt.fmr.com> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Oct 1 14:50:34 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:20 2004 Subject: Advice needed on placement of XML datatype validation methods Message-ID: <022c01bded3a$bb7f7360$0101a8c0@server.abinfosys.com> Hello, I am in the process of attaching datatype validation routines for element content in my XML file. I have come up with 2 approaches (as listed below)., but am not sure which is a better one. If someone could give their expert opinions .... APPROACH 1 I can use NOTATIONS to identify data validation processes with element content. eg. ]> 123 where AlphabetChecker.vld and NumberChecker.vld could contain validation routines for checking alphabet and number datatypes. APPROACH 2 I embed my datatype validation scripts in the XSL file I attach to my XML data.I can embed my datatype validation scripts in HTML which will be outputted by my XSL file (I am using XSL to do XML -> HTML transformation) for elements in the XML file. In this case I could possibly use (JScript/VBScript/JavaScript) as languages to implement my datatype validation routines. Which of the 2 approaches is better? These 2 approaches bring out the basic questions:- Where to place datatype validation routines for element content, in the XML-DTD or in the XSL file attached to the XML data? Thanks in advance, AMIT REKHI xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Oct 1 14:56:52 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:20 2004 Subject: SOX Message-ID: <002d01bded3b$0f5abc60$02000003@thing1.camb.opengroup.org> I see two distinct things here: 1. Serialization 2. Document processing. When processing a document, the application should decide on the classes to be used depending on (a) the markup language of the document and (b) how the document is to be processed. For serialization, the mapping should be specified in the document. But we should be able to mix these. The serialized objects are a document, conformant to the serialization markup language. And it may be necessary to process it to (a) make it conformant with a revised set of classes or (b) extract information for a previously unintended use. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 1 15:04:18 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:20 2004 Subject: SOX In-Reply-To: > Message-ID: <3.0.1.16.19981001140347.78776698@pop3.demon.co.uk> Quick notes... I am very pleased to see the quick and enthusiastic response. Please keep mailing. And we shall certainly need a virtual chair/conductor. Not me - I don't know quite enough about the terminology - but I will add support to the process. So a volunteer who knows the subject would get the highest XML-DEV accolade. It is possible that the code "SOX" may cause namespace clashes. We iterated for some time till we got "SAX" (avoiding JAX which was toilet in Klingon or something). I thought of SOAPI, knowing it would have to get discarded and so a useful starting point. You can only start suggesting names if you are going to contribute as well :-) At 13:23 01/10/98 +0000, Graham Moore wrote: > > >peter I agree that the mapping issue is of vital importance. In a similar Others have echoed this sentiment. [...] > >1) Possinbly we should be using XML to specify the binding. I would say "certainly" :-) >2) Leaving scope in the biding spec to allow for the declaration of >delegation structures. Given that inheritance is a specialisation of >delegation perhaps this should happen anyway. In the same way that arbitrary >functional mapping is undesirable so is the arbitrary construction of >delegation structures. This is the sort of area I start to get lost ... :-) which is why someone else needs to come forward. Remember that it must be S for SIMPLE. Like SAX. Nothing too cunning or clever. And we need code to be built in parallel. have to rush. 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 M.H.Kay at eng.icl.co.uk Thu Oct 1 15:06:33 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:20 2004 Subject: SOX Message-ID: <001101bded3c$af98f6a0$1e09e391@mhklaptop.bra01.icl.co.uk> > - how do we map elements onto classes. Property file? Regexps in PIs? >Stylesheets? or a mixture In SAXON I use a Java method: setElementHandler(pattern, handler) The pattern is usually an element name but it can also be a simple pattern of the form "parentname/childname". This is, by serendipity, a tiny subset of the XSL pattern syntax. The more sophisticated you make the pattern syntax, the more difficult become the rules for what happens when an element matches multiple patterns; but one approach would be to use XSL patterns as defined. The "handler" in SAXON is an instance of the class that will handle the element but it could equally be the class itself. (The advantage of passing an instance is that the same handler class can then be used for several element types, customised by some parameter in the constructor). It would be easy to add a mechanism that drives these calls from a property file or from PIs in the document; the reverse would be less easy. > - what are the *non-graphics* methods for an element , e.g.: > doneParse()/processXML() > isValid() [i.e. non-XML validation - type, values, etc.] > write() - recreate XML or other formats SAXON calls the following element-handler callbacks: - beforeGroup() before a group of one-or-more consecutive elements of the same type - startElement() - characters() - endElement() - afterGroup() after a group of consecutive elements of the same type The beforeGroup() and afterGroup() are there because I found them useful in doing rendition, e.g. generating HTML lists or tables. The first parameter to the callback is an ElementInfo object which the handler can call. The ElementInfo provides: - navigational methods to determine the context of the element. These include getParent(), getAncestor(), getPreviousSibling(), isFirstInGroup(), etc. etc. Arguably these should all be in the DOM; but the DOM is not very generous in its provision of "convenience" methods. Also, SAXON can provide a lot of context information even in a serial pass that is not building the DOM: it maintains knowledge of the stack and of "previous siblings" of elements on the stack, which I find is sufficient context for many purposes. - the ability to setUserData() and getUserData() on the element instance. These will often be used to create pointers from the "syntactic" (DOM) model of the document to the "semantic" (business object) model. - a set of methods to generate output. These rely on the ability to associate a Writer with either an element type or with an individual element instance, which provides the capability to split a document into parts (which can then, if you like, be recombined in a different sequence). There isn't a specific isValid(), rather any of the other methods has the option to do validation and return an exception if invalid. One thing that isn't in SAXON but is needed is support for IDREF or more generally for XPointer chasing within a document or from one document to another. Don't know if this is in scope for SOX! Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Oct 1 15:23:26 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:20 2004 Subject: SOX Message-ID: <004d01bded3e$c1f11740$02000003@thing1.camb.opengroup.org> From: Michael Kay >One thing that isn't in SAXON but is needed is support for >IDREF or more generally for XPointer chasing within a >document or from one document to another. Don't know if this >is in scope for SOX! In coins v2, I've added both generic support for IDREF and a specialized IDREF for registering an EventListener. I also found it vital, when going to wrapper elements, that the Bindings document specify the class of the application object as well as the class of the wrapper element. --This allows a wrapper element to handle any application object that implements a particular interface. Michael, I love the idea of specifying a pattern rather than just an element name. We should definately borrow from XSL here. I also think IDREF should be in scope, and there again, I like the idea of XPointer. 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 eriblair at mediom.qc.ca Thu Oct 1 15:27:05 1998 From: eriblair at mediom.qc.ca (=?iso-8859-1?Q?=C9ric?= Riblair) Date: Mon Jun 7 17:05:21 2004 Subject: Absent TAGs ... Message-ID: <199810011325.JAA10823@netra.mediom.qc.ca> Greetings, I work with msxml and xml files generated by a database. When a tag value is absent, the database don't generate the tag. In that way, when my scripts try to treat it ... an error occur. How can I bypass this problem. I already try, to attibute the tag to a VAR (in my JScript) and supply and IF statement, but with no result. Thanks for any clue, Eric xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 dvs1.informatik.tu-darmstadt.de Thu Oct 1 15:30:34 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:05:21 2004 Subject: Advice needed on placement of XML datatype validation methods Message-ID: <199810011317.PAA20478@berlin.dvs1.tu-darmstadt.de> Amit Rekhi wrote: > I am in the process of attaching datatype validation routines > for element content in my XML file. I have come up with 2 approaches (as > listed below)., but am not sure which is a better one. If someone could > give their expert opinions .... > > > APPROACH 1 > > I can use NOTATIONS to identify data validation processes with element > content. eg. > > > > > > > > ]> > 123 > > where AlphabetChecker.vld and NumberChecker.vld could contain validation > routines for checking alphabet and number datatypes. > > > APPROACH 2 > > I embed my datatype validation scripts in the XSL file I attach to my XML > data.I can embed my datatype validation scripts in HTML which will be > outputted by my XSL file (I am using XSL to do XML -> HTML transformation) > for elements in the XML file. In this case I could possibly use > (JScript/VBScript/JavaScript) as languages to implement my datatype > validation routines. > > Which of the 2 approaches is better? > > These 2 approaches bring out the basic questions:- > > Where to place datatype validation routines for element content, in the > XML-DTD or in the XSL file attached to the XML data? Of the two, I would probably use notations -- XSL is not yet finished and really has nothing to do with data types. However, you should not assign the data type on a per-element-instance basis as your example shows. This takes up extra space and is prone to errors -- element foo is a number in one case and alphabetic in another, which is probably not what you want. Instead, add a dt attribute for each element type and assign a fixed default. This way, the data type is fixed for a single element type. Eventually, this information should go in a schema file (XSchema/DCD) and a validating processor (or layer) will use built-in routines to do the checking. If you are going to assign datatype attributes, you ought to look at/use the data types in DCD. -- 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 dvs1.informatik.tu-darmstadt.de Thu Oct 1 15:46:12 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:05:21 2004 Subject: SOX Message-ID: <199810011324.PAA20540@berlin.dvs1.tu-darmstadt.de> Graham Moore wrote: > 1) Possinbly we should be using XML to specify the binding. > > [snip] > > Example functional mixin file: This is very simplistic but illustrates what > we could do. I haven't considered the delegation structure in any real > depth. > > > > > > The binding syntax should definitely be XML. I also suggest that it be done in such a way that the bindings can exist in a separate file (as shown in the example) or dropped into a schema file. (In the example above, could exist inside XSchema's ElementDecl element, where the elem attribute would not be set, or directly beneath an XSchema element, ready for reuse elsewhere.) -- 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 tbray at textuality.com Thu Oct 1 15:49:38 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:21 2004 Subject: Web server logs in XML? Message-ID: <3.0.32.19981001063915.00b03cd0@pop.intergate.bc.ca> At 03:03 AM 10/1/98 -0700, Michael Ax wrote: >>2. Compression reduces file size difference to 10%-30%. > >3rd nf reduces log files by 16:1 without compression. I think that the application of XML to things that are (a) large and (b) subject to fancy statistical processing is a good idea mostly as an *interchange* format. For doing heavy analysis, I would definitely cram it into an RDBMS first. On the other hand, it's tough to exchange 3nf data reliably between systems, but trivially easy with XML, and similarly easy to load/unload it to/from whatever fancy repository you're using either end. Also, for archiving it on tape, I think XML wins, because you have a chance of still being able to read it in 10 years. -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 rbourret at dvs1.informatik.tu-darmstadt.de Thu Oct 1 15:49:41 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:05:21 2004 Subject: Absent TAGs ... Message-ID: <199810011341.PAA20695@berlin.dvs1.tu-darmstadt.de> > I work with msxml and xml files generated by a database. When a tag value > is absent, the database don't generate the tag. In that way, when my > scripts try to treat it ... an error occur. How can I bypass this problem. > I already try, to attibute the tag to a VAR (in my JScript) and supply and > IF statement, but with no result. If the element is not required to be present (can be NULL in your database), change the DTD so that it's presence is optional. For example, if the foo element always includes bar but only sometimes includes baz, use the declaration: -- 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 tbray at textuality.com Thu Oct 1 15:49:51 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:21 2004 Subject: Questions on DCD Message-ID: <3.0.32.19981001064417.00b048f0@pop.intergate.bc.ca> At 08:13 PM 10/1/98 +0800, Olivo Miotto wrote: >3) A philosophical question: has anyone drawn up a clear functional >distinction between attributes and elements? DCD astutely refers >to both as properties, and indeed they have things in common. >Saying they are interchangeable (or at least that attributes can be >changed into elements) is however an oversimplification. It seems >to me that attributes are modifiers of the functionality of the element >they describe, while elements describe its content. I am not able to >formalize this very clearly though. Can someone help? Nobody has ever managed to formalize a decision procedure. DCD deliberately takes the view that the declarative tools used to constrain elements and attributes should be as similar as possible so as not to prejudice document designers' selections of what they'd like to use. >6) I know this is not going to make me popular, but I think that there >are too many datatypes I do too, and I've warned my co-editors to expect massive amputations in the committee process, if DCD ever gets taken up. -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 db at Eng.Sun.COM Thu Oct 1 15:52:35 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:21 2004 Subject: namespaces for name attribute values? Message-ID: <36138743.BA181952@eng.sun.com> [Resend, now that I can post again!] -------------- next part -------------- An embedded message was scrubbed... From: David Brownell Subject: Re: namespaces for name attribute values? Date: Tue, 22 Sep 1998 10:52:46 -0700 Size: 1679 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981001/9d7ef408/attachment.eml From db at Eng.Sun.COM Thu Oct 1 15:53:44 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:21 2004 Subject: Switching between DOM and SAX Message-ID: <36138768.938AC1CC@eng.sun.com> [ Resend, now that I can post again ] -------------- next part -------------- An embedded message was scrubbed... From: David Brownell Subject: Re: Switching between DOM and SAX Date: Tue, 22 Sep 1998 10:21:05 -0700 Size: 1569 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981001/4fa74227/attachment.eml From db at Eng.Sun.COM Thu Oct 1 16:34:15 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:21 2004 Subject: SOX References: > Message-ID: <36139204.E744A4A8@eng.sun.com> In the list of antecedents, let's not forget IBM's XML4J which has an "element factory" API for creating specialized elements. (Also, HotJava and Swing internals!) Some of my current thought: - To the extent that we're talking about actual components we are language-specific (preferably Java :-) but it could be useful to think a bit more generally. - I'd prefer to name element types as { namespace uri, tag } rather than with compound strings or a flat namespace. - Issues include how to construct a given node, and (IMHO) the desirability of specialized parse-time interactions to affect/approve the tree(s) constructed. - Depending on special DTDs or DTD rules may be unwise in the general case, and even in the typical one. - Most non-structural operations should be separated. For example, GUI stuff should all be separate interfaces. Some attention to delegation will be important. - Generating customized content. It's no good solving only half the problem, and customization during parsing is "easy" (as suggested by all the results there). - Separating configuration issues (property file vs a more structured XML file vs compiled in defaults vs inferring mappings from packages, etc) from everything else will help. A factory API helps a lot here. Clearly, I agree this is important. - 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 papresco at technologist.com Thu Oct 1 16:59:57 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:21 2004 Subject: Confusion regarding notation processing References: <01b001bded1c$b3fab0a0$0101a8c0@server.abinfosys.com> Message-ID: <36139339.2AC9775D@technologist.com> Amit Rekhi wrote: > > > > > > > ]> > > > When a VALIDATING xml processor will start processing the above, will it > only pass > > * Notation name (MyFormat in above case) > * Notation System Identifier (MyFormatProcessor.exe) > * Entity systm. identifier (MyFormatData.txt) > > to the application (on behalf of which the xml processor is validating) , or > is it also expected to pass the non XML data file(MyFormatData.txt) to it's > related process (MyFormatProcessor.exe) and initiate the processing? I don't think that the XML spec. is very specific about the responsibilities of processors, but the convention in both the SGML and the XML worlds is to pass the information you describe *from the XML document* and let the application handle the actual fetching and processing of the data. Personally, I do not think it is a good habit to point to an executable as the system identifier of a notation. Every notation has an potentially unbounded list of apps that can work with it: printers, renderers, COM components, Java beans, etc. etc. Which one would you put in the system declaration? Paul Prescod - http://itrc.uwaterloo.ca/~papresco Bart: Dad, do I really have to brush my teeth? Homer: No, but at least wash your mouth out with soda. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Oct 1 17:01:31 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:21 2004 Subject: XML and Objects References: <002601bdeafb$4fcda510$d3228018@jabr.ne.mediaone.net> Message-ID: <36139823.BC8990A6@eng.sun.com> Jonathan A. Borden wrote: > > Now to your specific question, if objects are represented in this fashion, > you can access members through interfaces (i.e. Java/C++) through get/set > pairs. A language XML interface layer is needed. This layer is identical to > COM's dispatch layer which allows COM objects to be used from within > Javascript and VBScript. COM uses a binary typelibrary as input. To a first approximation, a type library in COM corresponds to a Java "Class" object. Both let you introspect on methods that are exposed by objects, see interfaces and properties, invoke methods, and so on. Used with JNI, you get inter-language calling. (JNI uses "portable C" -- it's not OS-specific.) > Our > technique takes the SODL document and > > a) generates a typelibrary from it > b) employs a custom interface which is driven by the SODL document > > The advantage of (a) is that it is compatible with existing software > however the software is limited to Windows. Building on that correspondence, one could apply this technique with Java based systems. A specialized DTD could generate a class file. Whoops, whoa, don't bother, just use the Java class in the first place... That is, if you're content to be specific to a given platform (perhaps Java, perhaps Win32/x86 :-) you can do some very interesting tricks. BUT ... it may be desirable to design in a platform-neutral way. Not to ding any particular platform (certainly not Java!); I just want to point out that when using XML with Objects, there are lots of tradeoffs. - Dave > XML-DEV would be an excellent place to develop an independent (b) layer > specification. This spec would certainly need to interface with DOM. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 1 17:05:47 1998 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:05:22 2004 Subject: Questions on DCD Message-ID: Olivo Miotto [mailto:olivo@iss.nus.edu.sg] Wrote: ... >1) First of all, I'm very excited about DCD. I think it really does take >XML into a new realm. I'm a little unclear about the long term >strategy though: assuming that DCD is approved, is the aim to be >an alternative to (or even replace perhaps) DTDs? Or be a >mechanism for defining DTDs? In any case, the triangular >relationship XML Document <-> DTD <-> DCD needs some >clarification for me. 1. It appears that DCD will contribute to a W3C effort that will supercede DTDs. However, DCD (and XSchema) are both currently useful as a higher level language for authoring DTDs. We are using an internal tool that takes DCD-like source (with additional documentation elements) and creates a DTD and accompanying HTMLHelp file. If you would like us to run your DCD description of DCD through our converter and send you the resulting DTD and help files. I'll send you are modifications to the DCD DTD in a private message. >2) I can understand that compatibility with RDF is a noble target, >but I think the interchangeability of Elements and Attributes (DCD >section 2.1.2) clouds the water, making it more difficult to process >DCD files. I would rather the syntax="explicit" form be the only way >of specifying DCD. The remainder of my questions assume this >form. 2. I'm not particularly fond of some of the forms used. There are a lot of things XSchema does more elegantly. >3) A philosophical question: has anyone drawn up a clear functional >distinction between attributes and elements? DCD astutely refers >to both as properties, and indeed they have things in common. >Saying they are interchangeable (or at least that attributes can be >changed into elements) is however an oversimplification. It seems >to me that attributes are modifiers of the functionality of the element >they describe, while elements describe its content. I am not able to >formalize this very clearly though. Can someone help? 3. If you go back in the logs for a topic "Newbie Q" in the end of August, you will find an extensive discussion on this point. Since you indicated that you have problems accessing the archive server, I'll try to forward some of the key discussions. >4) Related to 3): DCD allows elements to also have default and >fixed values like attributes. Am I correct in thinking that this is lost >when producing a DTD from DCD? 4. I think that you are correct. >7) The boolean type should be "True" or "False", not "1" or "0". Typical SGML usage is 1 and 0. >8) If in your content you have a single optional element, you must put >it in a group. Is this correct? >9) I don't really understand why we need ID-role when we have >datatypes of id, idref and idrefs I've made the same comment. >10) I'm not really sure what is meant by open/closed content. How is >it different from ANY and Mixed content? >11) The tag has a space-separated list of values. I know this > is a good thing to do if values must be an attribute, but from a DTD >viewpoint it would be better as a sequence of tags, e.g. 11. Your suggestion is similar to the way XSchema did enumerations. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Thu Oct 1 18:06:06 1998 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:05:22 2004 Subject: Ownership of Names Message-ID: <00cb01bded55$1ccf6980$bcbc77c1@sgml.u-net.com> Eliot Kimber wrote: >As an aside, I note that much of this discussion revolves around issues of the definitions of key terms in the discussion, which is, of course, one of the purposes of topic navigation maps: to define things. I have long stressed the need for definitions to be primary objects in Topic Maps, but have consistently been battered down on the grounds that you don't need definitions for every topic (something I am far from convinced about, especially for maps that are to have a life of more than a few months). The idea of public resources that contain definitions is an acceptable alternative to definitions helped me accept the lack of priviledged definitions. It means that topic maps can share definitions by simply referencing the same set of definitions, so that you could automate relationships between maps. For example, all maps that reference Library of Congress concept XYZ can be considered to be indirectly related to each other. The interesting point is that these same thing can be said about things in Dewey classification 888.999.000 if this can be defined in the same manner. The question is whether a single way of referencing the object is adequate, or whether we should accept that definitions may be known by multiple public identifiers. To me it is paramount that we provide a mechanism for referencing the definitions of topics in a way that makes topic maps interlinkable, and in a way that allows multilingual data sets to be maintained over long periods of time. If we can do this by use of sharable ontologies then we have a chance of linking object sets that otherwise must irrevocably be kept asunder due to the fact they use different names to describe the same concept. Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 1 19:06:22 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:22 2004 Subject: Questions on DCD References: <48256690.0042CEC6.00@iss.nus.edu.sg> Message-ID: <3613B66E.FCA6A14B@locke.ccil.org> Olivo Miotto wrote: > 2) I can understand that compatibility with RDF is a noble target, > but I think the interchangeability of Elements and Attributes (DCD > section 2.1.2) clouds the water, making it more difficult to process > DCD files. I would rather the syntax="explicit" form be the only way > of specifying DCD. The remainder of my questions assume this > form. I agree. As I have said repeatedly, RDF-compatibility means that a format has to be processable by a naive RDF engine, not that the application processing the format has to be able to handle every possible RDF variation. > 3) A philosophical question: has anyone drawn up a clear functional > distinction between attributes and elements? Much sweat has gone into the question of when to use attributes and when to use elements in general. No definitive answers exist. > 4) Related to 3): DCD allows elements to also have default and > fixed values like attributes. Am I correct in thinking that this is lost > when producing a DTD from DCD? Yes. > Related to this, it seems that there is little consistency between > what is defined as an attribute and what is defined as an element. A > good example is AttributeDef where, if Values is an element, then > Default should also be, as it represents one of the above Values. See above. > 6) I know this is not going to make me popular, but I think that there > are too many datatypes, and they mix storage and presentation > formats. It seems to me that, in a text-based format, you should not > have to care if an integer is i1, ui1 or whatever. Similarly, why have > both char and string? And is there a real need for picture, scale and > precision? Do we really need length for strings? Maybe I am not > seeing the big picture here... The idea is to be able to preserve the datatype limitations of the source, so that an exact re-creation of it is possible from the XML version. I agree that the current version is a mess, though. > 9) I don't really understand why we need ID-role when we have > datatypes of id, idref and idrefs Neither do I. > 10) I'm not really sure what is meant by open/closed content. How is > it different from ANY and Mixed content? Open content has to be modeled in DTDs by ANY, but really means "this is the desired content, but other elements are not erroneous". SGML/XML DTDs can't express this. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Oct 1 19:22:32 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:22 2004 Subject: Questions on DCD In-Reply-To: <3613B66E.FCA6A14B@locke.ccil.org> References: <48256690.0042CEC6.00@iss.nus.edu.sg> <3613B66E.FCA6A14B@locke.ccil.org> Message-ID: <13843.47614.183559.719452@localhost.localdomain> John Cowan writes: > Olivo Miotto wrote: > > > 2) I can understand that compatibility with RDF is a noble target, > > but I think the interchangeability of Elements and Attributes (DCD > > section 2.1.2) clouds the water, making it more difficult to process > > DCD files. I would rather the syntax="explicit" form be the only way > > of specifying DCD. The remainder of my questions assume this > > form. > > I agree. As do I -- the interchangeability of attributes and elements is an unnecessarilty icky part of DCD, whatever the excuse. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Oct 1 21:22:01 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:22 2004 Subject: Another interesting app Message-ID: <3.0.32.19981001122147.00b02960@pop.intergate.bc.ca> Clever name, too: http://VoxML.mot.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Oct 1 21:36:36 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:05:22 2004 Subject: SOX: was Re: XML and Objects References: <3.0.1.16.19981001121803.744fdd8c@pop3.demon.co.uk> Message-ID: <3613DBA6.1055BB17@mecomnet.de> Peter Murray-Rust wrote: a number of things re "XML and Objects", and closed with the suggestion that it would be useful to focus the discussion on a set of questions. Although I am not the right party to moderate (I'm working in a different language, so the compatibility issues are academic), I would like to point to several essential questions which I have not yet seen addressed in these terms, as I would hope to see them resolved by whatever process develops. > > ... > > When a Document is created in the DOM the elements are of identical class > (ElementNode?). SUN and JUMBO add a layer where subclassed objects are > generated according to the elementName (and possibly other criteria). These > objects may have further methods for display and non-display purposes. If > we are going to have interoperable software then this is an area we should > regularise ASAP. > > [ contrast SUN and JUMBO2 ] > ... > > When I create MoleculeNode I endow it with JUMBO methods and therefore it > doesn't interoperate with SUN. I would be delighted to agree publicly on > how to do this now. If we leave it we shall be too late and we shall have > applications-specific )and possibly platform-specific element-oriented > programming. This would be very sad. There are several issues here 1. How to identify which behavior to associate with the element identifier? 2. How to identify which storage structure to associate with the element identifier? 3. Which behavior (DOM and/or application object model) is associated? 4. How is the behavior implemented? 5. How is the storage structure implemented? 1: I have found it straight-forward and sufficient to identify the element type through the simple mechanism of class-name lookup. Note that I am working in CLOS, which has a MOP adequate to this purpose. Pre-namespaces I had tended towards an index of dtd/document specific class definitions. With the advent of qualified names, and with the presumption, that definitions used in one document for a unique name should agree with those used for the same name in another document, the per-document qualification is superfluous. In the cl-xml implementation the element identifier simply denotes a symbol. An optional attribute permits instance specific variation. The symbol, in turn, names a DEFCLASS'd class. There is a safety check to ensure that the proper interface is supported, but the basic rule is: if the symbol names a known class, then the element is intended to encode the named class. no tables. no props files. In a CLOS environment, this depends only on a mechanism which identifies lisp packages with xml namespaces. For java, by analogy, a mechanism which identified java packages with xml namespaces would suffice. 2: Since, for my purposes, type and storage are both identified with the class in CLOS, the storage structure is identified through a mechanism identical to that used for type - class name lookup. Because of my approach to 4 and 5, this simplification is reasonable. 3: This is a much stickier problem. As I have followed the discussion, most of it has implied that one and the same instance serves to model both the object which was encoded in XML and the application's view of the related (or even identical) object. I recall only one note which suggested an alternative, that a standard element class model the element specific behavior distinct from application specific classes. I would second this notion. In other words, the XML instance is a model of the application instance for the purpose of encoding it in a serial stream. 4: Issue 3 carries over to the approach to 4 and 5. That is, in most cases the implementation implied by the discussion to date is that inheritance be used to achieve an identity between the element and the application instance. In the alternative note, I recall the suggestion being that a delegation relation extend from the element instance to the application instance. As I have come to understand XML as an encoding standard and not a modeling standard, these suggestions surprise me. Of the three possible forms a. identity between application and encoding instances b. encoding instance delegates to application c. application instance delegates to encoding the latter makes more sense for complex applications. For example, aspects of behavior may not coincide or may vary depending on the encoded content. This means, that a more complex translation process may be necessary in order to decode to the application model than would be appropriate to model in the DOM or its descendants. In some cases, I have found it advantageous to accomplish the translation functionally. In CLOS, the method definition mechanism offers the advantage that it is possible to specialize on multiple arguments. This means that it is possible to define a "translation application" which comprises an application instance and a collection methods which are specialized on the combination of element class and translation application. I have found this degree of specificity to be useful when decoding complex data structures. In the encoding direction, on the other hand method 'c' can be specified fairly directly in the class declaration. 5: For reasons analogous to 3, I find it sufficient to leave untouched the DOM(-equivalent) storage model which is sufficient for element instances. Application specific storage requirements are handled in the autonomous application specific instances. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Oct 2 00:46:14 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:22 2004 Subject: LISTRIVIA: Re: Absent TAGs ... In-Reply-To: <199810011325.JAA10823@netra.mediom.qc.ca> Message-ID: <3.0.1.16.19981001190232.2cbf3fe4@pop3.demon.co.uk> At 09:27 01/10/98 -0400, ric Riblair wrote: >Greetings, > >I work with msxml and xml files generated by a database. When a tag value >is absent, the database don't generate the tag. In that way, when my >scripts try to treat it ... an error occur. How can I bypass this problem. >I already try, to attibute the tag to a VAR (in my JScript) and supply and >IF statement, but with no result. Please do NOT post questions (or other general information) to multiple lists which include XML-DEV. It annoys a lot of people as they subscribe to many lists and get several copies of the question. Also it is extremely difficult to get coherent thread management as replies occur asynchronously on different lists. Choose your list carefully and post to just one. I'm pleased to see you have got an answer on this list anyway. 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 Fri Oct 2 01:11:35 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:22 2004 Subject: SOX: was Re: XML and Objects In-Reply-To: <3613DBA6.1055BB17@mecomnet.de> References: <3.0.1.16.19981001121803.744fdd8c@pop3.demon.co.uk> Message-ID: <3.0.1.16.19981002000723.2f4f3130@pop3.demon.co.uk> Thanks very much - these are very much among the sort of questions that I expect we shall need to address. At 21:46 01/10/98 +0200, james anderson wrote: >Peter Murray-Rust wrote: > >a number of things re "XML and Objects", and closed with the suggestion that >it would be useful to focus the discussion on a set of questions. >Although I am not the right party to moderate (I'm working in a different >language, so the compatibility issues are academic), I would like to point to I don't necessarily think we are limited to Java, though I think that will be the main thrust. From my perspective the client gets at XML element and needs to do something with it. There is no requirement that a particular element is always treated by the same code, any more than (say) there is a universal HTML client. >several essential questions which I have not yet seen addressed in these >terms, as I would hope to see them resolved by whatever process develops. > > >1: >I have found it straight-forward and sufficient to identify the element type >through the simple mechanism of class-name lookup. Note that I am working in Remember that the client simply has an element name to start with. They have to be able to identify a class (regardless of language to associate with it). This could be a planet-wide piece of Java (e.g. org.xmlcml.MoleculeNode.class for element ("http://www.xml-cml.org", Foo)) or it could be a locally mounted 'helper' application - the element is mapped to C:\bin\rasmol.exe. Either way we need a mapping. Some people have suggested mappings are very difficult. I'm more optimistic! > >In a CLOS environment, this depends only on a mechanism which identifies lisp >packages with xml namespaces. For java, by analogy, a mechanism which >identified java packages with xml namespaces would suffice. > >2: >Since, for my purposes, type and storage are both identified with the class in >CLOS, the storage structure is identified through a mechanism identical to >that used for type - class name lookup. Because of my approach to 4 and 5, >this simplification is reasonable. I suspect that in the first instance the storage will depend on the implementation of the processing code. That may be able to offer options (e.g. persistence) but people like me just want to start with something that works for simple cases and build up. > >3: >This is a much stickier problem. As I have followed the discussion, most of it >has implied that one and the same instance serves to model both the object >which was encoded in XML and the application's view of the related (or even >identical) object. I recall only one note which suggested an alternative, that >a standard element class model the element specific behavior distinct from >application specific classes. I would second this notion. In other words, the >XML instance is a model of the application instance for the purpose of >encoding it in a serial stream. I am not quite sure I understand this, but I would agree that the XML is an abstraction of the instance as far as possible. In my own field (molecules) I expect radically different implementations to view and process the same instance since people have different views. (e.g. benzene rings can be represented with single/double bonds or with aromatic bonds). I think this is more than just a style issue. > >4: [beyond me :-)] > >5: >For reasons analogous to 3, I find it sufficient to leave untouched the >DOM(-equivalent) storage model which is sufficient for element instances. >Application specific storage requirements are handled in the autonomous >application specific instances. For many objects I would wish storage which was different from the DOM or SAX representation (e.g. for efficiency of storage). Thus a molecule with 10^5 nodes is very inefficient if stored as nodes, but can reasonably be input and output as such. But I may have missed your point :-) 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 b.laforge at jxml.com Fri Oct 2 02:05:59 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:23 2004 Subject: SOX: was Re: XML and Objects Message-ID: <000801bded98$8b541fc0$02000003@thing1.camb.opengroup.org> From: Peter Murray-Rust >I don't necessarily think we are limited to Java, though I think that will >be the main thrust. From my perspective the client gets at XML element and >needs to do something with it. There is no requirement that a particular >element is always treated by the same code, any more than (say) there is a >universal HTML client. I would say that it depends. If the document was produced by serializing a graph of objects and you are intent on recreating that graph of objects, then you want to use the same classes. Though for this, the markup language used will likely include a simple means of determining which classes to use. Similarly, when there is a common class used by everyone who uses a particular markup language, it is best to use that class. I believe that this will mostly be the case for passive objects specialized at converting between the XML form of the data and the internal form. These conversions may be quite complex for some specialties. (Ever look at the tag structures used by the Library of Congress? I worked 5 years at Penn State University Library and have not since seen anything a tenth the complexity!) In both of the above cases, there may still be occasions when a non-standard mapping may be desired. Now lets look at the other extreme--the document describes a request or action to be performed and is being processed by the server which will handle that request. The request conforms to a particular markup language. This means that the system making the request can be understood by the system that must process the request. The point is that the requestor doesn't know how the server is going to handle the request. So there is no presumption of class mapping. Further, over time the architecture of the server may change, necessitating a change in class mapping. But the markup language need not change. What I like about XML is that it facilitates n-tier and peer-to-peer interactions by placing the emphasis on a well-designed markup language which is descriptive rather than proceedural. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Fri Oct 2 02:15:00 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:23 2004 Subject: Another interesting app Message-ID: <015001bded99$9c5690e0$2ee044c6@arcot-main> >Clever name, too: > > http://VoxML.mot.com/ I designed a very similar system almost two years ago for VOIS which worked remarkably well although not very scalable due to the price of voice recognition back then. It used a variation of HTML called VML (Voice Markup Language) which had voice-oriented tags for annotating text and specifying input parameters. The company went bankrupt so it never saw the light of day. I am happy to see VoxML announced because there is a huge market for such technology. It will be very interesting to apply XSL to VoxML. 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 peter at ursus.demon.co.uk Fri Oct 2 07:48:43 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:23 2004 Subject: SOX In-Reply-To: <36139204.E744A4A8@eng.sun.com> References: Message-ID: <3.0.1.16.19981002064315.2f4f64e4@pop3.demon.co.uk> At 07:30 01/10/98 -0700, David Brownell wrote: >In the list of antecedents, let's not forget IBM's XML4J >which has an "element factory" API for creating specialized >elements. Totally agreed. I should have included xml4j in my list of element-oriented approaches - I just haven't played much with xml4j. And this emphasises the need for creating as much communality at present. My main motivation is to be able to write things like MoleculeNode.class that can rely on a core XML implementation to manage all the non-domain-specific stuff. (I don't actually *enjoy* hacking namespaces, etc. every time they change :-). I'd hate us to get to the stage where we have applications which have to be labelled 'only processable with xml4j... xml-ea1 ... xxx ... jumbo' because we all used different interfaces. Of course there is a level at which we move from an OpenSource-like set of APIs and supporting code to manufacturer-specific toolkits, but I hope we have still a long way to go in the OpenSource direction. >Some of my current thought: > >- To the extent that we're talking about actual components > we are language-specific (preferably Java :-) but it could > be useful to think a bit more generally. Agreed. > >- I'd prefer to name element types as { namespace uri, tag } > rather than with compound strings or a flat namespace. I think this is critical. Every time I now come to an elementName I groan internally ("do I need to support namespaces at this point?"). I feel held back in some things I want to do because if I don't get it right it will cause pain later. > >- Issues include how to construct a given node, and (IMHO) > the desirability of specialized parse-time interactions to > affect/approve the tree(s) constructed. 'approve' means a form of 'validation'? - it seems a useful word. > >- Depending on special DTDs or DTD rules may be unwise in > the general case, and even in the typical one. > >- Most non-structural operations should be separated. For > example, GUI stuff should all be separate interfaces. Some > attention to delegation will be important. I think most of us would agree on this separation. And I suspect that the non-GUI stuff may be a good place to start. > >- Generating customized content. It's no good solving only half > the problem, and customization during parsing is "easy" (as > suggested by all the results there). Could you expand on 'customized content'? Does this mean creating element-specific storage and additional methods? > >- Separating configuration issues (property file vs a more > structured XML file vs compiled in defaults vs inferring > mappings from packages, etc) from everything else will help. > A factory API helps a lot here. > >Clearly, I agree this is important. Very pleased to have your contributions. 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 donpark at quake.net Fri Oct 2 08:28:56 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:23 2004 Subject: SOX (some observations) Message-ID: <001e01bdedcd$dfd6d940$2ee044c6@arcot-main> Here are some comments on element factory API based my experiences with Docuverse DOM SDK design. 1. Document factory is just as important as element factory. Document factory should be registry-based, possibly taking advantage of the Java Activation Framework. 2. Document factory and element factory should not be combined. Docuverse DOM SDK does combine them into a single interface (DOMFactory) and it turns out that there is little benefit and troublesome to combine the two factories. 3. It should be possible to have multiple element factories. This is needed when the user wants to augment the element factory provided by the document factory. 4. Class.newInstance is very slow and should be avoided if possible. Docuverse DOM SDK handles element-specific class instatiation using the Prototype design pattern. For each element type, you provide an instance to the PrototypeFactory and each factory method clones the prototype. This is considerably faster than newInstance. It also allows you to have your own default attribute values as well as 'default' children (i.e. all table elements can have tbody, thead, tfoot elements pre-inserted). Anyway, I am preparing to redesigning the factory framework in the DOM SDK so this SOX effort is very timely for me. 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 graham.moore at dpsl.co.uk Fri Oct 2 11:17:33 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:05:23 2004 Subject: SOX Message-ID: > >I see two distinct things here: > 1. Serialization > 2. Document processing. I think that serialisation is a part of an object system. We are dealing with object systems that can be - potentially - viewed through multiple functional lenses. To enable this we've decided upon a standard way to serialise and instantiate instances - XML and domBuilders. >When processing a document, the application should decide on >the classes to be used depending on (a) the markup language >of the document and (b) how the document is to be processed. I agree. Although I dont think we should think of processing documents. We should view it more generally as invoking operations on an object model. >For serialization, the mapping should be specified in the >document. The elementNode would / should provide the XML serialisation, any further serialisation formats are implemented in the functional mixins, as are the application specific methods. The application will serialise the structure as and when it needs to. If I'm sending my object model to an XML aware process then i'll use the elementNode serialiseXML method, if I'm sending it as the response to a request for a web page then I'll call the mixed-in serialiseHTML method. >> But we should be able to mix these. A delegation model would support the dynamic inclusion and reconfiguration of the functionality of a given instance. Thus providing multiple functional mixins and multiple mixin configurations. graham. gdm@dpsl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Fri Oct 2 14:07:47 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:05:23 2004 Subject: SOX: element<->class mapping References: <3.0.1.16.19981001121803.744fdd8c@pop3.demon.co.uk> <3.0.1.16.19981002000723.2f4f3130@pop3.demon.co.uk> Message-ID: <3614C402.29807915@mecomnet.de> Peter Murray-Rust wrote: > > ... > > Some people have suggested mappings are very difficult. I'm more optimistic! > > > >In a CLOS environment, this depends only on a mechanism which identifies lisp > >packages with xml namespaces. For java, by analogy, a mechanism which > >identified java packages with xml namespaces would suffice. The point is, that the mapping between serial encoding and application data is best separated into two stages: encoding and application modeling. The first is very simple. A minimum of element method specialization is necessary in order to encode / decode application data and type specialization is useful as for method dispatching in the second phase. For this purpose it suffices to declare a relation between java packages and xml namespaces and to use introspection to map from element name to class. One would have standard java packages appropriate for and associated with standard elements. The second (items 3 - 5 in the original note) is more complex. It is also, in my experience, not to be managed by simply identifying the correct class to use to decode the stream. The storage issue (5 and your response) is one example. Another is the issue of (re)integrating xml-encoded data into a data store. Decoding the data is just the first step. The decoded instance is then subject to more complex processing - to check its consistency (validation does not suffice), to translate it into internal form, to bind nominal links to instance data, etc. The first stage should not be burdened with the more complex mechanisms which this second stage requires. It should be kept as simple (and standardizable as possible). If that is accomplished, then the interface between the application and the parser can be set between the two phases. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 2 14:11:26 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:23 2004 Subject: Welcome, DOM! Message-ID: <199810021210.IAA26300@hesketh.com> Congratulations to all involved on the DOM's achieving W3C Recommendation status. Now we officially have a document and document structure format (XML, http://www.w3.org/TR/1998/REC-xml-19980210), a way to style them (CSS2, http://www.w3.org/TR/REC-CSS2), and a way to manipulate them (the DOM Level 1, http://www.w3.org/TR/REC-DOM-Level-1). That's quite a toolset. How are everyone's implementations coming along? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 Oct 2 14:33:45 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:05:23 2004 Subject: Welcome, DOM! References: <199810021210.IAA26300@hesketh.com> Message-ID: <3614C8B7.38CC2A94@infinet.com> "Simon St.Laurent" wrote: > Congratulations to all involved on the DOM's achieving W3C Recommendation > status. Now we officially have a document and document structure format > (XML, http://www.w3.org/TR/1998/REC-xml-19980210), a way to style them > (CSS2, http://www.w3.org/TR/REC-CSS2), and a way to manipulate them (the > DOM Level 1, http://www.w3.org/TR/REC-DOM-Level-1). > > That's quite a toolset. How are everyone's implementations coming along? >From what I can see nothing has changed except two things: (1) strings are now formally defined as DOMStrings which are 16 bit UTF-16 encoded Strings. (2) Attribute's are now Attr's. Why were Attribute's changed to Attr's. In a lot of ways this is sort of trivial but verbosity in API's is almost always better than some shorthand abbreviation. You can read words but not abbreviations. Can someone please clarify the motivation behind this change? I know this sort of issue is trivial but it would be nice to know nonetheless why this change was made. 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 b.laforge at jxml.com Fri Oct 2 14:49:36 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:23 2004 Subject: SOX Message-ID: <003201bdee02$d5798c60$ab026982@thing1.camb.opengroup.org> From: Graham Moore >>When processing a document, the application should decide on >>the classes to be used depending on (a) the markup language >>of the document and (b) how the document is to be processed. > >I agree. Although I dont think we should think of processing documents. We >should view it more generally as invoking operations on an object model. If the Object tree has been constructed using application-specific classes, then the result can take an active role as an agent, rather than a passive role as a DOM. After constructing the object tree, Coins always calls the run method on the root node, providing it implements Runable. Runtime context is provided via the document, which is implemented as an aggregate and a member of a cactus stack of program services. Stated another way, Coins supports XML agents. (OK, perhaps I've spent too much time working on mobile agents. But I really like the idea of agents constructed by a server from classes that it trusts acting on the behalf of clients. This solves a lot of security issues and lets us get out of that non-scalable sandbox!) Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Fri Oct 2 14:58:33 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:23 2004 Subject: Welcome, DOM! Message-ID: <002001bdee04$48966e60$2ee044c6@arcot-main> Tyler Baker wrote: >Why were Attribute's changed to Attr's. In a lot of ways this is sort of trivial >but verbosity in API's is almost always better than some shorthand abbreviation. >You can read words but not abbreviations. Can someone please clarify the >motivation behind this change? I know this sort of issue is trivial but it would >be nice to know nonetheless why this change was made. Attribute was renamed to Attr to avoid conflict with IDL's use of the word Attribute. Simon St. Laurent wrote: > That's quite a toolset. How are everyone's implementations coming along? Coming right along. Arnold's list of PR/REC differences made a big difference. FYI, the Docuverse DOM SDK will be updated over the weekend to support the REC version of the DOM spec. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Oct 2 15:08:30 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:23 2004 Subject: SOX again Message-ID: <003b01bdee05$acafee20$ab026982@thing1.camb.opengroup.org> >From: Graham Moore >>I agree. Although I dont think we should think of processing documents. We >>should view it more generally as invoking operations on an object model. > >If the Object tree has been constructed using application-specific >classes, then the result can take an active role as an agent, rather than >a passive role as a DOM. Sorry for the ramblings. What I meant to say was that invoking operations on an object model seems too narrow a scope. I like to think of the whole thing as document- or net-centric processing, where the focus is on the document or the network of interconnected documents. I fee the oo-view has failed in several ways. When you try to address security issues of mobile agents, you get into a real mess so long as you are dealing with objects--data and logic require distinct security models and need to be handled independently. Which makes sense when you realize that Classes are often pervasive within a small community, while the data is often transitory. XML processing in the most general sense might be thought of as combining data (from the document) with the logic of an application to render some desirable result. Lately I've been thinking of awt components and JavaBeans as the applicaiton logic, and having the objects in the object tree be wrappers which serve to connect the document contents to the application logic. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Oct 2 15:10:51 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:05:23 2004 Subject: Welcome, DOM! References: <002001bdee04$48966e60$2ee044c6@arcot-main> Message-ID: <3614D12C.A4C91D5B@infinet.com> Don Park wrote: > Tyler Baker wrote: > >Why were Attribute's changed to Attr's. In a lot of ways this is sort of > trivial > >but verbosity in API's is almost always better than some shorthand > abbreviation. > >You can read words but not abbreviations. Can someone please clarify the > >motivation behind this change? I know this sort of issue is trivial but it > would > >be nice to know nonetheless why this change was made. > > Attribute was renamed to Attr to avoid conflict with IDL's use of the word > Attribute. Geese it has been a while since I messed with CORBA. I should of caught that myself. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Oct 2 15:10:46 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:24 2004 Subject: Welcome, DOM! In-Reply-To: <002001bdee04$48966e60$2ee044c6@arcot-main> Message-ID: <199810021308.JAA26888@hesketh.com> At 05:57 AM 10/2/98 -0700, Don Park wrote: >Coming right along. Arnold's list of PR/REC differences made a big >difference. Where is this list? Did it sneak by me on XML-Dev? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 alberto.reggiori at jrc.it Fri Oct 2 16:15:20 1998 From: alberto.reggiori at jrc.it (Alberto Reggiori) Date: Mon Jun 7 17:05:24 2004 Subject: SOX References: <3.0.1.16.19981001140347.78776698@pop3.demon.co.uk> Message-ID: <3614DFE9.AF9A9F2@jrc.it> Peter Murray-Rust wrote: > It is possible that the code "SOX" may cause namespace clashes. We iterated > for some time till we got "SAX" (avoiding JAX which was toilet in Klingon > or something). I thought of SOAPI, knowing it would have to get discarded > and so a useful starting point. You can only start suggesting names if you > are going to contribute as well :-) > How Michael Key said we want to "create pointers from the "syntactic" (DOM) model of the document to the "semantic" (business object) model ". So, what about Semantic Sheets (SS) ? (too similar to Action Sheets???) Alberto xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Fri Oct 2 16:18:11 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:05:24 2004 Subject: Fw: DOM Level 1 Becomes a W3C Recommendation Message-ID: <00eb01bdee0f$6b7fce20$bcaddccf@ix.netcom.com> Simon, it was on the DOM list, I attach it for those not on both lists. Appologies to others. Frank -----Original Message----- From: Arnaud Le Hors To: Cc: Date: Thursday, October 01, 1998 1:01 PM Subject: Re: DOM Level 1 Becomes a W3C Recommendation >keshlam@us.ibm.com wrote: >> >> Is there a summary of the differences between the PR and Recommendation >> versions of the spec? Or are they identical? > >No the spec has evolved. Only to clarify or to fix bugs that were found. >So >I guess it is fair to ask for a summary of changes. Here it is: > >* wstring changed to DOMString >* changed Attribute interface to Attr >* moved pi to extended interfaces >* even though this can't be formerly specified in IDL some attributes >are now defined to raise an exception on setting or getting. This >concerns >CharacterData.data, Node.dataValue, and ProcessingInstruction.data >* added text about duplicate entities and notations being discarded >* added text about entities and notations not being editable in any way >* changed INVALID_NAME_ERR to INVALID_CHARACTER_ERR >* added INVALID_CHARACTER_ERR exception to createEntityReference >* added text about the Entity nodes being readonly and not having any >parent >* changed ExceptionCode to unsigned short >* added text about HIERARCHY_REQUEST_ERR being raised by >Node.insertBefore/replaceChild/appendChild when the specified node is >one of this node's ancestors. >* added text about the Notation nodes being readonly and not having any >parent. >* HTMLDocument.getElementById() returns null and not void if no matching >elements exist. >* changed attributes HTMLSelectElement.options and >HTMLSelectElement.length to readonly. >* clarified description of attribute HTMLTaleElement.rows >* changed attribute HTMLTableElement.tBodies to readonly >* TMLTableElement.tHead and TMLTableElement.tFoot return null and not >void if no such element exists. >* changed description of HTMLTableRowElement.insertCell() to make it >clear it inserts TD elements. >* changed attribute HTMLTableSectionElement.rows to readonly. >* added missing HTMLTextAreaElement.value attribute >* added a References section > >I hope this helps. >-- >Arnaud Le Hors - W3C, DOM Activity Lead - www.w3.org/People/Arnaud > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hyoung at fiz.huji.ac.il Fri Oct 2 16:37:50 1998 From: hyoung at fiz.huji.ac.il (Hyoungsoo Yoon) Date: Mon Jun 7 17:05:24 2004 Subject: Why is there no DOM-C++ binding in DOM spec? References: <002001bdee04$48966e60$2ee044c6@arcot-main> <3614D12C.A4C91D5B@infinet.com> Message-ID: <3614E581.E339B07B@fiz.huji.ac.il> Hello, I've been trying to implement DOM api in C++ language. But I just can't get past the initial design stage. My question is: How much freedom do I have in my implementation? Since no official language binding is provided in the spec (or is there any?), I suppose I can take some liberty. More specifically: [1] Do I need to adopt OMG IDL C++ language binding standard? It appears very specific to CORBA, which I'm not planning to include at this stage. [2] Or is it mandatory to include some sort of "object brokerage interface" such as CORBA or DCOM? [3] How important is this "detail" such as using Attr instead of Attribute? [4] More fundamentally, do we really need this standardization in C++ language? I can see its importance in script languages or "light-weight" languages such as java, which can be used, for example, inside a browser. But I can't think of any good examples for C++ (perhaps outside the context of CORBA or COM). Thanks all, youngsoo xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lauren at sqwest.bc.ca Fri Oct 2 18:40:44 1998 From: lauren at sqwest.bc.ca (Lauren Wood) Date: Mon Jun 7 17:05:24 2004 Subject: Welcome, DOM! In-Reply-To: <199810021308.JAA26888@hesketh.com> References: <002001bdee04$48966e60$2ee044c6@arcot-main> Message-ID: <199810021640.JAA20248@sqwest.bc.ca> At 02/10/98 06:10 AM , Simon St.Laurent wrote: >At 05:57 AM 10/2/98 -0700, Don Park wrote: >>Coming right along. Arnold's list of PR/REC differences made a big >>difference. > >Where is this list? Did it sneak by me on XML-Dev? It was posted to www-dom@w3.org, using the theory that people who are interested enough in the DOM to want the differences list are subscribed to the public DOM mailing list. To subscribe, send mail to www-dom-request@w3.org, with the subject line "subscribe". cheers, Lauren xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 2 19:38:31 1998 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:05:24 2004 Subject: Schema for Object-oriented XML (SOX) Message-ID: <3.0.1.32.19981002133810.006e2c04@pop.uunet.ca> Ladies and gentlemen, I am pleased to inform you that the W3C has acknowledged a submission entitled "Schema for Object-oriented XML (SOX)" which can be found at http://www.w3.org/Submission/1998/15/ The complete list of documents that are relevant to the SOX submission are listed here for you convenience: 1) Schema for Object-oriented XML (SOX) Specification http://www.w3.org/TR/NOTE-SOX/ 2) Core XML DTD for SOX http://www.w3.org/TR/NOTE-SOX/schema.dtd 3) HTML Text DTD http://www.w3.org/TR/NOTE-SOX/htmltext.ent 4) Core schema for SOX http://www.w3.org/TR/NOTE-SOX/schema.sox 5) HTML Text schema module http://www.w3.org/TR/NOTE-SOX/htmltext.mod 6) Typedefs schema module http://www.w3.org/TR/NOTE-SOX/typedefs.mod Abstract Automated processing of business documents in large-scale electronic commerce environments requires rigorous definition of the document structure, content and semantics to enable efficient software development processes for distributed applications. XML offers the Document Type Definition (DTD) as a formalism for defining the syntax and structure of XML documents. However, experience has shown that XML DTDs are not sufficient to specify content or semantics. Moreover, the fact that XML DTD syntax is incompatible with XML document syntax increases the complexity of supporting interoperation among heterogenous applications. Therefore, a schema facility is required to enable XML validation and higher levels of automated content checking by facilitating software mapping of XML data structures, supporting the generation of common application components, and enabling reuse at the document design and the application programming levels. This submission proposes a schema facility, "Schema for Object-oriented XML (SOX)", for defining the structure, content and semantics of XML documents to enable XML validation and higher levels of automated content checking. XML Schema provides an alternative to XML DTDs for modeling markup relationships to enable more efficient software development processes for distributed applications. SOX also provides basic intrinsic datatypes, an extensible datatyping mechanism, content model and attribute interface inheritance, a powerful namespace mechanism, and embedded documentation. As compared to XML DTDs, SOX dramatically decreases the complexity of supporting interoperation among heterogenous applications by facilitating software mapping of XML data structures, expressing domain abstractions and common relationships directly and explicitly, enabling reuse at the document design and the application programming levels, and supporting the generation of common application components SOX documents can be operated on by a SOX processor to produce many different types of output targets. Transformation of SOX documents will yield XML DTDs and object-oriented language classes to facilitate the development of intelligent applications, such as those needed to perform electronic commerce, for example. Other output targets of SOX include documentation derived from the documentation-based elements in SOX itself, and user interface components. Further output targets are yet to be defined, but the inherent flexibility of SOX allows for many other options. The SOX proposal is informed by the XML 1.0 specification as well as the XML-Data submission, the Document Content Description submission and the EXPRESS language reference manual (ISO 10303-11). A SOX document, or schema, is a valid XML document instance according to the SOX DTD, that represents a complete XML DTD-like structure. It has a document root element, and a representation of syntax that one would expect from a complete DTD, symbolically generated through the XML document instance. Regards, Murray Maloney xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Fri Oct 2 19:59:51 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:24 2004 Subject: Web server logs in XML? Message-ID: <5030300025878397000002L072*@MHS> "Please pardon my chiming in... I try, but I'm not quite up to speed with everything that's going on here and I have the nagging suspicion that I am missing something big. [snip] I have close to 10gb of web-server logs from the last 2 yrs and while this is theoretically appealing I, perhaps short-sightedly, have read everything that goes on here with an eye toward using XML as a, well, markup language used for universal exchange, not as the be-all & end all of native data-storage. " I have to agree with your sentiments in many ways. Basically there is always a tendency towards seeing everything as a nail when you just have a hammer (witness the Java phenomenon.) I believe that overselling any technology is probably a bad thing and I think that XML is being way oversold in some cases (in many cases for no other reason than to increase a products 'buzz word quotient'). I assume that the market will prevail and stomp any really insane applications, but I'm not always sure of that. So here is my suggestion: CXML (pronounced sex-em-el in order to make the marketing types happy!) What do you think? I believe I might have something here :-) I think that we should keep in mind that we are using one of the piggiest languages in the world to access one of the least efficient object models in the world. Only where there are gains to be had that are signficant enough to overcome these problems should XML be the technology chosen to solve the problem. There are many applications I've seen discussed where I would have just spent the 8 hours required to write a small custom parser and gotten 20 times the performance for about the same amount of work. Obviously in a data exchange situation with third parties it can make a lot of sense, and for document exchange it makes plenty of sense. But using it for a database format or store store a large amount of text like a log (which probably has such a simple format that it could easily be transformed to XML for export if that was required but which could until then be stored far more easily and efficiently in some other way) or as a replacement for a very efficient binary format (which can also be transformed to XML when the need arises without paying for the overhead all of the time), I think that many of these are just solutions looking desparately for a problem that someone else has already solved better. Just my opinion of course... I'm not trying to squash XML, since I'm getting paid to do it these days. I just think that overselling a technology is worse in the end than admitting its not the answer to world hunger. I think that Java has suffered tremendously by being sold as a solution for things its not up to dealing with. ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eric at hellman.net Fri Oct 2 20:06:03 1998 From: eric at hellman.net (Eric Hellman) Date: Mon Jun 7 17:05:24 2004 Subject: namespaces for name attribute values? Message-ID: Well, a versioned URL for Dublin Core would be nice, but I was thinking of something different. I'm suggesting that it may be useful to make a namespace declaration simply to declare semantics of something that isn't in a DTD, namely the attribute values. I've been afraid to respond to the list given the "Ownership of Names" orgy, but here's another example: Suppose you want an attribute value to contain a MIME type. Right now, you can either declare the attribute as CDATA or you can enumerate the possible MIME types. Suppose your goals are as follows: 1. You don't want a parser to check the value of the attribute. 2. You do want to instruct authors about appropriate values of the attribute. 3. You don't want to change the DTD when a new MIME type is invented. If you enumerate the MIME types, you have to change the DTD for every new MIME type that gets invented. If you declare the attribute as CDATA, then an author has to read a comment in your DTD to know where what attribute values are appropriate. This eliminates 99% of your pool of potential authors. If you declare a default xmlns (with an appropriate URL) for an element, an XML authoring application could know where information about appropriate attribute values might be found, and may avoid forcing authors to plow through your DTD. It's clear that this was not an intended use of namespaces, but as far as I can see, it won't do any harm. Eric David Brownell wrote: >Andrew Layman wrote: >> >> Perhaps you do not really have a problem. What I'm thinking is that if you >> wrote something similar to the example you showed, >> >> >> Eric Hellman >> >> >> then the meaning of DC:Creator is not affected by any additions made to >> Dublin Core. Your DTD remains valid, simply not as extensive as the >> (expanded) Dublin Core. > >For Dublin Core, perhaps -- but not in general. Suppose >the addition were to modify the content model for something >like the "Creator" element referred to above? Validity isn't >automatically preserved in such cases. > >Namespaces need versioning. URIs can easily include date >codes like "02Nov1997"; W3C itself uses such a scheme, as >you can see by looking at versions of the namespace spec. > >I'd expect the definers of such namespaces to identify >their versioning policy, including publishing URLs which >apply to each iteration. A "most current" URL can be of >use in some cases (loose coupling), but not usually in >systems that depend on precise semantics and hence need >updates to support new features. > > >So my response to Eric is to get a versioned URL for the >Dublin Core, and to use that! ;-) > >- - Dave Eric Hellman Openly Informatics, Inc. http://www.openly.com/ Tools for 21st Century Scholarly Publishing xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Fri Oct 2 20:12:50 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:24 2004 Subject: Questions on DCD Message-ID: <5030300025878838000002L082*@MHS> "Hi all, I've been looking at the DCD submission and the proposed DTD that was posted here a few days ago, and I have a few points to discuss- I thought this would be the best forum." Thanks for the comments. I've passed them on to the appropriate folks. ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 2 20:28:29 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:25 2004 Subject: SOX References: <3.0.1.16.19981002064315.2f4f64e4@pop3.demon.co.uk> Message-ID: <36151A55.85FDE8DF@eng.sun.com> Peter Murray-Rust wrote: > > >- Generating customized content. It's no good solving only half > > the problem, and customization during parsing is "easy" (as > > suggested by all the results there). > > Could you expand on 'customized content'? Does this mean creating > element-specific storage and additional methods? There are basically three places content/information shows up: as it's coming in (during parsing), when it's in memory, and when it's going back out. A simple test of API sufficiency is how easy it is to "round-trip" logical information. (I'll exclude DTD contents from "logical" info, as well as stuff like entity boundaries. If we assume schemas are happening, that simplifies APIs a lot!) Customized content "in-memory" is a broad category: basically all the representations an application may choose. DOM for this, a specialized representation for that. Multiple copies of this, drop that entirely. Merge info from this document with that other state. In an object-oriented terminology, setting up the "object model" for the application; yes, with additional methods. In such a model, a document may be no more than a temporary artifact, and the application may have rather strong requirements about how it stores data represented in XML by elements, text, and so on. (Clearly SAX does a very nice job of letting applications choose the most appropriate representation for their data! It may not be DOM, though for at least the simplest apps it should be.) Similarly for customizing the content when it goes back out. I'll mention two basic approaches that folk seem interested in: - Writing it back out as XML text. That was what I was referring to above. Basically, one needs the ability to transform back from an application-optimized version in memory to an XML transfer syntax. It may not look very much like the document did on input; that's often the point of the processing!! - Writing it back out in some other format, such as in the guise of object or relational database entries. One needs to be able to read this back in of course. If the focus is on the data (usually a good idea :-) then the usage of XML and DOM may not always be center stage. When I talk with folk doing document management systems, they don't always want XML except as an interchange format; ditto folk who are working on commerce or workflow apps. With an XML-focussed hat on for the moment, "customized content" was intended to address roundtripping information as XML text. But if done as well as it needs to be, it'll work with systems that aren't focussed exclusively on XML. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Fri Oct 2 20:31:42 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:25 2004 Subject: Questions on DCD Message-ID: <5030300025879520000002L002*@MHS> >>6) I know this is not going to make me popular, but I think that there >>are too many datatypes > >I do too, and I've warned my co-editors to expect massive amputations >in the committee process, if DCD ever gets taken up. > I think everyone thinks that this is the case. The problem is that if you have too few, then many applications will require ad hoc and inconsistent extensions of the mechanism. Too many and you bog down all processors with having to deal with lots of types that most people don't use (and you still don't cover all the bases.) I made a proposal related to the whole type validation mechanism, which really extends beyond DCD but would address a lot of its issues as well as allow for much more extensibility. I'd like to post it here for comment (with some internal information removed) in order to perhaps bash it out as a general type validation mechanism. However, right not its in a Notes database and if I post it here its going to look so horrible that it will probably be unreadable. But, just in case, here it is. I'd appreciate any comments on it (if you can read it.) Posting stuff to this mailing list from Notes generally seems to totally destroy its format. Overview This document is related to the DCD proposal made to the W3C, and more specifically the DCD 'constrain mechanism'. DCD provides a means for indicating constraints on the values of elements and attributes. This mechanism is provided via the Min/MinExclusive and Max/MaxExclusive properties, and has 'falls within a single range' semantics. In other words each element or attribute definition can express a value range (inclusive or exclusive) within which the value of each instance of that element or attribute in the target XML file must fit, in order to meet the constraints. The purpose of this document is to propose an alternative constraint mechanism which we feel is no more complex and far more flexible than the one current proposed. Just to provide a refresher course for the existing DCD constraint proposal, here is an example snippet from a DCD which defines an attribute which is of type int and which has a range of 1 to 10, inclusive. The same mechanism applies to element definitions as well. The content of the min/max values must of course make sense for the declared data type of the element or attribute. After doing a quick and dirty demonstration program of DCD (based on the existing functionality in the XML4J parser), the XML Team at JTC-SV would like to put forward a proposal which we feel makes the constraint mechanism more useful and extensible, without placing an undue burden on the common case of a simple document with simple validation needs (i.e. not constraints required, just structural validation.) The overall goals of this constraint mechanism are: Minimum code support requirements in the core parser architecture (i.e. minimal cost for those who don't use it) Reasonable implementation size and complexity Open endedness and flexibility for the uncommon case and user Simplicity of understanding and use for the common case and user We feel that a constraint mechanism is probably achievable which meets these requirements. As the likely targets of such a proposal, we obviously do not want to propose something which is not achievable and maintainable with reasonable effort, so we certainly hope not to contribute to the growing perception that 'deep thoughts' in the XML world are out of hand, and real world implementation is suffering for it. Driving Forces The primary driving force of this proposal is a belief that the constraint mechanism currently expressed in the DCD proposal is insufficient to meet more than a small fraction of the needs of the possibly quite wide target audience. We understand the reasoning behind this initial proposal, i.e. to maintain a level of simplicity that would increase the likelihood of acceptance and implementation; however, we feel that the current mechanism is sufficiently limited that its implementation might be counterproductive. The reasoning is that almost any real world application of the technology would require some amount of manual extension. Such extensions are not possible within the existing specification, and hence would almost certainly be implemented in a haphazard way, hindering interoperability of implementations. Also, since any such haphazard extensions have the potential of becoming defacto standards, we would like to avoid having such 'design by aggregation' imposed upon us by the marketplace. By providing a more extensible mechanism up front, we would hope to avoid this scenario, since any reasonable extension of the mechanism could be made without stepping outside the system provided. And thirdly, though obviously useful, the limited constraints expressable in the existing system does not seem sufficient enough to warrant the effort of implementing a constraint mechanism in the parser. Such a mechanism is non-trivial and imposes some mimimum of unavoidable overhead on the parser. For such an effort to be made and such a performance burden to be accepted, we would very much prefer to achieve more powerful constraint checking for our buck. The Basic Concept Our concept is based loosely upon the existing experience of spreadsheets, which are probably the prototypical example of simple 'application development' for the end user. In particular, the 'function' concept of the spreadsheet, which provides an easy to understand mechanism for doing simple arithmetic and logic operations. These functions are in the form of a simple function call which evaluates its parameters and returns a boolean pass/fail result. So, at its simplest level, a constraint expression would look something like this: In this scenario, a "Constraint" property is introduced. Its value is a string which expresses some constraint by way of a 'function syntax' expression. In this case the function is "InRange" and it takes two values, the minimum and maximum values of the range. All constraints will be of this form. High Level Implementation The implementation of this proposed validation scheme is relatively straightforward. It can be delivered in three conceptual layers, each of which provides increasing levels of sophistication for increasing levels of effort and coding skill. These layers will be discussed here in detail, as well as how those layers can be fit together and 'delivered'. Intrinsic Functions At the core of the validation system there will be a set of intrinsic functions, which are provided with the parser implementation, and which should be required in any DCD implementation by the specification. This will insure interoperability of core validation services. These functions will be selected for their high 'bang for the overhead buck' appeal, i.e. they will meet hopefully 90% of the common case needs with minimal overhead (since they will be packaged with the parser core.) A likely set of core functions would be: Name Example IsEqualTo Constraint="IsEqualTo(5.0)" IsGreaterThan Constraint="IsGreaterThan(&BaseLevel;)" IsLessThan Constraint="IsLessThan(25)" IsInRange Constraint="IsInRange(&ValidRange;)" IsOneOf Constraint="IsOneOf(Blue, Red, Pink)" IsTrue Constraint="IsTrue()" IsFalse Constraint="IsFalse()" IsEven, IsOdd Constraint="IsEven()" IsMultipleOf Constraint="IsMultipleOf(255)" IsInMultiRange Constraint="IsInMultiRange(1-10, 90-100)" IsStrEqualTo Constraint="!IsStrEqualTo('We the People')" IsDigit, IsChar, etc... Constraint="IsHexDigit()" And, Or, Xor Constraint="And(IsInRange(1, 90), !IsMultipleOf(5))" This set of functions should meet the needs of quite a wide range of applications, though there might be a couple more fundamental ones that could or should be added. Though the semantics of these are quite obvious, a little discussion of the finer points is presented before we move on. First of all, notice how these functions leverage the power of general entities, by allowing flexible replacement of function parameters. This capability will provide a lot of power to modify the validation over time without changing the DCD itself. This is not in an of itself an improvement over the existing validation scheme, since entity replacement is inherent to XML; however, the more expressive the validation mechanism, the more leverage is gained. Secondly, note the second to the last line, which describes the 'character type' functions. These can be mapped pretty directly to the language support for such things, and will provide a nice way to check a lot of characteristics of single character fields. There are language and locale issues involved here, which will be discussed at the end of this document. Also, note the last line which defines some boolean logic functions. These can be intrinsically handled by the processor itself, and will support much more complex constraints built from more basic ones. As long as we limit the nesting to something reasonable such as a single level, the complexity of these functions will be quite small. They will merely be a recursive container and invoker of other functions, with a little evaluation of the boolean results of each one. Though the example shows two parameters, there is no reason why it cannot easily allow an open ended number of subexpression parameters. Negation is implemented by the '!' prefix before a function, as in the last line where the function checks that the value is both in the range 1..90 inclusive and is not a multiple 5. This provides a lot of flexibility and avoids the need for having explicit Not versions of functions, and the implementation of it is ultra trivial. In the IsStrEqualTo() example checks that the value is not equal to "We the People". The amount of code to implement these intrinsic functions, above and beyond the basic amount of instructure required to support constraint checking at all, is very trivial. Most of them will resolve to singe lines of evaluation code. To insure openness, the function mechanism will probably be based on the namespace proposal as well. So, in reality, the above functions would actually be part of a "Htpp://W3C.Constraints/DCDStd" namespace for instance. This will allow a convenient partitioning of the function namespace, as well as a very flexible way of providing alternative processing by just mapping the namespace prefix to another URI that maps to a different set of functions! Third Party Functions The next level of support would be the ability to plug in third party validation functions. This would open up the system considerably by providing a well defined delivery mechanism for functions, to which third parties could write. As long as these functions can be expressed with the simple function syntax described above, they can be as complex as the developer wishes them to be and the user is willing to deal with. Support for third party functions requires a well defined interface to which they can be developed. This required interface is actually quite simple and convenient, and will have very few semantic demands to be met. The very simple semantics insures that open endedness is not compromised by the interface. A proposed interface is described below. Custom Functions At the upper end of the spectrum are custom applications which would provide their own functions for doing very domain specific constraint validation. These could include PIN number validation, database lookup of names or ids or social security numbers, and on and on. Our proposal provides a flexible back door for the validation mechanism to accomodate the most complex imagineable validation, without increasing the overhead of the common case by a single CPU cycle. Though there is no limit to the complexity or sophistication that these custom functions could achieve, there are no implementation issues here which go beyond those of the third party function development scenario discussed above, at least from our perspective as the parser provider. Implementation Details This section puts forward a specific example implementation that we believe will meet all of the requirements and fulfill all of the promise of the proposed system. Example Java implementations are presented, but the implementation would be easily done in C++ or any other quality object oriented language. The Function Interface A function is represented in the implementation as a simple abstract interface class. The interface is extremely simple, but allows the system to manage them and invoke them generically and reasonably efficiently. For this discusion, the interface is called ValFunction. A concrete implementation of it would look something like this in Java. This very simple class would allow the functions to be managed and invoked very simply and easily. Of course this is not a very complex example, and could be achieved by way of an intrinsic IsLessThan() function, but it shows how one would implement a simple function class. class ValidSalary implements ValFunction { // Default ctor only because they are factory created ValidSalary() { } // 'Parsing' method public void Parse(String[] astrParams) { // We only take one function param of maximum salary if (astrParams.length != 1) throw SomeError(); // Try to convert to our max salary member fMaxSal = new Double(astrParams[0]).doubleValue(); // Format our constraints into the description string strDesc = new String("< " + fMaxSal); } // Evaluation method public boolean bEvaluate(String strValue) { // Convert the string to a double and compare to max double fTmp = new Double(strValue).doubleValue(); return (fTmp < fMaxSal); } // Reporting method for errors public String strConstrainDesc() { return strDesc; } // Private data double fMaxSal = 0; }; The constructor is a default since functions will generally be 'factory created'. However, the factory can certainly invoke them with particular parameters. More on this below in the "Function Bundle Interface" section. The Parse() method is called once during the evaluation of an element or attribute which declares a constraint that uses the function. The contents of the function (the stuff after the function name, i.e. inside the function's parenthesis) is passed to the parser method in an array of strings which represent the comma separated function parameters. The function will evaluate these parameters, which represent the validity constraints set up for the element or attribute, and store that information in some (hopefully) optimal internal format. In the example above, which validates maximum salaries, it converts the single parameter to a double and stores that for later use From nwilson at programmar.com Fri Oct 2 21:53:51 1998 From: nwilson at programmar.com (Norman E. Wilson) Date: Mon Jun 7 17:05:25 2004 Subject: Web server logs in XML? References: <5030300025878397000002L072*@MHS> Message-ID: <36152F20.26B@programmar.com> Dean Roddey wrote: > I have to agree with your sentiments in many ways. Basically there is always a > tendency towards > seeing everything as a nail when you just have a hammer (witness the Java > phenomenon.) I believe > that overselling any technology is probably a bad thing and I think that XML is > being way oversold > in some cases (in many cases for no other reason than to increase a products > 'buzz word quotient'). On the other hand, part of the buzz generated by a "new technology? comes from being able to look at stubborn technical challenges (e.g., persistence, independence, naming, information sharing, reuse, etc.) in a brand new way. As evidenced by some of the discussions here, I think this is a healthy, productive and necessary process; yielding a continuous flow of new (though incomplete) insights into these challenges. I agree that there?s a real danger of undermining an effort by over-hyping it. At the same time, I believe that the process of rethinking old problems from new perspectives (and based upon novel opportunities) is critical to ongoing innovation. Perhaps this is not the correct forum for doing this (I'm new to the group, too); and obviously these considerations need to be carefully balanced. By the way, where can I get my copy of CXML? :-) Norm Wilson NorKen Technologies nwilson@programmar.com http://www.programmar.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Oct 2 22:49:50 1998 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:05:25 2004 Subject: Questions on DCD Message-ID: Dean Roddey [mailto:roddey@us.ibm.com] wrote: >I made a proposal related to the whole type validation mechanism, which really >extends beyond DCD but would address a lot of its issues as well as allow for >much more extensibility. I'd like to post it here for comment (with some >internal information removed) in order to perhaps bash it out as a general type >validation mechanism. However, right not its in a Notes database and if I post >it here its going to look so horrible that it will probably be unreadable. Instead of adding another parser, why wasn't the constraint specified as XML. i.e. Temperature in K Temperature in K Temperature in K xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simeons at allaire.com Fri Oct 2 23:56:01 1998 From: simeons at allaire.com (Simeon Simeonov) Date: Mon Jun 7 17:05:25 2004 Subject: WDDX (Was: XML and Objects) Message-ID: <0d8801bdee4e$94e88c90$7315b5cd@sim.allaire.com> >1) a DTD for a Simple Object Definition Language (SODL) this DTD is included >in a post to follow. FYI: http://www.allaire.com/developer/wddx is a place where you can find some information on an alternative approach to data serialization/deserialization that is not fully object-based. WDDX stands for Web Distributed Data Exchange, a technology that Allaire is making freely available to the Web community. WDDX deals with the task of providing a language and platform neutral structured data exchange mechanism based on XML 1.0. Current implementations provide support for the ColdFusion Markup Language, JavaScript, and COM/ASP. Perl and Java implementations are under development. We have also contacted the PHP and Python communities. Regards, Simeon Simeonov Allaire xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Oct 3 00:14:00 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:05:25 2004 Subject: XSL: Why? In-Reply-To: <3612A1EC.C0E07952@technologist.com> References: <199809301552.LAA27368@hesketh.com> <36126292.1BEAD074@locke.ccil.org> <3612A1EC.C0E07952@technologist.com> Message-ID: * Paul Prescod | | I presume that there is a reason that CSS was deemed not suitable as | the formatting model for XSL. CSS did not really have a concept of | "formatting objects". CSS2 does, if you look at the 'display' property, and it now has a boxed display model. | It only knew how to attach formatting semantics to existing objects. | At one point, some of the existing objects semantics had to be | already known: e.g. tables and links. I don't know if that has | changed recently. If not, CSS would need an overhaul to be | sufficient for formatting XML documents (or else you would have to | merge CSS and HTML somehow). CSS2 has a table model, but can not create links. Links aren't a problem with XML anyhow, since XLink takes care of that. The main difference between CSS2 and XSL is that CSS2 cannot reorder document content, or duplicate it. The support for generated text is also relatively weak, although it does have a generalized counter concept which is quite clever. For many uses CSS2 is going to suffice just fine, and it is much easier to learn and write than XSL is (the syntax is wonderfully readable and concise). For more advanced uses CSS2 won't cut it, but XSL hopefully will. --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 Curt.Arnold at hyprotech.com Sat Oct 3 01:15:14 1998 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:05:25 2004 Subject: Questions on DCD Message-ID: Curt.Arnold@hyprotech.com on 10/02/98 12:18:44 PM >>Instead of adding another parser, why wasn't the constraint specified as >>XML. i.e. >From: Dean Roddey [mailto:roddey@us.ibm.com] >I thought about that but I also thought about what I as a user would want to >actually have to use and I thought that that was just so wordy that I'd not >want to use it myself unless forced to. The other syntax is more comprehensible >to the human reader/writer in my opinion, takes up less bulk in the DOM tree, >and is really just as easy to parse in its raw form since the form is so simple. >Of course it won't be my decision and I just put the idea out there to get it >discussed. I'm sure that whatever gets done I'll probably not agree with it :-) One downside is that the DTD can't validate the constraints formulation (unless you have a custom constraint that checks constraints, but that is pretty circular). Schema authors are a fairly rarified bunch, so I wouldn't be enormously concerned about a few extra keystrokes (we will program our editors to do it for us, or when we finally get useful DTD-aware editors, it would auto-complete the elements for us). I would think the parser authors would bypass DOM creation so I don't see DOM space as being a huge issue. I was a little taken back by my quick look into VML, which basically did the same thing. Once you got beyond a shape, the descriptions of the shape looked like HP plotter commands. One thing that we are doing is adding an documentation fragments to that we can process DCD and generate HTMLHelp manuals for the schemas we are developing. Doing constraints as XML elements, would give us somewhere to explain the constraints. Temperature in K A temperature cannot be below absolute zero and it never gets to 1e30 in Houston except on really hot days. -----Original Message----- Sent: Friday, October 02, 1998 4:10 PM To: Arnold, Curt Subject: RE: Questions on DCD ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com Curt.Arnold@hyprotech.com on 10/02/98 12:18:44 PM Please respond to Curt.Arnold@hyprotech.com To: Dean Roddey/Cupertino/IBM@ibmus cc: Subject: RE: Questions on DCD Instead of adding another parser, why wasn't the constraint specified as XML. i.e. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Oct 3 02:51:50 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:25 2004 Subject: Welcome, DOM! - a copy of the list of changes Message-ID: <012201bdee67$f1043970$2ee044c6@arcot-main> >Where is this list? Did it sneak by me on XML-Dev? Following is from Arnaud Le Hors, W3C DOM Activity Lead. * wstring changed to DOMString * changed Attribute interface to Attr * moved pi to extended interfaces * even though this can't be formerly specified in IDL some attributes are now defined to raise an exception on setting or getting. This concerns CharacterData.data, Node.dataValue, and ProcessingInstruction.data * added text about duplicate entities and notations being discarded * added text about entities and notations not being editable in any way * changed INVALID_NAME_ERR to INVALID_CHARACTER_ERR * added INVALID_CHARACTER_ERR exception to createEntityReference * added text about the Entity nodes being readonly and not having any parent * changed ExceptionCode to unsigned short * added text about HIERARCHY_REQUEST_ERR being raised by Node.insertBefore/replaceChild/appendChild when the specified node is one of this node's ancestors. * added text about the Notation nodes being readonly and not having any parent. * HTMLDocument.getElementById() returns null and not void if no matching elements exist. * changed attributes HTMLSelectElement.options and HTMLSelectElement.length to readonly. * clarified description of attribute HTMLTaleElement.rows * changed attribute HTMLTableElement.tBodies to readonly * TMLTableElement.tHead and TMLTableElement.tFoot return null and not void if no such element exists. * changed description of HTMLTableRowElement.insertCell() to make it clear it inserts TD elements. * changed attribute HTMLTableSectionElement.rows to readonly. * added missing HTMLTextAreaElement.value attribute * added a References section 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 rbourret at dvs1.informatik.tu-darmstadt.de Sat Oct 3 11:58:27 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:05:25 2004 Subject: Questions on DCD Message-ID: <199810030957.LAA06794@berlin.dvs1.tu-darmstadt.de> Dean Roddey wrote: > I made a proposal related to the whole type validation mechanism, which really > extends beyond DCD but would address a lot of its issues as well as allow for > much more extensibility. I'd like to post it here for comment (with some > internal information removed) in order to perhaps bash it out as a general type > validation mechanism. However, right not its in a Notes database and if I post > it here its going to look so horrible that it will probably be unreadable. While I like this proposal and think there is a definite need for it, I would rather see it as an addition to, rather than a replacement of, a simple data type attribute. This is not a technical issue, merely a usability one. It has simply been my experience that explaining what a function is to non-technical or moderately technical people is very difficult; explaining what a data type is, is not. Furthermore, I suspect that 80-90% of the data typing needs in a document can be met by a subset of the DCD data types. I am therefore reluctant to get rid of such a simple method, especially since data type attributes would be easily reusable outside of schema files: 10 I also lean toward Curt Arnold's feeling that the functions should be written in XML. Certainly there are enough IDL/RPC/etc.-in-XML type proposals floating around that there would be no need to reinvent the wheel here. Might even be able to reuse some code... -- 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 jamesr at steptwo.com.au Sat Oct 3 15:29:07 1998 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:05:25 2004 Subject: It's time for practical XML! Message-ID: <199810031328.XAA00629@oznet11.ozemail.com.au> Hi all, I've just finished another couple of hours wading through XML-DEV and XML-L, and I confess my frustration has overtaken me. I don't want to make a big deal about this, but neither do I want it to rest (and from the private mailings I have received in the past from certain key individuals, I know I am not alone). It's time to stop writing standards. I don't want to know about any more *ML languages, however elegant they are. We are now at the stage where new standards are being submitted faster than old ones are being finalised. Now I know it is a lot more fun to talk about the next gee-wiz solutions to the world's problems, but we all need to get stuck into some hard work. A lot of people seem to be trying to hit every target with XML, and most are talking about "finding the killer app". XML does not need a killer app. It is not a solution unto itself. It is a handy tool for doing real-world work. I have not participated in these discussions on the whole, because I have been too busy implmeneting SGML in the workplace, using standard languages and off-the-shelf tools. I want to be able to do the same with XML. What we all need is: * rock-solid XML parsers for every platform under the sun, especially business development tools like: Visual Basic, Delphi, Powerbuilder, etc. * Embedded XML editors for use in business-specific applications. These need to be ActiveX controls, Delphi VCLs and the like. * Thousands of handy little tools that run without virtual machines, or other overhead, with simple interfaces, that make handling XML easy. Most of these solutions need to be commercial, with support, documentation, upgrade plans, bug-fix releases. Business will not use unsupported freeware, and they _will_ pay for the tools they need. There are a lot of _exceedingly_ good developers on this list. To them I say: Please, please, stop writing new specs, and help us all by writing real apps. 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 ross at zeus.mpce.mq.edu.au Sat Oct 3 16:36:13 1998 From: ross at zeus.mpce.mq.edu.au (Ross Moore) Date: Mon Jun 7 17:05:25 2004 Subject: It's time for practical XML! In-Reply-To: <199810031328.XAA00629@oznet11.ozemail.com.au> from "James Robertson" at Oct 3, 98 11:27:34 pm Message-ID: <199810031435.AAA00672@zeus.mpce.mq.edu.au> A non-text attachment was scrubbed... Name: not available Type: text Size: 2026 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981003/4d6e00fc/attachment.bat From b.laforge at jxml.com Sat Oct 3 17:05:36 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:25 2004 Subject: XML data model Message-ID: <000901bdeedf$64668540$02000003@thing1.camb.opengroup.org> One of the things I suspect we need to be able to map XML documents into application components is a data model of some kind. Coins v2 addresses these issues, all be it very crudly. This is done using a ClassDecl document for each element-to-bean mapping and a Bindings document for mapping element types to wrapper and application classes. The documentation for Bindings and ClassDecl is now available at http://www.jxml.com/coins/index.html I would suggest that there is very little of value in the form that these ml's take, and that they are quite incomplete as well. (And is entirely too closely tied to Java.) But I suggest to you that this is an early first step towards the data model that we need to tie XML syntax to document processing semantics. 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 bckman at ix.netcom.com Sat Oct 3 17:59:31 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:05:25 2004 Subject: It's time for practical XML! Message-ID: <004b01bdeee6$c2b56b00$adaddccf@ix.netcom.com> >To them I say: Please, please, stop writing new >specs, and help us all by writing real apps. Here's an interesting application, a DTD, and an applet that allows you convert XML to sheet music on a regular bowser MusicML, an XML experience. ============================ http://195.108.47.160/index.html How to use XML to write music! Perhaps not comercial grade, but a great example of what you can do right now. 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: Professional XML applications form Wrox Press, www.wrox.com -----Original Message----- From: James Robertson To: Date: Saturday, October 03, 1998 9:31 AM Subject: It's time for practical 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 b.laforge at jxml.com Sat Oct 3 18:29:35 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:25 2004 Subject: It's time for practical XML! Message-ID: <001b01bdeeeb$1c85d4e0$02000003@thing1.camb.opengroup.org> >Most of these solutions need to be commercial, >with support, documentation, upgrade plans, >bug-fix releases. Business will not use unsupported >freeware, and they _will_ pay for the tools they >need. I know pleanty of programmers who would love a job where they could work on these things. The problem seems to be in the business model. First, the internet is funny. Lots of folks willing to join a mailing list or download something that's free. But ask for a name and the numbers shrink. Ask for cash, and you will be luck to get any responses. And would you give me your credit card number? Really? One of the problems here is open standards. They are vital, but it means the small business may not have too much of a competitive edge when the big companies move in to take over a growing market. And a business plan must balance risks against potential profits. And without a business plan, there is no payroll for all those programmers who want to do this work. So we keep coming back to freeware. Now there are workable business plans. But they generally involve an element of consulting. Which is one way of avoiding the risks of an open market. But that doesn't give you the tools you want. One way out of this mess is the killer app. Another way is to broaden the market. And I think we could broaden the market by making it easy for all those Java programmers to write XML-based applications. But even that will take time. Of course, there's another complication. There is a segment of every open standards community that would rather see only freeware. Or perhaps they dislike proprietary products enough that any commercial- sounding endevor is discouraged. And yes, since a business must sell-or-die, there is a strong tendency to anti-social behavior. So things aren't all one sided. In any case, I think you are going to remain frustrated for a while, internet time that is. Though things seem to be moving even faster for XML than they did for Java. So there is hope. :-) 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 db at Eng.Sun.COM Sat Oct 3 18:53:59 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:26 2004 Subject: namespaces for name attribute values? References: Message-ID: <361655A6.5129FF6B@eng.sun.com> Eric Hellman wrote: > > Well, a versioned URL for Dublin Core would be nice, but I was thinking of > something different. I was just going by your example. > I'm suggesting that it may be useful to make a namespace declaration simply > to declare semantics of something that isn't in a DTD, namely the attribute > values. And I wouldn't disagree, but then you still need to get into the versioning issues to some degree. The URI associated with a namespace has no fundamental association with the semantics you're trying to declare! Unless the folk managing the name contexts associated with that URI have agreed to support associating those semantics, you (and any other folk who use that URI that way) may have problems due to changes beyond your control. > Suppose you want an attribute value to contain a MIME type. Right now, you > can either declare the attribute as CDATA or you can enumerate the possible > MIME types. > > ... > > If you declare a default xmlns (with an appropriate URL) for an element, an > XML authoring application could know where information about appropriate > attribute values might be found, and may avoid forcing authors to plow > through your DTD. In this case you want that code to manage versioning (e.g. of some list of approved MIME types) externally. The versioning problem is still there, but the semantics of such an attribute ("mime:type") are set up to vary over at least time. Most systems would consult a local table rather than creating a new globally accessible database of legal MIME types. So even if the tools authors use _could_ always access that database (no network failures), the "appropriate" values will have different meanings on the same day all over the world. In summary: all namespaces (ever) do is provide a layer of indirection. Their meanings change over at least time. When you use namespaces you need to consider what that change will do to your applications. - Dave > It's clear that this was not an intended use of namespaces, but as far as I > can see, it won't do any harm. > > Eric > > David Brownell wrote: > >Andrew Layman wrote: > >> > >> Perhaps you do not really have a problem. What I'm thinking is that if you > >> wrote something similar to the example you showed, > >> > >> > >> Eric Hellman > >> > >> > >> then the meaning of DC:Creator is not affected by any additions made to > >> Dublin Core. Your DTD remains valid, simply not as extensive as the > >> (expanded) Dublin Core. > > > >For Dublin Core, perhaps -- but not in general. Suppose > >the addition were to modify the content model for something > >like the "Creator" element referred to above? Validity isn't > >automatically preserved in such cases. > > > >Namespaces need versioning. URIs can easily include date > >codes like "02Nov1997"; W3C itself uses such a scheme, as > >you can see by looking at versions of the namespace spec. > > > >I'd expect the definers of such namespaces to identify > >their versioning policy, including publishing URLs which > >apply to each iteration. A "most current" URL can be of > >use in some cases (loose coupling), but not usually in > >systems that depend on precise semantics and hence need > >updates to support new features. > > > > > >So my response to Eric is to get a versioned URL for the > >Dublin Core, and to use that! ;-) > > > >- - Dave > Eric Hellman > Openly Informatics, Inc. > http://www.openly.com/ Tools for 21st Century Scholarly Publishing xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 3 19:37:51 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:26 2004 Subject: SOX: element<->class mapping References: <3.0.1.16.19981001121803.744fdd8c@pop3.demon.co.uk> <3.0.1.16.19981002000723.2f4f3130@pop3.demon.co.uk> <3614C402.29807915@mecomnet.de> Message-ID: <36166002.5E31A86B@eng.sun.com> james anderson wrote: > > The point is, that the mapping between serial encoding and > application data is best separated into two stages: encoding > and application modeling. Well, I'd claim "best" is a judgement that should be specific to some application domain. If the application is "element oriented" (as many can be) this separation may be irrelevant. > For this purpose [1st stage] it > suffices to declare a relation between java packages and xml > namespaces and to use introspection to map from element name > to class. One would have standard java packages appropriate > for and associated with standard elements. Of course with this sort of solution you prevent many-to-one mappings. Those can be convenient to work with. If one must take well formed XML and emit an HTML vocabulary, the ability to have one class handle all of HTML's empty-element printing syntax (e.g.
or
but never
) is a time saver, certainly at the "encoding" level and possibly higher up too. Many other solutions for this exist. For now, I'm assuming a factory method createElement(uri,tag) that can have many implementations, including the one james sketched above. > The second (items 3 - 5 in the original note) is more complex. Also, I'd claim, highly specific to the application structure. I'd certainly agree that in the general case, XML will be getting connected to some pre-existing application data which calls for complex model transformations to become XML. And that a good XML applications framework must enable that! However, I'd define the goals of an XML Object Framework to be focussed a bit more closely on what Peter called "Element Oriented Computing" ... where, I think, the assumption can be made that least some elements are the natural focus of an application. - 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 peter at ursus.demon.co.uk Sat Oct 3 20:34:24 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:26 2004 Subject: It's time for practical XML! In-Reply-To: <199810031328.XAA00629@oznet11.ozemail.com.au> Message-ID: <3.0.1.16.19981003193324.365f70e0@pop3.demon.co.uk> At 23:27 03/10/98 +1000, James Robertson wrote: >Hi all, > >I've just finished another couple of hours >wading through XML-DEV and XML-L, and I >confess my frustration has overtaken me. I understand this. I have been trying to develop this list as somewhere where things actually happen. We've had some success. But the successes rest on a great deal of *necessary* discussion. For example, in the discussion of how we build objects from elements it is clear that there is lightly explored territory with some very good contributions. There are different ways of doing things and some may be preferable to others - this will only emerge after the discussion. The history of SAX is an example. There were about 2 early forays into this field, which revealed it was important to do something and laid some groundwork. They then went fallow (a positive word) and finally David Megginson conducted XML-DEV during Dec 1997. It looked like it would take a month - and the first part did. But then there was the hard graft over ca. 3 more months while the details were ironed out. I would contend that the process per see could not be easily bettered. The same thing has happened - over a more gradual timescale with XSchema. Something is clearly needed in this area - whether XSchema is 'it', only time will tell. At present it looks like being the first offering in this field and over 50 people (I think) have contributed to the discussion. There is clearly a very great need for something similar for objects/elements. We are at an early concept stage. There are many different views of the way that elements might be transformed into objects. For many applications (e.g. technical, non-textual) this is *the* most powerful and critical part of XML. For example MathML and CML will rely on structured objects if there is to be re-use (rather than rendering) and we cannot proceed confidently until it's solved. > [...] > >It's time to stop writing standards. >I don't want to know about any more >*ML languages, however elegant they >are. We are now at the stage where >new standards are being submitted >faster than old ones are being finalised. I think we should distinguish between extensions to the functionality of XML and markup languages based on XML. The extensions to the functionality are horizontal such as XLink, XPointer, RDF, DCD/XSchema, XSL, etc. They may be a fundamental part of new markup languages. For example, my own contributions - CML and the Virtual HyperGlossary both rely on XLink to provide powerful data structure. *My* frustration is the XLink (and XPointer) are still not Recommendations. And I cannot expect people to build robust commercial tools until these specs are dry. > >Now I know it is a lot more fun to >talk about the next gee-wiz solutions >to the world's problems, but we all >need to get stuck into some hard work. I agree. I sometimes think that the discussion on XML-DEV is too far removed from implementation, but I haven't intervened. Many of the contributors also help create tools, demos, resources, etc. For example, the discussion on names may seem abstract, but people like Eliot Kimber have contributed greatly with implementations as well (e.g. PHyLIS - if have the caps right). Most of the regulars on this list work very hard at collaborative contributions - it may not always show above the surface. > >A lot of people seem to be trying to >hit every target with XML, and most are >talking about "finding the killer app". > >XML does not need a killer app. It is >not a solution unto itself. It is a >handy tool for doing real-world work. > >I have not participated in these discussions >on the whole, because I have been too busy >implmeneting SGML in the workplace, using >standard languages and off-the-shelf tools. Fine :-) and I hope you will implement XML when the tools are available for your purposes. Part of this list's traffic is coordinating the development of those tools. SGML had a lack of cheap tools and there was often little interoperability. So it led to good in-house solutions but poor WWW provision. XML is designed to be used over the wire and aspects of that are hard. As someone who has written some of the tools, even getting them distributed easily isn't easy. And interoperability is impossible without public discussion. > >I want to be able to do the same with XML. > >What we all need is: > >* rock-solid XML parsers for every platform > under the sun, especially business development > tools like: Visual Basic, Delphi, Powerbuilder, > etc. We have rock-solid parsers. We have a rock solid event-based API (SAX) and we have a rock-solid Object model (DOM). We desperately need the next layer on top of the DOM for may *ML applications. >* Embedded XML editors for use in business-specific > applications. These need to be ActiveX controls, > Delphi VCLs and the like. XML editors are *hard*. They require substantial investment. If they are to be syntactically (DTD) and semantically (Schema) driven we must have agreement on those. That's why XSchema and related efforts are so important. For example, I have written a forms-based editor for JUMBO. Works. *But* it is based on my own data types. It *has* to be, because no-one agrees on how to send a floating point number using XML. We shall, sometime. I'm frustrated by the lack of specs here :-) > >* Thousands of handy little tools that run without > virtual machines, or other overhead, with simple > interfaces, that make handling XML easy. They will not interoperate unless we have standards. Can I create an XML document with software X and send it to someone with software Y? Only if we agree on what is to be sent. There are a number of ways of agreeing: - everyone buys their toolkit from a single vendor. This can work, but it doesn't encourage innovation - a small number of toolkits evolve independently. This tends to lead to islands of interoperability. But it's awful for me. Let us assume that Netscape and MSIE expose different object models. Then to send a molecule from X to Y I have to write CML software for *each* browser. And when coins/XXX/SUN/XML4J all expose different interfaces the chemical community has the same babel as it has now (except that that is based on Fortran). Also semi-closed interfaces like this make it very difficult to develop semantic interoperability. - we discuss the problem openly and converge towards solutions where possible. XML is a prime example of this. There *was* a starting point (SGML) and it took 100+ people + many more contributors 1.5 years and 10000 e-mails to get to the current Rec. Namespaces took 2000 e-mails. We are attempting something that has never been done before - the creation of objects on one machine that must be semantically interoperable on another machine (after transmission in serialised form). The two clients have had no previous negotiation. [That, in part, is a reason why the name debate is so passionate and runs and runs - we have very little global experience of identifying machine-readable objects by universal names other than *.html documents]. > >Most of these solutions need to be commercial, >with support, documentation, upgrade plans, >bug-fix releases. Business will not use unsupported >freeware, and they _will_ pay for the tools they >need. I won't challenge this - even though I am an OpenSource fan and think that the Linux model is extensible to XML. [And many contributions on this list are top-quality OpenSource with no evidence that they are unsupportable.] My prediction is that over the next 2-3 months we shall see lots of first version XML tools from vendors - many, but not all, with SGML backgrounds. I suspect that there will be little effective interoperability between these tools except at syntactic level - they will emit WF XML, but beyond that they will give little support for managing documents produced by others. Maybe this is a necessary phase. I hope we can move past it. I am still in favour of a diversity of suppliers and applications but I hope we can work towards having semantic interoperability > >There are a lot of _exceedingly_ good developers >on this list. > >To them I say: Please, please, stop writing new >specs, and help us all by writing real apps. I think a lot *are* writing apps. I think also, that they desperately need specs to write these apps. My own experience is that I can develop something about 5 times faster if I have a spec to work to rather than working it out for myself. In the latter case there is: - the worry that you aren't going in the right direction - no one to turn to for help - no interoperability. etc. So when XLink, XSchema, XPointer, SOAPI (or whatever we call it) are frozen, people will develop apps much more rapidly. BTW - if you would like to help speed the process up we would be delighted :-) 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 Sat Oct 3 20:46:59 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:26 2004 Subject: SOX: element<->class mapping In-Reply-To: <36166002.5E31A86B@eng.sun.com> References: <3.0.1.16.19981001121803.744fdd8c@pop3.demon.co.uk> <3.0.1.16.19981002000723.2f4f3130@pop3.demon.co.uk> <3614C402.29807915@mecomnet.de> Message-ID: <3.0.1.16.19981003194655.1db7c560@pop3.demon.co.uk> At 10:33 03/10/98 -0700, David Brownell wrote: [...] >I'd certainly agree that in the general case, XML will be >getting connected to some pre-existing application data which >calls for complex model transformations to become XML. And >that a good XML applications framework must enable that! > >However, I'd define the goals of an XML Object Framework to >be focussed a bit more closely on what Peter called "Element >Oriented Computing" ... where, I think, the assumption can >be made that least some elements are the natural focus of >an application. I'm happy to change the name (EOC) if there is a more widely agreed existing one, but - like David - I think it defines an achievable current focus. I appreciate that there are many other exciting and valuable things to be done but unless we keep the focus very clear we shall simply have intractable discussions. I use EOC to mean the creation of element-specific methods to carry out tasks which are generally context independent. In my view they map onto (possibly complex) objects which may (but need not) involve a large amount of encapsulated subelements. Typical examples for me are: ... 0 0 1 0 1 0 1 0 0 C E G etc. For each of these complex software may have to be written and the programmer needs a simple agreed interface with the generic core XML engine. At present I think most of the approaches (SUN, XML4J, XXX, coins, JUMBO) is as far as we need to go - we just need to agree on a common API. P. > >- 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) > > 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 richard at goon.stg.brown.edu Sat Oct 3 20:53:01 1998 From: richard at goon.stg.brown.edu (Richard L. Goerwitz III) Date: Mon Jun 7 17:05:26 2004 Subject: It's time for practical XML! In-Reply-To: <199810031328.XAA00629@oznet11.ozemail.com.au> from James Robertson at "Oct 3, 98 11:27:34 pm" Message-ID: <199810031852.OAA09961@goon.stg.brown.edu> > Now I know it is a lot more fun to > talk about the next gee-wiz solutions > to the world's problems, but we all > need to get stuck into some hard work. This echos a thread that died out about two weeks ago. The gist of the argument then was similar to yours: We have people running off half-cocked after multiple, often competing, specs (e.g., schemas) - and talking about core portions of the 1.0 spec as if they were "legacy" items. Specs are flying right and left, timely ideas are being ignored, and tempers are flaring. Nobody can even agree on what an FPI is or what it's really do- ing in the XML spec. Although the discussions have quieted down, and people are talking more about compatibility of formats and goals, the damage is al- ready too obvious to be ignored: XML is starting to be seen as amorphous and unstable. Exacerbating the problem is the distance of the W3C from some important thought currents. Namespaces are the obvious example. We had any number of thoughtful, interesting postings about how to make namespaces truly useful (and how to integrate them fully with validation, as it is defined in the 1.0 spec). Very few productive responses were garnered from people whose vote counts. And many people were left with the feeling that the 1.0 validation/schema mechanism is going to be a legacy item be- fore it's ever even used. Once that feeling settled in, we again started to see the whole SGML-compatibility question re-opened. And we started seeing the sorts of gripes that reveal widespread ambivalence and con- fusion about what XML is really supposed to do. Worse yet, it is becoming clearer that the initial goals set out in the XML 1.0 spec are falling by the wayside. This can't help but give the rest of us a profound sense of uncertainty. Some random observations along these lines: 3) XML shall be compatible with SGML (the entire schema mechanism is being debated, and name- spaces, despite protests to the contrary, weaken and com- plicate use of DTDs) 4) It shall be easy to write programs which process XML documents (with every new spec, this prospect becomes more remote) 8) The design of XML shall be formal and concise (ditto) 10) Terseness in XML markup is of minimal importance (this position is reversed with namespace defaulting) I've always had confidence that there is enough brainpower here to satisfy most of the core constituencies. And especially since late September we're seeing more of an effort to do just this. My guess is that if the standards bodies don't make any bonehead moves, and if everyone will make stability and smooth transitions into prime goals, that everything will turn out okay. It will just take longer than predicted. Richard Goerwitz xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 3 21:20:31 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:26 2004 Subject: It's time for practical XML! In-Reply-To: <199810031852.OAA09961@goon.stg.brown.edu> References: <199810031328.XAA00629@oznet11.ozemail.com.au> <199810031852.OAA09961@goon.stg.brown.edu> Message-ID: <13846.29832.700936.140102@localhost.localdomain> Richard L. Goerwitz III writes: > Worse yet, it is becoming clearer that the initial goals set out > in the XML 1.0 spec are falling by the wayside. This can't help > but give the rest of us a profound sense of uncertainty. Some > random observations along these lines: > > 3) XML shall be compatible with SGML > (the entire schema mechanism is being debated, and name- > spaces, despite protests to the contrary, weaken and com- > plicate use of DTDs) The problem is that "SGML" != "ISO 8879:1986" -- there's new stuff, like WebSGML, that will probably never be implemented by itself but that provides XML with the ability to call itself "SGML-conformant." In other words, XML's claim to SGML compatibility is pretty meaningless anyway. > 4) It shall be easy to write programs which process XML documents > (with every new spec, this prospect becomes more remote) That's not really fair -- none of the new specs modifies XML 1.0, any more than HyTime, DSSSL, etc. modified ISO 8879:1986. Ignore them if you don't need them, and some (most?) will die out from attrition. > 8) The design of XML shall be formal and concise > (ditto) XML is in the same position that Java was in a couple of years ago: we're trying to decide how much should be let into the core, and how much should be kept outside. As of right now, nothing has officially been added to the XML core, so everything since XML 1.0 is outside (we've done much better than Java in this regard). There are certainly demands to change this -- everyone has a pet project that they would like to put in a future XML 1.1 or 2.0 core -- but the W3C has made no commitments even about creating an XML 1.1 or 2.0, much less adding anything to it. Personally, I'd like the XML 1.1 or 2.0 spec, if there ever is one, to be at least 25% smaller than XML 1.0. > 10) Terseness in XML markup is of minimal importance > (this position is reversed with namespace defaulting) Since namespaces are not part of the XML core, this design goal technically does not apply to them; nevertheless, I agree with you in disliking this feature of namespaces. > My guess is that if the standards bodies don't make any bonehead > moves, and if everyone will make stability and smooth transitions > into prime goals, that everything will turn out okay. It will just > take longer than predicted. The market as a whole is smarter than the individual people who participate in it, and it is *much* smarter than the people who try to direct it -- in the end, the market will politely ignore most of the new XML-related specs coming out and will end up choosing the one or two that it actually needs. Even if/when the standards bodies do make bonehead moves, we'll probably be OK. 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 srn at techno.com Sun Oct 4 00:42:31 1998 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:05:26 2004 Subject: It's time for practical XML! In-Reply-To: <199810031852.OAA09961@goon.stg.brown.edu> (richard@goon.stg.brown.edu) References: <199810031852.OAA09961@goon.stg.brown.edu> Message-ID: <199810032221.RAA01438@bruno.techno.com> > Exacerbating the problem is the distance of the W3C from some > important thought currents. I'd sure like to see more information owner/publishers (as opposed to system vendors) among the voting members of the W3C. I can't help thinking that if more voting members were concerned about creating a context in which the conservation and exploitation of information assets is optimized, we'd have a lot more stability, emanating from a much firmer sense of direction. I'm sorry, I know I keep harping on this, but it seems blindingly obvious to me that: The maximum improvement of human productivity should be the goal. -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 srn at techno.com Sun Oct 4 00:44:26 1998 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:05:26 2004 Subject: XML data model In-Reply-To: <000901bdeedf$64668540$02000003@thing1.camb.opengroup.org> (b.laforge@jxml.com) References: <000901bdeedf$64668540$02000003@thing1.camb.opengroup.org> Message-ID: <199810032201.RAA01395@bruno.techno.com> > One of the things I suspect we need to be able to map XML documents > into application components is a data model of some kind. Wouldn't it be nice if it were expressible/expressed as a property set? That's how SGML's data model is expressed. Also HyTime's. It's very likely that XML's data model can be expressed as a true subset ("grove plan") of the SGML Property Set. However, this would probably not be the friendliest possible way to express XML's property set. I suspect that the friendliest possible XML property set would use XML (e.g. DOM) terminology wherever possible. Work done by Fujitsu Labs has shown how XLink is expressible as a property set. Unsurprisingly, it turns out to be about the same as the relevant portions of the HyTime property set, except that all the names have been changed to correspond to XLink terminology. Property sets have some pretty attractive characteristics, and the "grove object model" which they serve as schemas was originally devised to describe the formal characteristics of SGML syntax. It's very neutral, very standard, very pure, and as simple as it can be. Moreover, property sets are expressible as XML documents; the DTD for property set documents already exists. Property sets describe classes of nodes, and the properties of each class of node, as such nodes are output by a parser for a given notation. A property set does not describe any methods, so it can form an excellent all-purpose foundation for methods and applications. Since every property of every syntactic construct is assigned a name in a property set, the names of properties readily form a natural basis for query languages, too. Having a property set for XML would set the stage for XML to become the language of documents that integrate information expressed in all other notations, because they can pretty much all have property sets, too. -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 simeons at allaire.com Sun Oct 4 01:22:03 1998 From: simeons at allaire.com (Simeon Simeonov) Date: Mon Jun 7 17:05:26 2004 Subject: It's time for practical XML! Message-ID: <0e8901bdef23$d9b5dc30$7315b5cd@sim.allaire.com> >XML does not need a killer app. It is >not a solution unto itself. It is a >handy tool for doing real-world work. ... and ... >To them I say: Please, please, stop writing new >specs, and help us all by writing real apps. I'm sorry to point people on this list to the same technology again in less than a week. Nevertheless, do check the Web Distributed Data Exchange (WDDX) technology out. It is free, it works right now, and it can be used to solve a broad range of problems that real-world web and non-web applications have to deal with. WDDX uses an XML 1.0 representation of data structures. It hides the details of XML processing on purpose. This is important because it gives WDDX the flexibility to leverage new XML standards as they become accepted and tool support for them becomes available. That's our way to solve the problem of the rapidly changing XML landscape w/o delaying the ship of useful technologies. The main WDDX site is at http://www.allaire.com/developer/wddx . The following article about WDDX made it to the cover page of this week's InfoWorld: http://www.infoworld.com/cgi-bin/displayIcommerce.pl?prophet.htm From donpark at quake.net Sun Oct 4 01:26:01 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:26 2004 Subject: XML-APP and XML-NEW (Re: It's time for practical XML!) Message-ID: <001d01bdef25$1e72a460$2ee044c6@arcot-main> What is happening now is just a part of growing pain. How luxurious it is to be complaining about moving too fast and too wide when most new technologies have problems just being accepted. What we need to do now is start two new mailing lists which aids and acts as catalyst for newbies and application development: 1. XML-NEW A mailing list for people learning XML and product announcements. I have long thought that newbies and spammers complement each other very well and not just in the negative sense. 2. XML-APP A mailing list for people developing XML applications. With above two additional mailing lists, we will have four tiers in the XML development community: W3C - for standards XML-DEV - for implementation and incubation of standards XML-APP - for application of standards XML-NEW - for beginners and announcements. I think this arrangement will go a long way toward relieving the growing pain we are feeling right now. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rexb at rbcomdesign.com Sun Oct 4 01:42:43 1998 From: rexb at rbcomdesign.com (Rex Brooks) Date: Mon Jun 7 17:05:26 2004 Subject: XML-APP and XML-NEW (Re: It's time for practical XML!) Message-ID: <199810032344.QAA01738@transbay.net> >What is happening now is just a part of growing pain. How luxurious it is >to be complaining about moving too fast and too wide when most new >technologies have problems just being accepted. > >What we need to do now is start two new mailing lists which aids and acts as >catalyst for newbies and application development: > >1. XML-NEW > >A mailing list for people learning XML and product announcements. I have >long thought that newbies and spammers complement each other very well and >not just in the negative sense. > >2. XML-APP > >A mailing list for people developing XML applications. > >With above two additional mailing lists, we will have four tiers in the XML >development community: > >W3C - for standards >XML-DEV - for implementation and incubation of standards >XML-APP - for application of standards >XML-NEW - for beginners and announcements. > >I think this arrangement will go a long way toward relieving the growing >pain we are feeling right now. > >Best, > >Don Park >Docuverse Yes! Sign me up for the Newbies about two weeks ago. Seriously, this is a good idea. Since I'm working with the Perl Module and java Servlet Module in the Apache Server to optimize delivery of VRML worlds, I could really have used some newbie resources, and still could, though, of course, I'll make do. Thanks for the idea. Rex Rex Brooks http://www.rbcomdesign.com 1361-A Addison rexb@rbcomdesign.com Berkeley, CA 94702 Vox: 510-849-2309 Virtual Reality Fax: 510-849-1306 Modelling Language chair: Content Development Working Group Consortium (VRMLC) co-chair: VRML-IPR Task Group xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 4 03:04:01 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:26 2004 Subject: ISO 13wawa and proxy FPIs Message-ID: <199810040114.VAA15550@locke.ccil.org> I have a proposal for creating valid FPIs for references such as the Sears catalog that Steven Newcomb brought up last week, now that Eliot and I have argued to a standstill about the underlying issues. I think that this will address the concerns of both sides. The problem as I now perceive it is that there are a variety of non-SGML catalogs in the world, from the 1922 Sears catalog to the King James Bible (considered as a chapter:verse -> text mapping) which don't have authorities to assign FPIs for them, or where the natural authority (Sears, Roebuck) isn't likely to do it. The idea here is to allow proxy FPIs, created as ISO 13wawa (I don't have access here to the actual number) FPIs that incorporate the name of the catalog creator. So the Sears entry would be: ISO 13wawa Proxy : Sears, Roebuck//NONSGML 1922 Catalog : Part 31247 and the text of John 3:14 would be ISO 13wawa Proxy: King James Bible//NONSGML John 3:14//EN Now there would need to be some distinction, possibly involving + and - somewhere, between *registered* proxies and *unregistered* ones. Anyone could register, say, the Dewey decimal system or the Library of Congress system, not just Mr. Dewey or the L.C., by registering the proxy name with the ISO 13wawa registrar. This would have to be cheap, since we want registrations in the public interest. The syntax might need to change to fit the SGML and ISO 9070 rules. -- 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 papresco at technologist.com Sun Oct 4 06:27:33 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:26 2004 Subject: It's time for practical XML! References: <199810031328.XAA00629@oznet11.ozemail.com.au> Message-ID: <3616F695.C899FC6D@technologist.com> James Robertson wrote: > > Hi all, > > I've just finished another couple of hours > wading through XML-DEV and XML-L, and I > confess my frustration has overtaken me. I'm sorry about your frustration, but my experience has been that mailing list diatribes seldom spur much action. > It's time to stop writing standards. > I don't want to know about any more > *ML languages, however elegant they > are. I thought that it was widely agreed that one of XML's most exciting applications is inter-organization standardization. It seems incredible that we would do all of the hard work required to build an infrastructure for that (XML 1.0) and then not actually create the inter-organization interchange specifications. Surely interchange is XML's killer app (oops!). And you can't get interchange with XML 1.0 alone. > We are now at the stage where > new standards are being submitted > faster than old ones are being finalised. Most of these are not new standards. There isn't a single *ML in the list of working drafts. They are W3C notes. They are trial balloons. They are ideas. We cannot outlaw people having ideas, and frankly I don't want to. "Chaos is the engine." -- Len Bullard. > What we all need is: [Software, software, software] How do XML-DEV discussions prevent the creation of this software? Most XML-DEV descussions are about people who are new to XML (or sometimes very experienced) trying to figure out how to apply it to their business problems: about expanding the user base: expanding the market for the tools you describe. For instance the recent topic maps and public identifiers discussion is about expanding the market by making *ML applicable to huge library catalogs. "All of the libraries in the world" -- just a tiny little market that Steve happens to think is worth pursuing. > Most of these solutions need to be commercial, > with support, documentation, upgrade plans, > bug-fix releases. Business will not use unsupported > freeware, That's not true. Show me a business that is not using Apache, Perl, Python, sendmail or some JVM and I'll show you a business that deserves to fail (and probably will). I work with massive companies that happily use Python, Perl, Jade and SP. In fact, I wouldn't know HOW to sell a solution that didn't involve SP somehow. > and they _will_ pay for the tools they > need. But that is true. > To them I say: Please, please, stop writing new > specs, and help us all by writing real apps. People write specs to try and understand their problem domain and to share that understanding with other people. If you understand yur problem domain well enough to know exactly what code needs to be written, then you are the logical person to write it! That's what I'm doing. (but sorry, I'm going to release my software for free, not sell it) Paul Prescod - http://itrc.uwaterloo.ca/~papresco Bart: Dad, do I really have to brush my teeth? Homer: No, but at least wash your mouth out with soda. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Sun Oct 4 06:55:40 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:27 2004 Subject: It's time for practical XML! References: <199810031328.XAA00629@oznet11.ozemail.com.au> Message-ID: <3616FC54.CEF5BDD8@technologist.com> I wanted to take issue with your particular product ideas, independent of your overall thesis. James Robertson wrote: > > * rock-solid XML parsers for every platform > under the sun, especially business development > tools like: Visual Basic, Delphi, Powerbuilder, > etc. It would be foolhardy for anyone to make a commercial parser when Microsoft already has promised that one will ship as a COM object with every version of Windows and Internet Explorer. > * Embedded XML editors for use in business-specific > applications. These need to be ActiveX controls, > Delphi VCLs and the like. My experience is that it is a lot of work to make a usable editor for structured documents. The hard part is the user interface. One of the prerequisites to such an editor is some style sheet language. You can invent your own, and then retool in a year and a half, but I suspect that most people would rather just wait for XSL. > * Thousands of handy little tools that run without > virtual machines, or other overhead, with simple > interfaces, that make handling XML easy. It is easy to speak of these tools in the abstract, but hard to make a business model for selling a little tool at a profit. The problems are not technical and would not be solved by a smaller number of new ideas floating around. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Bart: Dad, do I really have to brush my teeth? Homer: No, but at least wash your mouth out with soda. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Oct 4 10:24:30 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:27 2004 Subject: Role of XML-DEV (was Re: XML-APP and XML-NEW) In-Reply-To: <001d01bdef25$1e72a460$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19981004092404.1db71fa0@pop3.demon.co.uk> At 16:25 03/10/98 -0700, Don Park wrote: >What we need to do now is start two new mailing lists which aids and acts as >catalyst for newbies and application development: As the 'moderator' of XML-DEV I deliberately remain publicly neutral about whether new XML lists should be created or not (just as I remained neutral about compt.text.xml). However this posting suggests a revised purpose for XML-DEV, that I'm not in favour of. >With above two additional mailing lists, we will have four tiers in the XML >development community: > >W3C - for standards They actually call them Recommendations and (I think deliberately) do not use 'standard' >XML-DEV - for implementation and incubation of standards This has never been the primary or even secondary purpose of XML-DEV and I wouldn't want it to become that. The procedures for developing standards lies with the bodies - ISO, IEEE, W3C. They have well defined mechanisms which may or may not be enhanced through public mailing lists. It happens that part of what has happened on XML-DEV has included the generation of new ways of doing things *** paralleled by working code ***. [I suspect that SAX would have less successful (or taken a longer time to become successful) if there had not been an implementation which any parser-writer could use with minimal work.] No list remains static in a fast-moving field and unlike (say) a newsgroup XML-DEV has deliberately a minimalist 'charter'. 'XML-DEV is a list for (XML) developers'. This implies that the postings are related to development of the use of XML (not XML itself). Where other specialist lists exist (e.g. XSL or RDF) I would gently point a posting in that direction. [Recently there was a discussion about XSL that should have been on the XSL list rather than XML-DEV - I was away for a few days and didn't catch it.] There is no list for XLink or XPointer and questions on these are welcome here. The initial motivation 18 months ago was that XML-DEV was a place to develop working code alongside the developing XML spec. [I have a fear of specs which are too complex to implement.] A large number of parsers were developed during this time and several problems were identified in the emerging spec (e.g. PEs). There were also naturally announcements of new developments in the use of XML - new tools, new markup languages (i.e. DTDs or similar approaches). There were also questions *at developer level* about how to implement the spec(s). 'Developer' is interpreted widely. It can include people new to XML although I do not expect XML-DEV to be used for introductory questions. Many of these can be answered by reading the XML FAQ and others could be posted to comp.text.xml or XML-L if appropriate. However technical questions on particular pieces of software are often appropriate here. Later these may develop their own mailing lists. 'Developer' includes but is not limited to: - those writing XML-based tools - those making serious use of XML - those making serious use of XML-based tools - those developing new DTDs (or other XML 'applications') - those wanting to work out how to do new things with XML (this is why there has been a lot of discussion on names.) If some of these result in a group developing a NOTE or a de facto way of doing things, fine. But it's not the primary purpose. I note that many of the progenitors of XML and XML tools post to this list so I assume it fills a useful purpose for them. XML-DEV has been used for announcements and - assuming they are compatible with the above ideas - I'm quite happy for them. [They don't cause huge bandwidth at present.] I agree that there has been a considerable amount of general discussion recently [and I probably contributed in small part]. My current feeling is that some of the developers/implementers are going through a phase of taking stock but that there may be a lot of activity 'beneath the surface'. There are many directions in which to go and only some are achievable. Almost always the vision is greater than the reality of implementation. Personally I favour postings that suggest simple ways of doing simple things rather than all-embracing solutions that require a lot of buy-in from everyone. XML was difficult enough. XSchema has been created as deliberately simple at this stage. It sticks very closely to the concept of the DTD and doesn't require large conceptual leaps. When, I hope, the discussion on Element-oriented programming starts to coalesce I shall argue strongly for a minimalist approach. If you or others wish to create new lists - fine. But the position of XML-DEV should be seen as roughly what is outlined in this posting. 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 donpark at quake.net Sun Oct 4 13:26:58 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:27 2004 Subject: Role of XML-DEV (was Re: XML-APP and XML-NEW) Message-ID: <003601bdef89$d670da00$2ee044c6@arcot-main> Peter, It was never my intention to diffuse or divert the concentration of talents here. It was my intention to avoid eventual dilution to come. I don't know about you but I can not see XML being accepted by all the relevant industries without having a huge pool of XML-aware engineers numbering 50,000 or more. Whether the XML-DEV hardware can scale up to handle such number or not, it is ultimately unavoidable that the quality of XML-DEV will be reduced as the result of wider and wilder populous. Perhaps I am seeing too far down the road or just seeing things. I see XML-DEV taking up a role more important than even W3C and would very much like to protect it as much as possible by finding release to those who feel it should change. My applogies if I stepped on your toe with my bulldozer. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Oct 4 13:50:59 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:27 2004 Subject: Role of XML-DEV (was Re: XML-APP and XML-NEW) In-Reply-To: <003601bdef89$d670da00$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19981004124846.242706ae@pop3.demon.co.uk> At 04:24 04/10/98 -0700, Don Park wrote: >Peter, > >It was never my intention to diffuse or divert the concentration of talents >here. It was my intention to avoid eventual dilution to come. I don't know I agree - and I understood your motives. I wanted to make sure that the discussion didn't go off in wrong directions. Making a firm statement at the start is usually the best way :-) >about you but I can not see XML being accepted by all the relevant >industries without having a huge pool of XML-aware engineers numbering >50,000 or more. Whether the XML-DEV hardware can scale up to handle such Agreed. The main problem is training, right :-) [We are actively think about how to address that from Nottingham.] >number or not, it is ultimately unavoidable that the quality of XML-DEV will >be reduced as the result of wider and wilder populous. I think it's the liveware that is the main concern (i.e. HenryR). For example, whenever I post at w/e I get multiple copies of announcement from some braindead gateway, so I get 20 unwanted copies of garbage. For Henry that is much worse. The second area where scale hits is simply the volume of postings. We are up to >800 last month - and these are all of high quality. I read almost all for impact, but don't read all in detail (i.e. I don't work through the logic of AFs, topic maps, pernicious mixed content, how to run MSXML, etc.). We have the current differentiation: - OASIS, xml.com for current news. If I want to find out whether something has been announced I look there - FAQs for newbies ('what is a DDT" (sic)) - various specialist resources on home pages (SAX, James Tauber, James Clark, Steve Pepper etc.) - XSL, RDF, DOM have their own lists - XML-L for general discussion and announcements. We have never formally coordinated this but there seems to be enough difference that XML-L and XML-DEV have different roles. - comp.text.xml for whatever people want > >Perhaps I am seeing too far down the road or just seeing things. I see No. Many of us have similar vision. >XML-DEV taking up a role more important than even W3C and would very much >like to protect it as much as possible by finding release to those who feel >it should change. My applogies if I stepped on your toe with my bulldozer. Thanks for the compliment :-) I think the WWW finds its own solutions. There is evolution - birth, copulation, death - of newsgroups, lists, FAQs, sites, etc. Too many solutions too early lead to diffusion and often atrophy. I have often seen a fruitful discussion on a group stooped by the suggestion that it should move to a new thread - the same thing happens with lists. XML-L took a long while to get off the ground but now seems to flourish qualitatively and qualitatively. 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 dave at userland.com Sun Oct 4 14:24:45 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:05:27 2004 Subject: It's time for practical XML! In-Reply-To: <0e8901bdef23$d9b5dc30$7315b5cd@sim.allaire.com> Message-ID: <3.0.5.32.19981004052603.00cae180@scripting.com> We looked at WDDX and saw that it was a subset of XML-RPC. http://www.scripting.com/frontier5/xml/code/rpc.html WDDX makes no statement about transport. We're going to look at supporting it, but we're already deploying apps that do this stuff, along with WebMethods and others, have been since March. Allaire still has to settle on a transport (we suggest HTTP). Also, XML-RPC made Infoworld back in July, along with an interesting note that Microsoft is somehow involved: http://www.infoworld.com/cgi-bin/displayStory.pl?980710.whsoap.htm I would argue that XML is about working together. We have tremendous respect for Allaire. It would be wonderful if we could build applications that combine the capabilities of Cold Fusion and Frontier. We're inches away from this, and a little bit of building on each others' strengths is all it takes. Dave At 07:16 PM 10/3/98 -0400, you wrote: >>XML does not need a killer app. It is >>not a solution unto itself. It is a >>handy tool for doing real-world work. > > >... and ... > >>To them I say: Please, please, stop writing new >>specs, and help us all by writing real apps. > > >I'm sorry to point people on this list to the same technology again in less >than a week. Nevertheless, do check the Web Distributed Data Exchange (WDDX) >technology out. It is free, it works right now, and it can be used to solve >a broad range of problems that real-world web and non-web applications have >to deal with. > >WDDX uses an XML 1.0 representation of data structures. It hides the details >of XML processing on purpose. This is important because it gives WDDX the >flexibility to leverage new XML standards as they become accepted and tool >support for them becomes available. That's our way to solve the problem of >the rapidly changing XML landscape w/o delaying the ship of useful >technologies. > >The main WDDX site is at http://www.allaire.com/developer/wddx . The >following article about WDDX made it to the cover page of this week's >InfoWorld: http://www.infoworld.com/cgi-bin/displayIcommerce.pl?prophet.htm > > -------------------------------------- http://www.userland.com/directory.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 peter at ursus.demon.co.uk Sun Oct 4 14:40:35 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:27 2004 Subject: It's time for practical XML! In-Reply-To: <3.0.5.32.19981004052603.00cae180@scripting.com> References: <0e8901bdef23$d9b5dc30$7315b5cd@sim.allaire.com> Message-ID: <3.0.1.16.19981004133844.25afef18@pop3.demon.co.uk> At 05:26 04/10/98 -0700, Dave Winer wrote: [... details of WDDX, XML-RPC omitted ...] > >I would argue that XML is about working together. We have tremendous >respect for [XYZ]. It would be wonderful if we could build applications >that combine the capabilities of [PQR] and [ABC]. We're inches >away from this, and a little bit of building on each others' strengths is >all it takes. I think this sums up much of what we are trying to do on this list. Without commenting on the specific case [I haven't looked at the details] the thrust is that however good a single XML solution developed in isolation is, we must have interoperability if it's going to be universally used over the wire. That sometimes happens with single solutions - but often we have multiple ones. Then the problem has simply shifted from syntax to semantics. 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 larsga at ifi.uio.no Sun Oct 4 16:04:31 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:05:27 2004 Subject: Looking for an XML parser in Common Lisp In-Reply-To: <36128408.1FE0F436@mecomnet.de> References: <36125BED.1003A9F2@research.nokia.com> <36128408.1FE0F436@mecomnet.de> Message-ID: * james anderson | | look in the current release for the cl-http server. there's at least | one in there. I've now looked both in the sources and the release note, but have so far failed to find any XML parser in the Allegro port for Unix. I know making one has been discussed on the CL-HTTP mailing list, but it does not seem to have been written yet. --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 simonstl at simonstl.com Sun Oct 4 18:00:45 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:27 2004 Subject: It's time for practical XML! In-Reply-To: <3616FC54.CEF5BDD8@technologist.com> References: <199810031328.XAA00629@oznet11.ozemail.com.au> Message-ID: <199810041600.MAA13713@hesketh.com> At 11:40 PM 10/3/98 -0500, Paul Prescod wrote: >James Robertson wrote: >> >> * rock-solid XML parsers for every platform >> under the sun, especially business development >> tools like: Visual Basic, Delphi, Powerbuilder, >> etc. > >It would be foolhardy for anyone to make a commercial parser when >Microsoft already has promised that one will ship as a COM object with >every version of Windows and Internet Explorer. While it might not make sense to create the COM object, it might make a lot of sense to build supporting structures for VB, Delphi, PowerBuilder, and whatever other tool you like to work with. And it _might_ conceivably be worthwhile to build parsers for these environments. There are hurdles - Unicode one of the largest among them - but it might well make sense to build DOM-compliant or SAX-compliant (okay, fine, it probably won't be precisely SAX) for these environments. (Heck, I know a fair number of people using Delphi precisely because it _isn't_ an MS product, and they might like a non-MS parser for political reasons.) My personal focus these days is definitely on Java, but there are plenty of days I wish I had the Delphi environment's full set of tools. (Yes, I have JBuilder, but it's not quite the same...) Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 Sun Oct 4 18:00:47 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:27 2004 Subject: Role of XML-DEV (was Re: XML-APP and XML-NEW) In-Reply-To: <3.0.1.16.19981004124846.242706ae@pop3.demon.co.uk> References: <003601bdef89$d670da00$2ee044c6@arcot-main> Message-ID: <199810041600.MAA13716@hesketh.com> At 12:48 PM 10/4/98 +0000, Peter Murray-Rust wrote: >The second area where scale hits is simply the volume of postings. We are >up to >800 last month - and these are all of high quality. I read almost >all for impact, but don't read all in detail (i.e. I don't work through the >logic of AFs, topic maps, pernicious mixed content, how to run MSXML, etc.). XML-Dev's quality level has remained remarkably high - it's invariably the first list I read every day, followed closely by XML-L. I'm curious about one thing, though, and maybe the admin's can help with this. Is XML-Dev growing? The number of people speaking the discussion seems to be growing slowly; I wonder how the number of people lurking is doing/has done. >We have the current differentiation: > - OASIS, xml.com for current news. If I want to find out whether something >has been announced I look there > - FAQs for newbies ('what is a DDT" (sic)) > - various specialist resources on home pages (SAX, James Tauber, James >Clark, Steve Pepper etc.) > - XSL, RDF, DOM have their own lists > - XML-L for general discussion and announcements. We have never formally >coordinated this but there seems to be enough difference that XML-L and >XML-DEV have different roles. > - comp.text.xml for whatever people want I really see XML-Dev as the developer forum and XML-L as the (quieter) newbie forum. comp.text.xml is wide open, of course, though fairly quiet as well. The specialist lists (for which I'd usually rather read the archives than subscribe) perform their functions as well. It seems like we have a fair number of lists serving a relatively small number of people, and serving them fairly well. As far as general XML news sites go, we have several: http://www.xml.com seems to update approximately weekly http://www.xmlinfo.com seems to grow periodically http://sunsite.unc.edu seems to change almost daily http://www.oasis-open.org/cover/sgmlnew.html also grows almost daily Surfing multiple sites does get a bit tiring, but the news is at least of high quality on all of them. I'd say we have enough good places to talk; I'd just like to see more material appearing at http://www.xmlsoftware.com and http://www.schema.net. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 db at Eng.Sun.COM Sun Oct 4 18:07:45 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:27 2004 Subject: It's time for practical XML! References: <199810031328.XAA00629@oznet11.ozemail.com.au> <3616FC54.CEF5BDD8@technologist.com> Message-ID: <36179B3F.248B22E0@eng.sun.com> Paul Prescod wrote: > > James Robertson wrote: > > > > * rock-solid XML parsers for every platform > > under the sun, especially business development > > tools like: Visual Basic, Delphi, Powerbuilder, > > etc. > > It would be foolhardy for anyone to make a commercial parser when > Microsoft already has promised that one will ship as a COM object with > every version of Windows and Internet Explorer. And that one's not "commercial"? Hmm ... what about all the operating systems that Microsoft doesn't monopolize? I hope you're not saying they will never want XML support! I suspect you really meant to say that core XML infrastructure (parser, DOM, etc) was not an area where application developers would ever want to spend big bucks. I think that's true. But folk will still need rock-solid, and 100% conformant, parsers along with such tool support. - 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 larsga at ifi.uio.no Sun Oct 4 18:33:25 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:05:27 2004 Subject: It's time for practical XML! In-Reply-To: <199810041600.MAA13713@hesketh.com> References: <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> Message-ID: * Simon St.Laurent | | My personal focus these days is definitely on Java, but there are | plenty of days I wish I had the Delphi environment's full set of | tools. Maybe you'd find this interesting, then: --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 jtauber at jtauber.com Sun Oct 4 18:51:49 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:05:28 2004 Subject: Role of XML-DEV (was Re: XML-APP and XML-NEW) Message-ID: <004901bdefb7$a906f120$c26118cb@caleb> -----Original Message----- From: Simon St.Laurent >I'd say we have enough good places to talk; I'd just like to see more >material appearing at http://www.xmlsoftware.com and http://www.schema.net. Me too :-) Can people please give me feedback as to how these two sites could better serve people? xmlsoftware.com will soon be using Lars Marius Garshol's XSA system. Lars and I (well, Lars mostly) are working together to get XSA up and running so developers can let us know when software is released or updated. schema.net will soon house actual DTDs along with appropriate catalog(ue) entries (a catalog already exists for the entities). 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 simeons at allaire.com Mon Oct 5 00:30:06 1998 From: simeons at allaire.com (Simeon Simeonov) Date: Mon Jun 7 17:05:28 2004 Subject: It's time for practical XML! Message-ID: <020401bdefe5$bff97d70$7315b5cd@sim.allaire.com> Hi, Dave! Here are some comments: >We looked at WDDX and saw that it was a subset of XML-RPC. > >http://www.scripting.com/frontier5/xml/code/rpc.html Not really. WDDX is explicitly about not being related to RPC. It deals specifically and only with data. There is no notion of request-response, objects, methods, and interfaces. As far as data is concerned, apart the fact that we expose a recordset datatype, our datatypes are indeed similar. >WDDX makes no statement about transport. We're going to look at supporting >it, but we're already deploying apps that do this stuff, along with >WebMethods and others, have been since March. Allaire still has to settle >on a transport (we suggest HTTP). This is done on purpose, since WDDX is only about describing data. Yes, HTTP makes the most sense for moving data around the 'net. I recently saw an example of a WDDX-enabled app that pulled data from an ASP and a ColdFusion server to later display the data in MS Word. HTTP and DCOM were involved. I also know of applications that use WDDX as a structured representation for data they persist to databases. >Also, XML-RPC made Infoworld back in July, along with an interesting note >that Microsoft is somehow involved: > >http://www.infoworld.com/cgi-bin/displayStory.pl?980710.whsoap.htm Yes, this was an interesting article! >I would argue that XML is about working together. We have tremendous >respect for Allaire. It would be wonderful if we could build applications >that combine the capabilities of Cold Fusion and Frontier. We're inches >away from this, and a little bit of building on each others' strengths is >all it takes. Absolutely. I'll contact you on a private channel. Regards, Sim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Oct 5 02:01:02 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:28 2004 Subject: It's time for practical XML! References: <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> Message-ID: <361808BE.462F2045@technologist.com> "Simon St.Laurent" wrote: > > While it might not make sense to create the COM object, it might make a lot > of sense to build supporting structures for VB, Delphi, PowerBuilder, and > whatever other tool you like to work with. Wouldn't VB, Delphi, PowerBuilder etc. users use Microsoft's COM object parser? People do not, as an analogy, buy ".ini parsing libraries" for these platforms. They use thin layers over the Microsoft-provided APIs. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Bart: Dad, do I really have to brush my teeth? Homer: No, but at least wash your mouth out with soda. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 5 04:56:48 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:28 2004 Subject: It's time for practical XML! In-Reply-To: <361808BE.462F2045@technologist.com> References: <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> Message-ID: <199810050256.WAA17336@hesketh.com> At 06:46 PM 10/4/98 -0500, Paul Prescod wrote: >"Simon St.Laurent" wrote: >> >> While it might not make sense to create the COM object, it might make a lot >> of sense to build supporting structures for VB, Delphi, PowerBuilder, and >> whatever other tool you like to work with. > >Wouldn't VB, Delphi, PowerBuilder etc. users use Microsoft's COM object >parser? People do not, as an analogy, buy ".ini parsing libraries" for >these platforms. They use thin layers over the Microsoft-provided APIs. That just depends on how deep the tools MS provides are. If it's just a parser, they'll need more. If it's a parser + XSL + XLink, etc, well, maybe they'll call it IE 6! Just depends. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 cbullard at hiwaay.net Mon Oct 5 05:39:31 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:05:28 2004 Subject: It's time for practical XML! References: <199810031328.XAA00629@oznet11.ozemail.com.au> Message-ID: <36183EF2.6426@hiwaay.net> James Robertson wrote: > It's time to stop writing standards. > I don't want to know about any more > *ML languages, however elegant they > are. We are now at the stage where > new standards are being submitted > faster than old ones are being finalised. Probably true, but all things considered, a schema winner would be good first that settled the issues of datatypes, architectural forms or protos, etc. I am also hoping for clean Active-X tools that integrate with the common commercial platforms such as MS Access. Oddly after some years of SGML, I find myself building document management over relational systems, liking it, and wondering what I will do with markup systems beyond lifecycle support. Len Bullard IPS xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Oct 5 05:58:14 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:05:28 2004 Subject: XML data model References: <000901bdeedf$64668540$02000003@thing1.camb.opengroup.org> <199810032201.RAA01395@bruno.techno.com> Message-ID: <36184352.6623@hiwaay.net> Steven R. Newcomb wrote: > > Property sets describe classes of nodes, and the properties of each > class of node, as such nodes are output by a parser for a given > notation. A property set does not describe any methods, so it can > form an excellent all-purpose foundation for methods and applications. > Since every property of every syntactic construct is assigned a name > in a property set, the names of properties readily form a natural > basis for query languages, too. > > Having a property set for XML would set the stage for XML to become > the language of documents that integrate information expressed in all > other notations, because they can pretty much all have property sets, > too. Yes. This comes up on the VRML list from time to time as its designers puzzle over the best way to work with XML and DOM. If the property set approach were taken, IMHO, many of the issues of mapping among language standards would be settled and work could go forward in a sensible and rigorous way. The days of debating pointy brackets and curly brackets should be over. Nodes are nodes. Must be. Unfortunately, because XML is a syntax specification, that isn't workable except by ugly tricks with object tags and VRML protos. OTW, DOM will be extended with a core for each language, and XSL will sink to the bottom from all of the new flow objects some see as their best bet for integration. To me, that appears to defeat the whole purpose of this work. 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 ricko at allette.com.au Mon Oct 5 06:48:51 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:28 2004 Subject: Copyright and ownership article References: <0e8901bdef23$d9b5dc30$7315b5cd@sim.allaire.com> <3.0.1.16.19981004133844.25afef18@pop3.demon.co.uk> Message-ID: <36185153.301BFE80@allette.com.au> A tail to the thread on "ownership" of names in FPIs and of doamin names. There is a good article in The Atlantic Monthly in September about copyrights: "Who will own your next good idea" by Charles C. Mann. It gives the URL www.theatlantic.com but I couldnt get through. The paper version is certainly worth a read. 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 b.laforge at jxml.com Mon Oct 5 13:53:12 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:28 2004 Subject: XML data model Message-ID: <00e201bdf056$c871d940$02000003@thing1.camb.opengroup.org> From: len bullard >Steven R. Newcomb wrote: >> >> Property sets describe classes of nodes, and the properties of each >> class of node, as such nodes are output by a parser for a given >> notation. A property set does not describe any methods, so it can >> form an excellent all-purpose foundation for methods and applications. >> Since every property of every syntactic construct is assigned a name >> in a property set, the names of properties readily form a natural >> basis for query languages, too. >> >> Having a property set for XML would set the stage for XML to become >> the language of documents that integrate information expressed in all >> other notations, because they can pretty much all have property sets, >> too. > >Yes. This comes up on the VRML list from time to time as its designers >puzzle over the best way to work with XML and DOM. If the property >set approach were taken, IMHO, many of the issues of mapping among >language standards would be settled and work could go forward in a >sensible >and rigorous way. The days of debating pointy brackets and curly >brackets should be over. Nodes are nodes. Must be. Unfortunately, >because XML is a syntax specification, that isn't workable except >by ugly tricks with object tags and VRML protos. Some simple examples here might add a great deal to this discussion. I suspect that (a) this is vital, (b) I am not the only one unfamiliar with property sets, and (c) it is probably worth the bandwith to bring folks up to speed on this topic rather than simply cite some references. Thanks! Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Oct 5 14:23:51 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:28 2004 Subject: XML data model In-Reply-To: <00e201bdf056$c871d940$02000003@thing1.camb.opengroup.org> References: <00e201bdf056$c871d940$02000003@thing1.camb.opengroup.org> Message-ID: <13848.47661.39872.812093@localhost.localdomain> Bill la Forge writes: > Some simple examples here might add a great deal to this > discussion. I suspect that (a) this is vital, (b) I am not the > only one unfamiliar with property sets, and (c) it is probably > worth the bandwith to bring folks up to speed on this topic rather > than simply cite some references. For the normative description of property sets, see http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.4.html For a quick introduction to the SGML property set currently supported by Jade, see http://home.sprynet.com/sprynet/dmeggins/grove.html 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 Oct 5 16:05:42 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:05:28 2004 Subject: Looking for an XML parser in Common Lisp References: <36125BED.1003A9F2@research.nokia.com> <36128408.1FE0F436@mecomnet.de> Message-ID: <3618D2B6.34D1D86B@mecomnet.de> The source for an xml processor was in the cl-http 67-66-pre release (that's the latest i've pulled.) under contrib/janderson/xml. So far as I know from Mr. Mallery, it's in the later releases as well. as an aside, it's more a processor than a parser. I work with it primarily under mcl. A couple of months ago I did test it under franz allegro 4.0. 5.0 is next; soon. ("the disk is in the mail") There was an attempt to use it under acl/win where problems with the reader arose. I've loaded it, but haven't tried it with lispworks. Lars Marius Garshol wrote: > > * james anderson > | > | look in the current release for the cl-http server. there's at least > | one in there. > > I've now looked both in the sources and the release note, but have so > far failed to find any XML parser in the Allegro port for Unix. I know > making one has been discussed on the CL-HTTP mailing list, but it does > not seem to have been written yet. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 5 16:57:57 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:29 2004 Subject: It's time for practical XML! In-Reply-To: <199810050256.WAA17336@hesketh.com> References: <361808BE.462F2045@technologist.com> <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> Message-ID: <199810051457.KAA22082@hesketh.com> At 10:58 PM 10/4/98 -0400, Simon St.Laurent wrote: >At 06:46 PM 10/4/98 -0500, Paul Prescod wrote: >>"Simon St.Laurent" wrote: >>> >>> While it might not make sense to create the COM object, it might make a lot >>> of sense to build supporting structures for VB, Delphi, PowerBuilder, and >>> whatever other tool you like to work with. >> >>Wouldn't VB, Delphi, PowerBuilder etc. users use Microsoft's COM object >>parser? People do not, as an analogy, buy ".ini parsing libraries" for >>these platforms. They use thin layers over the Microsoft-provided APIs. > >That just depends on how deep the tools MS provides are. If it's just a >parser, they'll need more. If it's a parser + XSL + XLink, etc, well, >maybe they'll call it IE 6! Just depends. Speaking of all this, from Cafe Con Leche (http://sunsite.unc.edu/xml): >ICOM Datenverarbeitungs GmbH has released the first XML parser for Borland >Delphi. The parser is free. Source code is available for a price. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 mda at discerning.com Mon Oct 5 17:20:30 1998 From: mda at discerning.com (Mark D. Anderson) Date: Mon Jun 7 17:05:29 2004 Subject: combining xml files in the browser Message-ID: <004101bdf072$d6dbd0f0$0200a8c0@mdaxke.mediacity.com> I'm trying to determine the possibilities now for different ways to combine xml files for presentation, and also the envisioned mechanisms of the future. Neither the XSL nor the XML specs say a whole lot about intended usage model. The easy case is where I've got a single xml document and I want it displayed. No problem, I indicate the xsl style sheet in the xml document (or some html/xml protein coat), and send it to the browser. The browser then displays it. But typically I've got a whole bunch of individual xml documents (either as files, or because that is the way the underlying data source likes to return the data). But what I want to show is a single view involving contents of them all. Regardless of whether the browser displays xml "natively" or only html, there is the question of what to do when the underlying persistent data on my server partitions the xml differently from how it is to be presented. Here are some choices: 1) write a server-side thing that parses all the individual xml objects, and constructs a single xml or html document for the browser. this does almost all the work on the server, and tends to be special-cased. this is basically what i'm doing now. 2) similar to (1), except don't do any parsing: just cat the multiple xml objects together, and make the browser figure it out with the aid of a stylesheet. Of course, some overall tag will need to be put around it all, because xml has this annoying requirement of wanting just one root element. 3) send back a short xml document to the browser that has suitable links in it to indicate all the other xml documents that it should "include". (How is this done? How do I distinguish a link meaning "include content here" and one meaning "include reference here"? Do I need to finally go read XLink or XPointer or one of those other specs I've so far avoided?) 4) send back a short xml document that somehow includes a XML-QL or similar query, so that the browser performs the query, gets back the results (content or links), tracks those down, and *then* applies a style. So, what is the intended future model for this? One of these or something else? -mda xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Mon Oct 5 17:46:44 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:29 2004 Subject: combining xml files in the browser Message-ID: <013701bdf077$ec82a000$1e09e391@mhklaptop.bra01.icl.co.uk> >1) write a server-side thing that parses all the individual >xml objects, and constructs a single xml or html document >for the browser >2) similar to (1), except don't do any parsing: just cat >the multiple xml objects together, and make the browser figure >it out with the aid of a stylesheet. I'm doing a combination of these quite successfully: store lots of small XML fragments in an SQL database, retrieve those that are required using SQL in a servlet or ASP page, concatenate them to create a single XML document that contains the information the user wants and not much else, then parse this and convert to HTML. I do this final stage server-side as well, having got my fingers burnt with browser configuration problems, but I'd see it as happening client-side eventually. 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 jarle.stabell at dokpro.uio.no Mon Oct 5 17:54:49 1998 From: jarle.stabell at dokpro.uio.no (Jarle Stabell) Date: Mon Jun 7 17:05:29 2004 Subject: Delphi XML parser (Was: Re: It's time for practical XML!) Message-ID: <3.0.32.19981005175337.006ec5ac@hedvig.uio.no> Simon St.Laurent wrote: >>At 06:46 PM 10/4/98 -0500, Paul Prescod wrote: >>>"Simon St.Laurent" wrote: >>>> >>>> While it might not make sense to create the COM object, it might make a >lot >>>> of sense to build supporting structures for VB, Delphi, PowerBuilder, and >>>> whatever other tool you like to work with. >>> >>>Wouldn't VB, Delphi, PowerBuilder etc. users use Microsoft's COM object >>>parser? People do not, as an analogy, buy ".ini parsing libraries" for >>>these platforms. They use thin layers over the Microsoft-provided APIs. At least Delphi programmers much prefer native Delphi code. One of the main reasons for this is that it enables them to build all the code into a single executable, meaning less installation work/problems with DLLs. (Also, some potential customers are not happy about having to install the latest version of some specific big browser in order to run your program.) >>That just depends on how deep the tools MS provides are. If it's just a >>parser, they'll need more. If it's a parser + XSL + XLink, etc, well, >>maybe they'll call it IE 6! Just depends. > >Speaking of all this, from Cafe Con Leche (http://sunsite.unc.edu/xml): > >>ICOM Datenverarbeitungs GmbH has released the first XML parser for Borland >>Delphi. The parser is free. Source code is available for a price. There is another Delphi XML parser in beta at: http://www.cuesoft.com/xml/beta.htm 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 rafa at rae.es Mon Oct 5 19:15:36 1998 From: rafa at rae.es (Rafael Ruiz) Date: Mon Jun 7 17:05:29 2004 Subject: Copyright and ownership article In-Reply-To: <36185153.301BFE80@allette.com.au> Message-ID: On Mon, 5 Oct 1998, Rick Jelliffe wrote: > There is a good article in The Atlantic Monthly in September about copyrights: > "Who will own your next good idea" by Charles C. Mann. It gives the URL > www.theatlantic.com but I couldnt get through. The paper version is certainly It goes quite slow due to some images, but it works. [Ask your browser to reload a couple of times if it stops]. The article is divided into three parts: http://www.theatlantic.com/issues/98sep/copy.htm http://www.theatlantic.com/issues/98sep/copy2.htm http://www.theatlantic.com/issues/98sep/copy3.htm 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 roddey at us.ibm.com Mon Oct 5 19:20:51 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:29 2004 Subject: Questions on DCD Message-ID: <5030300025945047000002L072*@MHS> "One downside is that the DTD can't validate the constraints formulation (unless you have a custom constraint that checks constraints, but that is pretty circular). Schema authors are a fairly rarified bunch, so I wouldn't be enormously concerned about a few extra keystrokes (we will program our editors to do it for us, or when we finally get useful DTD-aware editors, it would auto-complete the elements for us). I would think the parser authors would bypass DOM creation so I don't see DOM space as being a huge issue." But the same verbosity is imposed upon the user of the validation scheme as well, right? As for sciping the DOM creation, I don't think you could, could you? Because of the open ended nature of the validation mechanism, if it was done as an element and its subcontent, there could be a lot of information in there that only the target validation function would understand how to make use of. How would you get that information to the function if you didn't either use my scheme of giving him an open ended string that he can parse, or building some known format (i.e. a DOM node) to pass to it? I dunno. In some ways you win and lose either way. Given the very open endedness of the scheme, I'd prefer the single formula style. But that's just my opinion, and I'm looking at it from a user's point of view not a machine's. From a machine's point of view, the element scheme would probably be more useful. "One thing that we are doing is adding an documentation fragments to that we can process DCD and generate HTMLHelp manuals for the schemas we are developing. Doing constraints as XML elements, would give us somewhere to explain the constraints." That's a good point. ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon Oct 5 19:24:34 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:29 2004 Subject: Questions on DCD Message-ID: <5030300025945160000002L002*@MHS> "While I like this proposal and think there is a definite need for it, I would rather see it as an addition to, rather than a replacement of, a simple data type attribute. This is not a technical issue, merely a usability one. It has simply been my experience that explaining what a function is to non-technical or moderately technical people is very difficult; explaining what a data type is, is not. Furthermore, I suspect that 80-90% of the data typing needs in a document can be met by a subset of the DCD data types. I am therefore reluctant to get rid of such a simple method, especially since data type attributes would be easily reusable outside of schema files:" I think I agree with that. I saw the validation scheme more as a way to do advance stuff and which could, if built into a parser, provide a way to do validation for any blessed W3C typing scheme as well (behind the scenes by just putting in a function bundle for those types and making the parser aware of the fact that these special types have associated validation functions out there to use.) ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 5 20:12:07 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:05:29 2004 Subject: EOC/SOX: element<->class mapping References: <3.0.1.16.19981001121803.744fdd8c@pop3.demon.co.uk> <3.0.1.16.19981002000723.2f4f3130@pop3.demon.co.uk> <3614C402.29807915@mecomnet.de> <36166002.5E31A86B@eng.sun.com> Message-ID: <36190C7F.12475D6C@mecomnet.de> David Brownell wrote: > > james anderson wrote: > ... > > > For this purpose [1st stage] it > > suffices to declare a relation between java packages and xml > > namespaces and to use introspection to map from element name > > to class. One would have standard java packages appropriate > > for and associated with standard elements. > > Of course with this sort of solution you prevent many-to-one > mappings. Those can be convenient to work with. If one must > take well formed XML and emit an HTML vocabulary, the ability > to have one class handle all of HTML's empty-element printing > syntax (e.g.
or
but never
) is a time saver, > certainly at the "encoding" level and possibly higher up too. > > Many other solutions for this exist. For now, I'm assuming > a factory method createElement(uri,tag) that can have many > implementations, including the one james sketched above. > I would agree, in principal, on the need for the above method for a factory instance. (In prior posts re namespaces I have argued that there is no use in separating the URI from the tag name, but I neglect that issue for the moment.) I advocate further, that the number of additional calls and the amount of anscilliary data be kept at a minimum. If I were to program in java, I would be concerned with the bulk and complexity of calls to specify the location of, and the need to administer the content of external mapping files and or other external specifications. Not to mention the need to distribute and maintain this meta-data with applets. This when, with judicious application of existing meta-object capabilities, the only call needed is one to match an xml namespace with a java package. While there may be EOC-requirements which extend beyond the need to specify an arbitrary class <-> element mapping, the namespace-based mechanism is sufficient for that, and therefore also sufficient for the problem which Mr. Brownell described. The application need only specify appropriate type relations between classes specific to HTML-elements and a parent class which comprises the desired behaviour and/or storage. One may well need to define interface classes and a package for this purpose. 1-N relations in the other direction are (as discussed earlier) a problem which extends beyond EOC. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Oct 6 02:11:55 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:05:29 2004 Subject: ANN: Docuverse DOM SDK PR3 Released Message-ID: <001801bdf0bd$d74c02d0$2ee044c6@arcot-main> Docuverse DOM SDK PR3 is the first publically available implemention of the final Document Object Model (DOM) Level 1 Specification (http://www.w3.org/TR/REC-DOM-Level-1/) You can download it from: http://www.docuverse.com/domsdk/index.html FYI, PR3 does not include the output framework support as originally planned but it does support serialization of the Core DOM objects. Support for serialization of HTML DOM objects as well as full output framework and PSE support will be in PR4. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Tue Oct 6 03:32:09 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:30 2004 Subject: XML data model Message-ID: <009b01bdf0c9$3b158240$02000003@thing1.camb.opengroup.org> Sorry, but I'm a little slow on the uptake, especially when something doesn't seem to touch on anything else that I'm familiar with. Again, some simple examples to relate these concepts to the problem of connecting XML data to Java objects might help a whole lot. Bill -----Original Message----- From: david@megginson.com To: XML Developers' List Date: Monday, October 05, 1998 8:25 AM Subject: Re: XML data model >Bill la Forge writes: > > > Some simple examples here might add a great deal to this > > discussion. I suspect that (a) this is vital, (b) I am not the > > only one unfamiliar with property sets, and (c) it is probably > > worth the bandwith to bring folks up to speed on this topic rather > > than simply cite some references. > >For the normative description of property sets, see > > http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.4.html > >For a quick introduction to the SGML property set currently supported >by Jade, see > > http://home.sprynet.com/sprynet/dmeggins/grove.html > > >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 amitr at abinfosys.com Tue Oct 6 05:33:10 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:30 2004 Subject: Any implementations of notations? Message-ID: <004f01bdf0da$8e0ee700$0101a8c0@server.abinfosys.com> Hello, After having sought the advice of XML gurus on this list , I have learnt that the type can be used for data validation of element content. eg. ]> TestData The SystemID =AlphaCheck.cmp could point to a COM component containing validation routines. QUESTIONS * I am in the process of trying to incorporate the use of notations in an XML based system I am working on, I was looking for some implementations involving notation use that could give me a clear picture of how user applications process the notational data (SystemID etc) given to it by the XML parser. Any clues/information/implementations on such types of XML applications? * Would anyone be knowing of any XML application which uses NOTATIONS the way I aspire to use them (as shown in the eg. above)? I have been told that datatype validation is taken care of by the DCD/XSchema specs, but they are yet to reach proper standardisation and so I look at notations within DTDs for taking care of my immediate need. Any help would be greatly appreciated, 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 olivo at iss.nus.edu.sg Tue Oct 6 05:43:21 1998 From: olivo at iss.nus.edu.sg (Olivo Miotto) Date: Mon Jun 7 17:05:30 2004 Subject: It's time for practical XML! Message-ID: <48256695.00129BEB.00@iss.nus.edu.sg> Hi I have thought about this thread. Perhaps (my 2c) the problem is in mailing lists rather than XML. There seems to be strong complaints in the original post about the diversity of the standard-making effort. I believe these stem from lack of appreciation for other people's problems, which are varied and equally urgent. For example, saying that what the community needs are "XML Editors" discounts the fact that many developers (most?) will never want XML files to be edited by humans. Not everyone is doing the same thing. The problem may be that we're all discussing all of these things in the same place, and it's difficult to find the information that interests us (now, shouldn't XML be solving that?) I must admit, though, that there is an aspect of the XML effort that bothers me, which is the overlap of some of the efforts. I am thinking of DCD/XSchema/XData/RDF for instance. I would like to see convergence or at least common strategies, nice and clear with pictures and examples. Maybe it's too early for that? Regards Olivo xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From graham.moore at dpsl.co.uk Tue Oct 6 10:26:46 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:05:30 2004 Subject: SOX - Overview, Issues, Implementati Message-ID: > I've just tried to organsie a few thoughts on the SOX issue; to clarify it for myself and maybe others. Perhaps we can take some of these headings or rename them, but I think we need some focus for the dicussion. This is a very important issue. We do not want to get this wrong. I've tried to highlight issues and alternatives, and where I feel strongly espress my opinion. So, here is an 1) Overview of what it is we are trying to achieve 2) Issues with Naming and Defining the association 3) Implementation 4) Potential Use - With Examples 5) where it can go 1) Overview To standardised the procedure of associating functionality with a seriliased object structure. Traditionally, objects have had the abiliy to serialise and unserialise themselves. The difference now is that with self describing serialised object structures the potential exists to associate different functional views with the same data object. The way in which a) the binding between the functionality ( functional object ?) and the object data is specified. b) this is implemented are the problems we are trying to solve. 2) Issues 2.1) Naming and Defining the association Who should name the functional assocition? 1) the receiving application could name the binding 2) the sending application could name the binding 3) the serialised instance could contain the binding information So do we need to agree on an interface for the domBuilder to allow all of these and other possibilities? Probably yes. 2.2) The binding information The binding could be a java package / OLE server. tThe naming works well with both oleServerName.automationObjectName javaPackageName.ClassName XXXX.ZZZZZZ in the general case. Does a package binding then imply a simple element to class mapping e.g. ...... mapping to menu.class within package myobjects A more refined step would be to specify all the bindings in an XML file. So we could have a package binding and then optionally an instance map as well. 3) Implementation I think the main question to answer is do we have an inheritance or delegation model. As others and myself have advocated, a delegation model is more powerful and a superset of inheritance. If we were all working using object lisp like systems then delegation would be the choice. However, most people are not and delegation does not integrate seamlessly with java or automation architectures. But it could be done. my opinion is that the functional binding specification should be written to allow for the definition of delegation structures with an additional 'strict' option - the dispatch order cannot be changed - to allow it to be implemented as an inheritance structure. 4) Potential Use & Examples 1) The 'coins' use of XML and the 'run' method on the root object demonstrates the use of XML as a transport and execution mechanism for agents. This is a specialisation of the general pattern of serialise, transport, rebuild and run. In this case the XML is the serialised form of the application. an example would be dynamciHTMLServer x.x.x.x5656 where name='index.html' so the binding would be from element finder to finder.class, but finder.class would probably inherit from the agent class. Calling 'run' would delegate the call to the finder class that would then execute. In the above case the agent would retreive a doc from a odbc database and send it or an error message to the 'reportTo' port. 2) Alternatively, the functionality is combined at the destination to provide a set of objects that are used the by the current application. Consider a TP system ... ... ... ... ... The TP system receivces this, binds the appropriate functionality and then asks the transaction trans.calculateTotal(); trans.calculateOfferReduction(); trans.CommitToDataBase(ODBCConnection); trans.CommitToDataBase(OO DB name); etc etc. 5) Where it can go.. Focus and contributions, organisation of thoughts; perhaps along some of the lines outlined above. A simple first step would be to define a domBuilder interface that could support a variety of ways forward. Perhaps as these are developed it will become clearer where to focus our efforts. lets go do it.. graham. gdm@dpsl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Oct 6 11:29:38 1998 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:05:30 2004 Subject: Microsoft COM parser (was Re: It's time for practical XML!) In-Reply-To: <361808BE.462F2045@technologist.com> References: <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> Message-ID: <199810060929.TAA06055@fep2.mail.ozemail.net> At 09:46 5/10/1998 , you wrote: | "Simon St.Laurent" wrote: | > | > While it might not make sense to create the COM object, it might make a lot | > of sense to build supporting structures for VB, Delphi, PowerBuilder, and | > whatever other tool you like to work with. | | Wouldn't VB, Delphi, PowerBuilder etc. users use Microsoft's COM object | parser? People do not, as an analogy, buy ".ini parsing libraries" for | these platforms. They use thin layers over the Microsoft-provided APIs. I think I'll jump on this, the second reference, to Microsoft's promised COM object. A couple of points: * So we want XML to be tied to the great monopoly? But, more practically: * When is this going to be delivered? * Will it work on NT 4/Windows 3.11/etc? * Will it be tied to IE? If I have to say to my customers, you need to install IE 6 in order to use XML, then that scares me. Shouldn't it scare you? So far, Microsoft placed a lot of functionality in IE, as part of it's plan to ensure market domination for it's browser. In any case, shouldn't we have more than one parser available? Or do we have all our eggs in the one basket? And finally, unless it is already in the IE 5 betas that are available, we will be waiting until NT 5 (year 2000), or IE 6 (?). 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 Vassili.Dzuba at wanadoo.fr Tue Oct 6 12:34:45 1998 From: Vassili.Dzuba at wanadoo.fr (Vassili Dzuba) Date: Mon Jun 7 17:05:30 2004 Subject: Announcement of MAJIX 1.0 : a WORD to XML converter Message-ID: <199810061030.MAA13171@ns.jbftelecom.com> Majix 1.0 : the new freeware in the world of marked languages TetraSix is now releasing Majix 1.0, a freeware you may access by visiting the Cie's site at http://www.tetrasix.com Majix 1.0 is the very first converter entirely written in Java which produces XML from RTF. Thanks to Majix 1.0, the conversion of RTF files into XML is easily done. This tool is deemed to be found essential by those concerned with the development of the Intranet, and those who run XML applications, as it allows users to populate a Word database without having first to create XML files. This is how TetraSix caracterizes MAJIX 1.0 - First of all, Majix 1.0 is pleasantly easy to use: the matching process between predefined Word styles and XML data items is very easy to do. - With Majix 1.0, every tag matching is managed by the user. Whatever the tag set (for instance, those tags used in any XML application and sector based DTD), it can be used when producing XML files. With this management fonction, users can start their own application from a common source - Majix 1.0 does not have fixed style sheets: you are free to add your own and to decide on your personal matching between different tag sets - Majix 1.0 is able to recognize pictures (whether included in a Word document or attached to it) and to place the appropriate tags. Majix 1.0 thus not only converts, but enriches complicated documents - MS Word tables are analysed and translated files contain the correct XML tags for these charts - Majix 1.0, because it is written according to XML grammar rules, guarantees your documents will be translated into well-formed XML files - Majix 1.0 can not only be used with msxsl (by Microsoft) to generate XML, but also with nsgmls (designed by James Clark) to validate the generated XML files. Majix 1.0 includes utilities which split XML documents into different size fragments which are adapted to any kind of publication on the World Wide Web - Majix 1.0 offers on-line help, which any browser of your choice will display. Majix 1.0 is available at the following address : http://www.tetrasix.com All your comments will be gratefully accepted and acknowledged. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 dvs1.informatik.tu-darmstadt.de Tue Oct 6 14:38:08 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:05:30 2004 Subject: It's time for practical XML! Message-ID: <199810061202.OAA01073@berlin.dvs1.tu-darmstadt.de> > I must admit, though, that there is an aspect of the XML effort that > bothers me, which is the overlap of some of the efforts. I am thinking of > DCD/XSchema/XData/RDF for instance. I would like to see convergence or at > least common strategies, nice and clear with pictures and examples. Maybe > it's too early for that? Overlapping proposals are an unfortunate reality of working out "standards". It is easy to think of XML, XLink, namespaces, etc. as having been handed down from on high, but I have no doubts that the process was just as messy as what you see now in the schema arena -- witness the overhauls of namespaces and XSL, for example. The only difference is whose efforts are overlapping and how public the process is. It has always been my hope that XSchema would help speed up, rather than hinder, the standards process by gathering and formalizing a large amount of input early in the process. (Of course, my motivation for helping in the project was not to forward standards, but simply to develop a simple schema language that I could use right now.) I do agree that the time is ripe for a convergence -- XSchema, DCD, and Schema-oriented XML all appear to be workable schema languages and all have, I believe, been at least partially implemented. In spite of their differences, they actually have more in common than not and cover roughly the same ground. This latter leads me to believe (rather naively, no doubt) that the W3C committee working on a schema language (assuming it exists) could simply choose, in one-from-column-A-two-from-column-B fashion, from the following areas and mold it into a common whole: Elements: * element names * element nesting (e.g. does an attribute definition need to be inside an element definition?) * element value type (attributes vs. PCDATA elements) Interaction with DTDs: * degree of DTD duplication, including degree of entity support * mappings to and from DTDs * interaction with DTDs Usability features (as desired): * container elements * authoring features (documentation, root, etc.)y * extensibility elements/strategy * parameterized element types * global attribute definition * modules * reuse/inheritance strategy (XLinks, ID/IDREF, extends, etc.) * etc. Other: * data type support * namespace support Use: * validation against a schema file * how to associate a schema file with an instance file Of course, it was naivete that led me to spend a good part of the summer on XSchema, so who am I to say? Still, it would be nice... -- 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 b.laforge at jxml.com Tue Oct 6 14:39:46 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:31 2004 Subject: SOX - Overview, Issues, Implementati Message-ID: <007801bdf126$4c66d1e0$02000003@thing1.camb.opengroup.org> Graham, I think we are going to need to take this more slowly, especially as we may be dealing with a new paradigm. >1) Overview > >To standardised the procedure of associating functionality with a seriliased >object structure. I don't see this at all. I am not at all interested in trying to figure out how to represent arbitrary grapghs of objects in XML. For me, the documents are primary. They are internalized as trees with secondary connections (IDREF's) and tertiary connections (links between documents) which are handled differently from the primary connections between nodes in the DOM. (Though right now, my emphasis is on a fourth connection, between an object in the tree and an application object. My focus is on internalizing a set of interconnected documents, performing some processing, and then updating selected documents. >Traditionally, objects have had the abiliy to serialise and unserialise >themselves. The difference now is that with self describing serialised >object structures the potential exists to associate different functional >views with the same data object. > >The way in which > > a) the binding between the functionality ( functional object ?) and the >object data is specified. > > b) this is implemented > >are the problems we are trying to solve. > >2) Issues > >2.1) Naming and Defining the association > >Who should name the functional assocition? > > 1) the receiving application could name the binding > 2) the sending application could name the binding > 3) the serialised instance could contain the binding information > >So do we need to agree on an interface for the domBuilder to allow all of >these and other possibilities? Probably yes. Lets look at what is being exchanged--the documents. so the first level of agreement needs to be on how the binding should be specified in the document, when that is appropriate, and when such information can be ignored. The next area of importance is the the shape of the domBuilder. Is it a standalone process (like coins)? or is it a class. If the latter, then what needs to be passed to it? What is the configuration information? A third area would be the api needed on the application objects, if any. A fourth area would be the data model for connecting XML and application objects. But key here is figuring out what this thing is and what kind of interfaces it might support (and why). >2.2) The binding information > Some of this looks like Microsoft terminology. A bit out of my scope. I think potentially there needs to be connections between an XML and the system it is running on, but I hope the document itself doesn't need to carry vendor-specific information!!! SOX may need some partitioning here. some developers may be sticking with the Sun JDK, while others are Microsoft all the way. Could we push this down to a lower level? I think it belongs, but nowhere near the top. A different appendix for each vendor- specific approach, perhaps. > The binding could be a java package / OLE server. tThe naming works well >with both > > oleServerName.automationObjectName > > javaPackageName.ClassName > > XXXX.ZZZZZZ in the general case. > > Does a package binding then imply a simple element to class mapping > > e.g. > > > ...... > > > mapping to menu.class within package myobjects > > A more refined step would be to specify all the bindings in an XML file. > > > > So we could have a package binding and then optionally an instance map as >well. And when you start using connection objects (I'm calling them wrappers right now) to move the data from the DOM into application-specific objects, you need to specify this connection object in the bindings as well. In a more general case, lets say you have a set of bindings, but within that set, there are different kinds of bindings supported. Now we can allow for wrappers, OLE servers, etc. > >3) Implementation > >I think the main question to answer is do we have an inheritance or >delegation model. As others and myself have advocated, a delegation model is >more powerful and a superset of inheritance. If we were all working using >object lisp like systems then delegation would be the choice. However, most >people are not and delegation does not integrate seamlessly with java or >automation architectures. But it could be done. > >my opinion is that the functional binding specification should be written to >allow for the definition of delegation structures with an additional >'strict' option - the dispatch order cannot be changed - to allow it to be >implemented as an inheritance structure. First, I'm confused by the word functional above. If it changes the meaning, of what was said, then I'm at a loss. By having different kinds of bindings, we can support a mix of models on an element-by-element basis. This is what coins does now. >4) Potential Use & Examples > >1) The 'coins' use of XML and the 'run' method on the root object >demonstrates the use of XML as a transport and execution mechanism for >agents. This is a specialisation of the general pattern of serialise, >transport, rebuild and run. In this case the XML is the serialised form of >the application. I think the words matter here. The term serialize is not generally restricted to DOM trees. I'd prefer to say externalize, transport, internalize. But parse is clearer than internalize. >an example would be > > > dynamciHTMLServer > x.x.x.x5656 > where name='index.html' > > >so the binding would be from > >element finder to finder.class, but finder.class would probably inherit from >the agent class. Well, I'd rather say that the binding depends on the current use being made of the document. If it is being transcribed into an email, then the bindings would be a bit different. If it is being processed for billing information, the bindings are again quite different. >Calling 'run' would delegate the call to the finder class that would then >execute. In the above case the agent would retreive a doc from a odbc >database and send it or an error message to the 'reportTo' port. > >2) Alternatively, the functionality is combined at the destination to >provide a set of objects that are used the by the current application. >Consider a TP system > > > > ... > ... > ... > ... > ... > > > >The TP system receivces this, binds the appropriate functionality and then >asks the transaction > >trans.calculateTotal(); >trans.calculateOfferReduction(); >trans.CommitToDataBase(ODBCConnection); >trans.CommitToDataBase(OO DB name); >etc >etc. Transport is a most exciting aspect, but only one aspect. The document is likely itself a wrapper for other documents. Further, a transported document itself is likely connected (linked to) other documents, forming a web of documents which provide the operating context for the transported document. >5) Where it can go.. > >Focus and contributions, organisation of thoughts; perhaps along some of the >lines outlined above. > >A simple first step would be to define a domBuilder interface that could >support a variety of ways forward. Perhaps as these are developed it will >become clearer where to focus our efforts. Might be better to focus on the shape first, before trying to attach interfaces to it. Is a bindings document the way to go? What about a data model for connecting a particular ml to a set of application documents? Perhaps the best thing is to clearly define the capability we are trying to develop. Bill >lets go do it.. > >graham. > >gdm@dpsl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Oct 6 15:17:30 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:31 2004 Subject: A plethora of schemas (was Re: It's time for practical XML!) In-Reply-To: <48256695.00129BEB.00@iss.nus.edu.sg> References: <48256695.00129BEB.00@iss.nus.edu.sg> Message-ID: <13850.6037.576415.349314@localhost.localdomain> Olivo Miotto writes: > I must admit, though, that there is an aspect of the XML effort > that bothers me, which is the overlap of some of the efforts. I am > thinking of DCD/XSchema/XData/RDF for instance. I would like to see > convergence or at least common strategies, nice and clear with > pictures and examples. Maybe it's too early for that? XML-Data is basically dead; DCD and XSchema, together with a few others, are outside proposals rather than W3C standards efforts -- a W3C working group will consider all of the proposals and then create a single standard for low-level XML structural schemas. RDF schemas are something different -- expect to see a lot of other application-specific high-level schema languages (for business models, e-commerce, etc.). 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 s861766 at mail86.yzu.edu.tw Tue Oct 6 15:54:23 1998 From: s861766 at mail86.yzu.edu.tw (Ephese Yang) Date: Mon Jun 7 17:05:31 2004 Subject: some question about SGML and XML Message-ID: <361A1F1C.8BFE7514@mail86.yzu.edu.tw> Hi, I am new in xml. Can someone tell me what is difference between SGML and XML? If I want to re-use SGML documents, do I need a SGML/XML converter to do this? If need, is there some freeware on public domain? Thanks your answers. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 6 16:03:31 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:31 2004 Subject: Microsoft COM parser (was Re: It's time for practical XML!) In-Reply-To: <199810060929.TAA06055@fep2.mail.ozemail.net> References: <361808BE.462F2045@technologist.com> <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> Message-ID: <199810061403.KAA01953@hesketh.com> At 07:28 PM 10/6/98 +1000, James Robertson wrote: >I think I'll jump on this, the second reference, to >Microsoft's promised COM object. > >A couple of points: > >* So we want XML to be tied to the great monopoly? > >But, more practically: > >* When is this going to be delivered? > >* Will it work on NT 4/Windows 3.11/etc? > >* Will it be tied to IE? > >If I have to say to my customers, you need to >install IE 6 in order to use XML, then that >scares me. Good points, and good reasons for more folks to develop Windows-specific but non-Microsoft solutions. It sounds like the Delphi crowd is already heading this direction; maybe others will follow. Componentizing parsers and other XML tools sounds good to me, whatever platform or development environment we're talking about. Speaking of which, I'd really like to see more for my poor old Mac... someday... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 Tue Oct 6 16:24:55 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:31 2004 Subject: TLAs (was: SOX) References: > Message-ID: <361A2813.7130EE5@locke.ccil.org> I think that to avoid massive confusion this list needs to drop "SOX" immediately and adopt another name, given the appearance of a W3C note called "SOX" (yet another XML schema language). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Tue Oct 6 17:41:40 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:05:31 2004 Subject: TLAs (was: SOX) References: > <361A2813.7130EE5@locke.ccil.org> Message-ID: <361A3AA1.F1615861@infinet.com> John Cowan wrote: > I think that to avoid massive confusion this list needs to drop > "SOX" immediately and adopt another name, given the appearance of a > W3C note called "SOX" (yet another XML schema language). How about SEX (Simple Element-Oriented XML). At least it would get the attention of the developer community and probably every cultural commentator as well (-: Seriously, do we really need the S for simple? I mean SAX is simple in how it presents parsed XML data to the application, but working with it is not quite as simple as it is a relatively low-level interface. Another question is do we really need an anacronymn. Programmers have this tendency to describe everything in terms of anacronyms, many of which don't make sense as they simply try and satisfy the requirement that an anacronymn be able to be pronounced in speech. Hey I am at a loss of words at the moment for a good name of what was tentatively called SOX so maybe we should have a contest for the best name here and vote on it. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eric at hellman.net Tue Oct 6 18:44:32 1998 From: eric at hellman.net (Eric Hellman) Date: Mon Jun 7 17:05:31 2004 Subject: More namespaces perversion Message-ID: David Brownell wrote: >In summary: all namespaces (ever) do is provide a layer of indirection. >Their meanings change over at least time. When you use namespaces you >need to consider what that change will do to your applications. It seems to me that the current NameSpaces draft adds TWO things to XML. 1. A layer of indirection is added. 2. A mechanism to associate XML elements with URI's is added. It seems to me that not much attention has been paid to the things that can usefully be done with that second function. After all, there is no role specified for the Namespace URI. But consider how different tools might make use of the Namespace URI. If I were adding Namespace support to a structured editor, I'd present the Namespace URI as a hyperlink button in my user interface - it's trivial to do, can't hurt anything. Now if I'm designing an XML DTD for use with that structured editor, it's suddenly possible to use the Namespace URI's as a documentation mechanism. I can get rid of all those unreadable comments in my DTD, and I document the dtd using web pages attached to each element via the default namespace attribute. This is particularly true in the latest draft, which allows a DTD author to specify default namespace URI's on an element-by-element basis simply by adding fixed xmlns attributes (no prefixing required!) I'm not saying this is necessarily a good thing to do, although it might be. (There are a bunch of advantages to separating the documentation from the DTD.) I'm just pointing out something that could result from widespread adoption of the current proposal. Eric Eric Hellman Openly Informatics, Inc. http://www.openly.com/ Tools for 21st Century Scholarly Publishing xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Tue Oct 6 19:24:46 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:05:31 2004 Subject: Deployability of XMLised HTML - authoritative survey? In-Reply-To: Message-ID: Hi I understand from anecdotal reports and my own experiments that it is possible to get most (recent?) browsers to sensibly interpret and render well formed XML that "looks a lot like" HTML. With much of HTML, this is just a matter of matching case and closing etc. The treatment of HTML's
and
as
and
is, it seems, workable. I'd very much like to hear that these anecdotes are true, and that someone somewhere has undertaken a more comprehensive survey of browser behaviour. I guess something like this must be going on in the HTML-futures area -- if so a URL pointer would be very much appreciated. Thanks for any references, Dan ps. reason I'm asking is that it would be nice (in various contexts) to be able to have a namespace URI dereference to something that contains both human-readable and browser displayable (X)HTML but that also contained machine oriented definitions. Content-negotiation would be another approach but might complicate cacheability of the delivered document... (?http cacheing experts please correct me on 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 Vassili.Dzuba at wanadoo.fr Tue Oct 6 19:41:04 1998 From: Vassili.Dzuba at wanadoo.fr (Vassili Dzuba) Date: Mon Jun 7 17:05:31 2004 Subject: annoucement of majix 1.0, a free MS-Word to XML converter Message-ID: <199810061736.TAA15767@ns.jbftelecom.com> Majix 1.0 : the new freeware in the world of marked languages TetraSix is now releasing Majix 1.0, a freeware you may access by visiting the Cie's site at http://www.tetrasix.com Majix 1.0 is the very first converter entirely written in Java which produces XML from RTF. Thanks to Majix 1.0, the conversion of RTF files into XML is easily done. This tool is deemed to be found essential by those concerned with the development of the Intranet, and those who run XML applications, as it allows users to populate a Word database without having first to create XML files. This is how TetraSix caracterizes MAJIX 1.0 - First of all, Majix 1.0 is pleasantly easy to use: the matching process between predefined Word styles and XML data items is very easy to do. - With Majix 1.0, every tag matching is managed by the user. Whatever the tag set (for instance, those tags used in any XML application and sector based DTD), it can be used when producing XML files. With this management fonction, users can start their own application from a common source - Majix 1.0 does not have fixed style sheets: you are free to add your own and to decide on your personal matching between different tag sets - Majix 1.0 is able to recognize pictures (whether included in a Word document or attached to it) and to place the appropriate tags. Majix 1.0 thus not only converts, but enriches complicated documents - MS Word tables are analysed and translated files contain the correct XML tags for these charts - Majix 1.0, because it is written according to XML grammar rules, guarantees your documents will be translated into well-formed XML files - Majix 1.0 can not only be used with msxsl (by Microsoft) to generate XML, but also with nsgmls (designed by James Clark) to validate the generated XML files. Majix 1.0 includes utilities which split XML documents into different size fragments which are adapted to any kind of publication on the World Wide Web - Majix 1.0 offers on-line help, which any browser of your choice will display. Majix 1.0 is available at the following address : http://www.tetrasix.com All your comments will be gratefully accepted and acknowledged. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 6 19:46:43 1998 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:05:31 2004 Subject: TLAs (was: SOX) In-Reply-To: <361A2813.7130EE5@locke.ccil.org> Message-ID: <3.0.1.32.19981006134550.0071cf40@pop.uunet.ca> At 10:24 AM 10/6/98 -0400, John Cowan wrote: >I think that to avoid massive confusion this list needs to drop >"SOX" immediately and adopt another name, given the appearance of a >W3C note called "SOX" (yet another XML schema language). On behalf of Veo Systems Inc, submittor of the W3C submission "Schema for Object-oriented XML (SOX)", I would like to apologize for any confusion that may be caused by NOTE-SOX. It is unfortunate that the same acronym was chosen at almost the same time to discuss topics that are so closely related. As it happens, NOTE-SOX was acknowledged by the W3C just days after Peter Murray-Rust first mentioned SOX on October 1st. Following private correspondence between Peter and I, he wrote "It is possible that the code "SOX" may cause namespace clashes." Veo appreciates Peter Murray-Rust's willingness to compromise, and the indulgence of the participants in the xml-dev mail list. Veo's schema submission is available from the W3C at: http://www.w3.org/Submission/1998/15/ 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 simonstl at simonstl.com Tue Oct 6 20:15:52 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:32 2004 Subject: Deployability of XMLised HTML - authoritative survey? In-Reply-To: References: Message-ID: <199810061815.OAA05124@hesketh.com> At 06:24 PM 10/6/98 +0100, Dan Brickley wrote: >I understand from anecdotal reports and my own experiments that it is >possible to get most (recent?) browsers to sensibly interpret and render >well formed XML that "looks a lot like" HTML. With much of HTML, this is >just a matter of matching case and closing etc. The treatment of >HTML's
and
as
and
is, it seems, workable. Reports are true; I'm doing this on the www.simonstl.com website. For an old analysis of the results of XML-ized HTML, see http://www.dejanews.com/getdoc.xp?AN=339640718 - note that this is pretty old and they used
instead of
. So far, my code works on most flavors of NS, IE, Lynx, and Amaya - see my site for details. I've been finishing (another) book, but hope to get back to this project soon. Sometime I'd like to build a nice neat table summarizing results. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 Tue Oct 6 20:32:41 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:32 2004 Subject: Deployability of XMLised HTML - authoritative survey? References: Message-ID: <361A620B.5C20BC58@locke.ccil.org> Dan Brickley wrote: > I'd very much like to hear that these anecdotes are true, and that > someone somewhere has undertaken a more comprehensive survey of browser > behaviour. I guess something like this must be going on in the > HTML-futures area -- if so a URL pointer would be very much appreciated. Well, I can say that Netscape 4.06, IE 4.01, and Lynx 2.7, all on Windows NT 4.0 SP3, are "XHTML-compliant" using the
trick. This hardly constitutes a comprehensive survey, of course, but have others datapoints to add? Maybe we can *make* a survey. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Tue Oct 6 21:49:20 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:32 2004 Subject: TLAs (was: SOX) Message-ID: <004101bdf162$18d2d040$02000003@thing1.camb.opengroup.org> SOX without the S is OX. And that should make a fine feast! Ignoring all the technical detalis of particularizing the elements in a DOM tree, it seems that we can simply say that a given set of bindings (however specified) transform an XML document into a DOM tree. It follows then that Bindings could be an interface with one method: public interface Bindings { public org.w3c.dom.Document convert(org.xml.sax.InputSource inputSource) throws SAXException; } Now, how one configures a Bindings object is an implementation issue. And for a given implementation, it may not even be configurable. This allows us to have Bindings which use Swing tree nodes, or Docuverse dom elements, or Coins. A nice interface for everything. (The SAX exception would typically be a SAXParseException.) 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 db at Eng.Sun.COM Wed Oct 7 00:56:46 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:32 2004 Subject: Deployability of XMLised HTML - authoritative survey? References: <361A620B.5C20BC58@locke.ccil.org> Message-ID: <361A9FB5.B96AB5A7@Eng.Sun.COM> John Cowan wrote: > > Well, I can say that Netscape 4.06, IE 4.01, and Lynx 2.7, all on > Windows NT 4.0 SP3, are "XHTML-compliant" using the
trick. The "3.0 browsers" seem a bit more sensitive; that's where some more facts would help most. I confess to having little sympathy for the folk running 2.0 browsers any more. IE 4.01 accepted "
" (no space) for me. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Oct 7 01:12:01 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:05:32 2004 Subject: Deployability of XMLised HTML - authoritative survey? In-Reply-To: <361A9FB5.B96AB5A7@Eng.Sun.COM> References: <361A620B.5C20BC58@locke.ccil.org> Message-ID: <199810062311.TAA08249@hesketh.com> At 03:54 PM 10/6/98 -0700, David Brownell wrote: >John Cowan wrote: >> >> Well, I can say that Netscape 4.06, IE 4.01, and Lynx 2.7, all on >> Windows NT 4.0 SP3, are "XHTML-compliant" using the
trick. > >The "3.0 browsers" seem a bit more sensitive; that's where some more >facts would help most. I confess to having little sympathy for the >folk running 2.0 browsers any more. Netscape and IE 3.0 seemed to work fine with
in my tests (including IE 3.01/Mac). I'll have to dig out an old DevEdge disk for 1.0 and 2.0. I may even have an old Mosaic someplace... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 Wed Oct 7 01:31:30 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:32 2004 Subject: TLAs (was: SOX) In-Reply-To: <361A3AA1.F1615861@infinet.com> References: <361A2813.7130EE5@locke.ccil.org> Message-ID: <3.0.1.16.19981007002646.353fa928@pop3.demon.co.uk> At 11:43 06/10/98 -0400, Tyler Baker wrote: >John Cowan wrote: > >> I think that to avoid massive confusion this list needs to drop >> "SOX" immediately and adopt another name, given the appearance of a >> W3C note called "SOX" (yet another XML schema language). > >How about SEX (Simple Element-Oriented XML). At least it would get the attention >of the developer community and probably every cultural commentator as well (-: Element-Oriented XML is a pleonasm; I'm not sure what XML without elements would look like :-). I used the term "Element-Oriented Computing" (or Processing) as an analogy with OOP. The point is that the programming is mapped onto the elements and for each element there is an (objected-oriented) chunk of code. An alternative is Element-Object mapping. I don't claim originality, but it has been a central theme of the way I have been programming since I started SGML about 4 years ago (with costwish). It needs a term to describe it as I think it's different from stylesheet-based programming (DSSSL gurus will probably contest this). > >Seriously, do we really need the S for simple? I mean SAX is simple in how it >presents parsed XML data to the application, but working with it is not quite as >simple as it is a relatively low-level interface. Well, *I* can use SAX and that sets an upper limit on complexity :-). More seriously I think it will be extremely important in this discussion to keep things as simple as possible. I certainly don't understand everything that has been written on S*X in the last week or so; this is a useful touchstone for an upper limit. > >Another question is do we really need an anacronymn. Programmers have this >tendency to describe everything in terms of anacronyms, many of which don't make >sense as they simply try and satisfy the requirement that an anacronymn be able >to be pronounced in speech. > >Hey I am at a loss of words at the moment for a good name of what was tentatively >called SOX so maybe we should have a contest for the best name here and vote on >it. I agree (thanks to MurrayM for his mail). It is useful to have a handle for this concept. Acronyms (sic) are useful. By analogy with XSchema, I'll kick off with XObject (XML-Objects). I bet it's not novel by now. 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 Wed Oct 7 01:31:31 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:32 2004 Subject: some question about SGML and XML In-Reply-To: <361A1F1C.8BFE7514@mail86.yzu.edu.tw> Message-ID: <3.0.1.16.19981007002953.353ffe70@pop3.demon.co.uk> At 21:46 06/10/98 +0800, Ephese Yang wrote: >Hi, > >I am new in xml. Can someone tell me what is difference between SGML and >XML? If I want to re-use SGML documents, do I need a SGML/XML converter >to do this? If need, is there some freeware on public domain? There are two essential places to look for XML information: http://www.oasis-open.org/cover Robin Cover's page http://www.ucc.ie/xml Peter Flynn's FAQ You will find everything there and pointers to everything elsewhere. 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 cbullard at hiwaay.net Wed Oct 7 04:05:18 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:05:32 2004 Subject: It's time for practical XML! References: <199810061202.OAA01073@berlin.dvs1.tu-darmstadt.de> Message-ID: <361ACBD9.3130@hiwaay.net> Ron Bourret wrote: > > Overlapping proposals are an unfortunate reality of working out "standards". It > is easy to think of XML, XLink, namespaces, etc. as having been handed down from > on high, but I have no doubts that the process was just as messy as what you see > now in the schema arena -- witness the overhauls of namespaces and XSL, for > example. The only difference is whose efforts are overlapping and how public > the process is. There are some differences. First, XML wasn't handed down from on high as you note. It is the culmination of almost two decades of effort on SGML and then HyTime just as XSL is informed by DSSSL. XML inherits much. Some very dedicated people have invested a good portion of their professional careers in markup technologies. The successes of SGML in making it possible to create and maintain very large document repositories informed the fairly short transition into XML. These efforts were maintained by professional standards organizations that operated according to processes informed by decades of experience in creating international standards. Overlapping efforts are a fact of life, but under the processes of say, ISO, these are curtailed to the degree possible by the charters of the working groups. So, no the processes are not usually as messy. But the messiness here is due in part to the use of the Internet and mail lists. IMHO, this also has enabled more people better access to the standards making process. Because of this, the speed with which a standard can emerge and vanish has increased. This is a somewhat new game. The players are learning how and the processes are maturing. Probably the most challenging area for XML is the role it plays as a meta language among application languages which do not share its foundation in a syntax-based specification. The discussion of property sets which emerged from the many years of trying to meet the issues in SGML should be considered because all of the Internet languages whose applications must interoperate are affected. XML, indeed, markup in general cannot solve the problems of interoperation nor can virtual machine based programming languages. Len Bullard IPS xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Oct 7 04:28:12 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:32 2004 Subject: Microsoft COM parser (was Re: It's time for practical XML!) References: <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> <199810060929.TAA06055@fep2.mail.ozemail.net> Message-ID: <361ACE92.204F2D69@technologist.com> James Robertson wrote: > > I think I'll jump on this, the second reference, to > Microsoft's promised COM object. > > A couple of points: > > * So we want XML to be tied to the great monopoly? No. But if I was going to make software to compete with the Great Monopoly, it would have to be free software. Commercial software is more expensive to develop, and the chances of making the money back are small. But you claim that free software isn't good enough. So what's the incentive? Paul Prescod - http://itrc.uwaterloo.ca/~papresco Bart: Dad, do I really have to brush my teeth? Homer: No, but at least wash your mouth out with soda. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 7 04:50:56 1998 From: jborden at mediaone.net (Jonathan A. Borden) Date: Mon Jun 7 17:05:33 2004 Subject: It's time for practical XML! In-Reply-To: <361ACBD9.3130@hiwaay.net> Message-ID: <000b01bdf19c$001302c0$d3228018@jabr.ne.mediaone.net> well put. [snip] > Probably the most challenging area for XML is the role it plays as a > meta language > among application languages which do not share its foundation in a > syntax-based > specification. The discussion of property sets which emerged from the > many years > of trying to meet the issues in SGML should be considered because all of > the > Internet languages whose applications must interoperate are affected. > XML, > indeed, markup in general cannot solve the problems of interoperation > nor can > virtual machine based programming languages. > > Len Bullard > IPS Perhaps of the greatest attractions of XML is hopefully the ability to bridge disparate systems, communications protocols and interfaces (in the broad sense of this term). If the world were 100% java there would be less need for XML solutions to interoperability ... all objects would talk to eachother in RMI and serialize themselves as java objects ... and theoretically all systems would interoperate - right? I doubt this will be reality in my lifetime and at least for what I can forsee as the future, there will be lots of good work connecting and bridging legacy (and new :-) systems. XML is poised to play an important role in this critical activity. No XML cannot solve this problem itself, nor can java, hence it remains important that XML solutions bridge programming languages and wire protocols. XML-RPC is a step in the direction of bridging wire protocols. I suggest that modeling the (IDL type) interface is of critical importance for XML if it is to have any meaningful role in interfaces in general. Both CORBA, COM and DCE-RPC are IDL based. Several XML IDL variants have been proposed. What we need out of XML IDL is interoperability with COM,CORBA,DCE-RPC IDL. This will provide language neutral XML based interoperability. Jonathan Borden JABR Technology http://jabr.ne.mediaone.net http://jabr.ne.mediaone.net/documents/sodl.htm http://jabr.ne.mediaone.net/documents/sodl.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 jamesr at steptwo.com.au Wed Oct 7 11:23:12 1998 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:05:33 2004 Subject: Microsoft COM parser (was Re: It's time for practical XML!) In-Reply-To: <361ACE92.204F2D69@technologist.com> References: <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> <199810060929.TAA06055@fep2.mail.ozemail.net> Message-ID: <199810070922.TAA14611@oznet14.ozemail.com.au> At 12:14 7/10/1998 , you wrote: | > I think I'll jump on this, the second reference, to | > Microsoft's promised COM object. | > | > A couple of points: | > | > * So we want XML to be tied to the great monopoly? | | No. But if I was going to make software to compete with the Great | Monopoly, it would have to be free software. Commercial software is more | expensive to develop, and the chances of making the money back are small. | But you claim that free software isn't good enough. So what's the | incentive? Well, if XML is going to have the huge impact everyone is hoping, then there will be a market, and therefore a source of revenue. Quite simply, those who are willing to lead the way when an idea is small will reap the benefits a thousand-fold when the market explodes in size. Take Netscape for example. As an SGML/XML consultant and software developer, I would not use free software unless: it had been through a number of versions; it was widely used; I had access to the source. Even then, I would have doubts. While there are a few obvious counter-examples (Linux and Apache), I would really rather use commercial software, and pay for it. I don't need an XML version of Word. Just a lightweight XML editor that can be embedded as a component in my Delphi/etc applications. It doesn't have to support graphics, namespaces, XLink, DCD, etc. Just DTDs and ideally a tiny bit of formatting to make it look nice for the user. Now I am contemplating developing this myself, simply to use in a project I am currently working on. I have the funds, but not the time. So, is there anyone out there, preferably in Australia, who has the expertise and time to do some contract programming on this? 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 peter at ursus.demon.co.uk Wed Oct 7 15:08:54 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:33 2004 Subject: TLAs (was: SOX) In-Reply-To: <3.0.1.32.19981006134550.0071cf40@pop.uunet.ca> References: <361A2813.7130EE5@locke.ccil.org> Message-ID: <3.0.1.16.19981007124345.0917eb06@pop3.demon.co.uk> At 13:45 06/10/98 -0400, Murray Maloney wrote: > >Veo appreciates Peter Murray-Rust's willingness to compromise, >and the indulgence of the participants in the xml-dev mail list. Not the first time :-) I also coined the TLA "XML" for eXperimental Markup Language and had to abandon it in favour of bigger things. (It's now called TecML - it will disappear as soon as people can get their act together over how to pass numbers over the WWW using XML.) > >Veo's schema submission is available from the W3C at: >http://www.w3.org/Submission/1998/15 Note that NOTE-SOX and XML-DEV-ex-SOX are substantially different so they is no competition other than for the handle 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 Wed Oct 7 15:09:02 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:33 2004 Subject: More namespaces perversion In-Reply-To: Message-ID: <3.0.1.16.19981007132232.35671f54@pop3.demon.co.uk> At 12:45 06/10/98 -0400, Eric Hellman wrote: >David Brownell wrote: >>In summary: all namespaces (ever) do is provide a layer of indirection. >>Their meanings change over at least time. When you use namespaces you >>need to consider what that change will do to your applications. > > >It seems to me that the current NameSpaces draft adds TWO things to XML. > >1. A layer of indirection is added. > >2. A mechanism to associate XML elements with URI's is added. > >It seems to me that not much attention has been paid to the things that can >usefully be done with that second function. After all, there is no role >specified for the Namespace URI. When one is writing element-oriented software there *may* needs to be a means of associating Java classes with elements. Thus if I have ... ... ... where C is the prefix for CML and M for MathML I need an absolute handle. If my code requires a search for MathML elements embedded in CML elements it can only be done through the URI - the prefixes are volatile. > >But consider how different tools might make use of the Namespace URI. > >If I were adding Namespace support to a structured editor, I'd present the >Namespace URI as a hyperlink button in my user interface - it's trivial to >do, can't hurt anything. The thing that's killing me at present is this: having read in an XML document to JUMBO2, edited it in some way, how to I add namespaces awareness to thew output. I have to decide where it's required (i.e. analyse the potential scoping, have a table of current namespaces, and make sure I don't have prefix clashes). None of it's rocket science, but all the little bits add up to a large amount of frustration. 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 Wed Oct 7 15:09:04 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:33 2004 Subject: SOX - Overview, Issues, Implementation In-Reply-To: <007801bdf126$4c66d1e0$02000003@thing1.camb.opengroup.org> Message-ID: <3.0.1.16.19981007140517.358f232e@pop3.demon.co.uk> At 08:38 06/10/98 -0400, Bill la Forge wrote: >Graham, > >I think we are going to need to take this more slowly, especially as >we may be dealing with a new paradigm. I agree. It is critical not to be too ambitious at present. I hope we can take it in steps. > > [Graham Moore] >>1) Overview >> >>To standardised the procedure of associating functionality with a >seriliased >>object structure. > > >I don't see this at all. I am not at all interested in trying to figure out >how >to represent arbitrary grapghs of objects in XML. I think that this wasn't intended to be so complicated. I think we are only concerned at this stage with mapping an XML element node (not the subtree and IDREFs, etc) onto a class or other object. > >> >>The way in which >> >> a) the binding between the functionality ( functional object ?) and the >>object data is specified. >> >> b) this is implemented >> >>are the problems we are trying to solve. So long as we keep it simple. >> >>2) Issues >> >>2.1) Naming and Defining the association >> >>Who should name the functional assocition? >> >> 1) the receiving application could name the binding >> 2) the sending application could name the binding >> 3) the serialised instance could contain the binding information >> >>So do we need to agree on an interface for the domBuilder to allow all of >>these and other possibilities? Probably yes. Originally (3) was chosen in the early namespace proposals using src= to link to a schema. I used this (and found it useful) but it has been superseded by a vacuum. [Because I move slowly JUMBO2 still uses remnants of this mechanism such as: which binds to jumbo.cml.MoleculeNode At least it works. (1) is what David Brownell offers in xml-ea1. When the elements hit the client they are matched against a properties file and mapped onto classes. I can be very happy with this, but everyone, including me, wants to see it in XML. *** XSchema would be perfect for this, folks??? I also like this because the *client* can vary the application. This means that is (hopefully) under their control. Thus if they get a , one person might want to send it to a database, another to synthesise it, another to calculate something with it. So there has to be freedom at this end. (2) this suggests that the actual tool used to create the document determines what tools are required to interpret it. This will lead to private conventions. Sure, XML will have private conventions, but I suggest we aim for interoperability at present. > > >Lets look at what is being exchanged--the documents. so the first >level of agreement needs to be on how the binding should be specified >in the document, when that is appropriate, and when such information >can be ignored. i.e. (3) above. I assume that we consider that schemas could be packaged alongside documents so that the actual instance doesn't need to be modified. > >The next area of importance is the the shape of the domBuilder. Is it >a standalone process (like coins)? or is it a class. If the latter, then >what needs to be passed to it? What is the configuration information? > >A third area would be the api needed on the application objects, if any. Yes. I hope this can be kept as simple as possible. > >A fourth area would be the data model for connecting XML and >application objects. > >But key here is figuring out what this thing is and what kind of >interfaces it might support (and why). > > >>2.2) The binding information >> > >Some of this looks like Microsoft terminology. A bit out of my scope. >I think potentially there needs to be connections between an XML >and the system it is running on, but I hope the document itself >doesn't need to carry vendor-specific information!!! SOX may >need some partitioning here. some developers may be sticking >with the Sun JDK, while others are Microsoft all the way. We clearly have to decide whether we can have a general approach or a Java/IDL only approach at the start. > >> >>3) Implementation >> >>I think the main question to answer is do we have an inheritance or >>delegation model. As others and myself have advocated, a delegation model >is >>more powerful and a superset of inheritance. If we were all working using >>object lisp like systems then delegation would be the choice. However, most >>people are not and delegation does not integrate seamlessly with java or >>automation architectures. But it could be done. I think that there is great virtue in having a simple java-compatible approach - there is such a lot to build on. If this leaves out more powerful approaches I don't think this will be an immediate disaster (after all we don't have anything yet !); > >>so the binding would be from >> >>element finder to finder.class, but finder.class would probably inherit >from >>the agent class. We have a problem with inheritance because there is no universally agreed method of defining it in SGML. To give an example of my own: I have a class ArrayNode to support: 1 2 3 4 5 And later I create: 1 2 1 1 2 3 2 1 where jumbo.cml.BondArrayNode extends jumbo.xml.data.ArrayNode But there is nothing in the SGML documents to enforce that bondArray can inherit the attributes of array. I doubt we can solve this in the first pass. > >Perhaps the best thing is to clearly define the capability we are trying to >develop. Agreed, but... if we keep it very simple then we can make progress. If not, we'll go into the quicksand. let's try to keep the concepts simple and implementable. > >Bill > >>lets go do it.. Also agreed. There is clearly a considerable demand and no negative voices. 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 Wed Oct 7 15:09:05 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:33 2004 Subject: It's time for practical XML! In-Reply-To: <199810061202.OAA01073@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19981007125651.379ff162@pop3.demon.co.uk> At 14:02 06/10/98 +0200, Ron Bourret wrote: > >It has always been my hope that XSchema would help speed up, rather than hinder, >the standards process by gathering and formalizing a large amount of input early >in the process. (Of course, my motivation for helping in the project was not to >forward standards, but simply to develop a simple schema language that I could >use right now.) I fully agree. And I support and applaud Ron and others for their effort on XSchema. When we were at the same stage with SAX there were a few voices who said it was unnecessary/too_simple etc. XSchema does a precise and workable job at present - encapsulating the semantics of a DTD in XML syntax **through an open process**. This means that it is highly unlikely that there are serious bugs or other problems. The question is whether it's useful. My own take is that it's important: - as a learning exercise - as a prototype on which applications can build - as something which is more important than might have been realised at the start - as an important intermediate step in the development of more ambitious schemas. Whether XSchema is at the core of these, history will decide. [...] > >This latter leads me to believe (rather naively, no doubt) that the W3C >committee working on a schema language (assuming it exists) could simply choose, >in one-from-column-A-two-from-column-B fashion, from the following areas and >mold it into a common whole: [... list snipped...] I think the key thing is to get it actually deployed and see who finds it useful for what :-). The lesson I am learning very strongly from the last few months is that it's much easier to imagine what you would like to do than to write interoperable code to make it happen. Therefore I always always rant on about things being simple. XSchema is about as simple as you can get without seriously losing DTD functionality. Ron and others are clear that code can be written for it. [I am yet to be convinced that *interoperable* code will be written for DCD or RDF - i.e. it may work in one manufacturer's environment but will there be freely available implementations?]. BTW Is XSchema finally released and frozen? Make a splash about it. > >Of course, it was naivete that led me to spend a good part of the summer on >XSchema, so who am I to say? Still, it would be nice... No - it wasn't - any more that it was naive for the others who have hacked code and contributed to specs. What I would like is some *formal* way of getting 'academic' credit for these works. SAX, XSchema, are worthy of formal peer-review. I would be happy to explore XML-DEV as a mechanism for this, but others might want 'safe' publication formats (i.e. paper journals). P. > >-- 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) > > 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 Wed Oct 7 15:33:47 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:33 2004 Subject: Microsoft COM parser (was Re: It's time for practical XML!) In-Reply-To: <199810070922.TAA14611@oznet14.ozemail.com.au> References: <361ACE92.204F2D69@technologist.com> <199810031328.XAA00629@oznet11.ozemail.com.au> <199810041600.MAA13713@hesketh.com> <199810060929.TAA06055@fep2.mail.ozemail.net> Message-ID: <3.0.1.16.19981007140735.358f0db8@pop3.demon.co.uk> At 19:21 07/10/98 +1000, James Robertson wrote: > >Now I am contemplating developing this myself, simply >to use in a project I am currently working on. I >have the funds, but not the time. > >So, is there anyone out there, preferably in Australia, >who has the expertise and time to do some contract >programming on this? > >Cheers, > >J What a wonderful mail! I am really pleased to see ideas for action. 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 rbourret at dvs1.informatik.tu-darmstadt.de Wed Oct 7 15:46:47 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:05:33 2004 Subject: It's time for practical XML! Message-ID: <199810071341.PAA10814@berlin.dvs1.tu-darmstadt.de> > BTW Is XSchema finally released and frozen? Make a splash about it. I'm hoping to get a final version out this week. The last round of reviews didn't produce many changes, and those it did produce were in recently added stuff (August or September). If you've still got comments on section 4 (XSchema and DTDs) or section 5 (Using XSchema), get them to me *now*. -- Ron Bourret Expected changes: ----------------- Sections 1-3: * Model cannot nest directly beneath Model (it can nest beneath Choice or Seq) * Add Enumeration container. Allow under AttDef and XSchema. * Add Doc and More to UnparsedEntity. Unparsed entity names must be unique. * Clarify description of Mixed. * Add ElementNS and ElementPrefix attributes to AttGroup, AttDef, and Ref. (How these work is still not 100% clear.) * Explain how to create XSchema documents for use in both namespace-aware and unaware environments. Section 4: * Loosen restrictions on Doc and comment conversion. * PIs are discarded. * Explain how to handle text encodings in external entities Section 5: * Add a public ID to the XSchema PI. Fix PI case. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 7 16:50:32 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:34 2004 Subject: (XML-DEV) SOX - Overview, Issues, Implementation Message-ID: <002401bdf201$f1c5c0c0$02000003@thing1.camb.opengroup.org> From: Peter Murray-Rust >I think that this wasn't intended to be so complicated. I think we are only >concerned at this stage with mapping an XML element node (not the subtree >and IDREFs, etc) onto a class or other object. Or onto a pair of objects, perhaps? I.E. An application object and a wrapper which implements the w3c Dom Element class. >>>2) Issues >>> >>>2.1) Naming and Defining the association >>> >>>Who should name the functional assocition? >>> >>> 1) the receiving application could name the binding >>> 2) the sending application could name the binding >>> 3) the serialised instance could contain the binding information >>> >>>So do we need to agree on an interface for the domBuilder to allow all of >>>these and other possibilities? Probably yes. > >Originally (3) was chosen in the early namespace proposals using src= to >link to a schema. I used this (and found it useful) but it has been >superseded by a vacuum. [Because I move slowly JUMBO2 still uses remnants >of this mechanism such as: > > > >which binds to jumbo.cml.MoleculeNode > >At least it works. > >(1) is what David Brownell offers in xml-ea1. When the elements hit the >client they are matched against a properties file and mapped onto classes. >I can be very happy with this, but everyone, including me, wants to see it >in XML. *** XSchema would be perfect for this, folks??? Only if each application has its own XSchema document for each use of each ml. I used to agree with this, but I now believe it should be a different document. >I also like this because the *client* can vary the application. This means >that is (hopefully) under their control. Thus if they get a , one >person might want to send it to a database, another to synthesise it, >another to calculate something with it. So there has to be freedom at this >end. > >(2) this suggests that the actual tool used to create the document >determines what tools are required to interpret it. This will lead to >private conventions. Sure, XML will have private conventions, but I suggest >we aim for interoperability at present. >> >> >>Lets look at what is being exchanged--the documents. so the first >>level of agreement needs to be on how the binding should be specified >>in the document, when that is appropriate, and when such information >>can be ignored. > >i.e. (3) above. I assume that we consider that schemas could be packaged >alongside documents so that the actual instance doesn't need to be modified. 1 & 3 look solid, with 1 being able to override 3. >>A fourth area would be the data model for connecting XML and >>application objects. >> >>But key here is figuring out what this thing is and what kind of >>interfaces it might support (and why). I'm still clueless on sgml properties. Anyone have a book to recommend? Something which assumes no knowledge of SGML? >>>2.2) The binding information >>> >> >>Some of this looks like Microsoft terminology. A bit out of my scope. >>I think potentially there needs to be connections between an XML >>and the system it is running on, but I hope the document itself >>doesn't need to carry vendor-specific information!!! SOX may >>need some partitioning here. some developers may be sticking >>with the Sun JDK, while others are Microsoft all the way. > >We clearly have to decide whether we can have a general approach or a >Java/IDL only approach at the start. I think now that there should be provision for vendor-specifics. In 1, the bindings are local to the application, separate from the document, and can be vendor specific. In 3, there is a build-in dependency already, as the classes (or the particular version compatible with the data) may be tied to the vendor. So I've toggled on this one. But I'd really like the vendor-specifics pushed down to individual element considerations. Say we have a Bindings markup language which is universal, but which suports vendor-specific mappings at the element level. >>>3) Implementation >>> >>>I think the main question to answer is do we have an inheritance or >>>delegation model. As others and myself have advocated, a delegation model >>is >>>more powerful and a superset of inheritance. If we were all working using >>>object lisp like systems then delegation would be the choice. However, most >>>people are not and delegation does not integrate seamlessly with java or >>>automation architectures. But it could be done. > >I think that there is great virtue in having a simple java-compatible >approach - there is such a lot to build on. If this leaves out more >powerful approaches I don't think this will be an immediate disaster (after >all we don't have anything yet !); > >> >>>so the binding would be from >>> >>>element finder to finder.class, but finder.class would probably inherit >>from >>>the agent class. > >We have a problem with inheritance because there is no universally agreed >method of defining it in SGML. To give an example of my own: > >I have a class ArrayNode to support: > >1 2 3 4 5 > >And later I create: > >1 2 1 1 2 3 2 1 > >where jumbo.cml.BondArrayNode extends jumbo.xml.data.ArrayNode > >But there is nothing in the SGML documents to enforce that bondArray can >inherit the attributes of array. I doubt we can solve this in the first pass. I've been playing with wrappers/connectors in Coins. The wrappers implement Element and are part of the DOM tree. And they do not need inheritence. Each wrapper holds an application object which is instantiated based on the application bindings (based on element name). (This allows for wrapper reuse.) The application objects are free to use inheritence. They may or may not be able to participate in the DOM tree, depending on their constructor--If they have a constructor which takes an Element parameter, then they are given the wrapper which holds the reference to that application object. (Basically, we're talking about a peer relationship in this case.) I had at one point seriously considered aggregation for Elements and instead decided on pairs of objects with either one-way or two-way connections. It seems powerful enough. Enables application inheritence while avoiding Element inheritence. >>>lets go do it.. > >Also agreed. There is clearly a considerable demand and no negative voices. Sounds like fun to me. 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 murray at muzmo.com Wed Oct 7 17:00:48 1998 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:05:34 2004 Subject: Publishing papers on XML-dev work In-Reply-To: <3.0.1.16.19981007125651.379ff162@pop3.demon.co.uk> References: <199810061202.OAA01073@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.32.19981007110010.006f8bd8@pop.uunet.ca> At 08:56 AM 10/7/98 -0400, Peter Murray-Rust wrote: > >What I would like is some *formal* way of getting 'academic' credit for >these works. SAX, XSchema, are worthy of formal peer-review. I would be >happy to explore XML-DEV as a mechanism for this, but others might want >'safe' publication formats (i.e. paper journals). > As co-chair of the 8th International WWW Conference (http://www8.org/) I encourage participants in this mailing list to submit papers for peer review, presentation and publication in the Proceedings of the conference. (http://www8.org/prepapercall.html) Important Dates: Paper submission deadline:? November 23, 1998 Author notification: February 1, 1999 Paper final version due:? March 1, 1999 Conference:? May 11-14, 1999 (Toronto) The WWW8 Conference, sponsored by the International World Wide Web Conference Committee (IW3C2), will consist of refereed technical papers, tutorials, workshops, posters, a W3C track, and a Developer's Day track. Technical papers present original reports of substantive new work in areas that can be theoretical (models, analysis techniques, semantics), empirical (experiments, case studies), or implementation-oriented (new systems, tools, methodologies, user interfaces). Papers should properly place the work within the field, cite related work, and clearly indicate the innovative aspects of the work and its contribution to the development of the WWW. Papers will be refereed by an international Program Committee. Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Email: murray@yuri.org Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Oct 7 17:58:36 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:05:34 2004 Subject: More namespaces perversion References: <3.0.1.16.19981007132232.35671f54@pop3.demon.co.uk> Message-ID: <361BABA2.12F79817@mecomnet.de> Peter Murray-Rust wrote: > > The thing that's killing me at present is this: > > having read in an XML document to JUMBO2, edited it in some way, how to I > add namespaces awareness to thew output. I have to decide where it's > required (i.e. analyse the potential scoping, have a table of current > namespaces, and make sure I don't have prefix clashes). None of it's rocket > science, but all the little bits add up to a large amount of frustration. if one were to intern the names into packages as they are read, then no lexical analysis is needed at the point where the document is written. each package gets a unique name when it is introduced (at the first uri-prefix binding). prefix bindings for all packages present within a document are output "somewhere" at the document beginning. if the document has been constructed, then, depending on ones element storage, although a tree walk may be necessary, lexical analysis is not. the prefix bindings use the unique names, as do the qualified names in the document body. this is the power of packages and interned symbols. it's a better representation of the "namespace problem" than individual name/uri pairs. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Oct 7 19:38:22 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:34 2004 Subject: Publishing papers on XML-dev work In-Reply-To: <3.0.1.32.19981007110010.006f8bd8@pop.uunet.ca> References: <3.0.1.16.19981007125651.379ff162@pop3.demon.co.uk> <199810061202.OAA01073@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19981007165611.2a47c522@pop3.demon.co.uk> At 11:00 07/10/98 -0400, Murray Maloney wrote: >At 08:56 AM 10/7/98 -0400, Peter Murray-Rust wrote: >> >>What I would like is some *formal* way of getting 'academic' credit for >>these works. SAX, XSchema, are worthy of formal peer-review. I would be >>happy to explore XML-DEV as a mechanism for this, but others might want >>'safe' publication formats (i.e. paper journals). >> >As co-chair of the 8th International WWW Conference (http://www8.org/) >I encourage participants in this mailing list to submit papers >for peer review, presentation and publication in the Proceedings >of the conference. (http://www8.org/prepapercall.html) Thanks, This is of course a suitable publication place, as is the WWW J or the new journal of Markup (?technologies). I imagine real-life presence at the meeting is expected. I also ask whether there is a mechanism for submitting NOTEs to the W3C other than from members. Rather like papers in Proc. Roy Soc or PNAS have to be communicated by fellows/academicians on behalf of the authors. And is there any moderation/review of NOTEs? [There must be technical and editorial review, I assume.] 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 db at Eng.Sun.COM Wed Oct 7 19:51:33 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:34 2004 Subject: More namespaces perversion References: Message-ID: <361BA910.CDA258C2@eng.sun.com> Eric Hellman wrote: > > David Brownell wrote: > >In summary: all namespaces (ever) do is provide a layer of indirection. > >Their meanings change over at least time. When you use namespaces you > >need to consider what that change will do to your applications. > > It seems to me that the current NameSpaces draft adds TWO things to XML. > > 1. A layer of indirection is added. Come to think of it, one of the ways that "XML Namespaces" seems most odd to me is that it doesn't even do this. That is, there are no semantics whatever associated with the "namespace": no formal way in which they identify a set of bindings between names and whatever it is that they denote. (That's wanting a "namespace" to be a "context", yes.) > 2. A mechanism to associate XML elements with URI's is added. > > It seems to me that not much attention has been paid to the things that can > usefully be done with that second function. After all, there is no role > specified for the Namespace URI. Exactly. This means that there will be no standard way to make use of the bindings (between element/attribute names and "meaning") that are necessary. Everything is allowed ... there's not even a useful way to compare the namespaces, given mechanisms like HTTP redirects which can turn one URI into another. - 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 terje at in-progress.com Wed Oct 7 19:53:18 1998 From: terje at in-progress.com (terje@in-progress.com) Date: Mon Jun 7 17:05:34 2004 Subject: XML community outreach Message-ID: At 5:00 AM 10/6/98, Simon St.Laurent wrote: >I know of two Web sites that are up and running using XML transformations >to HTML: (Please let me know if I'm wrong, folks!) > >http://www.xmlinfo.com/ (plus sister sites xmlsoftware.com and schema.net) >and http://www.ncfocus.com/ Plus and , not to mention an unknown number of Mac based websites that to various extent make use of Interaction's dynamic XML-to-HTML processing capabilities. -- Terje | Media Design in*Progress Software for Mac Web Professionals at C a s c a d e... a comprehensive Cascading Style Sheets editor XPublish - for efficient website publishing with XML Make your Web Site a Social Place with Interaction! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 7 19:57:37 1998 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:05:34 2004 Subject: Publishing papers on XML-dev work In-Reply-To: <3.0.1.16.19981007165611.2a47c522@pop3.demon.co.uk> References: <3.0.1.32.19981007110010.006f8bd8@pop.uunet.ca> <3.0.1.16.19981007125651.379ff162@pop3.demon.co.uk> <199810061202.OAA01073@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.32.19981007135706.006f2a2c@pop.uunet.ca> At 12:56 PM 10/7/98 -0400, Peter Murray-Rust wrote: >At 11:00 07/10/98 -0400, Murray Maloney wrote: >>As co-chair of the 8th International WWW Conference (http://www8.org/) >>I encourage participants in this mailing list to submit papers >>for peer review, presentation and publication in the Proceedings >>of the conference. (http://www8.org/prepapercall.html) > > This is of course a suitable publication place, as is the WWW J >or the new journal of Markup (?technologies). I thought that WWWJ was no more. The Markup Technologies journal is an excellent place to publish. I am on the editorial board. > > I imagine real-life presence at the meeting is expected. Expected and encouraged. I expect the '99 conference to contain a lot of XML-related material. Since so much important XML work happens on this list, I am encouraging all participants to consider submitting a paper. > > I also ask whether there is a mechanism for submitting NOTEs to the W3C >other than from members. Rather like papers in Proc. Roy Soc or PNAS have >to be communicated by fellows/academicians on behalf of the authors. And is >there any moderation/review of NOTEs? [There must be technical and >editorial review, I assume.] I can't speak on behalf of W3C. I do know that the staff reviews all submissions. However, my examiniation of staff comments on previous submissions would not lead me to equate their review with a proper peer review process. 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 Oct 7 21:06:08 1998 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:05:35 2004 Subject: Publishing papers on XML-dev work In-Reply-To: <3.0.1.16.19981007165611.2a47c522@pop3.demon.co.uk> References: <3.0.1.32.19981007110010.006f8bd8@pop.uunet.ca> <3.0.1.16.19981007125651.379ff162@pop3.demon.co.uk> <199810061202.OAA01073@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.32.19981007145008.006fbe18@pop.uunet.ca> FYI. This, just in... >>Annoucing A Computing Research Repository >> >>Researchers have made their papers available by putting them on personal >>web pages, departmental pages, and on various ad hoc sites known only >>to cognoscenti. Until now, there has not been a single repository to >>which researchers from the whole field of computing can submit reports. >> >>This is about to change. Through a partnership of ACM, the Los Alamos >>e-Print archive, and NCSTRL (Networked Computer Science Technical >>Reference Library), an online Computing Research Repository (CoRR) is >>being established. The Repository has been integrated into the >>collection of over 20,000 computer science research reports and other >>material available through NCSTRL (http://www.ncstrl.org) and will be >>linked with the ACM Digital Library. Most importantly, the Repository >>will be available to all members of the community at no charge. >> >>We encourage you to start using the Repository right away. For more details, >>see http://xxx.lanl.gov/archive/cs/intro.html. That site provides >>information on how to submit documents, browse, search, and subscribe to >>get notification of new articles of interest. Please spread the word >>among your colleagues and students. CoRR will only gain in value as >>more researchers use it. >> >>See http://www.acm.org/repository for a more detailed description of CoRR. > 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 Wed Oct 7 23:06:25 1998 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:05:35 2004 Subject: XML data model In-Reply-To: <00e201bdf056$c871d940$02000003@thing1.camb.opengroup.org> (b.laforge@jxml.com) References: <00e201bdf056$c871d940$02000003@thing1.camb.opengroup.org> Message-ID: <199810071256.HAA01557@bruno.techno.com> [Bill LaForge, regarding Property Sets:] > Some simple examples here might add a great deal to this discussion. > I suspect that (a) this is vital, (b) I am not the only one > unfamiliar with property sets, and (c) it is probably worth the > bandwith to bring folks up to speed on this topic rather than simply > cite some references. We're a bit short on *simple* examples. The two existing complete and comprehensive property sets, one for SGML and the other for HyTime, are quite challenging to absorb. However, they can be made much easier to absorb in small doses by means of interactively browsing a browsable representation. Using its "PropGrinder" technology to munge the SGML and HyTime Property Sets, TechnoTeacher has created sets of HTML files that accomplish this goal. The SGML property set can be found at http://209.41.82.36/sgmlps I think Eliot Kimber's PHyLIS demo uses a very simple (probably overly simple, at least for industrial purposes) property set for CGM. http://www.phylis.com -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 tkeating at usweb.com Wed Oct 7 23:26:59 1998 From: tkeating at usweb.com (Tim Keating) Date: Mon Jun 7 17:05:35 2004 Subject: Microsoft COM parser (was Re: It's time for practical XML!) Message-ID: <001001bdf238$06736c80$f86df4d0@tkeating.austin.usweb.com> I have an XML parser written in Delphi that currently supports parsing all parts of an XML doc EXCEPT the DTD . . . once I solve that little problem, I expect to be able to freely release it, with source. Also, as Delphi has one-click ActiveX wrapper creation, I will compile and offer it as an OCX, as well. On an unrelated note, anybody know why the mail list doesn't set the reply-to on messages to itself? T I M K E A T I N G Senior Consultant, Austin Group __________________________________________ USWeb Corporation http://www.usweb.com/ 8310 Capital of Texas Hwy. North, Suite 160 Austin, TX 78731 ph: 512 502 8833 fax: 512 502 8843 mailto:tkeating@usweb.com USWeb - A Strategic Partner for the Information Age xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Oct 7 23:32:13 1998 From: tgraham at mulberrytech.com (Tony Graham) Date: Mon Jun 7 17:05:35 2004 Subject: Publishing papers on XML-dev work In-Reply-To: <3.0.1.16.19981007165611.2a47c522@pop3.demon.co.uk> References: <3.0.1.16.19981007125651.379ff162@pop3.demon.co.uk> <199810061202.OAA01073@berlin.dvs1.tu-darmstadt.de> <3.0.1.32.19981007110010.006f8bd8@pop.uunet.ca> <3.0.1.16.19981007165611.2a47c522@pop3.demon.co.uk> Message-ID: At 7 Oct 1998 16:56 , Peter Murray-Rust wrote: > This is of course a suitable publication place, as is the WWW J or the new > journal of Markup (?technologies). Markup Languages: Theory & Practice is a new journal from The MIT Press. Information can be found at: http://mitpress.mit.edu/MLANG The core journal will be a quarterly print publication with supplementary materials including letters, samples, and examples on the journal's web site. Submissions on XML are welcome. For more information on submission procedures and the journal's DTD, would-be authors should contact Tommie Usdin at . 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 cbullard at hiwaay.net Thu Oct 8 02:30:52 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:05:35 2004 Subject: It's time for practical XML! References: <000b01bdf19c$001302c0$d3228018@jabr.ne.mediaone.net> Message-ID: <361C0730.1A26@hiwaay.net> Jonathan A. Borden wrote: > > Perhaps of the greatest attractions of XML is hopefully the ability to > bridge disparate systems, communications protocols and interfaces (in the > broad sense of this term). Yes, that is what markup technologies have been about since Goldfarb, Mosher and Lorrie released their seminal work. XML has by dint of its web origins brought many people outside the tradtional publishing crafts into the game. So now ideas that were once considered only by the left wing lunatic fringe of SGML are being fought for and embraced. Any of the MID team vets would love SOX, VML, etc. > If the world were 100% java there would be less need for XML solutions to > interoperability ... all objects would talk to eachother in RMI and > serialize themselves as java objects ... and theoretically all systems would > interoperate - right? Well... err... if a VM wins yes. I don't think we ever get more than 80% done before the last old thing becomes the next new thing and the CS business takes another round though the Moebus loop. Interfaces are critical but let the ISO Java committee have that problem. ;-) > I doubt this will be reality in my lifetime and at least for what I can > forsee as the future, there will be lots of good work connecting and > bridging legacy (and new :-) systems. XML is poised to play an important > role in this critical activity. Sure, yet the longer I've been around, the more I've come to appreciate the 80% victories. The other oft overlooked benefit of markup is lifecycle support. Moving tagged content onto new machines without having to worry about which way a platform counted significant bytes was a lot easier when the publishers (usually DoD contractors) bit the bullet and did SGML. IETMs were dammed expensive and hard to produce, so not too many were done. When you consider that the text in the caption property of the object is moreorless the same as the footer of a page in a book, one realizes just how expensive the next round of moving content to a new platform can be if we don't use markup. If you saw what goes on trying to deliver and validate the contents of a relational database to the FBI (eg, incident records) when they are still using byte offsets as record separators, as a taxpayer, you would revolt. It is expensive yet most of your public safety systems vendors have to vet their software for precisely that kind of delivery. Now think that this is a foodchain starting from the time a 911 call is logged, through the local police department, then to the state, then to the Feds. At the final step, those records are used to set policy for administering the law enforcement agencies and advising law givers worldwide. Scary. Done every day, though. IOW, while XML-based components and objects are exciting to the programmers, the grunt problems of delivering and maintaining very large databases of mixed document types are still major drivers for using markup. That is why where some still like to fear or castigate Microsoft, their support is the vital event. Now it is an issue of selling MS-based products for XML to communities of developers weaned on RTF and Do While Not EOF to a recordset. 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 graham.moore at dpsl.co.uk Thu Oct 8 09:22:45 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:05:35 2004 Subject: XObjects (was TLAa was SOX) Message-ID: > I like XObjects. XObjects IS what we are doing. Its like CLOS - common lisp object system. Does that mean we could have XOS - XML Object System ! SOX backwards makes it all a little confusing I fear. :) anyway interfaces......... > public interface Bindings > { > public org.w3c.dom.Document > convert(org.xml.sax.InputSource inputSource) > throws SAXException; > } i think the above is at the right level. Is this part of a domBuilder interface? if so should 'convert' be 'build' public interface domBuilder { public org.w3c.dom.Document build(org.xml.sax.InputSource inputSource) throws SAXException; public org.w3c.dom.Document build(org.xml.sax.InputSource inputSource, org.w3c.dom.Document mappingDOM) throws SAXException; etc. } The second prototype is an example of how generic binding types might be specified. The mappingDOM contains information regarding the instantiation of the DOM from the inputSource. graham. gdm@dpsl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 8 11:11:12 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:35 2004 Subject: XObjects (was TLAa was SOX) In-Reply-To: > Message-ID: <3.0.1.16.19981008092648.29f7b3a4@pop3.demon.co.uk> At 08:18 08/10/98 +0000, Graham Moore wrote: > >I like XObjects. XObjects IS what we are doing. OK - unless it clashes with something else (X-windows, Active-X) let's start using it. [There was one mail today about SOX and I didn't know which one :-(]. We can always change XObjects later. 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 Oct 8 11:11:19 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:35 2004 Subject: Looking for a redistributable XML editor In-Reply-To: <199810072355.AAA22198@imbolc.ucc.ie> References: <199810071609.QAA13869@hengill.rhi.hi.is> Message-ID: <3.0.1.16.19981008101015.3fcfadf6@pop3.demon.co.uk> [Crossposted to XML-DEV. Please reply to that list if you are actually offering concrete help, otherwise here]. Yesterday I asked if there were any freely redistributable XML editors that I could use for teaching XML at a complete beginner level. The answers I have got so far are: - emacs. But it is very large and not easily to distribute. Also some people find it difficult to use. Probably too complex for a 1-day course - errrrm, that's it. Not even a simple WF-editor. This leaves me feeling depressed. The only solution is for me to write one in JUMBO. [JUMBO already does structural editing and can edit single PCDATA children, but it's rather ucky at present.] It needs a single pane where elements can be selected and tagged. And the tags have editable attributes. That's all. Should take a weekend. Would anyone be interested [*]? I'm sad, because there clearly isn't any groundswell [apart from a few oddballs like me] to develop XML as a populist approach, as HTML was. It's envisaged that innovation and tools will only come from commercial companies and that the prime use of XML is with high quality commercial tools. [I get mails saying "we do this with Omnimark/AuthorEditor/SoftQuad... etc., why don't you?". Guess.] Of course there is a huge volume of very high quality XML freeware that I applaud frequently and loudly, but it doesn't seem to be targeted at increasing the populist uptake of XML. If we cannot even provide simple tools for people to learn how to author WF XML documents, no wonder it is slower than we thought. It was recently suggested that some members of XML-DEV [which I moderate] are condescending. I don't think this is fair. Many of them have been enormously helpful on frequent occasions and many have contributed enormously to the freeware and other resources. I think the misunderstanding is that they come from fully equipped SGML (sic) backgrounds where their employers or their business have already bought SGML tools and they have no urgent need to worry about the next generation of XML tools at this stage. They are steeped in in-house SGML and their view of XML is necessarily coloured by this. What we want is a larger membership from outside the SGML community with the same populist enthusiasm as there was for HTML. Perhaps we should go out to lists on www.* and do some marketing, rather than simply being tied to the commercial model. BTW the first GUI HTML editing tool was written by a graduate student, Joe Wang (tkWWW). [Joe also developed the Globewide Network Academy and I cannot praise him too highly.] You don't have to be in a company to write XML software. P. [*] How many of you interpreted this as "I would be interested in helping with this?" - rather than "I would be interested if PeterMR did the work" :-)? But the latter will also be valuable to know :-) 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 Oct 8 11:15:07 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:35 2004 Subject: LISTRIVIA (mail replies) In-Reply-To: <001001bdf238$06736c80$f86df4d0@tkeating.austin.usweb.com> Message-ID: <3.0.1.16.19981008101147.3fcf3680@pop3.demon.co.uk> At 16:18 07/10/98 -0500, Tim Keating wrote: > >On an unrelated note, anybody know why the mail list doesn't set the >reply-to on messages to itself? Henry Rzepa may expand, but we run the list on a server which we do not manage. Henry only has limited rights to manage the list and this is not, I think, one of them. 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 jtauber at jtauber.com Thu Oct 8 11:45:09 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:05:35 2004 Subject: LISTRIVIA (mail replies) Message-ID: <003801bdf2a0$a9f903c0$de6118cb@caleb> >At 16:18 07/10/98 -0500, Tim Keating wrote: >> >>On an unrelated note, anybody know why the mail list doesn't set the >>reply-to on messages to itself? Because it is evil to do so. xml-dev has it right IMHO. see http://www.unicom.com/pw/reply-to-harmful.html If mailing list software changes the reply-to address you get the following results: - mail intended for an individual often gets sent to the whole list - you can't reply to the author easily - (worse still) if a subscriber to the list has a broken mail system, you can get into infinite loops when mail bounces get sent back to the list. I've learnt all three the hard way. In the case of the infinite loops, a mailing list I maintained brought down a system with thousands of users. The only disadvantage of *not* changing the reply-to is that replies to all go to both the sender and the list, so out of politeness you edit the to field before sending. -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://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 h.rzepa at ic.ac.uk Thu Oct 8 13:28:27 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:05:35 2004 Subject: LISTRIVIA (mail replies) In-Reply-To: <003801bdf2a0$a9f903c0$de6118cb@caleb> Message-ID: >>At 16:18 07/10/98 -0500, Tim Keating wrote: >>> >>>On an unrelated note, anybody know why the mail list doesn't set the >>>reply-to on messages to itself? > >Because it is evil to do so. xml-dev has it right IMHO. > >see http://www.unicom.com/pw/reply-to-harmful.html I could not have summarised it better myself!! Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ If my digital email signature is invalid, download a new root at http://www.belsign.be/en/services/receive/install-ca.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Thu Oct 8 14:08:36 1998 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:05:35 2004 Subject: More namespaces perversion Message-ID: <03ba01bdf2b4$1caa4d80$bcbc77c1@sgml.u-net.com> >This means that there will be no standard way to make use of the bindings (between element/attribute names and "meaning") that are necessary. What is to stop you using the concept Descriptive Elements, or even the class definition facilities, used for property set definition, as defined in the SGML Extended Facilities annex of ISO 10744? Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Chris.Brew at edinburgh.ac.uk Thu Oct 8 14:24:04 1998 From: Chris.Brew at edinburgh.ac.uk (Chris Brew) Date: Mon Jun 7 17:05:36 2004 Subject: Looking for a redistributable XML editor In-Reply-To: <3.0.1.16.19981008101015.3fcfadf6@pop3.demon.co.uk> References: <199810072355.AAA22198@imbolc.ucc.ie> <199810071609.QAA13869@hengill.rhi.hi.is> Message-ID: >[Crossposted to XML-DEV. Please reply to that list if you are actually >offering concrete help, otherwise here]. > >Yesterday I asked if there were any freely redistributable XML editors that >I could use for teaching XML at a complete beginner level. The answers I >have got so far are: > > - emacs. But it is very large and not easily to distribute. Also some >people find it difficult to use. Probably too complex for a 1-day course > > - errrrm, that's it. > >Not even a simple WF-editor. For this purpose, and maybe others, I think Henry Thompson's XED is a useful starting point ( http://www.cogsci.ed.ac.uk/~ht/xed.html ). Henry says: XED is a text editor for XML document instances. It is designed to support hand-authoring of small-to-medium size XML documents, and is optimised for keyboard input. It works very hard to ensure that you cannot produce a non-well-formed document. Although it neither parses DTDs in detail nor validates, it does keep track of your document structure, and provides context-based accelerators to make element and attribute entry fast and easy. and (on distributablity) 5. XED availability Beta versions of XED are available for trial evaluation and individual use. I will not be posting new release announcements as I fix bugs, but I will respond to all bug reports. This beta release, in contrast to the alpha releases up until now, includes a self-extracting installation for WIN32 users [This probably goes some way to meeting your need. Yes, I'm in the next office to Henry! ] Email: Chris.Brew@edinburgh.ac.uk Address: Language Technology Group, HCRC, 2 Buccleuch Place, Edinburgh EH8 9LW,Scotland Telephone: +44 131 650 4632 Fax: +44 131 650 4587 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Oct 8 15:57:15 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:36 2004 Subject: XObjects (was TLAa was SOX) Message-ID: <004e01bdf2c3$3237bca0$ab026982@thing1.camb.opengroup.org> >I like XObjects. XObjects IS what we are doing. Its like CLOS - common lisp >object system. XObjects captures it perfectly. >anyway interfaces......... > >> public interface Bindings >> { >> public org.w3c.dom.Document >> convert(org.xml.sax.InputSource inputSource) >> throws SAXException; >> } > >i think the above is at the right level. Is this part of a domBuilder >interface? > >if so should 'convert' be 'build' > > public interface domBuilder > { > public org.w3c.dom.Document > build(org.xml.sax.InputSource inputSource) > throws SAXException; > > public org.w3c.dom.Document build(org.xml.sax.InputSource >inputSource, org.w3c.dom.Document mappingDOM) > throws SAXException; > > etc. > } > >The second prototype is an example of how generic binding types might be >specified. The mappingDOM contains information regarding the instantiation >of the DOM from the inputSource. > >graham. One area I always need advice on is the names of things. I'm happy with build and DomBuilder. (I'm thinking Java, so I've capitalized the interface name.) When a DomBuilder object is built from a BindingsML document, the DomBuilder object is the root element of the DOM tree (as defined by BindingsML). Lets say we have an object, domBuilderBuilder, itself a DomBuilder object, which builds DomBuilder objects from BindingsML documents: Document myMLBindingsDoc=bindingsBindings.build(myMLBindingsInputSource); Element root=myMLBindingsDoc.getDocumentElement(); DomBuilder myMLBuilder=(DomBuilder)root; Document applicationDoc=myMLBuilder.build(applicationInputSource); The above code then achieves the same effect as the second build method. Likely best handled as a static method. So I think we could have only one method in the DomBuilder interface. And it may be best to have that interface NOT extend any other interface. That way we can simply subclass existing systems, which already build DOM trees from XML documents. For example, the Docuverse class com.docuverse.dom.DOM has a openDocument which does a build. So we could subclass it and get immediate conformance. (With only a little care needed to handle the exceptions properly.) Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Oct 8 16:38:51 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:36 2004 Subject: Correction: XObjects (was TLAa was SOX) Message-ID: <00ca01bdf2c9$424e06c0$ab026982@thing1.camb.opengroup.org> > Document >myMLBindingsDoc=bindingsBindings.build(myMLBindingsInputSource); > Element root=myMLBindingsDoc.getDocumentElement(); > DomBuilder myMLBuilder=(DomBuilder)root; > Document applicationDoc=myMLBuilder.build(applicationInputSource); Correction: Document myMLBindingsDoc=domBuilderBuilder.build(myMLBindingsInputSource); Element root=myMLBindingsDoc.getDocumentElement(); DomBuilder myMLBuilder=(DomBuilder)root; Document applicationDoc=myMLBuilder.build(applicationInputSource); (I should have said domBuilderBuilder instead of bindingsBindings.) 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 jcupp at essc.psu.edu Thu Oct 8 16:49:56 1998 From: jcupp at essc.psu.edu (Jason R. Cupp) Date: Mon Jun 7 17:05:36 2004 Subject: XML community outreach References: Message-ID: <361CCF73.484CE2F3@essc.psu.edu> I've been transforming FGDC (Federal Geographic Data Committee) XML metadata for a while now using a parser I've written in PERL that knowns about simple linking and the proposal-draft of XSL. Try "http://www.pasda.psu.edu/documents/search.cgi?k=state+college+dem", then click a result to see the result of the transformation. We have over 2000 XML documents working together with simple linking and DTDs that save us from redundancy and the hassle of changing all of those documents when, for example, the name of a server would change. Because our documents are large, everytime a document is requested and 'styled' -- it is copied to a cache for quicker retrieval later... fun! -- Jason R. Cupp (jcupp@essc.psu.edu) Geographic Information Systems Programmer The Pennsylvania State University terje@in-progress.com wrote: > Plus and , > not to mention an unknown number of Mac based websites that to various > extent make use of Interaction's dynamic XML-to-HTML processing > capabilities. Simon St.Laurent wrote: > I know of two Web sites that are up and running using XML transformations > to HTML: (Please let me know if I'm wrong, folks!) > > http://www.xmlinfo.com/ (plus sister sites xmlsoftware.com and schema.net) > and http://www.ncfocus.com/ > Terje | Media Design in*Progress wrote: > > Software for Mac Web Professionals at > C a s c a d e... a comprehensive Cascading Style Sheets editor > XPublish - for efficient website publishing with XML > Make your Web Site a Social Place with Interaction! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 8 17:38:27 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:36 2004 Subject: Looking for a redistributable XML editor In-Reply-To: References: <3.0.1.16.19981008101015.3fcfadf6@pop3.demon.co.uk> <199810072355.AAA22198@imbolc.ucc.ie> <199810071609.QAA13869@hengill.rhi.hi.is> Message-ID: <3.0.1.16.19981008161448.2d9f5d0e@pop3.demon.co.uk> At 13:23 08/10/98 +0100, Chris Brew wrote: >XED is a text editor for XML document instances. It is designed to [...] > >and (on distributablity) > >5. XED availability > >Beta versions of XED are available for trial >evaluation and individual use. I will not be posting new release >announcements as I fix bugs, but I will respond to all bug reports. This >beta release, in contrast to the alpha releases up until now, includes a >self-extracting installation for WIN32 users And he also says: "Onward distribution or component reuse is not allowed." "Evaluation" and "Individual use" - phrases which occur in several pre-release and *-lite products - would clearly seem to prohibit: - public demonstration (not "individual use") - handing copies to students ("onward distribution") I am not being picky - I take copyright very seriously - and try to honour both the letter and the spirit of the author. Also, it has been suggested that I distribute XML Notepad (Microsoft). I have not seen the terms of this but even if they allow free distribution it requires the recipient to have MSIE 4 installed. I cannot redistribute this either technically or legally :-) Note that "free" often does not mean redistributable. P. 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 db at Eng.Sun.COM Thu Oct 8 17:48:30 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:37 2004 Subject: More namespaces perversion References: <03ba01bdf2b4$1caa4d80$bcbc77c1@sgml.u-net.com> Message-ID: <361CDDBF.CDBC0A18@eng.sun.com> Martin Bryan wrote: > > >This means that there will be no standard way to make use > >of the bindings (between element/attribute names and "meaning") that > >are necessary. > > What is to stop you using the concept Descriptive Elements, or even the > class definition facilities, used for property set definition, as defined in > the SGML Extended Facilities annex of ISO 10744? Nothing -- but the point is that there's nothing preventing me from doing anything else either! Hence, no standard: I can't look at a document and know what its namespaces "mean" in any useful sense. (With DTDs, one expected natural language text in the form of per-element/attribute/... comments.) Perhaps what we need is XML Processing Instructions to associate with the namespace declarations, which identify how the bindings between namespace URIs and semantics are provided ... ;-) Yes, I know that defining "meaning" was not a goal of the XML namespace team. - 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 tyler at infinet.com Thu Oct 8 18:05:04 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:05:37 2004 Subject: XObjects (was TLAa was SOX) References: > Message-ID: <361CE320.95422C82@infinet.com> Graham Moore wrote: > I like XObjects. XObjects IS what we are doing. Its like CLOS - common lisp > object system. > > Does that mean we could have XOS - XML Object System ! SOX backwards makes > it all a little confusing I fear. :) This sounds like a good name but it is hard to pronounce. Maybe something like XBind since this in essence is a binding framework for mapping XML Elements to programming language objects or structures. > anyway interfaces......... > > > public interface Bindings > > { > > public org.w3c.dom.Document > > convert(org.xml.sax.InputSource inputSource) > > throws SAXException; > > } > > i think the above is at the right level. Is this part of a domBuilder > interface? The DOM is a general purpose tree for storing the parsed contents of an XML stream. I really don't like this subclassing idea very much though as the DOM I believe is not suitable for this type of framework since you are no just dealing with Element nodes but you are dealing with all kinds of nodes. I prefer a framework which says nothing about how the object tree is created or even if there is an object tree. The application should be responsible for doing this... The proprietary Element interface of the parser I have has a method witht he signature: Element forElementName(String name, int index); What this says is that for a given element name, that particular element is responsible for returning an object implementation which satisfies the element type. This allows the application to easily build its own in-memory tree (this is what I used for the DOM implementation) in any way it sees fit, or else not build an in-memory tree at all. Generally in Object-Oriented Programming you are dealing with graphs (or in this case just a tree) of objects. You can make the assumption that each element has some idea of what type the child elements are in most cases, and in the cases where the type is unknown or opaque, you can return a general purpose Element implementation. I have found this data-driven approach to be a lot easier to deal with than just SAX although this is a good candidate for something that can be layered on top of SAX (right now I do this natively in the parser). SAX is a simple lower level tokenizing interface for XML Parsers and does the job well, but for a lot of applications, dealing with SAX events is not unlike going back to the good old days of C and building all your data structures out of a few functions when parsing a data stream. So if I have a rectangle object that has 4 possible children, x, y, width, and height the code for implementing the forElementName method would be something like: public Element forElementName(String name, int index) { if (name == "x") { this.x = new X(); return x; } else if (name == "y") { this.y = new Y(); return y; } else if (name == "width") { this.width = new Width(); return width; } else if (name == "height") { this.height = new Height(); return height; } return null; } where objects X, Y, Width, and Height implement the element interface as well. Of course it would make much more sense to treat all of these as attributes here, but I am just using this as an example. For the last 6 months I have been using this approach successfully in an application which may have no knowledge whatsoever of some of the child content in the element tree, only that it has an idea of how to dynamically instantiate the element handler for that particular content. I think it would be a shame if this XOS API (or whatever it is named) favored some registry based interface or mapping interface cause everyone has already done these sort of things already for all kinds of applications and in the end you usually find yourself in a configuration nightmare maintaining all of these mappings. One example is CORBA. An example where the dynamic approach to proxies works beautifully is in a distributed object architecture for Java called Voyager from ObjectSpace. My comments, 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 avirr at LanMinds.Com Thu Oct 8 18:51:18 1998 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:05:37 2004 Subject: XML community outreach In-Reply-To: Message-ID: At 5:00 AM 10/6/98, Simon St.Laurent wrote: > >I know of two Web sites that are up and running using XML transformations > >to HTML: (Please let me know if I'm wrong, folks!) > > CommerceNet's www.xmlx.com does this too, and I've seen several interesting demos of this kind of transform from XMLU. 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 peter at ursus.demon.co.uk Thu Oct 8 18:53:45 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:37 2004 Subject: XObjects (was TLAa was SOX) In-Reply-To: <361CE320.95422C82@infinet.com> References: Message-ID: <3.0.1.16.19981008171831.3c9f7f14@pop3.demon.co.uk> At 12:06 08/10/98 -0400, Tyler Baker wrote: [... interesting approach snipped ...] > >My comments, Thanks very much. I am grateful to see these concrete examples. The discussion has been very useful so far. I get the feeling that we need to take the plunge and decide whether we can go for a generic approach or whether we have to plump for a subset of languages/architectures. As always I urge us to stay on the side of simplicity. I could understand what Tyler wrote :-) My personal preference is still for inheritance, but that's probably inertia and probably because I don't know any better. 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 Oct 8 18:53:58 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:37 2004 Subject: More namespaces perversion In-Reply-To: <361CDDBF.CDBC0A18@eng.sun.com> References: <03ba01bdf2b4$1caa4d80$bcbc77c1@sgml.u-net.com> Message-ID: <3.0.1.16.19981008173109.3c9f496a@pop3.demon.co.uk> At 08:43 08/10/98 -0700, David Brownell wrote: [...] > >Perhaps what we need is XML Processing Instructions to associate >with the namespace declarations, which identify how the bindings >between namespace URIs and semantics are provided ... ;-) > This *used* to be part of the namespace proposal about 10 web years ago, with the src= attribute. src= mapped to a schema. A schema was deliberately undefined. SIG opinion was against anything like this in the namespace proposal and it was removed. Personally I found this a pity because I had implemented it in JUMBO1 and it worked fine. I had things like: The schema was very similar to the current XSchema, extended for each element with things like: - help - java class mapping - additional semantic constraints worked nicely - had to tear it all up (yes, I know the warnings are in the drafts - :-) The current namespace spec *deliberately* provides no semantic resolution. I argued against this because it seemed a recipe for chaos. So far I haven't been proved right or wrong - we are still in the inaction phase. The current jumbo has a placeholder: and similarly for other namespaces. Not pretty, but it works. There have been warnings about the complexity of registries - I assume that the xml-ea1 props file is a registry? Personally I don't yet care. I'd much rather see us try to make this work than simple wait around. I'm game for whatever URI<->functionality mapping we choose (as long as it's simple) so that we can at least get some experience. David's done it, I've done it - I assume there are others. It's part of XObjects and needs addressing soonest :-) 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 db at Eng.Sun.COM Thu Oct 8 19:13:55 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:37 2004 Subject: XObjects (was TLAa was SOX) References: <004e01bdf2c3$3237bca0$ab026982@thing1.camb.opengroup.org> Message-ID: <361CF1B0.D39C925C@eng.sun.com> I believe we need two modes of document creation: "empty", so they can be constructed programmatically; and "parsed", where they're built from a stream of XML text. I'm posting this note (1) to point out the need for those two creation modes, (2) to suggest an API for the former, and also (3) to point out why the latter is harder than has yet been noted on this list. (Sorry for the length of that part!) Consider an API like this for the former: // like SAX ParserFactory, but using standard // factory naming conventions "createXXX" public class XmlDocumentFactory { /** * Creates an empty XML Document using a DOM * implementation that's administratively specified. * That is conventionally the system property . */ public static Document createDocument (); /** * Creates an empty XML Document using a DOM * implementation that's identified by the parameter. */ public static Document createDocument (String impl); } Such a document could of course be configured to know about particular element-->object bindings. The implementation of Document would need a null constructor, period. Re the latter, I agree that a "Builder" API with "build" method makes much sense ... in fact, Sun's current (and changeable!) APIs adopt that exact naming convention. The structure of such a builder is a tricky problem. I think of it as a module that's separate from the DOM and separate from the (SAX) parser, but might need to be coupled to either or to both. Reason: neither API is sufficient for supporting all DOM semantics without some more coupling. Example: fully conforming to DOM means having access to more information than SAX exposes. Which attributes were defaulted? What are the default values of attributes? Where do entities start/stop? What parsed entities exist? And more. While it's easy to write a builder that takes a SAX event stream and a document, then populates a DOM Document from it, it can't possibly offer full DOM semantics. (Then there's efficiency...) Example: fully conforming to DOM means feeding more data into the DOM implementation than the DOM APIs allow! How would you construct a DocumentType object? Or reset an attribute to its default value? Etc. How important do folk think it is to be able to mix'n'match parsers and DOM implementations? - 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 db at Eng.Sun.COM Thu Oct 8 19:39:04 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:37 2004 Subject: More namespaces perversion References: <03ba01bdf2b4$1caa4d80$bcbc77c1@sgml.u-net.com> <3.0.1.16.19981008173109.3c9f496a@pop3.demon.co.uk> Message-ID: <361CF7AF.39495677@eng.sun.com> Peter Murray-Rust wrote: > > There have been warnings about the complexity of registries - I assume that > the xml-ea1 props file is a registry? What do you mean by 'registry'? Currently it's just the simplest convention for associating XML Beans ("XObjects") with element names; and since it's a flat namespace, it can't plug in to XML namespaces. Sometimes when folk say "registry" they mean some global database. I design such things out of systems every chance I get. > Personally I don't yet care. I'd much > rather see us try to make this work than simple wait around. I'm game for > whatever URI<->functionality mapping we choose (as long as it's simple) so > that we can at least get some experience. > > David's done it, I've done it - I assume there are others. It's part of > XObjects and needs addressing soonest :-) A draft I wrote up a while ago defined such bindings in XML syntax something like this ... codebase="xmlbeans.jar" > That sketch omits two important features: (a) importing bindngs defined for other namespaces, (b) document-specific bindings, such as for the "default" namespace or embedded in a document. So for example a directive might be used to associate a preferred set of bindings with a document. - 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 pam.gennusa at dpsl.co.uk Thu Oct 8 19:42:56 1998 From: pam.gennusa at dpsl.co.uk (Pam Gennusa) Date: Mon Jun 7 17:05:37 2004 Subject: ANNOUNCE - XML Europe '99 Call for Parti Message-ID: > Hello All - Just to let you know that the XML Europe '99 Call for Participation is available on the gca website (www.gca.org). Or you can contact my office if you would like a hard copy sent to you. The conference will be held at an incredible facility, Palacio de Exposiciones y Congresos in Granada Spain, 26-30 April 1999. There will be manager, user, and technical expert tracks throughout the 4-day conference, which is proceeded by a day of tutorials. There will be an exhibition hall for 2 and a half days. If you are interested in submitted a paper, and I hope you are, please submit it to europe99@dpsl.co.uk before 4 December 1998 (which is the absolute deadline). The Programme Committee will be meeting starting on the 5th of December. All notifications will be made by the 11th of January. I look forward to hearing from you. Kind regards, Pam ++++++++++++++++++++++++++++++++++++++++++++ Pam Gennusa, Conference Chair Managing Director, Database Publishing Systems Ltd 608 Delta Business Park, Great Western Way Swindon, Wiltshire SN5 7XF United Kingdom Tel: +44 (0)1793 512 515; Fax: +44 (0)1793 512 516 Website: www.dpsl.co.uk Email: pam.gennusa@dpsl.co.uk ++++++++++++++++++++++++++++++++++++++++++++ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Oct 8 20:30:00 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:37 2004 Subject: XObject (was was was) Message-ID: <003301bdf2e9$ba418600$ab026982@thing1.camb.opengroup.org> There seem to be a lot of problems with DOM: - an incomplete set of interfaces - excessive overhead for some applications. But from the perspective of a component programming environment, where each application object has a peer member (or is a member) of the DOM tree, there seems to be a big advantage: a standard navigation api. So having a standard for converting an application-specific document reference into application-specific elements of a DOM tree means that we have decoupled the application code from the tool that builds the DOM tree. It also then creates a standard new kind of component-- an XObject, which could be a really good thing indeed if they are easy to write. 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 peter at ursus.demon.co.uk Thu Oct 8 20:35:21 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:37 2004 Subject: More namespaces perversion In-Reply-To: <361CF7AF.39495677@eng.sun.com> References: <03ba01bdf2b4$1caa4d80$bcbc77c1@sgml.u-net.com> <3.0.1.16.19981008173109.3c9f496a@pop3.demon.co.uk> Message-ID: <3.0.1.16.19981008191952.3f5f6d4a@pop3.demon.co.uk> At 10:34 08/10/98 -0700, David Brownell wrote: >Peter Murray-Rust wrote: >> >> There have been warnings about the complexity of registries - I assume that >> the xml-ea1 props file is a registry? > >What do you mean by 'registry'? Currently it's just the simplest I am simply quoting the term :-). I assumed it was some pangalactic system for associating names with things. Like FPIs/catalogs etc. Only here, for classes and elements. >convention for associating XML Beans ("XObjects") with element names; >and since it's a flat namespace, it can't plug in to XML namespaces. > >Sometimes when folk say "registry" they mean some global database. >I design such things out of systems every chance I get. I agree completely. Let's get things working first and design the cosmos later. > > [...] >A draft I wrote up a while ago defined such bindings in XML syntax >something like this ... > > > > uri="http://www.example.com/xmlbeans/app1"> > codebase="xmlbeans.jar" > > > > > > > > > > This looks as if it should map trivially into XSchema (Ron, Simon???) XSchema comes out this week, I think - I'm not suggesting it should be altered to fit this - more that this - along with help could be the first use. > >That sketch omits two important features: (a) importing bindngs >defined for other namespaces, (b) document-specific bindings, such >as for the "default" namespace or embedded in a document. XSchema suggestions? Looks very promising... 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 Oct 8 20:37:12 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:37 2004 Subject: XObjects (was TLAa was SOX) In-Reply-To: <361CF1B0.D39C925C@eng.sun.com> References: <004e01bdf2c3$3237bca0$ab026982@thing1.camb.opengroup.org> Message-ID: <3.0.1.16.19981008193425.3c9fdcae@pop3.demon.co.uk> At 10:09 08/10/98 -0700, David Brownell wrote: >I believe we need two modes of document creation: "empty", >so they can be constructed programmatically; and "parsed", >where they're built from a stream of XML text. I agree completely. I found I needed something this while I was constructing my subclasses of ElementNode (I call it XNode in JUMBO). So we also have to consider it for ElementNodes. Typically I find the following modes of operation: - read in a complete XML file and construct the subclassed ElementNodes at document creation. This may involve special storage, validation, inter Element relationships, etc. - create an empty tree. build on empty nodes. then create the node internals. This must then be strictly compatible with the DTD (if any). Help in regulating this would be useful :-) - read in (or create) a tree with non-empty elements and then modify these interactively (edit). This is similar to the last operation but might require additional support. > [... useful code snipped ...] > >Re the latter, I agree that a "Builder" API with "build" >method makes much sense ... in fact, Sun's current (and >changeable!) APIs adopt that exact naming convention. I am really pleased to hear that SUN's APIs are changeable. This is exactly the time, XML-DEVers, to try to get as much communality as possible before the concrete sets. > >The structure of such a builder is a tricky problem. I >think of it as a module that's separate from the DOM and >separate from the (SAX) parser, but might need to be coupled >to either or to both. Reason: neither API is sufficient >for supporting all DOM semantics without some more coupling. > >Example: fully conforming to DOM means having access to more >information than SAX exposes. Which attributes were defaulted? >What are the default values of attributes? Where do entities >start/stop? What parsed entities exist? And more. While >it's easy to write a builder that takes a SAX event stream >and a document, then populates a DOM Document from it, it can't >possibly offer full DOM semantics. (Then there's efficiency...) We always knew that SAX was an 80/20 solution. It seems we have the following options: - ignore those bits that SAX doesn't manage at present. At least this gives us a working system (and you can see how keen I am on working systems...) For the sort of thing I do, entities, default attributes etc. are not essential. Maybe I'm being selfish... But I'd hate us to spend months discussing what we should put in. - extend SAX so it does (al)most what we want. I can't comment. - base everything on DOM. Do we have enough stuff in DOM 1.0 and do we have sufficient XML parsers interfaced to DOM? [I'm rather ignorant here]. > 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 Oct 8 20:49:20 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:37 2004 Subject: XObject (was was was) In-Reply-To: <003301bdf2e9$ba418600$ab026982@thing1.camb.opengroup.org> Message-ID: <3.0.1.16.19981008194747.3ea75c94@pop3.demon.co.uk> At 14:30 08/10/98 -0400, Bill la Forge wrote: >There seem to be a lot of problems with DOM: > - an incomplete set of interfaces > - excessive overhead for some applications. > >But from the perspective of a component programming >environment, where each application object has a >peer member (or is a member) of the DOM tree, >there seems to be a big advantage: > a standard navigation api. > >So having a standard for converting an application-specific >document reference into application-specific elements of >a DOM tree means that we have decoupled the >application code from the tool that builds the DOM tree. > >It also then creates a standard new kind of component-- >an XObject, which could be a really good thing indeed >if they are easy to write. Fully agreed. If it helps anyone, they are welcome to download my code from xml-cml.org. The simple subclassed nodes are in jumbo.xml.data.*Node and are things like FloatNode, EnumerationNode, etc. More fun things are jumbo.xml.graphics.*Node with some simple graphics primitives. [I think this isn't the latest version mounted]. Then there are jumbo.cmlxml.MoleculeNode, etc. Most inherit methods, often overridden, from jumbo.xml.data.DataTypeNode. The public methods at least give some idea of my mental struggles and they may be helpful... 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 rbourret at dvs1.informatik.tu-darmstadt.de Thu Oct 8 21:07:53 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:05:38 2004 Subject: More namespaces perversion Message-ID: <199810081906.VAA20902@berlin.dvs1.tu-darmstadt.de> > [David Brownell]: > >A draft I wrote up a while ago defined such bindings in XML syntax > >something like this ... > > > > [bindings snipped] > > [Peter Murray-Rust]: > This looks as if it should map trivially into XSchema (Ron, Simon???) > XSchema comes out this week, I think - I'm not suggesting it should be > altered to fit this - more that this - along with help could be the first use. This sort of information would easily fit in an XSchema file, currently under the More element, although in a later version it would probably get and element of its own, either for inclusion under an ElementDecl or possibly free-floating under XSchema (I'll have to think about that one). However, somebody (Bill LaForge?) thought that this stuff probably shouldn't go in the schema file, as it is application-specific, not schema specific. That is, while you would presumably have a single schema for a given document class, you would probably have multiple bindings. (Please correct me if I've gotten this wrong.) Of course, there's nothing to stop you from naming bindings and keeping multiple different binding sets in a single schema file, but at some point I have to wonder why you need the schema information at all. Does an application that uses element bindings also need the other schema information, such as content model and attributes? It strikes me that the application generating the bindings is more likely to need schema information than an application using the bindings. > [David Brownell]: > >That sketch omits two important features: (a) importing bindngs > >defined for other namespaces, (b) document-specific bindings, such > >as for the "default" namespace or embedded in a document. I suspect the import problems could be solved by the general XSchema scheme of using XLink to import stuff from other files. Document-specific bindings could be handled by associating the appropriate XSchema file with the document through an XSchema PI. (I might be missing exactly what is meant by document-specific bindings here.) -- 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 hyoung at fiz.huji.ac.il Thu Oct 8 21:25:36 1998 From: hyoung at fiz.huji.ac.il (Hyoungsoo Yoon) Date: Mon Jun 7 17:05:38 2004 Subject: Looking for a redistributable XML editor References: <3.0.1.16.19981008101015.3fcfadf6@pop3.demon.co.uk> <199810072355.AAA22198@imbolc.ucc.ie> <199810071609.QAA13869@hengill.rhi.hi.is> <3.0.1.16.19981008161448.2d9f5d0e@pop3.demon.co.uk> Message-ID: <361D11E9.289B9B1D@fiz.huji.ac.il> Peter Murray-Rust wrote: > > Also, it has been suggested that I distribute XML Notepad (Microsoft). > have not seen the terms of this but even if they allow free distribution it > requires the recipient to have MSIE 4 installed. I cannot redistribute this > either technically or legally :-) It (being able to use XML Notepad) was the only reason I installed buggy IE5 beta on one of my systems. Believe it or not, it is the best (free) XML editor I have right now without these time stamps or copyright strings. (I don't think I really want to pay hundred bucks for those *commercial* editors, most of which are not really *commercial* grade IMHO.) youngsoo xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Thu Oct 8 21:28:41 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:05:38 2004 Subject: Looking for a redistributable XML editor In-Reply-To: Peter Murray-Rust's message of "Thu, 08 Oct 1998 16:14:48" References: <3.0.1.16.19981008101015.3fcfadf6@pop3.demon.co.uk> <199810072355.AAA22198@imbolc.ucc.ie> <199810071609.QAA13869@hengill.rhi.hi.is> <3.0.1.16.19981008161448.2d9f5d0e@pop3.demon.co.uk> Message-ID: Peter writes: [The XED licence precludes redistribution] Peter, I've responded positively in the past to requests for demos and/or use in teaching: ask me and I'll give you an answer. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 8 21:45:49 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:38 2004 Subject: More namespaces perversion In-Reply-To: <199810081906.VAA20902@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19981008204505.0bf74ba2@pop3.demon.co.uk> At 21:06 08/10/98 +0200, Ron Bourret wrote: [...] > >However, somebody (Bill LaForge?) thought that this stuff probably shouldn't go >in the schema file, as it is application-specific, not schema specific. That >is, while you would presumably have a single schema for a given document class, >you would probably have multiple bindings. (Please correct me if I've gotten >this wrong.) This is a core problem and rather isomorphous to (I think) DavidB's points 1-3. Does the Element-Object binding occur in the document/application/client, etc. I think we have to have an extensible, overridable mechanism. thinking as I go ... Assume I have defined in a DTD and therefore mapped to an ElementType (from memory - is that right?) in (say) http://www.xml-cml.org/cmlXSchema.xml. This is the planetwide definition of CML DTD and its associated XSchema. Assume we also add a of some sort: &moleculeJava; (Apologies for not reading the XSchema spec - it's offline... Please correct this example, Ron) The definitive binding is mapped onto an entity moleculeJava distributed from xml-cml.org. But when the client gets it they can override moleculeJava with their own entity. This will be quite common (I approve of it) since there will be very different functionalities that people want. The only thing is that they must implement the same API - the one we are discussing under XObjects. [...] > >> [David Brownell]: >> >That sketch omits two important features: (a) importing bindngs >> >defined for other namespaces, (b) document-specific bindings, such >> >as for the "default" namespace or embedded in a document. > >I suspect the import problems could be solved by the general XSchema scheme of >using XLink to import stuff from other files. Document-specific bindings could >be handled by associating the appropriate XSchema file with the document through >an XSchema PI. (I might be missing exactly what is meant by document-specific >bindings here.) I agree that XLink is another mechanism - I thought it was going to be a Recommendation a long time ago. If it were - and if we agreed some transclusion mechanism - my entity stuff could be something like: where moleculeJava was an ENTITY (if I have the syntax right). The earlier one seems easier. The main thing is to have an override mechanism 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 Oct 8 21:58:34 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:38 2004 Subject: Looking for a redistributable XML editor In-Reply-To: References: <3.0.1.16.19981008101015.3fcfadf6@pop3.demon.co.uk> <199810072355.AAA22198@imbolc.ucc.ie> <199810071609.QAA13869@hengill.rhi.hi.is> <3.0.1.16.19981008161448.2d9f5d0e@pop3.demon.co.uk> Message-ID: <3.0.1.16.19981008205431.0bf72a42@pop3.demon.co.uk> At 20:28 08/10/98 +0100, Henry S. Thompson wrote: >Peter writes: [The XED licence precludes redistribution] > >Peter, I've responded positively in the past to requests for demos >and/or use in teaching: ask me and I'll give you an answer. Many thanks. The first occasion is a seminar (in London) for businesses (see www.netproject.com) which we are running from the University. [The university - not the lecturers - are getting paid for this.] To make it easy I have been copying major software onto CDROM for the participants. We have not yet decided whether they can take the CDROMs away. If so, we might charge them. It is always useful for people to continue to do things after the event. So the various possibilities are: - demo XED to the class - distribute XED to the class and reclaim at it the end of the day. Tell them that if they want it internally they can download it as long as they use it for evaluation only and otherwise abide by the terms of the license. - allow them to take it away It is possible that we shall be asked to run further courses it which case it would be useful to agree a general policy to avoid having to return to you each time. BTW is there a publicly planned future for XED - i.e. is there likely to be a chargeable product or is it primarily for internal use or what? Many thanks and best wishes, 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 Oct 8 21:58:37 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:38 2004 Subject: Looking for a redistributable XML editor In-Reply-To: <361D11E9.289B9B1D@fiz.huji.ac.il> References: <3.0.1.16.19981008101015.3fcfadf6@pop3.demon.co.uk> <199810072355.AAA22198@imbolc.ucc.ie> <199810071609.QAA13869@hengill.rhi.hi.is> <3.0.1.16.19981008161448.2d9f5d0e@pop3.demon.co.uk> Message-ID: <3.0.1.16.19981008205822.0bf709f8@pop3.demon.co.uk> At 21:26 08/10/98 +0200, Hyoungsoo Yoon wrote: > >It (being able to use XML Notepad) was the only reason I installed >buggy IE5 beta on one of my systems. Believe it or not, it is the >best (free) XML editor I have right now without these time stamps or >copyright strings. > Thanks for the info. The problem - as you imply - is that one has to install MSIE. My non-installation is simply lack of disk space and the various problems that happen when one upgrades... and I cannot ask other people to undergo the same. 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 leonardr at Adobe.COM Thu Oct 8 22:36:06 1998 From: leonardr at Adobe.COM (Leonard Rosenthol) Date: Mon Jun 7 17:05:38 2004 Subject: JAR files (was Re: XML and Objects) In-Reply-To: References: <36108C1F.DC6F482E@eng.sun.com> Message-ID: At 1:23 AM +0000 9/29/98, Chris Hubick wrote: >> The Java ARchive (JAR) format has manifests at the very beginning, >> so that the correct digital signatures can be computed during download. > > A JAR file is a Zip file. > Actually, no they aren't. If you read the JAR specification, the actual format of the archive is NOT specified. Only the existance of the manifest file & directory and it's content. It is only by existing usage that currently available .jar files happen to use the ZIP archiving format. Leonard ---------------------------------------------------------------------------- Leonard Rosenthol Designated Free Electron (612) 766-4718 (Minn) Adobe Systems Incorporated (215) 233-5270 (Philly) PGP Fingerprint: 8CC9 8878 921E C627 0BC1 15BB FC19 64A9 0016 1397 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Oct 8 23:17:50 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:38 2004 Subject: More namespaces perversion Message-ID: <002201bdf301$1b7967a0$ab026982@thing1.camb.opengroup.org> From: Ron Bourret >> [Peter Murray-Rust]: >> This looks as if it should map trivially into XSchema (Ron, Simon???) >> XSchema comes out this week, I think - I'm not suggesting it should be >> altered to fit this - more that this - along with help could be the first use. > >This sort of information would easily fit in an XSchema file, currently under >the More element, although in a later version it would probably get and element >of its own, either for inclusion under an ElementDecl or possibly free-floating >under XSchema (I'll have to think about that one). > >However, somebody (Bill LaForge?) thought that this stuff probably shouldn't go >in the schema file, as it is application-specific, not schema specific. That >is, while you would presumably have a single schema for a given document class, >you would probably have multiple bindings. (Please correct me if I've gotten >this wrong.) Sounds right to me. -Bill >Of course, there's nothing to stop you from naming bindings and keeping multiple >different binding sets in a single schema file, but at some point I have to >wonder why you need the schema information at all. Does an application that >uses element bindings also need the other schema information, such as content >model and attributes? It strikes me that the application generating the >bindings is more likely to need schema information than an application using the >bindings. To restate this slightly, the XSchema is needed at the time the mapping from XML to application is defined. In the case of Coins, that is code-generation time. The bindings are used subsequently to connect the elements with the generated code and the application classes. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Oct 8 23:32:09 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:38 2004 Subject: XObjects (was TLAa was SOX) Message-ID: <003f01bdf303$32ceb160$ab026982@thing1.camb.opengroup.org> From: Peter Murray-Rust >At 10:09 08/10/98 -0700, David Brownell wrote: >>I believe we need two modes of document creation: "empty", >>so they can be constructed programmatically; and "parsed", >>where they're built from a stream of XML text. > >I agree completely. I found I needed something this while I was >constructing my subclasses of ElementNode (I call it XNode in JUMBO). So we >also have to consider it for ElementNodes. I agree as well. DomBuilder needs a second method for building an empty document. >Typically I find the following modes of operation: > - read in a complete XML file and construct the subclassed ElementNodes at >document creation. This may involve special storage, validation, inter >Element relationships, etc. > - create an empty tree. build on empty nodes. then create the node >internals. This must then be strictly compatible with the DTD (if any). >Help in regulating this would be useful :-) > - read in (or create) a tree with non-empty elements and then modify these >interactively (edit). This is similar to the last operation but might >require additional support. This is where something like XSchema could play a big role. A particular instance of DomBuilder should be bound to a single XSchema. If we have a DomBuilder that can handle XSchema's for editing, then the resulting editing-specific DOM tree should have pleanty of methods available for assisting. >> >>The structure of such a builder is a tricky problem. I >>think of it as a module that's separate from the DOM and >>separate from the (SAX) parser, but might need to be coupled >>to either or to both. Reason: neither API is sufficient >>for supporting all DOM semantics without some more coupling. >> >>Example: fully conforming to DOM means having access to more >>information than SAX exposes. Which attributes were defaulted? >>What are the default values of attributes? Where do entities >>start/stop? What parsed entities exist? And more. While >>it's easy to write a builder that takes a SAX event stream >>and a document, then populates a DOM Document from it, it can't >>possibly offer full DOM semantics. (Then there's efficiency...) > >We always knew that SAX was an 80/20 solution. It seems we have the >following options: > - ignore those bits that SAX doesn't manage at present. At least this >gives us a working system (and you can see how keen I am on working >systems...) For the sort of thing I do, entities, default attributes etc. >are not essential. Maybe I'm being selfish... But I'd hate us to spend >months discussing what we should put in. > - extend SAX so it does (al)most what we want. I can't comment. > - base everything on DOM. Do we have enough stuff in DOM 1.0 and do we >have sufficient XML parsers interfaced to DOM? [I'm rather ignorant here]. We can also get this information in the back door (as given above). But now I see a chicken/egg problem: What about those cases when we don't know before hand the applicable markup language? In that case the DomBuilder will need to handle all posibilities. Or is it reasonable to pre-parse? 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 db at Eng.Sun.COM Fri Oct 9 02:04:24 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:38 2004 Subject: More namespaces (non)perversion References: <199810081906.VAA20902@berlin.dvs1.tu-darmstadt.de> Message-ID: <361D52BE.4F2C6749@Eng.Sun.COM> Ron Bourret wrote: > However, somebody (Bill LaForge?) thought that this stuff probably shouldn't go > in the schema file, as it is application-specific, not schema specific. That > is, while you would presumably have a single schema for a given document class, > you would probably have multiple bindings. (Please correct me if I've gotten > this wrong.) I've certainly said as much in a number of presentations: the association between these "XML Beans" (XObjects) is a function of the task being performed with the data, not of the data itself. Some have called that "subject oriented" computing. It's an old and well proven model. Most people see it in terms of connecting different languages together via data format specs. That's not the simplest model though, and many folk want simple models to use (start with, evolve from, etc). Hence the recurrent desire of many folk to have a schema support stuff like this -- they've heard of schemas, schemas are new too, so just group it all together. > Of course, there's nothing to stop you from naming bindings and keeping multiple > different binding sets in a single schema file, but at some point I have to > wonder why you need the schema information at all. Does an application that > uses element bindings also need the other schema information, such as content > model and attributes? It strikes me that the application generating the > bindings is more likely to need schema information than an application using the > bindings. I see schema data as more describing the structure and semantics of the information, and the bindings describing the behaviour in the context of particular application tasks. Data + Behaviour = Objects, as they say. > > [David Brownell]: > > >That sketch omits two important features: (a) importing bindngs > > >defined for other namespaces, (b) document-specific bindings, such > > >as for the "default" namespace or embedded in a document. > > I suspect the import problems could be solved by the general XSchema scheme of > using XLink to import stuff from other files. Document-specific bindings could > be handled by associating the appropriate XSchema file with the document through > an XSchema PI. (I might be missing exactly what is meant by document-specific > bindings here.) The main issue I see with XLink there is that it's not done ... :-) There were actually two radically different issues I lumped under that moniker "document-specific bindings": (B1) stuff associated with the "default" namespace (no URI), presumably different for each document ... elements not associated with a namespace URI; (B2) documents which embed their own bindings, eliminating the problem of managing separate documents for bindings. The problem of referring to a set of bindings that was already defined is straightforward -- as I noted, a directive works. An XSchema PI is the same notion. - 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 ht at cogsci.ed.ac.uk Fri Oct 9 03:05:41 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:05:38 2004 Subject: Looking for a redistributable XML editor References: <3.0.1.16.19981008101015.3fcfadf6@pop3.demon.co.uk> <199810072355.AAA22198@imbolc.ucc.ie> <199810071609.QAA13869@hengill.rhi.hi.is> <3.0.1.16.19981008161448.2d9f5d0e@pop3.demon.co.uk> <3.0.1.16.19981008205431.0bf72a42@pop3.demon.co.uk> Message-ID: <3715.199810090105@mcilvanney.cogsci.ed.ac.uk> Peter wrote: [details of his XED request] I've replied directly to Peter on those. > BTW is there a publicly planned future for XED - i.e. is there likely to > be a chargeable product or is it primarily for internal use or what? There will be a 1.0 release by the end of the year, still free, but with a fee for sources for commercial exploitation. There MAY be a commercialised version with extra features in the new year, but the free edition won't go away. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ --CAA25982.907894993/cogsci.ed.ac.uk-- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From olivo at iss.nus.edu.sg Fri Oct 9 03:15:10 1998 From: olivo at iss.nus.edu.sg (Olivo Miotto) Date: Mon Jun 7 17:05:38 2004 Subject: Datatype constraints in DCDs Message-ID: <48256698.0003C151.00@iss.nus.edu.sg> I've been through the note with Dean Roddey's proposal for constraint formulation (http://www.lists.ic.ac.uk/hypermail/xml-dev/9810/0064.html), and I think it's on the right track. It seems that some of the concerns voiced in its replies are justified though, in particular the use of an additional parsing mechanism. I think XML parsing should be used. Dean offers an extensible mechanism, which is good; the alternatives proposed would create a number of additional tags which seems undesirable. Lastly, his concerns about the readability of the DCD I think are good, but on one hand this type of constraint building may be more interesting for non-human readable files; on the other, I feel the readability is impaired by the And/Or constructs in his proposal. I have thought about it, and believe that a more "slimline" solution would be to introduce a single tag, which works as an "if" statement, as follows Several ValidIf tags in sequence are ORed (somewhat like if...elseif) Nested ValidIf tags are ANDed (somewhat like nested if) Specifying an enumeration may be simply done as follows Actually, by making "Equals" the default rule, we have which does away with the tag which I though was a little grotty. This is the definition of the tag The rule attribute is left as CDATA to allow for custom validation rules. An initial simple set may be Equals LessThan LessOrEqual NotEquals GreaterThan GreaterOrEqual (or EQ, NE, LT, LE, GT, GE which seem sufficiently commonly understood). Because of the stronger typing given by the Datatype parameter, I believe there is no need for separate operators for string and numerals. A number of operators may be added, such as "MultipleOf", or "BeginsWith" or "Contains" etc. but I would propose keeping the basic set simple. I think the basic operators above would cover the majority of cases, especially if you remember that the objective is to describe the data constaints, not to test arbitrary data. I haven't thought a lot about it, but I believe this could accomodate operators like "IsNull" or "IsNotNull" (without value attribute), important to RDBMS folks. Well, that's it. I think this would clean up a lot of the datatype-related bits that are crowding the element and attribute definitions in DCD. I hope I have not overlooked anything. Look forward to your comments. Olivo ----- Olivo Miotto Technology Expert (Distributed Object Computing) Institute of Systems Science, National University of Singapore olivo@iss.nus.edu.sg Tel: +65-772 6644 Fax: +65-778 2571 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From graham.moore at dpsl.co.uk Fri Oct 9 09:57:50 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:05:39 2004 Subject: XObjects Message-ID: > I think Tyler is right when he says that having access to the parser events is useful. While the SaxInput should remain in the domBuilder interface could one extension be something more raw. build(URL xml); for example. The domBuilder can create its own parser set itself to be the event sink and build the DOM from the events. Tyler wrote > >The DOM is a general purpose tree for storing the parsed contents of an XML >stream. I really don't like this subclassing idea very much though as the DOM >I believe is not suitable for this type of framework since you are no just >dealing with Element nodes but you are dealing with all kinds of nodes. Yes but at the end of the day a node is a node is a node. And isn't "is-a-kind-of" the time to use the inheritance pattern? I still prefer a delegation mechanism to a simple inheritance. More dynamic, more powerful. With delegation you could have a Node object, a functional object and a delegator object The functional and Node objects are added to the delegator object (mix them in). The delegator is then the reference to the composite functionality. There is no dependency between the functional and Node objects. > I prefer a framework which says nothing about how the object tree is created or > even if there is an object tree. The application should be responsible for > doing this... The application is responsible. Its the application that gives the domBuilder the construction rules / element bindings / delegation structures that it wants applied. And the app gets back a functional dom or set of objects. > So if I have a rectangle object that has 4 possible children, x, y, width, and > height the code for implementing the forElementName method would be something > like: > public Element forElementName(String name, int index) { > if (name == "x") { > this.x = new X(); > return x; > } > else if (name == "y") { > this.y = new Y(); > return y; > } > else if (name == "width") { > this.width = new Width(); > return width; > } > else if (name == "height") { > this.height = new Height(); > return height; > } > return null; >} > where objects X, Y, Width, and Height implement the element interface as well. > Of course it would make much more sense to treat all of these as attributes > here, but I am just using this as an example. The generic form of this is.... public gdo createFunctionalXMLObject(gdo parent, String className){ gdo result= null; try { Class c = Class.forName(PACKAGE + ". " + className); Constructor cons = c.getConstructors()[0]; result = (gdo)cons.newInstance(null); result.init(parent,elemName); } catch (Exception e){ System.out.println("Class creation error : " + e); } return result; } Where PACKAGE is the java package name. I think this is pretty much the way the SUN ea stuff works already. Assumptions here are that a) the functional class subclasses from gdo (generic data object) / Node. b) there is a default constructor that takes no arguments. Comparing the two examples : for every application where you need functionality attached to XML objects In the generic scenerio the application writer merely specifies the bindings and writes ONLY the new functional class, if a new one needs to be written. This means they dont have to write the builder or implement the DOM node methods. Notice also how in VB set x = CreateObject(PACKAGE & "." & className) in C++ obj = CoCreateInstance(PACKAGE + "." + className); and in python x = OleCreate(PACKAGE + "." + className) - I can't remember the function call but its something like that. Paul knows. Would work. In addition I think the thing to remember is that someone has structured the XML as it is for a reason. If there is no interest in maintiaining the structure but a set of functional objects are required then either : 1) The xml is a single container with a flat list of children or 2) The domBuilder is configured to return a collection of objects that it builds from the XML. If there is no mapping then you get the generic data object. > I think it would be a shame if this XOS API (or whatever it is named) favored > some registry based interface or mapping interface cause everyone has already > done these sort of things already for all kinds of applications and in the end > you usually find yourself in a configuration nightmare maintaining all of > these > mappings. Yes, but at some stage you need to know the functional object to build. Where in your example above do you find the class 'Height' is it local to the application package?, the domBuilder package?. There needs to be some mechanism for specifying the binding. I think that using the element name as a direct mapping into the current package will lead to problems further down the line. graham. gdm@dpsl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From deeshu at yahoo.com Fri Oct 9 10:15:07 1998 From: deeshu at yahoo.com (jagadish gade) Date: Mon Jun 7 17:05:39 2004 Subject: XML community outreach Message-ID: <19981009081158.28860.rocketmail@send1e.yahoomail.com> hai, >yes there are two sites for xml transformations one forthe molecular experiments of the chemical markup language(cml), second for jon boskas's shakespeare plays . There are some more example sources listed at http://www.sil.org/sgml/xml.html#examples. if you know more on this let me know by jagdish ---Avi Rappoport wrote: > > At 5:00 AM 10/6/98, Simon St.Laurent wrote: > > >I know of two Web sites that are up and running using XML transformations > > >to HTML: (Please let me know if I'm wrong, folks!) > > > > CommerceNet's www.xmlx.com does this too, and I've seen several interesting > demos of this kind of transform from XMLU. > > 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) > > _________________________________________________________ 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 deeshu at yahoo.com Fri Oct 9 10:17:49 1998 From: deeshu at yahoo.com (jagadish gade) Date: Mon Jun 7 17:05:39 2004 Subject: XML community outreach Message-ID: <19981009081456.5481.rocketmail@send101.yahoomail.com> hai, >yes there are two sites for xml transformations one forthe molecular experiments of the chemical markup language(cml), second for jon boskas's shakespeare plays . There are some more example sources listed at http://www.sil.org/sgml/xml.html#examples. if you know more on this let me know by jagdish ---Avi Rappoport wrote: > > At 5:00 AM 10/6/98, Simon St.Laurent wrote: > > >I know of two Web sites that are up and running using XML transformations > > >to HTML: (Please let me know if I'm wrong, folks!) > > > > CommerceNet's www.xmlx.com does this too, and I've seen several interesting > demos of this kind of transform from XMLU. > > 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) > > _________________________________________________________ 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 peter at ursus.demon.co.uk Fri Oct 9 10:56:46 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:39 2004 Subject: LISTRIVIA (was Re: XML community outreach) In-Reply-To: <19981009081456.5481.rocketmail@send101.yahoomail.com> Message-ID: <3.0.1.16.19981009095513.2b1f3be0@pop3.demon.co.uk> At 01:14 09/10/98 -0700, jagadish gade wrote: Two copies of a personal message to: >hai, And unnecessarily quoted the xml-dev signature. Please do not use this list for personal messages and try to keep the bandwidth down. I am now charged for: - the connect charge - the ISP charge - transatlantic data traffic Yesterday someone (kindly, but unnecessarily) mailed me a large executable I didn't want. All of this costs me and many other list members real personal money. 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 graham.moore at dpsl.co.uk Fri Oct 9 12:42:47 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:05:39 2004 Subject: XObjects Message-ID: > I apologise if anyone gets this twice, I have a problem with my mail currently. I think Tyler is right when he says that having access to the parser events is useful. While the SaxInput should remain in the domBuilder interface could one extension be something more raw. build(URL xml); for example. The domBuilder can create its own parser set itself to be the event sink and build the DOM from the events. Tyler wrote > >The DOM is a general purpose tree for storing the parsed contents of an XML >stream. I really don't like this subclassing idea very much though as the DOM >I believe is not suitable for this type of framework since you are no just >dealing with Element nodes but you are dealing with all kinds of nodes. Yes but at the end of the day a node is a node is a node. And isn't "is-a-kind-of" the time to use the inheritance pattern? I still prefer a delegation mechanism to a simple inheritance. More dynamic, more powerful. With delegation you could have a Node object, a functional object and a delegator object The functional and Node objects are added to the delegator object (mix them in). The delegator is then the reference to the composite functionality. There is no dependency between the functional and Node objects. > I prefer a framework which says nothing about how the object tree is created or > even if there is an object tree. The application should be responsible for > doing this... The application is responsible. Its the application that gives the domBuilder the construction rules / element bindings / delegation structures that it wants applied. And the app gets back a functional dom or set of objects. > So if I have a rectangle object that has 4 possible children, x, y, width, and > height the code for implementing the forElementName method would be something > like: > public Element forElementName(String name, int index) { > if (name == "x") { > this.x = new X(); > return x; > } > else if (name == "y") { > this.y = new Y(); > return y; > } > else if (name == "width") { > this.width = new Width(); > return width; > } > else if (name == "height") { > this.height = new Height(); > return height; > } > return null; >} > where objects X, Y, Width, and Height implement the element interface as well. > Of course it would make much more sense to treat all of these as attributes > here, but I am just using this as an example. The generic form of this is.... public gdo createFunctionalXMLObject(gdo parent, String className){ gdo result= null; try { Class c = Class.forName(PACKAGE + ". " + className); Constructor cons = c.getConstructors()[0]; result = (gdo)cons.newInstance(null); result.init(parent,elemName); } catch (Exception e){ System.out.println("Class creation error : " + e); } return result; } Where PACKAGE is the java package name. I think this is pretty much the way the SUN ea stuff works already. Assumptions here are that a) the functional class subclasses from gdo (generic data object) / Node. b) there is a default constructor that takes no arguments. Comparing the two examples : for every application where you need functionality attached to XML objects In the generic scenerio the application writer merely specifies the bindings and writes ONLY the new functional class, if a new one needs to be written. This means they dont have to write the builder or implement the DOM node methods. Notice also how in VB set x = CreateObject(PACKAGE & "." & className) in C++ obj = CoCreateInstance(PACKAGE + "." + className); and in python x = OleCreate(PACKAGE + "." + className) - I can't remember the function call but its something like that. Paul knows. Would work. In addition I think the thing to remember is that someone has structured the XML as it is for a reason. If there is no interest in maintiaining the structure but a set of functional objects are required then either : 1) The xml is a single container with a flat list of children or 2) The domBuilder is configured to return a collection of objects that it builds from the XML. If there is no mapping then you get the generic data object. > I think it would be a shame if this XOS API (or whatever it is named) favored > some registry based interface or mapping interface cause everyone has already > done these sort of things already for all kinds of applications and in the end > you usually find yourself in a configuration nightmare maintaining all of > these > mappings. Yes, but at some stage you need to know the functional object to build. Where in your example above do you find the class 'Height' is it local to the application package?, the domBuilder package?. There needs to be some mechanism for specifying the binding. I think that using the element name as a direct mapping into the current package will lead to problems further down the line. graham. gdm@dpsl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rajesh_n1 at verifone.com Fri Oct 9 12:56:47 1998 From: rajesh_n1 at verifone.com (rajesh_n1@verifone.com) Date: Mon Jun 7 17:05:39 2004 Subject: Looking for a C++ XML Parser Message-ID: Hi all, We are looking for a C++ implementation of an XML parser (with source code, if possible) for commercial use. Requirements : * should be fast.(as fast as possible :-). * should be DTD aware . * preferably, a validating one with the option of switching off the Validation. Any idea where can I get a free one or one that can be purchased? Thanks, Rajesh N -------------------------------------------------------------------------------- -------------------------------------------------------------- VeriFone India Ltd., WindTunnel Road, MurugeshPalya, Bangalore-17. E-mail : rajesh_n1@verifone.com Ph : +91 - 80 - 529 8151/2/3/4 x 4017 (O) 080 - 527 17 08 (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 rajesh_n1 at verifone.com Fri Oct 9 13:16:40 1998 From: rajesh_n1 at verifone.com (rajesh_n1@verifone.com) Date: Mon Jun 7 17:05:39 2004 Subject: Looking for a C++ XML Parser Message-ID: oops!! I forgot to mention the platform.... We need the parser for HPUX 10.20 and HPUX 11.0. (Hence a parser with source code is preferred.) thanks, Rajesh N > Richard J. Anderson@DI > 10/09/98 12:05 PM > > Hi, > > What platform are you looking for ? > > Regards, > > Richard Anderson. > > >Hi all, > We are looking for a C++ implementation of an XML parser (with source >code, if possible) >for commercial use. >Requirements : >* should be fast.(as fast as possible :-). >* should be DTD aware . >* preferably, a validating one with the option of switching off the >Validation. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RJA at dip.co.uk Fri Oct 9 13:37:09 1998 From: RJA at dip.co.uk (RJA@dip.co.uk) Date: Mon Jun 7 17:05:39 2004 Subject: XML Parsers Message-ID: <80256698.003F5C17.00@dip.co.uk> Richard J. Anderson@DI 10/09/98 12:37 PM Hi, Could somebody point me to the W3 recommendation/proposal for a DTD DOM, if there is one. I've already got the core recommendation for DOM, but I want to know what interfaces I should support for accessing a DTD. Many thanks, Richard. **************************************************************** *** This post is of a personal nature and does not in anyway *** *** reflect the opinions or developments of DIP. *** **************************************************************** xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From benzim at rpi.edu Fri Oct 9 14:29:20 1998 From: benzim at rpi.edu (Matthew M. Benzing) Date: Mon Jun 7 17:05:39 2004 Subject: XML Workshops Message-ID: <01BDF35D.C9B78E80@isl.lib.rpi.edu> Does anyone know of any introductory XML workshops or short courses that are going to be held in the northeast US or Canada within the next calendar year? Thanks in advance, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Matthew M. Benzing Information Systems Librarian Rensselaer Polytechnic Institute (518) 276-2582 benzim@rpi.edu <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Oct 9 14:59:38 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:39 2004 Subject: More namespaces (non)perversion Message-ID: <002e01bdf384$d1d56de0$ab026982@thing1.camb.opengroup.org> From: David Brownell >I see schema data as more describing the structure and semantics >of the information, and the bindings describing the behaviour in >the context of particular application tasks. > >Data + Behaviour = Objects, as they say. I would rather say that the bindings identify or select the behavior. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Oct 9 15:31:27 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:39 2004 Subject: XObjects Message-ID: <004301bdf389$289ba500$ab026982@thing1.camb.opengroup.org> From: Graham Moore >I think Tyler is right when he says that having access to the parser events >is useful. While the SaxInput should remain in the domBuilder interface >could one extension be something more raw. > > build(URL xml); for example. The domBuilder can create its own >parser set itself to be the event sink and build the DOM from the events. Looking more and more like the Docuverse DOM.openDocument(Object). There should be some minimum set of parameter types which should be supported for conformance, SaxInput being one of them. URL is easy enough that mandating it shouldn't be a problem. But aside from SaxInput and SaxException, do we really want to mandate the use of SAX events? If we can find a way around that particular mandate, then we allow a tighter coupling between the parser and DOM construction, and allow for a more complete extraction of information from the document. This is where wrappers and delegation have something to offer. As long as the wrapper or a mixin of the aggregate are responsible for the events, only that code which handles the events need be vendor-specific: Simple application code that implements Element can be in the DOM tree directly, but would not have access to parse events. Application code held by a wrapper or participating in an aggregate would support an api or a design pattern (which is to say, JavaBeans), which benefits indirectly from parse events. >I still prefer a delegation mechanism to a simple inheritance. More dynamic, >more powerful. > >With delegation you could have a Node object, a functional object and a >delegator object > >The functional and Node objects are added to the delegator object (mix them >in). The delegator is then the reference to the composite functionality. >There is no dependency between the functional and Node objects. I believe it is appropriate to support the alternatives here via the Bindings specification, on a per-element basis. >> I prefer a framework which says nothing about how the object tree is >created or >> even if there is an object tree. The application should be responsible >for >> doing this... > >The application is responsible. Its the application that gives the >domBuilder the construction rules / element bindings / delegation structures >that it wants applied. And the app gets back a functional dom or set of >objects. Further, the application should be able to select different domBuilder's from different vendors and use them all together. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Oct 9 15:42:06 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:39 2004 Subject: TBodies ... References: <007001bdf305$23cc4ea0$2ee044c6@arcot-main> Message-ID: <361E1284.E79F2E55@locke.ccil.org> Don Park wrote: >> In other words, should the *implict* in the above >> HTML fragment tag be *explicitly* represented in the DOM? > I didn't answer this question earlier because there is no clear anwer. > > The DOM spec is very vague in this area. SGML rules, however, are not. An element with "O O" omissibility *exists* whether its tags appear in the source or not. Thus every HTML-DOM must have HTML as the top-level element even if there are no HTML tags. The same rule applies to HEAD, BODY, and TBODY. (SGML weenies on XML-DEV: am I wrong?) > Yes, I would like to assume that all table rows are inside table section > elements. But then I would also like to be able to add some custom elements > or attributes into my document. > > Perhaps what we need is a way to have two views of a Document. A 'perfect > world' view of the document for predictability and a 'anything goes' view of > a document for flexibility. I don't see this as a problem. This is not about rejecting what is there, but treating what does not appear as present. -- 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 ricko at allette.com.au Fri Oct 9 15:44:59 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:39 2004 Subject: Do we need link-catalogs for schemas? (was Re: More namespaces perversion) References: <03ba01bdf2b4$1caa4d80$bcbc77c1@sgml.u-net.com> <3.0.1.16.19981008173109.3c9f496a@pop3.demon.co.uk> Message-ID: <361E14DE.1500AA38@allette.com.au> Peter Murray-Rust ¼g¹D¡G > At 08:43 08/10/98 -0700, David Brownell wrote: > [...] > > > >Perhaps what we need is XML Processing Instructions to associate > >with the namespace declarations, which identify how the bindings > >between namespace URIs and semantics are provided ... ;-) > > > This *used* to be part of the namespace proposal about 10 web years ago, > with the src= attribute. src= mapped to a schema. A schema was deliberately > undefined. SIG opinion was against anything like this in the namespace > proposal and it was removed. Perhaps it is time to (attempt to) ressuscitate XML-Bind. This was a project of mine which I put forward during the Namespaces debate. The thrust of this was that the then namespace draft conflated two things: * some way to *bind* GIs into public identififiers (URL+GI or whatever) {this is what the current namespace has limited itself to} * some way to *link* this identifier to all sorts of interesting information. I tried to push the idea that having just a simple "src" attribute in the namespace PI tied restricted it arbitrarily, and had the bad effect of hardwiring a single vendor's schema. So instead I pushed a catalog idea, and in particular that the namespace proposal actually reflected a need for a new kind of link: linking from element types rather than from instances on elements. One wants to name them because one wants to link to or from them. I would like to raise this link-catalog idea again. The link-catalog idea was that potentially every stakeholder (end-user, document creator, browser-maker, DTD/schema creator) may want to use these type-links (for documentation, schema distribution, etc). It would be best if this were explicitly marked up using XLL extended links. A document should be able to have a web of type-related resources linked to/from it. Now the great thing about using instance syntax for new schemas (e.g. XSchema) is that no new linking declaration system needs to be invented: we can define any kind of link we need and markup the element in the Xschema instance. That way we get type-links. So now we are at the stage: 1) namespace proposal binds GI names to public identifiers 2) XSchmema proposal (and its ilk) can allow links from GIs to a catalog (e.g. using a fixed attribute) *but* we need to actually do it; 4) XLL proposal allows extended links, with which we can implement a catalog system, *but* we need to actually do it. So I would propose that XML-DEV should design an element set for catalog entries, it should cascade or be able to link with other catalogues. It might be a valuable enhancement to XSchema, and indicate to the W3C schema people the direction that people would like to go. (In particular, that there are many possible schemas, and even natrual language documents are valuable for defined document types.) The kind of thing I am thinking of is this: Links for HTMLs P element type In this example there is a single entry. The description field indicates the catalog entry relates to HTML paragraphs. The first lot of links link to schema definitions for HTML paragraphs, given in various notations (DTD, XSchema, DCD, RDF Schema). Then comes documentation for it in various ways (VHG, English, German). Finally comes a link to another link-catalog, which allows cascading or a web of links. In each entry, I have used an XLL href (a URL) and used an SGML FPI (Formal Public Identifier) for the role atribute. Anyone who wants to define a new role would make up a new FPI for that role. XML-DEV would create a good starting set of FPIs for the catalog: DTD XSchema English Documentation (.. and so on for every language) link-catalog After that, there should be some kind of new attibute in Xschema, available on all elements, called perhaps "link-catalog-href". This contains a URL pointing to an XML-Dev link-catalog IMHO this kind of thing would be a major addition to the power of XML: the W3C efforts to define a new single schema definition language are, to some extent, misguided and out-of-sequence in that it would be better to first set up an infrastructure by which schemas and documentation can be located. I am not convinced that having multitudes of schema definition languages is a bad thing: perhaps it is better to let companies compete and just provide an infrastructure which allows them to provide good product without hijacking documents. Cheers. 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 graham.moore at dpsl.co.uk Fri Oct 9 16:12:35 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:05:39 2004 Subject: XObjects Message-ID: > bill wrote > > But aside from SaxInput and SaxException, do we really want to mandate the > use of SAX events? If we can find a way around that particular mandate, > then we allow a tighter coupling between the parser and DOM construction, > and allow for a more complete extraction of information from the document. I think you are suggesting a tighter binding - thus more open - with parser events as opposed to SAX events? I think this would be good, along the lines of more granularity, more control more refined implementations. >This is where wrappers and delegation have something to offer. As long as > the wrapper or a mixin of the aggregate are responsible for the events, > only that code which handles the events need be vendor-specific: > Simple application code that implements Element can be in > the DOM tree directly, but would not have access to parse events. > Application code held by a wrapper or participating in an > aggregate would support an api or a design pattern (which > is to say, JavaBeans), which benefits indirectly from parse events. I think where this leads us is to a situation where an application is effectively a LISP evaluator and the XML has become an S-Expression. But to keep things simple the parse events should for the moment be used to build the DOM and its mixed-in functionality. The app thens invokes methods on the functional DOM. I like the idea that XML is LISP though. > I believe it is appropriate to support the alternatives here via the > Bindings > specification, on a per-element basis. > Further, the application should be able to select different domBuilder's > from different vendors and use them all together. Yes and Yes. I know this list is primarily for views but we need some confirmation of what we think is good or else it appears that there is no agreement and no common ground. graham. gdm@dpsl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Oct 9 16:54:15 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:40 2004 Subject: XObjects Message-ID: <001801bdf394$abdc68e0$ab026982@thing1.camb.opengroup.org> From: Graham Moore >> Simple application code that implements Element can be in >> the DOM tree directly, but would not have access to parse events. > >> Application code held by a wrapper or participating in an >> aggregate would support an api or a design pattern (which >> is to say, JavaBeans), which benefits indirectly from parse events. > >I think where this leads us is to a situation where an application is >effectively a LISP evaluator and the XML has become an S-Expression. > >But to keep things simple the parse events should for the moment be used to >build the DOM and its mixed-in functionality. The app thens invokes methods >on the functional DOM. > >I like the idea that XML is LISP though. Typically, parse events should be used to build the DOM tree. Again, a variety of approaches and perversions should be accomodated. Some application objects would be aware of the DOM tree and not have any methods that are called as a result of a parse event. At the other extreme are application objects which are unaware of the DOM tree, but which have methods called as a result of various parse events: A JavaBean may have various properties set at START ELEMENT. It may raise an exception as a result. The exception can then become a SAXParseEvent which identifies the element in the XML document where the exception occured. At END DOCUMENT, a refid may be resolved as an application object which supports listener registration. The referenced object is then called to register the event listener object which had the refid. Coins currently supports both of the above. Perhaps we could generalize and say that the data held by SAX parse events is important for building the DOM, and that that data is not needed by the XObject, but still there may be methods that need to be called. The two events that I see as important here are end-element and end-document. And the important data is Location, which is needed to generate useful SAXParseEvents. This suggests another interface which may optionally be implemented by an XObject: public interface XObjectParseEvents { public void endElement(org.w3c.dom.Element element, org.xml.sax.Locator locator) throws org.xml.sax.SAXException; public void endDocument(org.w3c.dom.Element element, org.xml.sax.Locator locator) throws org.xml.sax.SAXException; } In the above, element might be the object being called, or it might be the wrapper which holds the object being called, or the mixin in the same aggregate. The value of this is that the DomBuilder need not be entirely SAX conformant, allowing a better integration between the parser and the DOM. 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 murray at muzmo.com Fri Oct 9 17:00:47 1998 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:05:40 2004 Subject: Do we need link-catalogs for schemas? In-Reply-To: <361E14DE.1500AA38@allette.com.au> References: <03ba01bdf2b4$1caa4d80$bcbc77c1@sgml.u-net.com> <3.0.1.16.19981008173109.3c9f496a@pop3.demon.co.uk> Message-ID: <3.0.1.32.19981009105957.006cde38@pop.uunet.ca> I think that it is definitely worth looking at Rick's proposal. I can imagine how SOX could use and benefit from this kind of binding mechanism for every element, attribute, datatype, entity, notation, and even PIs and namespaces themselves. I would hope that such a binding mechanism would allow one to associate XML objects with various flavors of semantics: behaviour (IDL, Java, etc.), meaning (prose, images, etc.), style sheets (CSS, XSL, etc.), equivalences (UML, XSchema, etc.), and other relationships. Regards, Murray At 09:51 AM 10/9/98 -0400, Rick Jelliffe wrote: > >Perhaps it is time to (attempt to) ressuscitate XML-Bind. This was a project of >mine which I put forward during the Namespaces debate. The thrust of this was that >the then namespace draft conflated two things: > * some way to *bind* GIs into public identififiers (URL+GI or whatever) {this >is what the current namespace has limited itself to} > * some way to *link* this identifier to all sorts of interesting information. >I tried to push the idea that having just a simple "src" attribute in the namespace >PI tied restricted it arbitrarily, and had the bad effect of hardwiring a single >vendor's schema. > >So instead I pushed a catalog idea, and in particular that the namespace proposal >actually reflected a need for a new kind of link: linking from element types rather >than from instances on elements. One wants to name them because one wants to link >to or from them. I would like to raise this link-catalog idea again. > >The link-catalog idea was that potentially every stakeholder (end-user, document >creator, browser-maker, DTD/schema creator) may want to use these type-links (for >documentation, schema distribution, etc). It would be best if this were explicitly >marked up using XLL extended links. A document should be able to have a web of >type-related resources linked to/from it. > >Now the great thing about using instance syntax for new schemas (e.g. XSchema) is >that >no new linking declaration system needs to be invented: we can define any kind of >link we need and markup the element in the Xschema instance. That way we get >type-links. > >So now we are at the stage: > >1) namespace proposal binds GI names to public identifiers >2) XSchmema proposal (and its ilk) can allow links from GIs to a catalog (e.g. >using a fixed attribute) *but* we need to actually do it; >4) XLL proposal allows extended links, with which we can implement a catalog >system, *but* we need to actually do it. > >So I would propose that XML-DEV should design an element set for catalog entries, >it should cascade or be able to link with other catalogues. It might be a valuable >enhancement to XSchema, and indicate to the W3C schema people the direction that >people would like to go. (In particular, that there are many possible schemas, and >even natrual language documents are valuable for defined document types.) > >The kind of thing I am thinking of is this: > > > > > Links for HTMLs P element type > > role="-//www.w3.org/NOTATION XML DTD//EN" /> > role="-//www.w3.org/NOTATION XSchema//EN" /> > role="-//www.ms.com/NOTATION DCD//EN" /> > role="-//www.w3.org//NOTATION RDF Schema//EN" /> > > role="-//XML-DEV//NOTATION Virtual Hyper Glossary//EN" /> > role="-//XML-DEV//TEXT English Documentation//EN"/> > > > role="-//XML-DEV//SGML Link Catalog/EN"/> > > > >In this example there is a single entry. The description field indicates the >catalog entry relates to HTML paragraphs. The first lot of links link to schema >definitions for HTML paragraphs, given in various notations (DTD, XSchema, DCD, RDF >Schema). Then comes documentation for it in various ways (VHG, English, German). >Finally comes a link to another link-catalog, which allows cascading or a web of >links. > >In each entry, I have used an XLL href (a URL) and used an SGML FPI (Formal Public >Identifier) for the role atribute. Anyone who wants to define a new role would >make up a new FPI for that role. XML-DEV would create a good starting set of FPIs >for the catalog: > DTD > XSchema > English Documentation (.. and so on for every language) > link-catalog > >After that, there should be some kind of new attibute in Xschema, available on all >elements, called perhaps "link-catalog-href". This contains a URL pointing to an >XML-Dev link-catalog > >IMHO this kind of thing would be a major addition to the power of XML: the W3C >efforts to define a new single schema definition language are, to some extent, >misguided and out-of-sequence in that it would be better to first set up an >infrastructure by which schemas and documentation can be located. I am not >convinced that having multitudes of schema definition languages is a bad thing: >perhaps it is better to let companies compete and just provide an infrastructure >which allows them to provide good product without hijacking documents. > >Cheers. > >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) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Veillard at w3.org Fri Oct 9 17:49:34 1998 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:05:40 2004 Subject: XML Parsers In-Reply-To: <80256698.003F5C17.00@dip.co.uk>; from RJA@dip.co.uk on Fri, Oct 09, 1998 at 12:37:29PM +0100 References: <80256698.003F5C17.00@dip.co.uk> Message-ID: <19981009114854.E25448@w3.org> Quoting RJA@dip.co.uk (RJA@dip.co.uk): > Could somebody point me to the W3 recommendation/proposal for a DTD DOM, if > there is one. I've already got the core recommendation for DOM, but I > want to know what interfaces I should support for accessing a DTD. If you look at the DOM Group requirements: http://www.w3.org/TR/WD-DOM/requirements Section 1.7 relates to the DTD support and basically it's not supported in DOM Level one. But they expect to provide access to the DTD (if available) in the future, Daniel -- Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks : Tel : +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html, Fax : +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Oct 9 18:37:45 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:05:40 2004 Subject: XObjects References: > Message-ID: <361E37B4.8F3598D@infinet.com> Graham Moore wrote: > I think Tyler is right when he says that having access to the parser events > is useful. While the SaxInput should remain in the domBuilder interface > could one extension be something more raw. > > build(URL xml); for example. The domBuilder can create its own > parser set itself to be the event sink and build the DOM from the events. > > Tyler wrote > > > >The DOM is a general purpose tree for storing the parsed contents of an XML > >stream. I really don't like this subclassing idea very much though as the > DOM > >I believe is not suitable for this type of framework since you are no just > >dealing with Element nodes but you are dealing with all kinds of nodes. > > Yes but at the end of the day a node is a node is a node. And isn't > "is-a-kind-of" the time to use the inheritance pattern? > > I still prefer a delegation mechanism to a simple inheritance. More dynamic, > more powerful. > > With delegation you could have a Node object, a functional object and a > delegator object > > The functional and Node objects are added to the delegator object (mix them > in). The delegator is then the reference to the composite functionality. > There is no dependency between the functional and Node objects. > > > I prefer a framework which says nothing about how the object tree is > created or > > even if there is an object tree. The application should be responsible > for > > doing this... > > The application is responsible. Its the application that gives the > domBuilder the construction rules / element bindings / delegation structures > that it wants applied. And the app gets back a functional dom or set of > objects. > I think you are all missing the point here about what I was talking about. In simple terms this is how it all works and it all has nothing to do with the DOM. (1) There is a root element handler that is passed to the parser which handles all of the events generated by parsing the root element. If a new child element of the root element is encountered, the root element is responsible for instantiating an element handler for the given element name. If no element handler can be instantiated then null is returned. (2) All of the generic events of SAX you could consider are delegated down to the currently selected parent element which is receiving character, element, and pi events among others. This is done natively in my parser and has nothing to do with SAX per se, but this sort of framework can be easily built on top of SAX in a few hours I would think. I personally have had a lot of success using this method (I will admit my opinion is biased by my own personal adulation) and find it to be just about as straightforward as using Java Object Serialization as a framework for reading and writing object state. (3) No registry, bindings, or any other muckety muck is necessary. All you need is an instantiated implementation for a root element which knows how to instantiate children elements who know how to instantiate children elements and so on and so forth. It is equivalent to calling readObject() in Java Object Serialization where you need to know the root object type to case to, but you don't have to worry about the types of any of the child objects as the root object knows what types they need to be cast to. > > I think it would be a shame if this XOS API (or whatever it is named) > favored > > some registry based interface or mapping interface cause everyone has > already > > done these sort of things already for all kinds of applications and in the > end > > you usually find yourself in a configuration nightmare maintaining all of > > these > > mappings. > > Yes, but at some stage you need to know the functional object to build. > Where in your example above do you find the class 'Height' is it local to > the application package?, the domBuilder package?. There needs to be some > mechanism for specifying the binding. I think that using the element name as > a direct mapping into the current package will lead to problems further down > the line. This in Java is all Classloader specific. Basically, when you have an object of a particular type, the same classloader is used implicitly for instantiating all of the child objects in the object graph unless a new class loader is instantiated and used to define a particular class explicitly. For my puposes I use a PI at the beginning of the document which defines the class name of the root element. The way the core application works, I don't need to specify URL's to Jar files (this is handled at a higher level) but this sort of thing could go into a PI as well for executing this sort of dynamic action. Last but not least, an element name is merely a symbol that is used for each element to locate and possibly instantiate an appropriate handler for that element type. Using some namespaces mechanism (the first namespaces draft worked great but the current draft really makes this namespaces issue unnecessarily complicated) you can further differentiate element types based on the URI of the namespace. I will try and get a basic implementation of what I am talking about whipped up by next week. Right now I am swamped with other work and have no time to dedicate to projects like these )-: 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 b.laforge at jxml.com Fri Oct 9 19:13:23 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:40 2004 Subject: XObjects Message-ID: <003001bdf3a7$ed5fabc0$ab026982@thing1.camb.opengroup.org> From: Tyler Baker >(1) There is a root element handler that is passed to the parser which handles >all of the events generated by parsing the root element. If a new child element >of the root element is encountered, the root element is responsible for >instantiating an element handler for the given element name. If no element >handler can be instantiated then null is returned. > >(2) All of the generic events of SAX you could consider are delegated down to >the currently selected parent element which is receiving character, element, and >pi events among others. This is done natively in my parser and has nothing to >do with SAX per se, but this sort of framework can be easily built on top of SAX >in a few hours I would think. I personally have had a lot of success using this >method (I will admit my opinion is biased by my own personal adulation) and find >it to be just about as straightforward as using Java Object Serialization as a >framework for reading and writing object state. > >(3) No registry, bindings, or any other muckety muck is necessary. All you need >is an instantiated implementation for a root element which knows how to >instantiate children elements who know how to instantiate children elements and >so on and so forth. It is equivalent to calling readObject() in Java Object >Serialization where you need to know the root object type to case to, but you >don't have to worry about the types of any of the child objects as the root >object knows what types they need to be cast to. As a component programmer (distinct from an oo programmer), I attempt to avoid embeding in a component class any knowledge of other component classes. (A component may know about interfaces and objects, but not other components.) The last thing I want is to have components created by other components using the new operator. Coins supports this programming style--all you need is a binding for the smart root. My own programming style depends on either factories or (preferably) binderies. Shouldn't XObject be able to accomodate diverse styles as well? OK, it means moving closer to the SAX DocumentHandler interface than what I had proposed. We need a START-ELEMENT to accomodate this. But then we've constrained the implementation. Tough choice. Perhaps a DOM- specific set of arguments on that START-ELEMENT would be a good compromise: public void startElement( java.lang.String name, org.w3c.dom.NamedNodeMap, org.xml.sax.Location) throws SAXException; This again allow for greater integration with the DOM without either precluding or excluding the use of SAX. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Oct 9 19:18:13 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:40 2004 Subject: Do we need link-catalogs for schemas? Message-ID: <003301bdf3a8$e9e9a260$ab026982@thing1.camb.opengroup.org> Two concerns here: 1. There should be a way to cascade whole Bind documents, not just individual entries, as well as adopting a first-encountered entry rule. This would allow one Bind to override another, dropping inappropriate items under an entry. 2. Binding an entry to a class should be accomplished without recourse to a link. This would allow for light-weight bindings. From: Murray Maloney >I think that it is definitely worth looking at Rick's proposal. >I can imagine how SOX could use and benefit from this kind >of binding mechanism for every element, attribute, datatype, >entity, notation, and even PIs and namespaces themselves. > >I would hope that such a binding mechanism would allow one >to associate XML objects with various flavors of semantics: >behaviour (IDL, Java, etc.), meaning (prose, images, etc.), >style sheets (CSS, XSL, etc.), equivalences (UML, XSchema, etc.), >and other relationships. > >Regards, > >Murray > >At 09:51 AM 10/9/98 -0400, Rick Jelliffe wrote: >> >>Perhaps it is time to (attempt to) ressuscitate XML-Bind. This was a project of >>mine which I put forward during the Namespaces debate. The thrust of this was that >>the then namespace draft conflated two things: >> * some way to *bind* GIs into public identififiers (URL+GI or whatever) {this >>is what the current namespace has limited itself to} >> * some way to *link* this identifier to all sorts of interesting information. >>I tried to push the idea that having just a simple "src" attribute in the namespace >>PI tied restricted it arbitrarily, and had the bad effect of hardwiring a single >>vendor's schema. >> >>So instead I pushed a catalog idea, and in particular that the namespace proposal >>actually reflected a need for a new kind of link: linking from element types rather >>than from instances on elements. One wants to name them because one wants to link >>to or from them. I would like to raise this link-catalog idea again. >> >>The link-catalog idea was that potentially every stakeholder (end-user, document >>creator, browser-maker, DTD/schema creator) may want to use these type-links (for >>documentation, schema distribution, etc). It would be best if this were explicitly >>marked up using XLL extended links. A document should be able to have a web of >>type-related resources linked to/from it. >> >>Now the great thing about using instance syntax for new schemas (e.g. XSchema) is >>that >>no new linking declaration system needs to be invented: we can define any kind of >>link we need and markup the element in the Xschema instance. That way we get >>type-links. >> >>So now we are at the stage: >> >>1) namespace proposal binds GI names to public identifiers >>2) XSchmema proposal (and its ilk) can allow links from GIs to a catalog (e.g. >>using a fixed attribute) *but* we need to actually do it; >>4) XLL proposal allows extended links, with which we can implement a catalog >>system, *but* we need to actually do it. >> >>So I would propose that XML-DEV should design an element set for catalog entries, >>it should cascade or be able to link with other catalogues. It might be a valuable >>enhancement to XSchema, and indicate to the W3C schema people the direction that >>people would like to go. (In particular, that there are many possible schemas, and >>even natrual language documents are valuable for defined document types.) >> >>The kind of thing I am thinking of is this: >> >> >> >> >> Links for HTMLs P element type >> >> > role="-//www.w3.org/NOTATION XML DTD//EN" /> >> > role="-//www.w3.org/NOTATION XSchema//EN" /> >> > role="-//www.ms.com/NOTATION DCD//EN" /> >> > role="-//www.w3.org//NOTATION RDF Schema//EN" /> >> >> > role="-//XML-DEV//NOTATION Virtual Hyper Glossary//EN" /> >> > role="-//XML-DEV//TEXT English Documentation//EN"/> >> >> >> > role="-//XML-DEV//SGML Link Catalog/EN"/> >> >> >> >>In this example there is a single entry. The description field indicates the >>catalog entry relates to HTML paragraphs. The first lot of links link to schema >>definitions for HTML paragraphs, given in various notations (DTD, XSchema, DCD, RDF >>Schema). Then comes documentation for it in various ways (VHG, English, German). >>Finally comes a link to another link-catalog, which allows cascading or a web of >>links. >> >>In each entry, I have used an XLL href (a URL) and used an SGML FPI (Formal Public >>Identifier) for the role atribute. Anyone who wants to define a new role would >>make up a new FPI for that role. XML-DEV would create a good starting set of FPIs >>for the catalog: >> DTD >> XSchema >> English Documentation (.. and so on for every language) >> link-catalog >> >>After that, there should be some kind of new attibute in Xschema, available on all >>elements, called perhaps "link-catalog-href". This contains a URL pointing to an >>XML-Dev link-catalog >> >>IMHO this kind of thing would be a major addition to the power of XML: the W3C >>efforts to define a new single schema definition language are, to some extent, >>misguided and out-of-sequence in that it would be better to first set up an >>infrastructure by which schemas and documentation can be located. I am not >>convinced that having multitudes of schema definition languages is a bad thing: >>perhaps it is better to let companies compete and just provide an infrastructure >>which allows them to provide good product without hijacking documents. >> >>Cheers. >> >>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 murray at muzmo.com Fri Oct 9 19:42:07 1998 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:05:40 2004 Subject: Do we need link-catalogs for schemas? In-Reply-To: <003301bdf3a8$e9e9a260$ab026982@thing1.camb.opengroup.org> Message-ID: <3.0.1.32.19981009134132.0099a260@pop.uunet.ca> At 01:19 PM 10/9/98 -0400, Bill la Forge wrote: >Two concerns here: > > 1. There should be a way to cascade whole Bind documents, > not just individual entries, as well as adopting a > first-encountered > entry rule. This would allow one Bind to override another, > dropping inappropriate items under an entry. So, just as a stylesheet could be designed for a particular DTD, so too could a Bindings document. Or a Bindings document might apply to a "library" of element/attribute definitions. I think that you are also underscoring a need for delegation. I'm not yet sure whether I agree with the first-encountered rule. We need to examine the cost of not allowing bindings to be cumulative. > > 2. Binding an entry to a class should be accomplished without > recourse to a link. This would allow for light-weight bindings. That would be one way to look at it. Another way to keep it fairly light-weight is to allow that a set of Bindings might be contained in the same document. Thus, we would maintain a link mechanism is all cases, but allow for the equivalent of a fragment identifier (#) to say that te Binding is located in the self-same document. 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 roddey at us.ibm.com Fri Oct 9 20:02:37 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:40 2004 Subject: Datatype constraints in DCDs Message-ID: <5030300026123326000002L062*@MHS> > > > > > > It looks like the consensus is definitely that the more wordy XML encoding of the constraint information is preferable. And I'm not too stressed out about that, since I won't be the one reading them anyway :-) But I would question the above scheme for enumerations. There was some desire to replace the proposed DCD enumeration mechanism, but I think the above scheme would get way wordy just to (for instance) check that something was one of the months of the year, one of the possible XML encodings, one of the countries of the world, etc... I'd definitely like to have some way to get the possible values all into some slightly less versbose chunk. Even if human convenience is not an issue, bandwidth still remains a concern, right? I'd almost, in the name of reuse, argue for an EnumDecl that defined such enums for reuse by name, though someone might easily poke holes in that argument because I've not thought it out. ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 9 20:37:54 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:05:40 2004 Subject: XObjects References: <003001bdf3a7$ed5fabc0$ab026982@thing1.camb.opengroup.org> Message-ID: <361E53D4.E36DB522@infinet.com> Bill la Forge wrote: > From: Tyler Baker > >(1) There is a root element handler that is passed to the parser which > handles > >all of the events generated by parsing the root element. If a new child > element > >of the root element is encountered, the root element is responsible for > >instantiating an element handler for the given element name. If no element > >handler can be instantiated then null is returned. > > > >(2) All of the generic events of SAX you could consider are delegated down > to > >the currently selected parent element which is receiving character, > element, and > >pi events among others. This is done natively in my parser and has nothing > to > >do with SAX per se, but this sort of framework can be easily built on top > of SAX > >in a few hours I would think. I personally have had a lot of success using > this > >method (I will admit my opinion is biased by my own personal adulation) and > find > >it to be just about as straightforward as using Java Object Serialization > as a > >framework for reading and writing object state. > > > >(3) No registry, bindings, or any other muckety muck is necessary. All you > need > >is an instantiated implementation for a root element which knows how to > >instantiate children elements who know how to instantiate children elements > and > >so on and so forth. It is equivalent to calling readObject() in Java > Object > >Serialization where you need to know the root object type to case to, but > you > >don't have to worry about the types of any of the child objects as the root > >object knows what types they need to be cast to. > > As a component programmer (distinct from an oo programmer), I attempt to > avoid > embeding in a component class any knowledge of other component classes. > (A component may know about interfaces and objects, but not other > components.) > The last thing I want is to have components created by other components > using > the new operator. Well if you are building any data structure, the children must be some type which the parent nodes unde, even a very abstract type. In the element handling code, whether you choose to reference the element handlers returned as interfaces or objects is at the application programmer's discretion. Unless you are going to have a completely abstract tree of very primitive data, I feel you need to do this. The approach of subclassing org.w3c.dom.Element is similiar to the approach I am talking about except the approach I have says nothing about how the application chooses to build the abstract data structure that may fully or partially represent the XML data. In addition, unknown element types can be conditionally ignored (as well as their corresponding children) at will. > Coins supports this programming style--all you need is a binding for the > smart root. > My own programming style depends on either factories or (preferably) > binderies. This approach I feel is great for systems like GUI's which have a pretty strict contract on their layout (i.e. in some manner component a is located it point x,y in component b's container space) which can easily be constructed with a binding type system. > Shouldn't XObject be able to accomodate diverse styles as well? > OK, it means moving closer to the SAX DocumentHandler interface than what I > had proposed. We need a START-ELEMENT to accomodate this. It really does help, especially for applications which may want to create temporary list objects to store an unknown number of child elements. Sometimes you don't want everything represented internally as a list, but you need the list for convenience in storing these objects during the parsing process. When endElement() is called, the list is discarded and the contents are dealt with as such. > But then we've constrained the implementation. Tough choice. Perhaps a DOM- > specific set of arguments on that START-ELEMENT would be a good compromise: > > public void startElement( > java.lang.String name, > org.w3c.dom.NamedNodeMap, > org.xml.sax.Location) > throws SAXException; This would work fine if you are first building the DOM and then reparsing it before presenting the events to the application. I am just saying why not eliminate the overhead of building the DOM tree in the first place and send it straight to the app. > This again allow for greater integration with the DOM without either > precluding or excluding the use of SAX. Is this a goal? Why should we be working with the DOM for DOM's sake. I just don't see the reason why the DOM is necessary here and I consider it to be an intermediary form of bloar. 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 b.laforge at jxml.com Fri Oct 9 20:45:26 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:40 2004 Subject: Do we need link-catalogs for schemas? Message-ID: <005801bdf3b5$1933d7a0$ab026982@thing1.camb.opengroup.org> From: Murray Maloney >At 01:19 PM 10/9/98 -0400, Bill la Forge wrote: >>Two concerns here: >> >> 1. There should be a way to cascade whole Bind documents, >> not just individual entries, as well as adopting a >> first-encountered >> entry rule. This would allow one Bind to override another, >> dropping inappropriate items under an entry. > >So, just as a stylesheet could be designed for a particular DTD, >so too could a Bindings document. Or a Bindings document might >apply to a "library" of element/attribute definitions. A generic Bind document may be bound to a particular DTD. But an application specific one with Java class bindings would probably not be--as a DTD may be usable by more that one program, each with its own element/class bindings. >I think that you are also underscoring a need for delegation. I don't follow. >I'm not yet sure whether I agree with the first-encountered rule. >We need to examine the cost of not allowing bindings to be cumulative. Bindings can be cumulative by making use of the cascading link internal to the entry. (This is definately getting ahead of the discussion-- I shouldn't have raised such a detail.) > > >> >> 2. Binding an entry to a class should be accomplished without >> recourse to a link. This would allow for light-weight bindings. > >That would be one way to look at it. Another way to keep it >fairly light-weight is to allow that a set of Bindings might >be contained in the same document. Thus, we would maintain >a link mechanism is all cases, but allow for the equivalent >of a fragment identifier (#) to say that te Binding is located >in the self-same document. That does get you more than half way there. But if the binding for an entry is nothing more than a few data items, it seems more appropriate simply to include them right there in the entry. I think the key here is that we are dealing here with information specific to a application. So bindings would likely be defined mostly at the top level and rarely at the level where the Bind document is dealing with generic information applicable to all uses of a particular markup language. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Fri Oct 9 20:59:30 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:40 2004 Subject: XObjects Message-ID: <006301bdf3b7$03ea66a0$ab026982@thing1.camb.opengroup.org> From: Tyler Baker >> This again allow for greater integration with the DOM without either >> precluding or excluding the use of SAX. > >Is this a goal? Why should we be working with the DOM for DOM's sake. I just >don't see the reason why the DOM is necessary here and I consider it to be an >intermediary form of bloar. We may be driving towards fundamentally different things. I am not sure if there is a significant overlap. I see XObject as being founded in the DOM for navigation, with a set of bindings which transforms a document into a composition of components which themselves are an active aspect of the application: document + bindings + classes = application-specific agent This approach precludes many things. It is not generic to XML processing. 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 murray at muzmo.com Fri Oct 9 22:39:02 1998 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:05:41 2004 Subject: Datatype constraints in DCDs In-Reply-To: <5030300026123326000002L062*@MHS> Message-ID: <3.0.1.32.19981009163836.006e8de8@pop.uunet.ca> At 02:09 PM 10/9/98 -0400, Dean Roddey wrote: > >> >> >> >> >> >> > >It looks like the consensus is definitely that the more wordy XML encoding of >the constraint information is preferable. And I'm not too stressed out about >that, since I won't be the one reading them anyway :-) But I would question the >above scheme for enumerations. There was some desire to replace the proposed >DCD enumeration mechanism, but I think the above scheme would get way wordy >just to (for instance) check that something was one of the months of the year, >one of the possible XML encodings, one of the countries of the world, etc... >I'd definitely like to have some way to get the possible values all into some >slightly less versbose chunk. Even if human convenience is not an issue, >bandwidth still remains a concern, right? > >I'd almost, in the name of reuse, argue for an EnumDecl that defined such enums >for reuse by name, though someone might easily poke holes in that argument >because I've not thought it out. In SOX, we have one form of datatype declaration that specifies an enumeration of values. So, for example: Now you can write: and the "colour" attribute is constrained to be one of the three values enumerated in the "color" datatype. And you can use the "color" datatype on any attribute or any element whose content model is string. Truth is, in this case one would probably want something more like this: The interface can be attached to any element as a collection of attribute definitions. The value of each attribute must be a number (scalar) in the range 0-65535 (0000-FFFF). So, you would write an instance thus: 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 cfranks at microsoft.com Fri Oct 9 23:25:46 1998 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:05:41 2004 Subject: Do we need link-catalogs for schemas? (was Re: More namespace s perversion) Message-ID: Rick - Is there one "link-catalog" per document, or can I nest and scope them? I.e. how do you deal with the fragment composition issue? -----Original Message----- From: Rick Jelliffe [mailto:ricko@allette.com.au] Sent: Friday, October 09, 1998 6:51 AM To: Peter Murray-Rust Cc: xml-dev@ic.ac.uk Subject: Do we need link-catalogs for schemas? (was Re: More namespaces perversion) ... The kind of thing I am thinking of is this: Links for HTMLs P element type xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simeons at allaire.com Sat Oct 10 06:03:30 1998 From: simeons at allaire.com (Simeon Simeonov) Date: Mon Jun 7 17:05:41 2004 Subject: ISO8601 Java utilities Message-ID: <05eb01bdf402$1d209b30$7315b5cd@sim.allaire.com> Hi, Do you know of any ISO8601 date format parsing utilities written in Java? I've used Sam Blackburn's WFC classes for ISO8601 parsing in C++ but why port if I could reuse? Thanks, Sim Allaire xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 11 00:47:34 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:05:41 2004 Subject: XML-tagged religion.200 available Message-ID: <199810102243.PAA18301@boethius.eng.sun.com> A major revision to the XML-tagged religion set is now available at http://sunsite.unc.edu/pub/sun-info/standards/xml/eg/rel200.zip There are lots of changes from the old release (1.10). The biggest change is that I've removed the verse numbers; these are now to be generated by style sheets. I've included sample DSSSL style sheets as proof of concept. Directions are included for generating RTF versions of the XML files using Jade. Not part of the release, but provided for reference purposes at the same temporary location, are the RTF files you will get if you run Jade using the style sheets included in the package: http://sunsite.unc.edu/pub/sun-info/standards/xml/eg/r200rtf.zip Since many people use these texts as benchmarks for XML parsers, I have tried hard to make the files absolutely compliant with the XML 1.0 specification. However, mistakes happen, and I would appreciate hearing from anyone who notices an error in markup. Corrections to the texts themselves are always welcome and will be included in the next revision. Jon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 11 18:00:26 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:41 2004 Subject: Do we need link-catalogs for schemas? (was Re: More namespaces perversion) Message-ID: <3620D7BE.4D1CDED7@allette.com.au> Charles Frankston ¼g¹D¡G > Is there one "link-catalog" per document, or can I nest and scope them? > I.e. how do you deal with the fragment composition issue? At its simplest, the link-catalog is just aweb of XLL extended pointers, with roles given using some nice FPI/URN mechanism. I dont see that it should matter if all the links were put in the same entry in the same resource: Links for HTMLs P element type or inn different entries in the same resource Links for HTMLs P element type Links for HTMLs P element type or even in different resources Links for HTMLs P element type Links for HTMLs P element type I leave out other examples where one link in an entry merely points to another link in another entry, or points to another link-catalog in another resource. The link-catalog does nto need to be part of a document: it can be part of an application--an XML editor from Microsoft would presumably infer a link-catalog linking to Microsoft schema data (using Microsoft schema notations) in augmentation to whatever link-catalogs were present in the particular document instance (or #FIXED linked from its DTD). For nesting and scoping, a link-catalog link for the doctype element (i.e. the root) is enough to locate a whole schema. Minimally, all that is needed is an entry for every unique namespace. But individual entries can be used to annotate and extend schemas for particular purposes, in particular by adding sub-schemas and documentation. This is how people would expect such a link-catalog to work. Delegation is fine to provide, if users expect it. The use of such a mechanism allows registration of various subclassing mechanisms too so that local poicy can be implemented: Links for HTMLs P element type In that case, the link invokes a validation program. My kindly browser manufacturer might even define callbacks into which I can put data entry programs: Links for HTMLs P element type I As far as nesting and scoping, I would tend not to want to provide any mechanism. The idea is to create a web of type-links which augment each other rather than replace. But I cannot see why any vendors could not implement their own policy: to ignore (but not delete) links using other vendor's schema or to automatically add or infer links to schemas at their own site. Or to prefer "close" entries in preference to "far" entries. I want to allow Microsoft to come up with their own schema system and to compete on that, but not exclude another vendor from also having their own system. For new readers, the "composing of fragments issue" is this: if we cut out a WF fragment of one document and paste it into another, how can we cart along all the other information (catalogs, schema data, type links, etc). The important thing is that the link catalog entries are organized to GIs (other things may be possible, but I want to get GIs right first): these entries can be cut up into fragments just as simply as a document can be. In a link-catalog system, the schemas themselves (or CSS, or whatever) are not cut up with the document. The same code which corrects the namespace declarations during such cut and pasting also has enough information to correct link-catalogs. (Whether the link-catalog can stay the same (in which case a fragment carts around some of its orinigating context, which may be an OK thing), or just have the GI changed to the GI of the fragment, is not clear to me. ) In a sense, there are already many kinds of data which are crying out for this kind of link: MIME catalogs, CSS/XSL, Web schemas, all of these are based on linking from type information. (Actually, I suppose that with the namespace proposal, even OASIS SOCATs fall into class of inforamtion, to a certain extent. In the case of MIME catalogs, the grain is kept at the highest level, in the case of CSS/XSL, the grain is quite detailed structured information. We see on XML-DEV at the moment several discussions on how to create objects by linking methods to GIs. The web would be richer, and many kinds of systems simpler, if there were a nice simple mechanism for doing this, such as this kind of link-catalog. As I have mentioned, I am not sure that there is a great need for a Web-Schema system, such as is being proposed. I think it would be much better fro W3C to agree on simple datatyping, and then agree on some link-catalog system with some predetermined FPIS so that basic standard schemas can be invoked (and also CSS, XSL, DTDs, RDF, SOCATs, MIME catalogs, etc). That leaves vendors free to develop schemas which are optimized for their constituency in whatever ad hoc consortia are commercially appropriate. In ISO I noticed a very strong feeling that when a standard moved to far from "infrastrucutre" to "application" it all got too political and unsatisfactory, and even perhaps anti-competitive and futile. One might think that a schema definition language is "infrastructure", but I rather fancy that it might be closer to "application", in that it undoubtedly will reflect the capabilities of the commercial products of its developers. Rick Jelliffe -------------- next part -------------- An embedded message was scrubbed... From: Rick Jelliffe Subject: Re: Do we need link-catalogs for schemas? (was Re: More namespace s perversion) Date: Sun, 11 Oct 1998 13:14:09 +0800 Size: 7676 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981011/80db4700/attachment.eml From b.laforge at jxml.com Sun Oct 11 20:27:33 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:41 2004 Subject: Do we need link-catalogs for schemas? (was Re: More namespaces perversion) Message-ID: <001d01bdf544$f5026cc0$ab026982@thing1.camb.opengroup.org> Real simple question: What is a GI? Bill -----Original Message----- From: Rick Jelliffe To: xml-dev@ic.ac.uk Date: Sunday, October 11, 1998 12:01 PM Subject: Do we need link-catalogs for schemas? (was Re: More namespaces p= erversion) > Charles Frankston =BCg=B9D=A1G > >> Is there one "link-catalog" per document, or can I nest and scope >them? >> I.e. how do you deal with the fragment composition issue? > >At its simplest, the link-catalog is just aweb of XLL extended pointers, >with >roles given using some nice FPI/URN mechanism. I dont see that it >should matter >if all the links were put in the same entry in the same resource: > > > Links for HTMLs P element type > > role=3D"-//www.w3.org//NOTATION XML DTD//EN" /> > role=3D"-//www.w3.org//NOTATION XSchema//EN" /> > >or inn different entries in the same resource > > > Links for HTMLs P element type > > role=3D"-//www.w3.org//NOTATION XML DTD//EN" /> > > > Links for HTMLs P element type > role=3D"-//www.w3.org//NOTATION XSchema//EN" /> > > >or even in different resources > > > Links for HTMLs P element type > > role=3D"-//www.w3.org//NOTATION XML DTD//EN" /> > > > > > > Links for HTMLs P element type > role=3D"-//www.w3.org//NOTATION XSchema//EN" /> > > >I leave out other examples where one link in an entry merely points to >another >link in another entry, or points to another link-catalog in another >resource. >The link-catalog does nto need to be part of a document: it can be part >of an >application--an XML editor from Microsoft would presumably infer a >link-catalog >linking to Microsoft schema data (using Microsoft schema notations) in >augmentation to whatever link-catalogs were present in the particular >document >instance (or #FIXED linked from its DTD). > >For nesting and scoping, a link-catalog link for the doctype element >(i.e. the >root) is enough to locate a whole schema. Minimally, all that is needed >is an >entry for every unique namespace. But individual entries can be used to >annotate >and extend schemas for particular purposes, in particular by adding >sub-schemas >and documentation. This is how people would expect such a link-catalog >to work. > >Delegation is fine to provide, if users expect it. > >The use of such a mechanism allows registration of various subclassing >mechanisms >too so that local poicy can be implemented: > > > Links for HTMLs P element type > role=3D"-//Rick Jelliffe//NONSGML Java program to check a DO= M >that > paragraph IDs start with small letter p//EN" /> > > >In that case, the link invokes a validation program. My kindly browser >manufacturer might even define callbacks into which I can put data entry > >programs: > > > Links for HTMLs P element type > role=3D"-//IDN ms.com//NONSGML IE6 Data Entry Program//EN" /= > > >I >As far as nesting and scoping, I would tend not to want to provide any >mechanism. >The idea is to create a web of type-links which augment each other >rather than >replace. But I cannot see why any vendors could not implement their own >policy: >to ignore (but not delete) links using other vendor's schema or to >automatically >add or infer links to schemas at their own site. Or to prefer "close" >entries in >preference to "far" entries. I want to allow Microsoft to come up with >their own >schema system and to compete on that, but not exclude another vendor >from also >having their own system. > >For new readers, the "composing of fragments issue" is this: if we cut >out a WF >fragment of one document and paste it into another, how can we cart >along all the >other information (catalogs, schema data, type links, etc). The >important thing >is that the link catalog entries are organized to GIs (other things may >be >possible, but I want to get GIs right first): these entries can be cut >up into >fragments just as simply as a document can be. > >In a link-catalog system, the schemas themselves (or CSS, or whatever) >are not >cut up with the document. The same code which corrects the namespace >declarations during such cut and pasting also has enough information to >correct >link-catalogs. (Whether the link-catalog can stay the same (in which >case a >fragment carts around some of its orinigating context, which may be an >OK thing), >or just have the GI changed to the GI of the fragment, is not clear to >me. ) > >In a sense, there are already many kinds of data which are crying out >for this >kind of link: >MIME catalogs, CSS/XSL, Web schemas, all of these are based on linking >from type >information. (Actually, I suppose that with the namespace proposal, >even OASIS >SOCATs fall into class of inforamtion, to a certain extent. In the case >of MIME >catalogs, the grain is kept at the highest level, in the case of >CSS/XSL, the >grain is quite detailed structured information. We see on XML-DEV at the >moment >several discussions on how to create objects by linking methods to GIs. > >The web would be richer, and many kinds of systems simpler, if there >were a nice >simple mechanism for doing this, such as this kind of link-catalog. As >I have >mentioned, I am not sure that there is a great need for a Web-Schema >system, such >as is being proposed. I think it would be much better fro W3C to agree >on simple >datatyping, and then agree on some link-catalog system with some >predetermined >FPIS so that basic standard schemas can be invoked (and also CSS, XSL, >DTDs, RDF, >SOCATs, MIME catalogs, etc). That leaves vendors free to develop >schemas which >are optimized for their constituency in whatever ad hoc consortia are >commercially appropriate. > >In ISO I noticed a very strong feeling that when a standard moved to far >from >"infrastrucutre" to "application" it all got too political and >unsatisfactory, >and even perhaps anti-competitive and futile. One might think that a >schema >definition language is "infrastructure", but I rather fancy that it >might be >closer to "application", in that it undoubtedly will reflect the >capabilities of >the commercial products of its developers. > > > 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 peter at ursus.demon.co.uk Sun Oct 11 22:04:15 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:41 2004 Subject: Do we need link-catalogs for schemas? In-Reply-To: <001d01bdf544$f5026cc0$ab026982@thing1.camb.opengroup.org> Message-ID: <3.0.1.16.19981011210356.25f7b6aa@pop3.demon.co.uk> At 14:28 11/10/98 -0400, Bill la Forge wrote: >Real simple question: What is a GI? Until SGML-experts give a precise answer... It stands for Generic Identifier and for practical purposes is (I think) synonymous with Element Type Name in XML, i.e. has a GI of "FOO". Question in return, what exactly is delegation and can you give an example. [It's been mentioned both in the context of Java classes and link-catalogs]. P. [... a HUGE amount of quoted material snipped ...] 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 b.laforge at jxml.com Mon Oct 12 00:18:50 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:41 2004 Subject: Do we need link-catalogs for schemas? Message-ID: <000c01bdf564$95699020$ab026982@thing1.camb.opengroup.org> From: Peter Murray-Rust >It stands for Generic Identifier and for practical purposes is (I think) >synonymous with Element Type Name in XML, i.e. has a GI of "FOO". That's what I first thought. But then I began to wonder... >Question in return, what exactly is delegation and can you give an example. >[It's been mentioned both in the context of Java classes and link-catalogs]. I think it has to do with aggregation. A client of the aggregate requests a delegate of the aggregate which supports a particular interface. At least, this is what I've been assuming... This is the heart of COM and was to be a part of JavaBeans. It is also the key to advanced Coin applications, as the CoinsDocument class is part of an aggregate. It is important in Java, to get arround single-inheritence. I believe the problem with the JavaSoft aggregation was that the client specified a Class object, requiring that the tree of classes ('cause you must include interfaces) had to be searched for each object in the aggregate collection of objects. Coins uses a filter object to select the appropriate delegate. This means that (1) you can simply use the instanceof operator in the filter match method instead of having to do the class tree search and (2) you can select based on any criteria, allowing for selection based on role. (I need to make this package accessable again on the Coins web page. Its freeware.) Now since there is no standard api (for Java), its kinda hard to give a simple example, code wise. But lets say that we have a Juggler with two listener registration interfaces, one for start and one for stop. If the Juggler were a single class, you would simply cast the Juggler object to the appropriate interface. Unfortunately, that means that the two interfaces can not have any common methods. If the registration interfaces for start and stop were seperate objects, but were different interface types, then you could ask the Juggler aggregate object for, say, an instance of the startListenerRegistration object. If role were supported, then the objects supporting the ActionListenerRegistration interface could be requested as the "start" object or the "stop" object. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Mon Oct 12 02:53:59 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:41 2004 Subject: Aggregation api used by Coins Message-ID: <000501bdf57a$f5575b00$ab026982@thing1.camb.opengroup.org> The aggrigation code used by Coins is available without commercial restriction: http://www.jxml.com/coins/download.html (Slect the services981011.zip file) In Coins, Aggregation builds on a cactus stack of services. CoinsDocument is an interface which extends org.w3c.dom.Document and com.jxml.services.ServiceItem, which allows it to participate in an Aggregate. Bill >From: Peter Murray-Rust >>Question in return, what exactly is delegation and can you give an example. >>[It's been mentioned both in the context of Java classes and link-catalogs]. > > >I think it has to do with aggregation. A client of the aggregate requests a >delegate of the aggregate which supports a particular interface. At least, this >is what I've been assuming... > >This is the heart of COM and was to be a part of JavaBeans. It is also the >key to advanced Coin applications, as the CoinsDocument class is part of >an aggregate. > >It is important in Java, to get arround single-inheritence. I believe the problem >with the JavaSoft aggregation was that the client specified a Class object, >requiring that the tree of classes ('cause you must include interfaces) had >to be searched for each object in the aggregate collection of objects. > >Coins uses a filter object to select the appropriate delegate. This means that >(1) you can simply use the instanceof operator in the filter match method instead >of having to do the class tree search and (2) you can select based on any >criteria, allowing for selection based on role. > >(I need to make this package accessable again on the Coins web page. Its freeware.) > >Now since there is no standard api (for Java), its kinda hard to give a >simple example, code wise. But lets say that we have a Juggler with two listener >registration interfaces, one for start and one for stop. If the Juggler were a single class, >you would simply cast the Juggler object to the appropriate interface. Unfortunately, that >means that the two interfaces can not have any common methods. > >If the registration interfaces for start and stop were seperate objects, but were different >interface types, then you could ask the Juggler aggregate object for, say, an instance of >the startListenerRegistration object. > >If role were supported, then the objects supporting the ActionListenerRegistration >interface could be requested as the "start" object or the "stop" object. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From olivo at iss.nus.edu.sg Mon Oct 12 04:41:40 1998 From: olivo at iss.nus.edu.sg (Olivo Miotto) Date: Mon Jun 7 17:05:41 2004 Subject: Datatype constraints in DCDs Message-ID: <4825669B.000F4040.00@iss.nus.edu.sg> Dean Roddey writes: >It looks like the consensus is definitely that the more wordy XML encoding of >the constraint information is preferable. And I'm not too stressed out about >that, since I won't be the one reading them anyway :-) But I would question the >above scheme for enumerations. There was some desire to replace the proposed >DCD enumeration mechanism, but I think the above scheme would get way wordy >just to (for instance) check that something was one of the months of the year, >one of the possible XML encodings, one of the countries of the world, etc... >I'd definitely like to have some way to get the possible values all into some >slightly less versbose chunk. Even if human convenience is not an issue, >bandwidth still remains a concern, right? Yes, of course. And that's the reason why I hypothesized that, with "Equals" being the default, we would have: which is 25% cheaper. Also, nothing stops us from allowing which requires additional parsing, but with very limited complexity. In fact, the main issue with your proposed scheme was the need to parse a separate syntax, but something like space-separated name lists are of course easy to process. The main problem I see with space-separated lists is that they do not allow for whitespace within strings. This is ok (though not great) for attributes, but not for elements. >I'd almost, in the name of reuse, argue for an EnumDecl that defined such enums >for reuse by name, though someone might easily poke holes in that argument >because I've not thought it out. Actually that sounds like a very good idea, except I would do it for datatypes, not just enum values, eg: and also Hmm... just to throw ideas around- could one even have composite datatypes? Such as And then, your ElementDef may look something like and a valid XML tag would be This is something like the AttributeGroup Concept, but somewhat more abstract in its definition. Regards Olivo xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From olivo at iss.nus.edu.sg Mon Oct 12 04:48:16 1998 From: olivo at iss.nus.edu.sg (Olivo Miotto) Date: Mon Jun 7 17:05:41 2004 Subject: ISO8601 Java utilities Message-ID: <4825669B.000FC67B.00@iss.nus.edu.sg> Hi Sim, a couple of months back I was trying to find the same, and unfortunately had no luck Let us know if you get anything. Thanks Olivo xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Oct 12 06:28:42 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:41 2004 Subject: More namespaces perversion References: <03ba01bdf2b4$1caa4d80$bcbc77c1@sgml.u-net.com> <3.0.1.16.19981008173109.3c9f496a@pop3.demon.co.uk> Message-ID: <362174B9.55861F49@technologist.com> Peter Murray-Rust wrote: > > The current namespace spec *deliberately* provides no semantic resolution. > I argued against this because it seemed a recipe for chaos. So far I > haven't been proved right or wrong - we are still in the inaction phase. I disagree. XSL exists and is defined as a namespace. The mechanism seems to work fine. Not only is there no need to point to a schema for XSL, there is no schema to point to: the only "schema" is the XSL specification itself. Any actual schema for XSL would have to depend heavily on the equivalent of XML's "ANY" keyword. It is good that the WG did not force a schema on people who do not want one. What would have been the benefit in requiring XSL to declare conformance to a schema that would be so loose as to be useless *anyway*? No one schema language can define all languages, which is why it is best not to tie namespaces to any schema language. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Bart: Dad, do I really have to brush my teeth? Homer: No, but at least wash your mouth out with soda. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From graham.moore at dpsl.co.uk Mon Oct 12 09:26:03 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:05:41 2004 Subject: XObjects Message-ID: > 1) Using a PI means that the XML is no longer nuetral. I think this is bad. I want to be able to send an XML transaction to two different places where the places know the binding they want to associate. I dont want the XML telling them. 2) Having a root object that knows how to build its children and its children know how to build there children etc seems redundant as the data structures are self describing. I think the reason this is all so exciting is that we have the ability to move away from this constrained object instantiation model to a more dynamic one. We can build generic data objects and add in functionality. A generic data object can be used because the data is self describing. The generic data object removes the need for every class to know how to build its children. We already see the generic way a DOM - with no functionality is built. It only requires a small extension to build a functional DOM in a generic fashion. Bill wrote > document + bindings + classes = application-specific agent I agree with : document + bindings + classes = I'm not sure we should limit it to agents though. Agents are one application. > This approach precludes many things. It is not generic to > XML processing. I dont see this as XML processing. I see XML as being a standard way of representing serialised objects. The fact that they are open and self describing allow dynamic binding of functionality. Once the objects are built they are just objects and are used with the rest of the application. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From kent at trl.ibm.co.jp Mon Oct 12 09:54:37 1998 From: kent at trl.ibm.co.jp (TAMURA Kent) Date: Mon Jun 7 17:05:41 2004 Subject: ANN: IBM XML for Java 1.1.4 Message-ID: <199810120753.QAA31316@ns.trl.ibm.com> IBM XML for Java 1.1.4, XML processor written in Java, was updated at 7th Oct. http://www.alphaworks.ibm.com/formula/xml o Support for DOM Level 1 Recommendation [01 Oct 1998] o Performance improvement: Runs twice as fast o Additional support for 18 different EBCDIC encodings o Many bug fixes since version 1.0.9 -- TAMURA, Kent @ Tokyo Research Laboratory, IBM Japan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Mon Oct 12 11:54:00 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:42 2004 Subject: XObjects Message-ID: <017001bdf5c0$e844c970$1c09e391@bra01wmhkay.bra01.icl.co.uk> Tyler Baker wrote: >I think you are all missing the point here about what I was talking about. In >simple terms this is how it all works and it all has nothing to do with the DOM. > >(1) There is a root element handler that is passed to the parser which handles >all of the events generated by parsing the root element > >(2) All of the generic events of SAX you could consider are delegated down to >the currently selected parent element which is receiving character, element, and >pi events among others > >(3) No registry, bindings, or any other muckety muck is necessary This is the way an early version of SAXON worked. I found with experience that it was simpler to define the association between an element-type and an element-handler class using a setElementHandler(tag, class) interface, rather than defining it in the element handler for the parent class. For example, it works far better when the processing for a tag is identical regardless whether it appears within an , a or a . (If different behaviour is required, SAXON also allows different element handlers to be used for depending on whether it appears within an , a or a .) A compromise suggested by XSL, and which has been requested by users as a SAXON enhancement, is for the parent element to say whether or not the children are to be processed, while retaining document-level rules that define how they should be processed. 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 M.H.Kay at eng.icl.co.uk Mon Oct 12 12:10:34 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:42 2004 Subject: XObjects (was TLAa was SOX) Message-ID: <020c01bdf5c7$ebee6c50$1c09e391@bra01wmhkay.bra01.icl.co.uk> I'm not sure who it was that wrote: >>i think the above is at the right level. Is this part of a domBuilder >>interface? >> >>if so should 'convert' be 'build' >> >> public interface domBuilder >> { >> public org.w3c.dom.Document >> build(org.xml.sax.InputSource inputSource) >> throws SAXException; >> I cannot resist reminding you of my posting to this list on 25 Sep 1998 in which I suggested: public interface DOMBuilder { /** * Define the parser to be used when building the DOM. * The DOM implementation is free to ignore this and use its * own parser if it wishes. */ public void setParser (Parser parser); /** * Build the DOM document from an input source. * @param source The InputSource to use. * @return The DOM Document object that results from * parsing the input. */ public Document build (InputSource source) throws java.io.IOException, org.xml.sax.SAXException; } Well, great minds think alike... FWIW, I have implemented this interface for the DOM products from Docuverse, SUN, and IBM in a new version of SAXON that is not yet released. One reservation I do have about this discussion is that a lot of people are proposing using an XML document as the primary way of defining the mapping from element types to element-handling classes. I think there are many situations where that's fine, but I've also seen SAXON applications where it wouldn't be, because the mappings change with time or are set up by higher-level software. Better to define the mapping table as a Java object with methods to add or remove or change individual mappings; it's then easy to add a layer on top of this to load the mappings from an XML document in the case where they are sufficiently static. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Mon Oct 12 16:31:43 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:42 2004 Subject: XObjects (was TLAa was SOX) Message-ID: <003201bdf5ec$504618a0$ab026982@thing1.camb.opengroup.org> From: Michael Kay >I cannot resist reminding you of my posting to this list on 25 Sep 1998 in >which I suggested: > >public interface DOMBuilder >{ > >/** >* Define the parser to be used when building the DOM. >* The DOM implementation is free to ignore this and use its >* own parser if it wishes. >*/ > >public void setParser (Parser parser); > >/** >* Build the DOM document from an input source. >* @param source The InputSource to use. >* @return The DOM Document object that results from >* parsing the input. >*/ > >public Document build (InputSource source) >throws java.io.IOException, org.xml.sax.SAXException; > >} > >Well, great minds think alike... FWIW, I have implemented this interface for >the DOM products from Docuverse, SUN, and IBM in a new version of SAXON that >is not yet released. The DomBuilder (or DOMBuilder) interface, I would argue, should not include a setParser method--I don't see a great deal of utility in being able to switch parsers mid-stream. Also, setParser creates a tie back to the full SAX, which precludes a closer integration with DOM. I've been playing with Coins/Docuverse, and here's what I've come up with so far: package com.jxml.xml; import org.w3c.dom.*; import org.xml.sax.*; /** * A DomBuilder object has a fixed mapping from XML elements to Java classes. */ public interface DomBuilder { /** * Parse an XML document and return a Document object. */ public Document build(Object inputSource) throws SAXException; /** * Returns a Document object with an empty root element. */ public Document createDocument(); } The assumption here is that an object with this interface is for a specific markup language and a specific set of bindings for that markup language. That being the case, perhaps a third method should be included: org.w3c.dom.DocumentType getDocumentType(); The idea of having createDocument create the root element is a carryover from Docuverse. It may be a good idea, but I'm not adament about it. >One reservation I do have about this discussion is that a lot of people are >proposing using an XML document as the primary way of defining the mapping >from element types to element-handling classes. I think there are many >situations where that's fine, but I've also seen SAXON applications where it >wouldn't be, because the mappings change with time or are set up by >higher-level software. Better to define the mapping table as a Java object >with methods to add or remove or change individual mappings; it's then easy >to add a layer on top of this to load the mappings from an XML document in >the case where they are sufficiently static. I like to think of degrees of specialization: 1. Some applications will be based on SAX and not use DOM. 2. Some applications will be based on DOM, use the DomBuilder interface, an not use too much else from SAX. Some of these applications may use a specialized variant on DocumentHandler which integrates better with the DOM. 3. Some applications will use various bindings, simply by having access to more than one object which implements the DomBuilder interface. 4. Some applications will employ Bindings (or BIND) documents. There are many applications which will not be able to use DOM. But I don't think that they should be our main focus at this time. There are going to be commercial interests which will focus on high-performance DOM building. It may be wise to define some standards that accommodate this in a timely fashion. SAX was a marvelous thing, still wholly valid for many applications, but does not integrate well with DOM. I see the whole Bindings thing as being important, especially to Coins, but not of absolute primary importance. I'd rank things as follows: 1. DomBuilder interface standard. Generically applicable. 2. An alternative to DocumentHandler which closely integrates with DOM. Already we see things like the com.sun.xml.tree.ElementNode.doneParse method. 3. Bindings support. Docuverse provides a Factory interface, Coins uses a document, and Sun has offered a dictionary of classes keyed by element name. 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 M.H.Kay at eng.icl.co.uk Mon Oct 12 16:54:07 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:42 2004 Subject: XObjects (was TLAa was SOX) Message-ID: <021f01bdf5ef$8a494b50$1c09e391@bra01wmhkay.bra01.icl.co.uk> >The DomBuilder (or DOMBuilder) interface, I would argue, should not include >a setParser method--I don't see a great deal of utility in being able to switch >parsers mid-stream. The reason I had it was that two out of the three DOM implementations I have used are built on top of SAX parsers and allow me to specify which SAX parser to use. I guess setParser() therefore belongs in a sub-interface for "DOM implementations built on top of SAX", but I was lazy. (It's got nothing to do with changing parsers midstream). >I like to think of degrees of specialization: > > 1. Some applications will be based on SAX > and not use DOM. > > 2. Some applications will be based on DOM, > use the DomBuilder interface, an not use > too much else from SAX. > Absolutely. One of the things I think I have achieved with SAXON is the ability to switch easily between event-based application logic and navigational application logic, allowing both techniques to be used in the same application, driven either from SAX or from the DOM as appropriate, with the same element-oriented classes for both cases. I think that is a real requirement, because I've seen many applications that started one way and then evolved as the processing requirements became clearer. Mike xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From db at Eng.Sun.COM Mon Oct 12 19:13:45 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:42 2004 Subject: Do we need link-catalogs for schemas? References: <3.0.1.16.19981011210356.25f7b6aa@pop3.demon.co.uk> Message-ID: <3622379E.7105BD47@eng.sun.com> Peter Murray-Rust wrote: > Question in return, what exactly is delegation and can > you give an example. [It's been mentioned both in the > context of Java classes and link-catalogs]. Delegation is when you make a request to "something" and instead of handling the request itself, it hands it off to "something" else and then returns what that returns. Sort of like a subroutine call; managers delegate tasks to employees, and so on. When used with object oriented systems (like those folk write in Java) delegation presumes a shared interface. If a class supports a set of methods, it can delegate the implementation of those methods to any other class that supports them. Sometimes "adapters" can be used to patch up minor "impedence mismatches" in terms of the signatures (or sometimes semantics) of the methods. When one talks about implementing naming systems (GIs touch on naming issues :-) there are three general mechanisms to be concerned with. Delegation is one of them, sometimes called "chaining". Redirection is another, sometimes called "forwarding" (we all understand HTTP redirects, yes?). A third is Partitioning -- e.g. entries in an Encyclopaedia are partitioned alphabetically, A-B, C-E, etc, and either a client or a server might try a partitioned search. Since naming is so fundamental to system structuring, such techniques show up all over the place. Hence the overlap in terminology: it really is the same technique. - 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 tyler at infinet.com Mon Oct 12 19:31:31 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:05:42 2004 Subject: XObjects References: <017001bdf5c0$e844c970$1c09e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <36223CE9.F8502F65@infinet.com> Michael Kay wrote: > Tyler Baker wrote: > >I think you are all missing the point here about what I was talking about. > In > >simple terms this is how it all works and it all has nothing to do with the > DOM. > > > >(1) There is a root element handler that is passed to the parser which > handles > >all of the events generated by parsing the root element > > > >(2) All of the generic events of SAX you could consider are delegated down > to > >the currently selected parent element which is receiving character, > element, and > >pi events among others > > > >(3) No registry, bindings, or any other muckety muck is necessary > > This is the way an early version of SAXON worked. I found with experience > that it was simpler to define the association between an element-type and an > element-handler class using a setElementHandler(tag, class) interface, > rather than defining it in the element handler for the parent class. For > example, it works far better when the processing for a tag is identical > regardless whether it appears within an , a or a . (If different > behaviour is required, SAXON also allows different element handlers to be > used for depending on whether it appears within an , a or a .) I feel you are somewhat correct for entire applications, but for components having them need to have some outside knowledge of a global registry causes obvious problems. I have already tried the registry approach and found huge pains with it. I guess it all depends on the type of application you have. For the app I have, it is very component-oriented, hence my bias here. > A compromise suggested by XSL, and which has been requested by users as a > SAXON enhancement, is for the parent element to say whether or not the > children are to be processed, while retaining document-level rules that > define how they should be processed. XSL is a totally different ballgame, though I see what you are trying to day here. Unfortunately, this sort of compromise looks as if it will complicate things even further for XML processing. My experience tells me not to spread around functional processing into lots of different areas, but try and keep it clean and concise in one block. This sort of compromise spreads the element handler lookup and the vetoing of particular element handlers into two different areas. 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 roddey at us.ibm.com Mon Oct 12 20:35:54 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:42 2004 Subject: What is delegation Message-ID: <5030300026190384000002L042*@MHS> >From: Peter Murray-Rust >Date: Sun, 11 Oct 1998 21:03:56 >Subject: Re: Do we need link-catalogs for schemas? > >Question in return, what exactly is delegation and can you give an example. >[It's been mentioned both in the context of Java classes and link-catalogs]. > I'm sure you'll get some definitions, but here are some examples that may help... One place where delegation is used is when you want to push extensibility 'downward' instead of 'upward'. Upward extensibility is provided by way of derivation. I provide a generic base class and you derive from it to create a different class. All code written to this interface deals through the base class (or interface) polymorphically. But, in some cases, you want to have a single class be the public persona for something and force the extensibility 'downwards'. In this case, the public class is a concrete class, but its only member is a reference to an 'implementation object' which may or may not be polymorphic. The public class' implementation is nothing but a set of methods which turn around and call a sibling method in the implementation class. Sometimes they do a little value added work, or do pre/post condition checking and so forth. So the public class just delegates all the work to some actual implementation class. The benefit of this is more conceptual than technical I guess. I use it in my CIDLib class libraries. There is a 'kernel abstraction' DLL which encapsulates all system and RTL access. The classes in there are very simple and are not for public viewing. The next level up creates public classes, each of which just uses its sibling class in the kernel, delegating all work to it, but translating all errors propogating out into more complex, publically useful errors. In this case, the implementation classes are not used polymorphically. Since one version of each kernel implementation class exists per operating system platform supported, they each implement the exact same class name are just used monomorphically (since they will never exist at the same time.) This speeds things up, particuarly since the public class' methods are often just inlines that delegate to the underlying kernel class. It also makes life simpler for the public who can deal with concrete classes, it allows a very clean separation between platform dependent and independent code, and does not tie the public API to the internal API via inheritance. The other scenario is the 'how to aggregate' type of thing. The classic scenario is a tricycle. If I build a tricycle from a seat class, a front wheel class, a frame class, and a handle bar class, how do I aggregate that? Some folks would say you have base interfaces for such things (or mixins in C++) and mix them into a single Trycycle class. This gets maximum reuse for minimum effort, and it directly models the system being built, which is aggregated in the same way. However, its not really that clean. A 'thing' once put into a coherent system, often does not exhibit the same 'degrees of freedom' that it had as a standlone unit. For instance, if you mixed in the interfaces for all of these objects, then all of the freedom of the standalone things will 'show through'. In other words, you could call the wheel's 'Turn()' method directly. But in a real aggregate system, everything has new constraints which are defined by the system, not by the bits. You cannot turn a tricycle's whell without also turning the handlebars (at least if its working right.) Aggregation via delegation deals with this issue while still allowing for reuse. The Tricycle class just 'Has-A' wheel, seat, frame, and handlebar object. It then exposes a new API which expresses the constraints of the system. This new API then just turns around and delegates the actions to the individual bits, but it enforces the constraints. It provides a 'Turn()' which insures that the handle bar and wheel objects are turned together, by just passing on the event to them both and insuring that they never turn separately (unless it supports a "Crash()" API perhaps :-) This is not to say that mixing in functionality via mixin classes or interfaces is not useful. Its just that its more useful when modelling 'optional behavior' type of stuff. Modelling real world aggregation is more often better served by aggregation and delegation, though it does require more work and some more code bloat to do it. Anyway, that's a quickie explanation of where it can be useful and why. There are others but I'm sure no one wants us writing small books on off topic stuff here. ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From estephen at appliedtheory.com Mon Oct 12 23:08:45 1998 From: estephen at appliedtheory.com (Eric A. Stephens) Date: Mon Jun 7 17:05:42 2004 Subject: xml/xsl to ps/pdf In-Reply-To: <5030300026190384000002L042*@MHS> Message-ID: Does anyone know if there are converters that will convert xml documents via xsl to paginated ps/pdf format documents? Said differently, is there a way to create paginated html from xml/xsl? Eric A. Stephens estephen@AppliedTheory.com Software Engineering Group http://www.AppliedTheory.com AppliedTheory Communications, 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 db at Eng.Sun.COM Tue Oct 13 01:03:47 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:42 2004 Subject: What is delegation References: <5030300026190384000002L042*@MHS> Message-ID: <362289CC.E9AF5C2F@eng.sun.com> Dean Roddey wrote: > > I'm sure you'll get some definitions, but here are > some examples that may help... See also my response of this morning, archived at http://www.lists.ic.ac.uk/hypermail/xml-dev/9810/0245.html Some technical motivations for delegating: - Coping with situations where the interface isn't "exactly" the same (e.g. adapters that implicitly add another argument, extra setup needed, etc); - Sometimes you need lots of objects to delegate to the same object, and yet have distinct identity. That object might be a flyweight, but to use it in some cases you might need to restore its weight. - Base classes differ; client A needs something to call object B but needs its callback to derive from some concrete class. It delegates to object C which is so derived, and which calls B. - As Dean noted, "composite" objects include others with "has-a". Distributed systems often work that way ... a user account object "has-a" home directory, a password, a set of files. But those are objects in their own right, so "is-a" (subtyping) is wrong. I've not found "aggregation" to be helpful except when talking about COM, but that may be because COM has rules about aggregating that don't apply to more classic object composition/delegation schemes. And of course, everyone has their own ways to slice'n'dice design problems. - 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 db at Eng.Sun.COM Tue Oct 13 01:18:09 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:42 2004 Subject: XObjects References: <017001bdf5c0$e844c970$1c09e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <36228D27.6FFE730@eng.sun.com> Michael Kay wrote: > > I found with experience > that it was simpler to define the association between an element-type and an > element-handler class using a setElementHandler(tag, class) interface, > rather than defining it in the element handler for the parent class. For > example, it works far better when the processing for a tag is identical > regardless whether it appears within an , a or a . This was our conclusion too. If nothing else it's the 80/20 tradeoff to say this is how it works ... other cases can be handled by letting the ... elements handle child tags as appropriate. Also, context-specific associations fly in the face of DOM support, since DOM factories provide no such context for element creation. One could forgo compatibility with that model; but why? - 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 scjin at webi.co.kr Tue Oct 13 01:54:51 1998 From: scjin at webi.co.kr (seung-chan JIN) Date: Mon Jun 7 17:05:42 2004 Subject: unsubscribe Message-ID: <362296CC.DC65C3F6@webi.co.kr> unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 13 04:43:00 1998 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:05:42 2004 Subject: ANN: XML COM Metadata persistence & marshalling Message-ID: <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Hello, I am pleased to announce the development of a set of components which provide XML Metadata Object Persistence (XMOP). These components provide for the automatic persistence of COM and Java objects in an XML DTD format known as the Simple Object Definition Language (SODL). The XMOPFactory object aggregates COM components and exposes the IMarshal and IPersistStream interfaces driven by typelibrary information. The aggregated COM component gains the ability to Marshal By Value (MBV) in an automatic fashion. This facility can be provided to Java objects through the use of introspection. More information is available at: http://jabr.ne.mediaone.net/documents/sodl.htm http://jabr.ne.mediaone.net/documents/xmop.htm http://jabr.ne.mediaone.net/xml.htm The SODL DTD is at http://jabr.ne.mediaone.net/documents/sodl10.dtd I will begin beta testing of these components shortly. Interested parties should e-mail me. Jonathan Borden JABR mailto:jborden@mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jonsm at aol.com Tue Oct 13 05:41:33 1998 From: Jonsm at aol.com (Jonsm@aol.com) Date: Mon Jun 7 17:05:42 2004 Subject: XObjects Message-ID: <6887671e.3622cb90@aol.com> I've spent some time working on an implementation similar to XObjects using James Clark's XP code as a starting point. XP implements just the transformation stage of the XSL proposal. The basic idea of XT is to take a XML parse event stream in, build a tree from it, apply the transformation rules, and generate an output event stream. I'm in the process of making three changes to the code. 1) Make plugable objects for accepting the output event stream (in other words, a document factory). XT has existing objects for IO stream output, pretty printed IO stream output, and string based output. The is also a special factory for building HTML output instead of XML output. Needed because HTML empty elements are different than XML ones. I've implemented a new one to support chaining - in order words allowing the output from one XSL sheet to be efficiently fed into another. 2) I'm now looking at building one that takes a bindings file and instantiates objects from the mapping described in the file. One demo idea was to use XSL to map the input XML to HTML objects and then bind to the Java DhHTML classes in WFC. The HTML would never be generated as text, the document factory would directly build the tree out of the Java DhHTML objects. Next I might add an object for vector graphics or drawing molecules. 3) Transformations in XSL work by building up patterns, matching these patterns to the input tree, and then executing some actions. The actions generate events to the output object. I've added the capability to XT to allow external Java classes to be used as actions. I don't know what the current W3C position on extensibility for XSL is since it was deferred in the current draft. My scheme is very simple: This is my current scheme for chaining and binding, it's not implement yet.... Chains together two stylesheets. The second stage uses the built-in document factory for the app reading the xml file. The bind parameter is passed to this document factor to specify node bindings. No stylesheet specified, implied identity transform XSL will just pass the input events straight to the output doc factory Binds multiple maps to the default document factory. Repeats of parms ok? Selects a different document factory instead of the default Binding files look like: If a tagname is not matched in the binding file it binds to the default node factory for the document factory. Obviously the external node objects must be closely tied into the Document Factory. For example if the Document Factory is IE the nodes need to be derived from DhElement. default document factory with no object mappings An XSL file would allow: select a new document factory or send it some new binding I'd also like to support schemas at each stage for validity checking... I'm treating XML processing as a pipe with a document factory at each stage. Jon Smirl jonsm@aol.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Oct 13 08:56:56 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:43 2004 Subject: xml/xsl to ps/pdf In-Reply-To: References: <5030300026190384000002L042*@MHS> Message-ID: <3.0.1.16.19981013005557.80d74954@pop3.demon.co.uk> Hi Eric, At 17:08 12/10/98 -0400, Eric A. Stephens wrote: >Does anyone know if there are converters that will convert xml documents >via xsl to paginated ps/pdf format documents? Said differently, is there a >way to create paginated html from xml/xsl? You may find it useful to post to the XSL list: xsl-list@mulberrytech.com which is the specialist place for XSL discussions.. 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 RJA at dip.co.uk Tue Oct 13 10:02:03 1998 From: RJA at dip.co.uk (RJA@dip.co.uk) Date: Mon Jun 7 17:05:43 2004 Subject: C++ or IDL definitions for SAX Message-ID: <8025669C.002B888E.00@dip.co.uk> Richard J. Anderson@DI 10/13/98 09:02 AM Hi, I'm currently looking into SAX and was wondering if anybody had any C++ or IDL definitions for SAX I could have ? On a slightly different note, are there are better alternatives to SAX for a simple event based API ? Regards, Richard. PS. Is 660k a second a reasonable speed for an XML parser running on a P200 with an average IDE drive ? *** This email is of a personal nature and dose not in any way reflect the opinions or developments of data interchange plc *** xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Oct 13 12:09:02 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:05:43 2004 Subject: xml/xsl to ps/pdf Message-ID: <020a01bdf691$4cd59b00$ce6118cb@tony-toshiba> -----Original Message----- From: Eric A. Stephens >Does anyone know if there are converters that will convert xml documents >via xsl to paginated ps/pdf format documents? Said differently, is there a >way to create paginated html from xml/xsl? I am developing an application called FOP that is presently a prototype set of Python scripts but will be available as Java classes shortly. It is early days yet, but I'm keen for people to try it out and let me know what they'd like implemented first. It takes an XML representation of a formatting object tree (ie what XT would generate with an XSL stylesheet using the FO vocabulary) and spits out a PDF. See http://www.jtauber.com/fop/ but, again, note that it is early days. I probably shouldn't be publicly announcing it yet (given it only just deserves the term 'alpha'), but I'll take the risk :-) 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 amitr at abinfosys.com Tue Oct 13 15:57:40 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:43 2004 Subject: Regarding XSchema : Section 4.3.1 Message-ID: <006401bdf6b2$6ac6ffc0$0101a8c0@server.abinfosys.com> Hello, I was going through the XSchema spec. and had a few doubts. If someone could throw light :- * The section 4.3.1 of the XSchema spec "Converting DTDs to XSchema Documents" states that Parameter entity declarations may be converted to parsed general entity declarations and use. If this were to happen then this means that the resulting XSchema would have a DTD (internal/external subset) which would house the converted parameter entity declarations as general entity declarations since XSchema does not give any construct for Parsed General Entity declarations. Am I right? * Section 4.3.1 also states that Parsed general entity declarations CANNOT be transformed to XSchema structures. If we may transform parameter entity declarations (from a source DTD) into corresponding general parsed entity declarations (in the target XSchema) , then why the restriction in case of general parsed entity declarations? Any help would be appreciated , Thanks in advance, 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 Vaiyapuri_Subramanian at rmic.com Tue Oct 13 17:07:09 1998 From: Vaiyapuri_Subramanian at rmic.com (Vaiyapuri Subramanian) Date: Mon Jun 7 17:05:43 2004 Subject: No subject Message-ID: Hi, Here is another site for posting XML questions. http://trial.internet.com:8000/cgi-bin/ubbs/Ultimate.cgi Thanks & Bye , Vaiyapuri Subramanian , ( O ) 800 / 933 - 7642 x 3278 . ( R ) 336 / 759 - 0777 x 614 . xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jonsm at aol.com Tue Oct 13 17:59:07 1998 From: Jonsm at aol.com (Jonsm@aol.com) Date: Mon Jun 7 17:05:43 2004 Subject: Another scheme for document factories... Message-ID: <29610627.3623786a@aol.com> This works off of the assumption that the host application's document factory has two modes, a light weight mode where it just builds nodes in memory, and a heavy weight mode where it has been turned the nodes into a display object or output to a file. This eliminates the need for a special chaining DF. James Clark has an interesting API for a document factory in XT (the result object). It supports a DF can write to a file without constructing a tree in memory. He achieves node output by recursing after writing the start tag. This allows only one copy of the document tree to be in memory when processing large documents. To allow chaining I've extended this scheme by breaking the document node into two pieces, the pointers describing the tree structure and the actual data in the node. My default DF supports rapid stylesheet chaining by implementing a fastcopy method. This method builds a new tree structure for the node and just references the original node contents. The following syntax allows specifying the DF at each stage of processing.... // give the default DF a new set of bindings // load the stylesheet into memory // run the last application, there is none so load the rest of the input document in light weight mode // change the application to xsl // reset the DF to default bindings // load the stylesheet into memory // run the last application, xsl, this will cause a new tree to be built in light weight mode // change the application to xsl // set a different DF and give it a set of bindings // run the last application, xsl // since there are no more PIs this will cause a new tree to be built in heavy weight mode // run the last application, there is none so load the rest of the input document in light weight mode // run the last application, xsl, , this will cause a new tree to be built in light weight mode // set a different DF and give it a set of bindings // run the last application, xsl // since there are no more PIs this will cause a new tree to be built in heavy weight mode // run the last application, there is none so load the rest of the input document in light weight mode // run the last application, xsl // since there are no more PIs this will cause a new tree to be built in heavy weight mode // set a different DF and give it a set of bindings // run the last application, the default application // since there are no more PIs this will cause a tree to be built in heavy weight mode // run the last application, the default application // since there are no more PIs this will cause a tree to be built in heavy weight mode Jon Smirl jonsm@aol.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Oct 13 18:03:59 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:05:43 2004 Subject: Regarding XSchema : Section 4.3.1 Message-ID: <199810131529.RAA06761@berlin.dvs1.tu-darmstadt.de> Amit Rekhi wrote: > * The section 4.3.1 of the XSchema spec "Converting DTDs to > XSchema Documents" states that Parameter entity declarations may be > converted to parsed general entity declarations and use. > > If this were to happen then this means that the resulting > XSchema would have a DTD (internal/external subset) which would house the > converted parameter entity declarations as general entity declarations since > XSchema does not give any construct for Parsed General Entity declarations. > Am I right? Correct. > * Section 4.3.1 also states that Parsed general entity declarations > CANNOT be transformed to XSchema structures. > > If we may transform parameter entity declarations (from a source > DTD) into corresponding general parsed entity declarations (in the target > XSchema) , then why the restriction in case of general parsed entity > declarations? The problem is that parsed general entities apply the file in whose DTD they are defined. If we transfer the parsed general entity definitions to the DTD of the XSchema file, they apply to the XSchema file. That is, they do not apply to the instance file defined by that XSchema file, which is what you want. If you want to keep such definitions around, you must place them in an external subset that is included in each instance file. While this is certainly possible, it has nothing to do with XSchema. -- 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 david at megginson.com Tue Oct 13 20:41:05 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:43 2004 Subject: C++ or IDL definitions for SAX In-Reply-To: <8025669C.002B888E.00@dip.co.uk> References: <8025669C.002B888E.00@dip.co.uk> Message-ID: <13859.40521.159621.53762@localhost.localdomain> RJA@dip.co.uk writes: > I'm currently looking into SAX and was wondering if anybody had any > C++ or IDL definitions for SAX I could have ? Various people have offered to work on them, but none has yet appeared. It should be simple to build a fairly-good SAX driver on top of EXPAT. > On a slightly different note, are there are better alternatives to > SAX for a simple event based API ? There may well be technically-superior event-based APIs for your particular work; the greatest advantage of SAX is simply that it's widely implemented, and thus benefits from the basic law of networking (the usefulness of a network is the square of its number of users). That said, the advantage does not yet extend to C++, since I know of no SAX implementations there. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Tue Oct 13 21:55:28 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:05:43 2004 Subject: C++ or IDL definitions for SAX References: <8025669C.002B888E.00@dip.co.uk> <13859.40521.159621.53762@localhost.localdomain> Message-ID: <3623B033.8E2ACB15@infinet.com> david@megginson.com wrote: > RJA@dip.co.uk writes: > > > I'm currently looking into SAX and was wondering if anybody had any > > C++ or IDL definitions for SAX I could have ? > > Various people have offered to work on them, but none has yet > appeared. It should be simple to build a fairly-good SAX driver on > top of EXPAT. I am not so sure a CORBA IDL definition of SAX would be so useful anyways unless you developed some efficient method of multiplexing the SAX events that get sent over the network. As far as C++ goes, I don't think a lot of people are doing too much work here because any popular C++ tools for Windows have pretty much no chance anymore of making an impact because of a very well known large company having the reputation of cloning anything and everything of any value written in C++ (looks like Java and a few other lesser known languages are the last bastion of hope for the software industry). Check out CNN on CNN/Fortune at 10:00 PM EST tonight to see what I am talking about. Writing software for the Windows platform I don't feel makes any sense any more for a long-term perspective as any useful software you actually create will be cloned in bad faith by a certain well-known company. Politics aside, as far as C++ on UNIX goes, I am not aware of any vendors doing anything CORBA related with respect to XML. I have not checked InPrise's pages or IONA's pages in a long time, but if there is any XML related CORBA application for UNIX, these folks are a start. > > On a slightly different note, are there are better alternatives to > > SAX for a simple event based API ? > Not really. Event based API's basicly have to just parse the content of the document and present it in raw form to the application in the form of Strings, and character data. There is no reason to make a process this simple any more complex than SAX in the first place. Pretty much all event-based parsers present content to the application in a native form that is very much like SAX anyways, so there is no real reason technically why SAX is inferior from a performance perspective. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Oct 14 01:13:29 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:43 2004 Subject: C++ or IDL definitions for SAX In-Reply-To: <3623B033.8E2ACB15@infinet.com> References: <8025669C.002B888E.00@dip.co.uk> <13859.40521.159621.53762@localhost.localdomain> <3623B033.8E2ACB15@infinet.com> Message-ID: <13859.47307.356304.422659@localhost.localdomain> Tyler Baker writes: > I am not so sure a CORBA IDL definition of SAX would be so useful > anyways unless you developed some efficient method of multiplexing > the SAX events that get sent over the network. It seems like a fairly simple thing to manage, because the dependencies are mostly one-way -- the driver could deliver events in chunks of 100 (or 1,000, or whatever), blocking only when it needs user input from an EntityResolver. > As far as C++ goes, I don't think a lot of people are doing too > much work here because any popular C++ tools for Windows have > pretty much no chance anymore of making an impact because of a very > well known large company having the reputation of cloning anything > and everything of any value written in C++ (looks like Java and a > few other lesser known languages are the last bastion of hope for > the software industry). That might be an extreme position. MS certainly has reduced techno-diversity in commercial software, but it hasn't been able to do much damage to free software (which is where most XML parsers live): for example, Apache and Perl still own their markets. 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 ricko at allette.com.au Wed Oct 14 05:50:09 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:43 2004 Subject: "delegate" and "GI" (was RE: Do we need link-catalogs for schemas?) In-Reply-To: <3622379E.7105BD47@eng.sun.com> Message-ID: <002401bdf725$ee8276a0$c5e887cb@NT.JELLIFFE.COM.AU> > Peter Murray-Rust wrote: > > > Question in return, what exactly is delegation and can > > you give an example. [It's been mentioned both in the > > context of Java classes and link-catalogs] James Tauber, who graces this list sometimes, devised an extension to the (OASIS) SOCAT catalogs called "delegation". This is one of the main things markup people often have in mind when they use the term "delegation", as far as concrete technologies, though of course, it is a ubiquitous idea. A delegation is a link (i.e. to another catalog) and a policy (i.e. "use these catalog entries by preferene"). SOCAT catalogs is a (non-XML) format which basically allows you to remap or override identifiers in a document. This helps resolve public identifiers and notation identifiers, or correct system identifiers. The online version is at http://www.sgmlopen.org/html/a401.htm. The SOCAT delegation system has a nice wrinkle--delegates are declared using a kind of simple pattern-matching, to exploit the regularities in FPIs: "The DELEGATE keyword indicates that external identifiers with a public identifier that has partial public identifier as a prefix should be resolved using a catalog is specified by the associated storage object identifier." There was another question "what is a GI". Generic Identifier was the term used in the SGML standard for the name of an element type; you can see that the concept of "generic markup" came first, and SGML was developed to support it. One reason it was also chosen was that, strictly, it was felt that the "name" of an element was its ID; people find even the basic distinction between an element and an element type difficult, so it there was a feeling that it might be better to keep the term GI, which avoided mention of elements let alone types. As things progressed it became clearer that the "GI" was really a special attribute, and that it mainly functioned as a content model and attribute selector, rather than identifying the genus which processing might be interested in per se (other attributes might have more useful information, hence the architecture movement). Furthermore that element type was much more than could be usefully expressed in just one DTD (hence the architecture movement again, where you can have multiple parallel DTDs or schemas, but which take other attributes as the "Element Type Name"). 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 amitr at abinfosys.com Wed Oct 14 06:37:26 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:43 2004 Subject: Regarding XSchema Section 5.2.9 Message-ID: <001901bdf72d$5fb55430$0101a8c0@server.abinfosys.com> Hello, After having gone through Section 5.2.9 "Custom Uses" of the XSchema ver 1.0 , draft 23 September 1998, I realised that data type information regarding PCDATA elements can be specified here amongst other things. I was looking for an example of how to specify this data type information. i.e. If I have a .xsc file :- . . * At which level should I specify the containing the datatype for PCDATA? At the level or at the level? * How to represent datatype information within the element? i.e. If I want that the Test-Element (see above) should have datatype = alpha only , how to represent this information within the element? Thanks in advance for any help, 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 M.H.Kay at eng.icl.co.uk Wed Oct 14 10:51:02 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:43 2004 Subject: C++ or IDL definitions for SAX Message-ID: <001401bdf74f$234d0890$7008e391@bra01wmhkay.bra01.icl.co.uk> >Tyler Baker writes: > > > I am not so sure a CORBA IDL definition of SAX would be so useful > > anyways unless you developed some efficient method of multiplexing > > the SAX events that get sent over the network. > >It seems like a fairly simple thing to manage, because the >dependencies are mostly one-way -- the driver could deliver events in >chunks of 100 (or 1,000, or whatever I decided after some experiments that the most efficient way to marshall and unmarshall a stream of SAX events (both in programmer effort and run-time performance) was to send the XML document and re-parse it at the other end. 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 nico at echange.fr Wed Oct 14 12:51:30 1998 From: nico at echange.fr (Nicolas Monnet) Date: Mon Jun 7 17:05:43 2004 Subject: a practical xml application, HTML form processing, how to do it? Message-ID: <362481E4.20BCEA50@echange.fr> Hi there, First let me introduce the issue I'm trying to address. XML seems to solved a lot of issues I've encoutered before. Among those, is the 'template' thing: id est, in a complex & dynamic web site, it's always a problem to make the presentation part and the computing part interoperate. Typically, there are two solutions: * ASP/JSP/PHP, where the code and the layout/output are mixed Leads to maintenance nightmares. As soon as the code is gettig complex enough, it' getting unreadable. * Template-based mechanisms Often not flexible enough. When you want to add flexibility, you end up designing your own little language to handle conditional stuff. E.g., in a db table output, you may want to have a label only if there is a non-NULL value. Here comes XML, and here's the idea I have. I want to be able specify an HTML formular or list of formular (think 'wizard', with 'Next >>' buttons) as an XML file. Now I haven't ever used XML, just read a lot of specs and APIs docs, and what I'm asking here is the following: could someone write a short example of a (part of a) XML document that could specify this, or give me hints? Then I'll implement it and release it. For example, I'm thinking about something along those lines: User information

Please provide user information

Your name: (mandatory)

 Your age: (optional) Enter comments here: (optional) ...etc... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SMUENCH at us.oracle.com Wed Oct 14 14:09:59 1998 From: SMUENCH at us.oracle.com (Steve Muench) Date: Mon Jun 7 17:05:43 2004 Subject: Info on IE 5.0 XML Support Message-ID: <199810141209.FAA20560@mailsun3> All, Found this link this morning. Seems to include statements that will put to rest a lot of the "you don't *really* support XML until you..." discussions that have been going back and forth here: http://www.microsoft.com/presspass/press/1998/Oct98/XMLcapPR.htm In particular, an excerpt: Direct viewing of XML: The Microsoft XML implementation lets users view XML using XSL or Cascading Style Sheets with their Web browser, just as they view HTML documents. Take care. ______________________________________________________________________ Steve | Consulting | Java Business Objects | smuench@oracle.com Muench | Product Mgr | & XML Tech Evangelism | geocities.com/~smuench xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Usha_R2 at verifone.com Wed Oct 14 14:17:23 1998 From: Usha_R2 at verifone.com (Usha_R2@verifone.com) Date: Mon Jun 7 17:05:43 2004 Subject: Nested XML files Message-ID: <7BA6E16CF180D111944700A0C9979DE51D4FAE@blr-nt-mail2.verifone.com> Hi! All, We can have a DTD as a collection of DTD files. Similarly, can a XML file contain other xml files. Consider the following example: --------file2.dtd--------- --------------------------- Now I use this in file1.dtd *********File1.dtd********** %file2; ***************************** Defining File1.xml as follows: ---------------File1.xml-------------- xyz 123 ------------------------------------------- Now in File1.xml, I can have both "X" and "Y" elements. Can I use one xml file in another. For example instead of defining element again in File1.xml, suppose if I have File2.xml as follows: *******file2.xml*********** 123 *************************** How do I use these in File1.xml again. Can I define an external entity for an .xml file also. I tried this and it seems to be giving some problems. Please let me know if its possible. Thanks in advance Usha K. Usha Rani Dept : Applications Phone : (080) - 2869920 Email : usha_r2@verifone.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 14 17:32:03 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:43 2004 Subject: Regarding XSchema : Section 4.3.1 References: <006401bdf6b2$6ac6ffc0$0101a8c0@server.abinfosys.com> Message-ID: <3624C3CE.667241CD@locke.ccil.org> Amit Rekhi wrote: > > * The section 4.3.1 of the XSchema spec "Converting DTDs to > XSchema Documents" states that Parameter entity declarations may be > converted to parsed general entity declarations and use. > > If this were to happen then this means that the resulting > XSchema would have a DTD (internal/external subset) which would house the > converted parameter entity declarations as general entity declarations since > XSchema does not give any construct for Parsed General Entity declarations. > Am I right? Yes. > If we may transform parameter entity declarations (from a source > DTD) into corresponding general parsed entity declarations (in the target > XSchema), Not in the XSchema as such, but in the *DTD* of the XSchema, presumably though not necessarily in its internal subset. > then why the restriction in case of general parsed entity > declarations? Because unless we are willing to abandon compatibility with XML 1.0 and SGML entirely (and we, the XSchema team, are *not* willing), there is no *point* in recording general parsed entities in the XSchema, since by the time the XSchema is processed, basic XML processing has to have already been done, including expanding entities. It is simply not WF XML to have entity references to entities that don't appear in the DTD of the document. DTDs serve three functions: entity declaration, attribute defaulting/rationalizing, and validation. XSchema handles the third and perhaps the second, but not the first. The only reason to allow *unparsed* entities to be declared in XSchemas is to validate ENTITY/ENTITIES attributes. -- 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 elharo at sunsite.unc.edu Wed Oct 14 17:46:53 1998 From: elharo at sunsite.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs In-Reply-To: <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: I've been working on my second book on XML which will include a lot more practical examples than the first. Right now I'm writing a chapter in which I describe a dozen or so different XML applications. Eventually, I'll devote a chapter each to several of these. But I may not be able to do as much as I want or as much as the authors of these specs might like. The reason is excessive restrictions on reuse and republication of DTDs and theirm associated markup languages. The only DTDs I have found whose license agreement is open enough to allow me to republish and discuss them in my book are the few explicitly adopted by the W3C. The rest have copyright statements that most often explicitly prohibit me from using them. Many of them are so restricted that it's not permissible to use the DTD in a document of my own creation, much less modify it to fit my needs. So far authors I have contacted personally have been very receptive to allowing me to use their DTDs, and in most cases it's been obvious that their intent was to allow broader use. Nonetheless before I can use any of these in a book, I'm going to have to get them to sign a two-page contract dreamed up by IDG's lawyers. I expect many of them to refuse, because it is a bad contract. I blame IDG's lawyers for that problem. No contract should be necessary, however. The whole point of XML is to allow broad, standardized documents. To this end any markup language that's created, whether described in a DTD, a DCD, an XSchema, or something else, must explicitly allow itself to be reused and reprinted without prior permission. Right now I'm worried about reprinting it in books, but the problem of including these DTDs on web sites is even more crucial. My preference is that these DTDs be placed in the public domain, because it's simplest and easiest to explain to lawyers. Open source works well too. Even a copyright statement that allows reuse but not modification is adequate for many needs, including most of mine. However, a DTD that simply includes a standard copyright statement immediately becomes unusable in many corporations. While I expect many people and companies will simply ignore these restrictions (which the authors never intended anyway) I don't think many people will be comfortable relying on this in our overly litigious world. Therefore I want to implore all authors of published DTDs to go back and look at your copyright statements. Ask yourself, "What does this really say? What do I want people to do with this DTD? Are they actually allowed to do that?" There's very little to be gained by writing a DTD you hope an industry will adopt, if you explicitly or implicitly prohibit the industry from adopting it. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@sunsite.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML: Extensible Markup Language (IDG Books 1998) | | http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Wed Oct 14 18:22:04 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:05:44 2004 Subject: "delegate" and "GI" (was RE: Do we need link-catalogs for schemas?) Message-ID: <016701bdf78e$7c25a320$c86118cb@tony-toshiba> -----Original Message----- From: Rick Jelliffe >James Tauber, who graces "by grace" - nt.xml#child(1,book,name,"Ephesians").child(2,chapter).child(8,verse) > this list sometimes, devised an extension to the (OASIS) SOCAT catalogs called >"delegation". I owe the term delegation in this context to James Clark who replaced my term "cascading" which I wasn't happy with because of possible confusion with CSS. 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 cowan at locke.ccil.org Wed Oct 14 18:57:57 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs References: Message-ID: <3624D7FF.97A9FB5@locke.ccil.org> Elliotte Rusty Harold wrote: > The only DTDs I have found whose license agreement is open enough to allow > me to republish and discuss them in my book are the few explicitly adopted > by the W3C. The rest have copyright statements that most often explicitly > prohibit me from using them. IBTWSH is in the public domain, though I retain the moral right (not a legal right) to be known as its author. See http://www.ccil.org/~cowan/XML/ibtwsh.dtd . Part of the reason for that was to avoid conflicts with HTML 4.0, of which it makes occasional fair use (mostly by accident). I now think, however, that a modified BSD-style license makes more sense, something like this: -- 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 peter at ursus.demon.co.uk Wed Oct 14 18:59:55 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs In-Reply-To: References: <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: <3.0.1.16.19981014180036.8a578f44@pop3.demon.co.uk> At 11:47 14/10/98 -0400, Elliotte Rusty Harold wrote: >I've been working on my second book on XML which will include a lot more >practical examples than the first. Right now I'm writing a chapter in which >I describe a dozen or so different XML applications. Eventually, I'll >devote a chapter each to several of these. But I may not be able to do as >much as I want or as much as the authors of these specs might like. The >reason is excessive restrictions on reuse and republication of DTDs and >theirm associated markup languages. I am very sympathetic to this and will appreciate guidance since I have authored 2 DTDs - in the hope that others will find them useful. I am a believer in the open source philosophy and have released JUMBO under that approach. However I am less clear what to do with documents - either *.dtd and *.xml - and have specifically included copyrights on my DTDs. > >The only DTDs I have found whose license agreement is open enough to allow >me to republish and discuss them in my book are the few explicitly adopted >by the W3C. The rest have copyright statements that most often explicitly >prohibit me from using them. Many of them are so restricted that it's not >permissible to use the DTD in a document of my own creation, much less >modify it to fit my needs. I agree that the W3C copyright is appropriate. Note that "W3C" is a trademark. > >So far authors I have contacted personally have been very receptive to >allowing me to use their DTDs, and in most cases it's been obvious that >their intent was to allow broader use. Nonetheless before I can use any of I agree and that is my intent. I am not clear how to go about it. >these in a book, I'm going to have to get them to sign a two-page contract >dreamed up by IDG's lawyers. I expect many of them to refuse, because it is >a bad contract. I blame IDG's lawyers for that problem. > >No contract should be necessary, however. The whole point of XML is to >allow broad, standardized documents. To this end any markup language that's >created, whether described in a DTD, a DCD, an XSchema, or something else, >must explicitly allow itself to be reused and reprinted without prior >permission. Right now I'm worried about reprinting it in books, but the >problem of including these DTDs on web sites is even more crucial. > >My preference is that these DTDs be placed in the public domain, because IMO public domain is not appropriate. Very few documents are actually in the public domain - most have some sort of protection. My understanding is that anyone can take a PD document, modify it *** and then copyright it***. This could mean that the original authors could be prevented from using their own work. >it's simplest and easiest to explain to lawyers. Open source works well >too. Even a copyright statement that allows reuse but not modification is >adequate for many needs, including most of mine. I think it has to be that. DTDs are so important because they represent contracts between the author and the reader/user. If that contract breaks because the DTD is modified by someone and mutant versions are distributed, then the author may get criticise for something that was not their action. It is also critical to protect authors' moral rights. I also - perhaps as an academic - make a distinction between academic use and for-profit use. I don't think we should discuss here the ethics of academic groups generating revenue from the use of their labours, but it matters to many people. I suspect that this will figure in many copyrights. > >However, a DTD that simply includes a standard copyright statement >immediately becomes unusable in many corporations. While I expect many >people and companies will simply ignore these restrictions (which the >authors never intended anyway) I don't think many people will be >comfortable relying on this in our overly litigious world. Yes - I think we need some leads here. > >Therefore I want to implore all authors of published DTDs to go back and >look at your copyright statements. Ask yourself, "What does this really >say? What do I want people to do with this DTD? Are they actually allowed >to do that?" There's very little to be gained by writing a DTD you hope an >industry will adopt, if you explicitly or implicitly prohibit the industry >from adopting it. > 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 cowan at locke.ccil.org Wed Oct 14 19:18:08 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs References: <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> <3.0.1.16.19981014180036.8a578f44@pop3.demon.co.uk> Message-ID: <3624DCA6.43EA7F86@locke.ccil.org> Peter Murray-Rust wrote: > IMO public domain is not appropriate. Very few documents are actually in > the public domain - most have some sort of protection. Many documents (in the U.S., any document published before 1923, YMMV) are in the public domain. > My understanding is > that anyone can take a PD document, modify it *** and then copyright it***. Not so, unless the referent of "it" is shifting. The resultant modified document can be copyright as to the modifications, but not the original. Once in the public domain, always in the public domain. > This could mean that the original authors could be prevented from using > their own work. Impossible. They could at best be prevented from using the modified form. This is important for software where the PD version may be unmaintained and so people have to go to the commercial version if they want the latest fixes, but less so for more static kinds of content. > I think it has to be that. DTDs are so important because they represent > contracts between the author and the reader/user. If that contract breaks > because the DTD is modified by someone and mutant versions are distributed, > then the author may get criticise for something that was not their action. I think that the copyright laws are not the proper way to maintain this principle. After all, doubting users can always download the authentic version from the author's website. If you are truly concerned, however, a rewritten version of the Artistic License (http://www.opensource.org/artistic-license.html) may help you. > It is also critical to protect authors' moral rights. Unfortunately, authors (as distinct from sculptors, painters, etc.) have no moral rights that international law recognizes as worthy of protection. I always insist on "the moral right to be known as the author of this document", but this has no legal force, unlike the analogous claim by a visual artist. -- 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 Oct 14 19:24:54 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs In-Reply-To: <3624D7FF.97A9FB5@locke.ccil.org> References: <3624D7FF.97A9FB5@locke.ccil.org> Message-ID: <13860.56846.332410.686038@localhost.localdomain> John Cowan writes: > IBTWSH is in the public domain, though I retain the moral right > (not a legal right) to be known as its author. See > http://www.ccil.org/~cowan/XML/ibtwsh.dtd . Part of the reason for > that was to avoid conflicts with HTML 4.0, of which it makes > occasional fair use (mostly by accident). Sometimes the public domain makes the most sense -- it's a leap of faith (or, at least, generosity), in that you're allowed for the chance that someone else might make a lot of money from your work without giving you any. Like IBTWSH, SAX is and will remain in the public domain (not GPL'd, BSD'd, or anything like that). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Oct 14 19:29:31 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs In-Reply-To: <3.0.1.16.19981014180036.8a578f44@pop3.demon.co.uk> References: <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> <3.0.1.16.19981014180036.8a578f44@pop3.demon.co.uk> Message-ID: <13860.57017.413494.993435@localhost.localdomain> Peter Murray-Rust writes: > IMO public domain is not appropriate. Very few documents are > actually in the public domain - most have some sort of > protection. My understanding is that anyone can take a PD document, > modify it *** and then copyright it***. This could mean that the > original authors could be prevented from using their own work. The company can copyright its changes, but the original work remains in the public domain. This kind of thing happened with TeX, but it never really did much damage. For example, the medieval poem BEOWULF and the novels of Charles Dickens are all in the public domain. Many authors and publishers have copyrighted specific editions of them, but the core texts themselves remain free. 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 jbolles at homeaccount.com Wed Oct 14 19:54:52 1998 From: jbolles at homeaccount.com (Jack Bolles) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs References: Message-ID: <3624E5A9.B5D9BB03@homeaccount.com> Both of these are still being finalized, but I believe are far enough along for XML proof of concepts. www.fixprotocol.org www.otp.org Jack ------------------------------------------------------ Jack Bolles Software Engineer - UI Designer Home Account Networks ------------------------------------------------------ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Wed Oct 14 19:59:12 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs Message-ID: <003e01bdf79b$ba92b410$7008e391@bra01wmhkay.bra01.icl.co.uk> >IBTWSH is in the public domain, though I retain the moral right >(not a legal right) to be known as its author. Confusing perhaps, but a "moral right", as defined in copyright law, *is* a legal right. I don't know if the term "public domain" is defined in copyright law. Mike Kay [caveat: I am not a lawyer and this message is not legal advice] xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 14 20:32:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs References: <3624D7FF.97A9FB5@locke.ccil.org> <13860.56846.332410.686038@localhost.localdomain> Message-ID: <3624EE31.493C1DD2@locke.ccil.org> david@megginson.com wrote: > Sometimes the public domain makes the most sense -- it's a leap of > faith (or, at least, generosity), in that you're allowed for the > chance that someone else might make a lot of money from your work > without giving you any. The BSD license has that property too, and in fact people *have* made lots of money from BSD (the operating system, not the license) and not paid the Regents any, still less the "contributors". > Like IBTWSH, SAX is and will remain in the > public domain (not GPL'd, BSD'd, or anything like that). Omitting the famous uppercase disclaimer, however, risks your being sued for big $$$$ when some application fails horribly that happens to contain a SAX-based parser. -- 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 Oct 14 20:35:46 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:44 2004 Subject: A call for open source DTDs References: <003e01bdf79b$ba92b410$7008e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <3624EEE7.DA45C92@locke.ccil.org> Michael Kay wrote: > >IBTWSH is in the public domain, though I retain the moral right > >(not a legal right) to be known as its author. > > Confusing perhaps, but a "moral right", as defined in copyright law, *is* a > legal right. True. But authors do not have any legal "moral rights". Their moral moral rights, however, remain intact even if not enforceable by legal process. > I don't know if the term "public domain" is defined in copyright law. Only implicitly. What is not protected by copyright is said to be in the public domain, though there is no definite process for dedicating something to the public domain. In general, nobody is likely to get into trouble for assuming that something saying "This document is in the public domain" is in the public domain, unless they know or reasonably should know (as in the case of a cracked computer game, e.g.) that it is not. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Oct 14 21:04:51 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:45 2004 Subject: MSIE5 Beta 2 + XML Message-ID: <3.0.32.19981014120344.00a18760@pop.intergate.bc.ca> MS yesterday announced that the next beta of IE5 would have more XML support. They gave me a preliminary run-through of what's there and what's not there, check it out at XML.com -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Oct 14 21:09:02 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:45 2004 Subject: A call for open source DTDs In-Reply-To: <3624EE31.493C1DD2@locke.ccil.org> References: <3624D7FF.97A9FB5@locke.ccil.org> <13860.56846.332410.686038@localhost.localdomain> <3624EE31.493C1DD2@locke.ccil.org> Message-ID: <13860.63166.172955.890794@localhost.localdomain> John Cowan writes: > Omitting the famous uppercase disclaimer, however, risks your being > sued for big $$$$ when some application fails horribly that > happens to contain a SAX-based parser. Every SAX source file does contain the following: // No warranty; no copyright -- use this as you will. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From db at Eng.Sun.COM Wed Oct 14 22:25:58 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:45 2004 Subject: A call for open source DTDs References: <003e01bdf79b$ba92b410$7008e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <362507B8.A84B83E4@eng.sun.com> Michael Kay wrote: > > >IBTWSH is in the public domain, though I retain the moral right > >(not a legal right) to be known as its author. > > Confusing perhaps, but a "moral right", as defined in copyright law, *is* a > legal right. While I believe that's true in much (all?) of Europe, this is an area where US and European laws say different things about Intellectual Property. In the US it's quite clear that morality and law are unrelated ... ;-) Speaking of which, I've always wondered exactly what those European "moral rights" of authors (etc) are. Could someone give me a URL for a good summary? - 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 lists at lumdata.com Wed Oct 14 22:50:45 1998 From: lists at lumdata.com (Scott Vanderbilt) Date: Mon Jun 7 17:05:45 2004 Subject: A call for open source DTDs In-Reply-To: <3.0.1.16.19981014180036.8a578f44@pop3.demon.co.uk> References: <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: Regarding copyright ownership of DTD: Copyright law protects expressions of ideas, not the underlying ideas themselves. In many instances, a well-written DTD can only be expressed in a particular manner, with allowances made for naming of elements, attributes, etc. Therefore, any protection under copyright law would be limited, because the scope of copyright protection is proportional to the range of expression available to articulate the underlying ideas communicated by the DTD. This is called the "merger doctrine" and is well known in copyright law, especially with regard to the area of computers. In much the same way as I cannot copyright the QuickSort algorithm, or the recipe for ice cubes, acquiring a defensible copyright in most DTDs would be well nigh impossible. If you took most any DTD where the circumstances necessarily limit the ways in which such a DTD could be constructed, changed the element names, and made a few other minor alterations, only an exceedingly foolish DTD "author" would press a claim for copyright infringement. In cases where the choices available to an author are limited, the ideas underlying the work are deemed to "merge" with their expression, thereby rendering the work unprotectible. For those who are interested in reading more on the matter, I suggest reading the court's opinion in Computer Assocs. Int'l v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992). It deals with software, but many of the principles enunicated in that case would bear directly on a case involving infringement of a DTD. Cheers. ========================================================================== Scott D. Vanderbilt mailto:scott@lumdata.com Luminous Dataworks Phone: (310) 253-9918 Custom database solutions Fax: (310) 842-7025 for the World Wide Web ========================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1988 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981014/67337e11/attachment.bin From cowan at locke.ccil.org Wed Oct 14 23:47:04 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:45 2004 Subject: A call for open source DTDs References: <003e01bdf79b$ba92b410$7008e391@bra01wmhkay.bra01.icl.co.uk> <362507B8.A84B83E4@eng.sun.com> Message-ID: <36251BA7.CC720CBA@locke.ccil.org> David Brownell wrote: > While I believe that's true in much (all?) of Europe, this > is an area where US and European laws say different things > about Intellectual Property. In the US it's quite clear > that morality and law are unrelated ... ;-) Nope. The U.S. has now joined the Berne convention, which means it has adopted the moral-rights-for-visual-artists clauses of it through the Visual Artists Protection Act of 1990. > Speaking of which, I've always wondered exactly what those > European "moral rights" of authors (etc) are. Could someone > give me a URL for a good summary? The two basic moral rights are the paternity right (the right to be known as the creator of a work, and to not be identified as the creator of a distorted or mutilated version of the work) and the integrity right (the right to prevent the work from being destroyed, unless it is affixed to a building, in which case it can be destroyed when the building is). Obviously the second right is more appropriate for "thing" rather than "pattern" works, e.g. paintings and sculptures, not books or movies or phonorecords or software. It turns out that the Berne convention on paper grants both types of rights to all creators, but allows any country to opt out of moral-rights clauses for authors: the U.S. has done so de facto by never enacting enabling legislation. In the U.K. such rights are very weak, de facto nonexistent. Considering the importance of these markets, international protection for the moral rights of authors is lacking. BTW, in this context the opposite of "moral right" is "economic right": both kinds are legal rights under the Berne convention. -- 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 emberson at faslab.com Thu Oct 15 00:02:22 1998 From: emberson at faslab.com (Richard Emberson) Date: Mon Jun 7 17:05:45 2004 Subject: REC-xml-19980210 unparsed entity Message-ID: <199810142200.PAA08697@edinburgh.faslab.com> In section 4.4, the spec states when a parsed general entity "occurs as Attribute value", it is forbidden which means that a fatal error has occurred. In section 3.3.1, part: "Validity Constraint: Entity Name", it is a validity constraint violation if the value is not a Name of an unparsed entity. It seems that there are two different actions for the same condition. Which take priority, the fatal error that is detected by all XML processors or the validity constraint violation that is only detected by validating processors? Richard Emberson emberson@faslab.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From emberson at faslab.com Thu Oct 15 00:09:31 1998 From: emberson at faslab.com (Richard Emberson) Date: Mon Jun 7 17:05:45 2004 Subject: REC-xml-19980210: whitespace Message-ID: <199810142207.PAA08702@edinburgh.faslab.com> Section 3.3.3: Attribute Value Normalization "a whitespace character (#x20, #xD, #xA, #x9) is processed by appending #x20 to the normalized value, except that only a single #x20 is appended for a "#xD#xA" sequence that is part of an external parsed entity or the literal entity value of an internal parsed entity" Section 4.4, Processor Treatment of Entities and References, seems to indicate that in a "Reference in Attribute Value" only an Internal General Enitity is included (Included in literal). An external parsed entity is Forbidden. How can whitespace from an external parsed entity be normalized in an attribute value as suggested by Section 3.3.3? Richard Emberson emberson@faslab.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From emberson at faslab.com Thu Oct 15 00:12:38 1998 From: emberson at faslab.com (Richard Emberson) Date: Mon Jun 7 17:05:45 2004 Subject: REC-xml-19980210: default attribute values Message-ID: <199810142208.PAA08706@edinburgh.faslab.com> Section 3.3.2: "If a default value is declared, when an XML processor encounters an omitted attribute, it is to behave as though the attribute were present with the declared default value." Section 2.9, Validity Constraint: Standalone Document Declaration: "...attributes with default values, if elements to which these attributes apply appear in the document without specifications of values for these attributes,..." If the XML processor always automatically produces such attributes with their default values when they are missing, how can the Validity Constraint ever be true? Does the checking of this Validity Constraint occur before the XML processor makes its correction? Richard Emberson emberson@faslab.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From emberson at faslab.com Thu Oct 15 00:12:47 1998 From: emberson at faslab.com (Richard Emberson) Date: Mon Jun 7 17:05:45 2004 Subject: REC-xml-19980210: normalized attribute values Message-ID: <199810142209.PAA08710@edinburgh.faslab.com> Section 3.3.3: "Before the value of an attribute is passed to the application or checked for validity, the XML processor must normalize it as follows: ..." Secton 2.9: Validity Constraint: Standalone Document Declaration "attributes with values subject to normalization, where the attribute appears in the document with a value which will change as a result of normalization,..." According to Section 3.3.3, the attribute's value is normalized before its checked for validity. How can the condition in Section 2.9 ever be true? Does the XML processor actually check for this Validity Constraint violation before normalization? Richard Emberson emberson@faslab.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From emberson at faslab.com Thu Oct 15 00:26:47 1998 From: emberson at faslab.com (Richard Emberson) Date: Mon Jun 7 17:05:45 2004 Subject: REC-xml-19980210 Concerning validation, in section 3 Message-ID: <199810142224.PAA08719@edinburgh.faslab.com> Concerning validation, in section 3 it states: An element is valid if there is a declaration matching elementdecl where the Name matches the element type and also: The declaration matches ANY, and the types of all child elements have been declared. Isn't the second condition redundant. If a child element has not been declared then the validity violation will be caught the first statement. Which is to say, if a child has not been declared, then when the child element's text is being parsed, its lack of declaration will be caught by a validating parser at that point and there is no need to check for this at the parent element level. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Thu Oct 15 01:27:46 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:45 2004 Subject: REC-xml-19980210: normalized attribute values References: <199810142209.PAA08710@edinburgh.faslab.com> Message-ID: <36252377.4D9136A7@technologist.com> Richard Emberson wrote: > > Does the XML processor actually check for this Validity Constraint > violation before normalization? Yes, I think so. The "checked for validity" that 3.3.3. discusses is "checked for conformance to its DTD." 3.3.3. could be more explicit. (the W3C doesn't really seem to have a mechanism for minor patches to its specs...does it?) Paul Prescod - http://itrc.uwaterloo.ca/~papresco It's such a Bore Being always Poor LANGSTON HUGHES http://www.northshore.net/homepages/hope/engHughes.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 papresco at technologist.com Thu Oct 15 01:41:24 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:45 2004 Subject: REC-xml-19980210 unparsed entity References: <199810142200.PAA08697@edinburgh.faslab.com> Message-ID: <3625285E.70BAEDAC@technologist.com> > Which take priority, the fatal error that is detected by all XML > processors or the validity constraint violation that is only > detected by validating processors? Why does one have to take precedence? You could report both errors. Paul Prescod - http://itrc.uwaterloo.ca/~papresco It's such a Bore Being always Poor LANGSTON HUGHES http://www.northshore.net/homepages/hope/engHughes.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 papresco at technologist.com Thu Oct 15 01:56:33 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:45 2004 Subject: REC-xml-19980210: whitespace References: <199810142207.PAA08702@edinburgh.faslab.com> Message-ID: <36252B2B.1703AE06@technologist.com> Richard Emberson wrote: > > > a single #x20 > is appended for a "#xD#xA" sequence that is part of an external > parsed entity or the literal entity value of an internal parsed > entity" > > Section 4.4, Processor Treatment of Entities and References, > seems to indicate that in a "Reference in Attribute Value" only > an Internal General Enitity is included (Included in literal). > An external parsed entity is Forbidden. How can whitespace from > an external parsed entity be normalized in an attribute value > as suggested by Section 3.3.3? This seems like a buglet to me. Paul Prescod - http://itrc.uwaterloo.ca/~papresco It's such a Bore Being always Poor LANGSTON HUGHES http://www.northshore.net/homepages/hope/engHughes.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 papresco at technologist.com Thu Oct 15 02:14:44 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:46 2004 Subject: REC-xml-19980210: normalized attribute values References: <199810142209.PAA08710@edinburgh.faslab.com> Message-ID: <36252D82.44971119@technologist.com> Richard Emberson wrote: > > Validity Constraint: Standalone Document Declaration You should be aware that the SDD isn't that useful, in general: http://www.lists.ic.ac.uk/hypermail/xml-dev/9805/0154.html http://www.lists.ic.ac.uk/hypermail/xml-dev/9805/0155.html Paul Prescod - http://itrc.uwaterloo.ca/~papresco 4'33" is rarely performed as an encore. - Steve Newcomb (info about 4'33") http://www.lenzo.com/~sburke/stuff/cage_433.html http://www.intrex.net/rwgarr/johncage.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 Bckman at ix.netcom.com Thu Oct 15 02:31:16 1998 From: Bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:05:46 2004 Subject: MSIE5 Beta 2 + XML Message-ID: <004901bdf7d3$c315fc40$17d7bacd@bckman> I've been hacking the beta for some time now, here's what you can expect. Good support for XSL, 99% support for the DOM recomendation! What this means essentially is that it is now possible to display XML over the web. Frank Frank Boumphrey Style and XML information http://www.hypermedic.com/style/index.htm Author: Professional Style Sheets for HTML and XML http:// www.wrox.com ----- Original Message ----- From: Tim Bray To: Sent: Wednesday, October 14, 1998 3:04 PM Subject: MSIE5 Beta 2 + XML >MS yesterday announced that the next beta of IE5 would have more XML >support. They gave me a preliminary run-through of what's there and >what's not there, check it out at XML.com -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 tbray at textuality.com Thu Oct 15 02:38:41 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:46 2004 Subject: MSIE5 Beta 2 + XML Message-ID: <3.0.32.19981014173738.00b40cf0@pop.intergate.bc.ca> At 08:34 PM 10/14/98 -0400, Frank Boumphrey wrote: >I've been hacking the beta for some time now, here's what you can expect. >Good support for XSL, So what. XSL is a ***>>>FUTURE<<<***!!! I want Microsoft and Netscape to first buckle down and implement 100% support for the 21-month old totally stable well-understood CSS 1 spec. The XSL stuff is cool but MS is running a *big* risk of people going ahead and implementing something that may be real different from where XSL ends up next summer. I cannot in good conscience recommend to anyone that they implement anything mission-critical based on XSL, and I'm one of the world's biggest supporters of the XSL work. >99% support for the DOM recomendation! Unreservedly good news. >What this means essentially is that it is now possible to display XML over >the web. Almost. So close you can taste it. But we need for NS to get their act together so you don't have to be browser-specific to achieve this. And we also need these guys to take some of the time they're investing in standards of the future and put them into finishing the job on standards of the present. -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 Bckman at ix.netcom.com Thu Oct 15 02:46:48 1998 From: Bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:05:46 2004 Subject: MSIE5 Beta 2 + XML Message-ID: <006201bdf7d5$fe7f6b20$17d7bacd@bckman> So what. XSL is a ***>>>FUTURE<<<***!!! My thoughts exactly :>). I am using a simple script and the DOM to transform XML to HTMLon the fly, and style it with a CSS style sheet. Details available privately if any one wants them, but I'm under a NDA until the official release. Frank Frank Boumphrey Style and XML information http://www.hypermedic.com/style/index.htm Author: Professional Style Sheets for HTML and XML http:// www.wrox.com ----- Original Message ----- From: Tim Bray To: Frank Boumphrey ; Sent: Wednesday, October 14, 1998 8:38 PM Subject: Re: MSIE5 Beta 2 + XML >At 08:34 PM 10/14/98 -0400, Frank Boumphrey wrote: >>I've been hacking the beta for some time now, here's what you can expect. >>Good support for XSL, > >So what. XSL is a ***>>>FUTURE<<<***!!! I want Microsoft and Netscape >to first buckle down and implement 100% support for the 21-month old >totally stable well-understood CSS 1 spec. The XSL stuff is cool >but MS is running a *big* risk of people going ahead and implementing >something that may be real different from where XSL ends up next >summer. I cannot in good conscience recommend to anyone that they >implement anything mission-critical based on XSL, and I'm one of >the world's biggest supporters of the XSL work. > >>99% support for the DOM recomendation! > >Unreservedly good news. > >>What this means essentially is that it is now possible to display XML over >>the web. > >Almost. So close you can taste it. But we need for NS to get their >act together so you don't have to be browser-specific to achieve this. >And we also need these guys to take some of the time they're investing in >standards of the future and put them into finishing the job on standards >of the present. -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 Thu Oct 15 02:53:19 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:46 2004 Subject: MSIE5 Beta 2 + XML Message-ID: <3.0.32.19981014175221.00a24e90@pop.intergate.bc.ca> At 08:51 PM 10/14/98 -0400, Frank Boumphrey wrote: >I am using a simple script and the DOM to transform XML to HTMLon the fly, >and style it with a CSS style sheet. You're doing this to achieve effects not available via CSS alone, I assume? In principle it would be better to do it with XML+CSS alone so that a programmer could have read/manipulate access to the XML stuff through the DOM without the transform getting in the way... One nice thing about your approach is that it works about the same on client & server. -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 amitr at abinfosys.com Thu Oct 15 05:58:03 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:46 2004 Subject: Regarding XSchema : Section 4.3.1 Message-ID: <01e201bdf7f1$0e8729c0$0101a8c0@server.abinfosys.com> John, Just wanted to confirm whether I got your point properly. >no *point* in recording general parsed entities in the XSchema, since >by the time the XSchema is processed, basic XML processing has to have >already been done, including expanding entities. * The basic XML processing here would refer to the processing of the XML file which conforms to the XSchema.Am I right? * By defining general parameter entities in XSchema , we would be non-conforming to XML 1.0 , since we would want to have general entity refrences in the XSchema instance and those general entity ref's in the instance would never get expanded as * they were'nt defined in the instance DTD (unless ofcourse you do define them) * the instance does not recognise the general entity declarations in the it's validating XSchema file, as that file is itself also an XML! Therefore, entity refrences in the instance remain as is and so the non - well formedness! Right? * The only reason why parameter entities(of the source DTD) may be allowed in the XSchema DTD (of the target XSchema) is since parameter entities have only DTD scope and converting them to general entity decls. in the XSchema DTD would let their scope remain only in the entire XSchema file, which is just what we want. Correct? 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 ricko at allette.com.au Thu Oct 15 05:59:38 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:46 2004 Subject: A call for open source DTDs In-Reply-To: Message-ID: <000701bdf7f0$66e46de0$4fe887cb@NT.JELLIFFE.COM.AU> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Elliotte Rusty Harold > I've been working on my second book on XML which will include a lot more > practical examples than the first. Right now I'm writing a > chapter in which > I describe a dozen or so different XML applications. Eventually, I'll > devote a chapter each to several of these. But I may not be able to do as > much as I want or as much as the authors of these specs might like. The > reason is excessive restrictions on reuse and republication of DTDs and > theirm associated markup languages. You might also like to do something similar to my book (The XML & SGML Cookbook, ISBN 0-13-614223-0 see fourth leaf): I put the notice "The author does not assert copyright over any SGML markup declaration in this book, unless noted." It is not enough to expect others to provide copyright-free declarations, authors have to do it themselves. The copyright problems were big enough that I kept away from directly including large chunks of non-ISO or non-W3C DTDs, but that served my purpose of finding the underlying patterns in DTDs. There are many tricky cases. For example, ISO claims it has copyright on country codes: so people can "use" the codes, but only ISO (or the delegated registartion body) can publish them (this is strange, since many of the codes came from UN in the first place, so it is dubious). (I got permission, but there is a widepsread feeling among the authors of standards that no such copyright exists on codenames. However, presumably this crazy new US Bill on the phone directory issue may alter that.) But, even if the codenames themselves may be used by impunity, it is possible that the particular file which contains codes may be copyright: this is why I got permission from whoever rekeyed or transcribed some the codes I used (e.g. the language codes). One issue that came up was that the ISO entity sets have a copyright notice which certainly allows the sets to be used in software, but does not explicitly mention the status for books. Charles Goldfarb (my series editor, an erstwhile lawyer, inventor of SGML) who I think drafted that notice, informed me that a book was certainly something "for use with SGML systems" and so there was no copyright problem. The same approach was taken in in AW book (by Mikes) on X-Windows, which gives a right to "publish" providing a copyright notice is given. One thing you should do to minimize any copyright if you are worried is to reformat the source code, and replace all comments with your own. Comments and layout both have "originality", which certainly may be copyrighted. If you do this, you should also alter the formal public identifier for the DTD, if it exists: move the owner field across into the right-hand description, and put your book's ISBN into the vacated owner field: -//old owner//DTD foo//EN becomes -//new owner//DTD old owner::foo//EN 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 amitr at abinfosys.com Thu Oct 15 07:41:59 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:46 2004 Subject: Doubt regading gen. entity ref. in element content Message-ID: <02ed01bdf7ff$8f466b80$0101a8c0@server.abinfosys.com> Hello, Would there be any change in the element content model if the element content contained an external parsed general entity refrence?. i.e. If I have an xml file :- . . ]> Test1 &ele2-replace; . . /*----file = ele2.xml-----*/ Test From raepple_s at ibb.de Thu Oct 15 09:42:40 1998 From: raepple_s at ibb.de (StefanRaepple) Date: Mon Jun 7 17:05:46 2004 Subject: XML Message-ID: <01BDF820.2995D890@ibb.de> Hello, I have a problem in understanding the middle-tier-server. My question about that device is: Is that existing device physically or logical ? And if it's physically, where can I find it on the client-side or on the server-side ? What's the job of this device ? In fact I've no idea about the middle-tier-server Thanks for any answer Stefan Raepple xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hb at ix.heise.de Thu Oct 15 13:32:46 1998 From: hb at ix.heise.de (Henning Behme) Date: Mon Jun 7 17:05:46 2004 Subject: ANN: DBMS -> XML -> HTML (article) Message-ID: <3625DCFB.F56379B3@ix.heise.de> Hi, although I am not quite sure, whether the members of this list won't find it trivial, here is a bit of practical use of XML, an article from the current issue of iX (yes I am biased :-): creating HTML files from an XML source that was created from a database using a report; including how to make menus available for different applications which are created via DSSSL/jade. If anyone's interested: http://www.heise.de/ix/artikel/E/1998/11/186/ (English) http://www.heise.de/ix/artikel/1998/11/186/ (German) Best regards, Henning Behme iX - Magazin fuer professionelle Informationstechnik Helstorfer Str. 7 * 30625 Hannover * Germany http://www.heise.de/ix/ * +49 511 5352-374 * -361 (Fax) ------ White, adj. and n. Black (Ambrose Bierce) ------ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Thu Oct 15 14:12:07 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:05:46 2004 Subject: A call for open source DTDs In-Reply-To: Scott Vanderbilt's message of "Wed, 14 Oct 1998 13:50:49 -0700" References: <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: Scott Vanderbilt writes: > Regarding copyright ownership of DTD: > > Copyright law protects expressions of ideas, not the underlying ideas > themselves. In many instances, a well-written DTD can only be expressed in > a particular manner, with allowances made for naming of elements, > attributes, etc. Therefore, any protection under copyright law would be > limited, because the scope of copyright protection is proportional to the > range of expression available to articulate the underlying ideas > communicated by the DTD. This is called the "merger doctrine" and is well > known in copyright law, especially with regard to the area of computers. I beg to differ. The effort involved in the construction of substantial DTDs such as those from the DocBook or TEI is a least as much in the articulation of the ideas in the formal schema language of SGML DTDs as in the original document structure ideas themselves. As such, I think any unlicensed redistribution of those DTDs would be a clear and easily prosecuted case of copyright infringement. In any case, as it stands a DTD is a document, and documents are ipso facto copyright by their authors. You're certainly correct that if I made a rational reconstruction of the DocBook or TEI DTD functionality, I'd be on pretty safe ground, and even if I expanded all the parameter entity references of e.g. the TEI under a given set of switch settings, I might be able to get away with redistribution of the result, although that's MUCH less clear. The parallel with QuickSort is illuminating. If I redistribute YOUR awk implementation of QuickSort, with our without relabling some of the variables, I've violated your copyright. If I code QuickSort myself in perl, I'm just fine. If I use a2p on your source and redistribute the results, the lawyers will have a field day. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Thu Oct 15 14:49:51 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:05:46 2004 Subject: REC-xml-19980210: whitespace In-Reply-To: Paul Prescod's message of Wed, 14 Oct 1998 18:52:27 -0400 Message-ID: <199810151249.NAA00826@cogsci.ed.ac.uk> > > > a single #x20 > > is appended for a "#xD#xA" sequence that is part of an external > > parsed entity or the literal entity value of an internal parsed > > entity" > This seems like a buglet to me. Is not the document itself an external parsed entity? It's an entity, it's parsed, and it's not internal... -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lists at lumdata.com Thu Oct 15 17:03:24 1998 From: lists at lumdata.com (Scott Vanderbilt) Date: Mon Jun 7 17:05:46 2004 Subject: A call for open source DTDs In-Reply-To: References: Scott Vanderbilt's message of "Wed, 14 Oct 1998 13:50:49 -0700" <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: At 1:11 PM +0100 10/15/98, Henry S. Thompson wrote: >I beg to differ. The effort involved in the construction of >substantial DTDs such as those from the DocBook or TEI is a least as >much in the articulation of the ideas in the formal schema language of >SGML DTDs as in the original document structure ideas themselves. As >such, I think any unlicensed redistribution of those DTDs would be a >clear and easily prosecuted case of copyright infringement. > >In any case, as it stands a DTD is a document, and documents are ipso >facto copyright by their authors. You're certainly correct that if I >made a rational reconstruction of the DocBook or TEI DTD >functionality, I'd be on pretty safe ground, and even if I expanded >all the parameter entity references of e.g. the TEI under a given set >of switch settings, I might be able to get away with redistribution of >the result, although that's MUCH less clear. The first thing I should point out, as was brought to my attention by John Cowan, is, the Berne Treaty and other attempts to harmonize the laws of various countries notwithstanding, there are still some substantial differences between the US and elsewhere. My familiarity is with US law, so please take that into consideration. In the US, when determining whether a work is coprightable matter, the amount of effort expended in creating a document is not really the issue. Even if it took ten person-years to create a DTD, if there was only one way to articulate the underlying schema, it's not going to have copyright protection against anything other than an incontrovertibly verbatim copy. Which, in my opinion, is a sensible result. Now, as to whether a particular schema can be represented by multiple DTDs which are not substantially the same, that is an issue of fact, and as such, is fodder for the Hundred Years Thread, which I respectfully decline to initiate. Cheers. ========================================================================== Scott D. Vanderbilt mailto:scott@lumdata.com Luminous Dataworks Phone: (310) 253-9918 Custom database solutions Fax: (310) 842-7025 for the World Wide Web ========================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at sunsite.unc.edu Thu Oct 15 17:24:07 1998 From: elharo at sunsite.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:05:46 2004 Subject: A call for open source DTDs In-Reply-To: References: Scott Vanderbilt's message of "Wed, 14 Oct 1998 13:50:49 -0700" <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: Let me elaborate a little on the problem. Let us suppose we have a DTD for plumbing. This DTD is copyright 1998 International Plumbers Association. Can I legally place the DTD is an XML document of my own creation? The answer is no. That would be the same as including an entire poem or other work in my document rather than quoting a part of it. Can I place the DTD in a separate file on my web server and reference it like this: Again, legally, the answer is no. I cannot legally place the copyrighted document on my server any more than I can copy a copyrighted HTML file from another web site onto my own. I can, however, do this: This relies on the International Association of Plumburs not changing the URL of the plumbing DTD, not changing the DTD itself, and maintaining a web server that's fast and accessible independently of the state of my web server. And it completely fails for offline documents. So this isn't a good solution. Is open source a solution? Maybe, especially if the DTD is external to the document. However, standard open source licenses like the GPL are problematic because they would seem to imply that if the DTD is included with the document itself, then the entire document must be open source. They are one file, after all. Not even Richard Stallman tries to make all programs compiled with gcc, open source. Neither should using an open source DTD taint the document the DTD validates. So if we want open source we need a new kind of open source license that's clearer about the distinction between DTDs and documents, even though they may be present in the same file. The simplest solution is to simply declare that the DTD is in the public domain. This works well with existing systems and allows anyone to use the DTD any way they need to. The only potential downside I see to this is that there may be some standardization problems if people are allowed to change the DTD willy-nilly. Long-term I suspect we'll develop some standard licensing language that allows unlimited reuse, but only if the name is changed, perhaps something like Perl's artistic license where you can do anything you want with it as long as you don't call it Perl. In any case, the main thing I want to bring up is to make sure DTD authors think about these things when writing copyright statements. If people are going to use your DTD, they absolutely must be able to republish it. Without special permission, standard copyright prevents that. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@sunsite.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML: Extensible Markup Language (IDG Books 1998) | | http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at sunsite.unc.edu Thu Oct 15 17:24:28 1998 From: elharo at sunsite.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:05:47 2004 Subject: A call for open source DTDs In-Reply-To: <000701bdf7f0$66e46de0$4fe887cb@NT.JELLIFFE.COM.AU> References: Message-ID: At 2:00 PM +1000 10/15/98, Rick Jelliffe wrote: >You might also like to do something similar to my book (The XML & SGML >Cookbook, ISBN 0-13-614223-0 see fourth leaf): I put the notice "The author >does not assert copyright over any SGML markup declaration in this book, >unless noted." It is not enough to expect others to provide copyright-free >declarations, authors have to do it themselves. > I routinely include in all my books a statement that all source code is in the public domain and may be used, reused, and modified freely without permission or attribution. I consider that one of the prime benefits of buying the books. I certainly hope readers find my book useful, and want to reuse the code they find there. I also want to avoid getting besieged with constant requests for permission to use some three line bit of JavaScript. It's not likely any book example is likely to be a multimillion dollar program. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@sunsite.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML: Extensible Markup Language (IDG Books 1998) | | http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Oct 15 17:46:37 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:05:47 2004 Subject: A call for open source DTDs In-Reply-To: Elliotte Rusty Harold's message of "Thu, 15 Oct 1998 11:17:57 -0400" References: Scott Vanderbilt's message of "Wed, 14 Oct 1998 13:50:49 -0700" <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: Elliotte> Elliotte Rusty Harold 0> In article , Elliotte 0> wrote: Elliotte> Is open source a solution? Maybe, especially if the DTD is Elliotte> external to the document. However, standard open source Elliotte> licenses like the GPL are problematic because they would Elliotte> seem to imply that if the DTD is included with the document Elliotte> itself, then the entire document must be open source. IINM, this is (almost exactly) the situation that the LGPL is designed for - your proprietary document may be linked to the open DTD and distributed as long as the user retains the ability to link with a different DTD. is probably a good place to verify whether this is a correct interpretation for documents. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Oct 15 18:02:01 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:47 2004 Subject: REC-xml-19980210: normalized attribute values References: <199810142209.PAA08710@edinburgh.faslab.com> Message-ID: <36261B6D.37D204E@eng.sun.com> Richard Emberson wrote: > Does the XML processor actually check for this Validity Constraint > violation before normalization? It's a validity constraint, so it must check if it's a validating processor. The check is simple: compare values before and after normalization, and if they differ then the document was NOT standalone. (Implies check should be done AFTER normalization, not before!) - 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 cowan at locke.ccil.org Thu Oct 15 18:11:45 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:47 2004 Subject: REC-xml-19980210 unparsed entity References: <199810142200.PAA08697@edinburgh.faslab.com> Message-ID: <36261ECF.C69BD09B@locke.ccil.org> Richard Emberson wrote: > In section 4.4, the spec states when a parsed general entity > "occurs as Attribute value", it is forbidden which means that a > fatal error has occurred. I suppose this is an error on your part for "unparsed general entity" or "parsed external entity". Parsed general entities include internal entities, references to which are permitted. > In section 3.3.1, part: "Validity Constraint: Entity Name", > it is a validity constraint violation if the value is not a Name > of an unparsed entity. > > It seems that there are two different actions for the same condition. These are two distinct matters. Clause 4.4 says that a *reference* to an external entity, parsed or unparsed, is forbidden in attribute values. Doing so is a violation of the WFC "No External Entity References" in clause 3.1. Clause 3.3.1 says that the value of an entity attribute must be the name of (not a reference to) an unparsed external entity. That is a validity constraint, since non-validating parsers may not be aware of the type of an attribute, and are free to treat them all as CDATA. -- 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 db at Eng.Sun.COM Thu Oct 15 18:17:27 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:47 2004 Subject: REC-xml-19980210: default attribute values References: <199810142208.PAA08706@edinburgh.faslab.com> Message-ID: <36261E0B.E4EE8EC0@eng.sun.com> Richard Emberson wrote: > If the XML processor always automatically produces such > attributes with their default values when they are missing, > how can the Validity Constraint ever be true? The instant a validating processor notes the need to provide a default for a document declared "standalone", it can report this as a validity error. - 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 db at Eng.Sun.COM Thu Oct 15 18:26:05 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:47 2004 Subject: REC-xml-19980210: whitespace References: <199810151249.NAA00826@cogsci.ed.ac.uk> Message-ID: <362620EC.D045CE5B@eng.sun.com> Richard Tobin wrote: > > > > > a single #x20 > > > is appended for a "#xD#xA" sequence that is part of an external > > > parsed entity or the literal entity value of an internal parsed > > > entity" > > > This seems like a buglet to me. > > Is not the document itself an external parsed entity? It's an entity, > it's parsed, and it's not internal... Moreover, 2.10 says (albeit oddly) that CRLF gets normalized to LF everywhere, and the LF would get normalized to a single space inside of an attribute (or Public Identifier) value. There's an inconsistency somewhere with respect to CRLF handling, but the "always normalize CRLF to LF" approach makes things generally consistent. One issue is that 2.10 only identifies this in a parenthetical (non-normative?) comment, and the text there that's normative is more restrictive. - 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 cowan at locke.ccil.org Thu Oct 15 18:38:20 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:47 2004 Subject: A call for open source DTDs References: <000701bdf7f0$66e46de0$4fe887cb@NT.JELLIFFE.COM.AU> Message-ID: <3626252A.D1BBBFF9@locke.ccil.org> Rick Jelliffe wrote: > One thing you should do to minimize any copyright if you are worried is to > reformat the source code, and replace all comments with your own. Comments > and layout both have "originality", which certainly may be copyrighted. That doesn't help. Such a document is a derivative work, and the right to make derivative works is one of the copyright owner's rights. Unless you have a public or private license, you may not make derivative works. Note that a derivative work need not share a single bit with the original, as in the case of a text translated into another language. Contrariwise, two photographs of the same subject from the same viewpoint in the same light may be pixel-for-pixel identical and yet have entirely separate copyrights. -- 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 Oct 15 18:54:38 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:47 2004 Subject: Doubt regading gen. entity ref. in element content References: <02ed01bdf7ff$8f466b80$0101a8c0@server.abinfosys.com> Message-ID: <36262901.1049BEAF@locke.ccil.org> Amit Rekhi wrote: > Would there be any change in the element content model if the > element content contained an external parsed general entity refrence? No. Element content checks are done after references have been resolved. -- 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 petsa at us.ibm.com Thu Oct 15 19:46:08 1998 From: petsa at us.ibm.com (petsa@us.ibm.com) Date: Mon Jun 7 17:05:47 2004 Subject: Regarding XSchema Section 5.2.9 Message-ID: <8525669D.004720A1.00@us.ibm.com> Reply to Amit Rekhi re. where do I specify the datatype? You may want to look at the DCD spec: http://www.w3.org/TR/NOTE-dcd Ashok Malhotra, IBM, petsa@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 15 20:17:07 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:47 2004 Subject: A call for open source DTDs References: <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: <36263C59.2A3A903C@locke.ccil.org> Henry S. Thompson wrote: > In any case, as it stands a DTD is a document, and documents are ipso > facto copyright by their authors. You're certainly correct that if I > made a rational reconstruction of the DocBook or TEI DTD > functionality, I'd be on pretty safe ground, You would. > and even if I expanded > all the parameter entity references of e.g. the TEI under a given set > of switch settings, I might be able to get away with redistribution of > the result, although that's MUCH less clear. No, you would not, except as provided by some copyright license with TEI's copyright owners. As I posted before, the right to make derivative works is a component part of the bundle of rights that the copyright owner has. > The parallel with QuickSort is illuminating. If I redistribute YOUR > awk implementation of QuickSort, with our without relabling some of > the variables, I've violated your copyright. If I code QuickSort > myself in perl, I'm just fine. Correct. However, if the algorithm were patented (which it is not), you would have other problems. > If I use a2p on your source and > redistribute the results, the lawyers will have a field day. It's only the other fella's lawyers who will have a field day. Your lawyer will tell you to settle, and quick. Running a2p over a document is just like translating it into French --- you can't distribute the result without a license. BTW, these are all international (i.e. Berne convention) rules, not local law. -- 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 Oct 15 20:28:48 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:47 2004 Subject: A call for open source DTDs References: Scott Vanderbilt's message of "Wed, 14 Oct 1998 13:50:49 -0700" <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: <36263F04.9B07B9F0@locke.ccil.org> Scott Vanderbilt wrote: > In the US, when determining whether a work is coprightable matter, the > amount of effort expended in creating a document is not really the issue. > Even if it took ten person-years to create a DTD, if there was only one way > to articulate the underlying schema, it's not going to have copyright > protection against anything other than an incontrovertibly verbatim copy. That's not my understanding of form-content merger, though it is close. In U.S. law, if there is *only one sensible way* of expressing something, then that expression is inherently uncopyrightable. If I prepare a list of the towns in New York State in alphabetical order, it does not matter how many others have done the same, or even if I copied from their work. The list is simply too trivial to meet even the relaxed standard of "originality" which copyright law applies. > Which, in my opinion, is a sensible result. I agree. > Now, as to whether a particular schema can be represented by multiple DTDs > which are not substantially the same, that is an issue of fact, and as > such, is fodder for the Hundred Years Thread, which I respectfully decline > to initiate. Well, I will squelch the thread using a counterexample. IBTWSH is by intention an expression of the same schema as (part of) HTML 4.0. However, it is an independently derived work, which I wrote based on my *understanding* of HTML 4.0. If I had simply copied the W3C version and deleted everything which I didn't wish to include in my subset, it would be a derivative work, but I didn't do that. I did, of course, verify (by hand) IBTWSH against HTML 4.0 to make sure it was a true subset, but that does not interfere with its copyright status, any more than verifying one dictionary against another does so, as long as portions of the verifying dictionary do not find their way into the verified dictionary. -- 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 Oct 15 20:35:44 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:47 2004 Subject: A call for open source DTDs References: Scott Vanderbilt's message of "Wed, 14 Oct 1998 13:50:49 -0700" <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: <362640A0.7E263CB3@locke.ccil.org> Elliotte Rusty Harold wrote: > Is open source a solution? Maybe, especially if the DTD is external to the > document. However, standard open source licenses like the GPL are > problematic because they would seem to imply that if the DTD is included > with the document itself, then the entire document must be open source. I think that would be true if the DTD were incorporated into a document, but not if it (or a copy of it) was merely referred to. So a GPLed external subset would not taint documents that link it, any more than the GPL itself taints all the Web pages that link to *it* (as opposed to incorporating it by reference). This would reject your first case (DTD as internal subset) but accept the second case (link to local copy) as well as the third case (link to standard copy). I'm passing this question to the Open Sourcerers. > The simplest solution is to simply declare that the DTD is in the public > domain. This works well with existing systems and allows anyone to use > the DTD any way they need to. The only potential downside I see to this is > that there may be some standardization problems if people are allowed to > change the DTD willy-nilly. Classically it is trademark law rather than copyright law that handles this problem. You can't declare your hardware "Tested by Underwriters Laboratories" or use the UL logo without actually being so, because "Underwriters Laboratories" and the logo are trademarks. > Long-term I suspect we'll develop some standard > licensing language that allows unlimited reuse, but only if the name is > changed, perhaps something like Perl's artistic license where you can do > anything you want with it as long as you don't call it Perl. Perhaps I'll try to devise such a thing for DTDs. Stay tuned. -- 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 matt at veosystems.com Thu Oct 15 20:43:34 1998 From: matt at veosystems.com (matt@veosystems.com) Date: Mon Jun 7 17:05:47 2004 Subject: A call for open source DTDs In-Reply-To: <36263F04.9B07B9F0@locke.ccil.org> from "John Cowan" at Oct 15, 98 02:29:24 pm Message-ID: <19981015184313.26674.qmail@veosystems.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 1647 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981015/1c71cbfd/attachment.bat From ricko at allette.com.au Thu Oct 15 20:53:35 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:47 2004 Subject: A call for open source DTDs In-Reply-To: <3626252A.D1BBBFF9@locke.ccil.org> Message-ID: <000501bdf86d$4f430d40$03e987cb@NT.JELLIFFE.COM.AU> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > John Cowan > Rick Jelliffe wrote: > > > One thing you should do to minimize any copyright if you are > worried is to > > reformat the source code, and replace all comments with your > own. Comments > > and layout both have "originality", which certainly may be copyrighted. > > That doesn't help. Such a document is a derivative work, and the right > to make derivative works is one of the copyright owner's rights. Unless > you have a public or private license, you may not make derivative works. But there are few structures which can be proprietary: most structures are found in common use in any DTD, or can be traced first to ISO DTDs. For example, most of the basic HTML elements can also be found in the ISO 8879 general DTD; apparantly these found their way indirectly to CERN through some a derived DTD in seminars. So it is hard to find a content model which has any originality, that leaves names and comments and layout. Let me put it another way. If your content models are common (no originality=no copyright), and if the element names are insdustry standard (no oringality=no copyright), then you should still rewrite comments and rejig the layout. Does anyone seriously think that someone can have copyright over for example? 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 cowan at locke.ccil.org Thu Oct 15 21:08:19 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:47 2004 Subject: REC-xml-19980210: whitespace References: <199810151249.NAA00826@cogsci.ed.ac.uk> <362620EC.D045CE5B@eng.sun.com> Message-ID: <36264847.2E3C5A1@locke.ccil.org> David Brownell wrote: > Moreover, 2.10 says (albeit oddly) that CRLF gets normalized > to LF everywhere, and the LF would get normalized to a single > space inside of an attribute (or Public Identifier) value. Hmmm. Real CRLFs get normalized to LFs, but does that apply to the appearance of " "? I think not. In attribute values, however, -- 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 tgt at lanl.gov Thu Oct 15 22:54:09 1998 From: tgt at lanl.gov (Thierry Thelliez) Date: Mon Jun 7 17:05:48 2004 Subject: FPI questions Message-ID: <36265E84.B20017F3@lanl.gov> We are attempting to implement XML for one of our projects. There is a need for our users to cross reference documents/data. We were looking for a way to generate/format a universal ID. FPI seems to solve this issue but: 1- Why having yet another syntax ? I mean -//myOrg//myDocType myDocName//en could be: No myOrg myDocType myDocName en 2- Where can I find more info about FPIs ? I spend a long time with a web search engine but got only few interesting documents. Where can I find ISO 9070 related documents ? The ISO web site is not very user friendly for a first timer. 3- Assuming that we keep this syntax, would it be valid to have something like: -//anOrg::anAuthor//aDocType aDocName::aVersionNumber//en or even worse: -//aCountry::anOrg::aDepartment::anAuthor//aDocType::aDocTypeVersionNumber aDocName::aDocVersionNumber//en 4- There is already some code out there to help parsing XMLs (I took a Smalltalk code and ported it to GemStone). Is there anything to parse FPIs ? Regards Thierry -- ..................................................................... . Thierry Thelliez Los Alamos National Laboratory . . Email: tgt@lanl.gov CIC-15 . . Voice: (505) 665 8631 MS M310 . . Fax: (505) 665 5725 Los Alamos NM 87545 . . URL: http://www.lanl.gov/cgi-bin/phone/113845 USA . ..................................................................... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981015/8ea8cd93/attachment.htm From emberson at faslab.com Thu Oct 15 23:27:24 1998 From: emberson at faslab.com (Richard Emberson) Date: Mon Jun 7 17:05:48 2004 Subject: REC-xml-19980210: whitespace Message-ID: <199810152125.OAA12011@edinburgh.faslab.com> John Cowan wrote: > David Brownell wrote: > > > Moreover, 2.10 says (albeit oddly) that CRLF gets normalized > > to LF everywhere, and the LF would get normalized to a single > > space inside of an attribute (or Public Identifier) value. > > Hmmm. Real CRLFs get normalized to LFs, but does that apply > to the appearance of " "? I think not. > In attribute values, however, At a minimum, Section 3.3.3 Attribute-Value Normalization and other places where white space is discussed seems a little short of exact. In Section 3.3.3, bullet #1: "a character reference is processed by appending the referenced character to the attribute value" None of the other bullets deal with character references. The value of the character reference is appended to the attribute value. Its part of the attribute value. Note: When do characters in the attribute value get put into the normalized value? Bullet #4 states that "other characters are processed by appending them to the normalized value." It seems that character references are never explicilty transfered from the attribute value to the normalized value. What happens when the character reference is: #x20? If the attribute is not CDATA, then nothing. If the attribute is CDATA, then if the #x20 is leading or trailing, then its stripped, else if the #x20 is part of a sequence of #x20's, then only one #x20 takes the place of the sequence. What happens when the character reference is: #x09? Nothing happens because the bullet #3 does not apply to character references. What happens when the character reference is: #x0A? Nothing happens because the bullet #3 does not apply to character references. What happens when the character reference is: #x0D? Nothing happens because the bullet #3 does not apply to character references. This implies that the sequence " " is not converted into a #x20 (this was noted by John Cowan above). Section 2.11 End-of-Line Handling, does not apply since a character reference can not contain both #x0D and #x0A in a single reference. So, it is possible for normalized attribute values (of type CDATA and not CDATA) to contain sequences of #x20s and the character sequence #x0D#x0A. If this is not the intent of the spec. then Section 3.3.3 needs a little work. I do not know if this is what was really desired by the authors of the spec but (at least to me) thats what the spec says. If even character reference whitespace are to be processed/normalized, I would recommend that first a value is created by appending character reference, recursive appending of entity references, and simple appending other characters, and then CDATA/non-CDATA normalization takes place, i.e, a two step description. That way the sequence " " will be normalized, again, assuming that thats what the spec is trying to say. I am not out to criticized the spec or its authors; I'm just trying to build a validating parser and not being an SGML-techie or not having partaken in the year+ w3c xml spec development process, I only have the spec to go on. I have the feeling that since there is so much semantics, not just syntax, in the spec someone ought to have, for example, someone like Guy Steele take a pass at it. Richard Emberson xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Fri Oct 16 00:23:06 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:05:48 2004 Subject: REC-xml-19980210: whitespace In-Reply-To: Richard Emberson's message of Thu, 15 Oct 1998 14:25:32 -0700 Message-ID: <1780.199810152222@doyle.cogsci.ed.ac.uk> I think the wording of the section on attribute-value normalisation is meant to mean nothing more or less than that line breaks in attribute values do not need special processing: if you translate cr-lf to lf on input (as suggested in 2.11), then replacing the lf with a space will do the right thing. To say it again: you might think that if you translated cr-lf to lf on input, you would have to keep track of this so that when normalising an attribute value you could put in two spaces, one for the cr and one for the lf. Section 3.3.3 says that you don't have to (indeed must not) do this. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Fri Oct 16 01:58:47 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:48 2004 Subject: What is PI data exactly? Message-ID: <5030300026345491000002L012*@MHS> So if a PI has a target and data, what is the data in the following scenarios? Is the first null data and the second a string of spaces? Is PI data normalized in any way? If the SAX interface specifies that the PI event is target and data, with null if no data, which of the above scenarios would have null data? Are the processors out there consistent in this? Where in the spec did everyone go to back their decisions on this? If there was some text in there and it had spaces on either side, is that kept or normalized? Why is the sky blue? :-) But really, is there some authoritative answer to this or is everyone just doing it ad hoc or is everyone just following someone else's lead? TIA ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 16 05:03:16 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:48 2004 Subject: What is PI data exactly? In-Reply-To: <5030300026345491000002L012*@MHS> from "Dean Roddey" at Oct 15, 98 08:06:32 pm Message-ID: <199810160317.XAA08596@locke.ccil.org> Dean Roddey scripsit: > So if a PI has a target and data, what is the data in the following scenarios? > > > > > Is the first null data and the second a string of spaces? The first case is definitely null data. Production 16 says that the optional data is prefixed by one or more whitespace characters which are not part of it. So the second case has data consisting of a zero-length string. It wouldn't astonish me if some parsers returned null in both cases. However, trailing whitespace is left alone. -- 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 ricko at allette.com.au Fri Oct 16 07:17:42 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:48 2004 Subject: FPI questions In-Reply-To: <36265E84.B20017F3@lanl.gov> Message-ID: <000201bdf8c4$7d2f4410$c5e987cb@NT.JELLIFFE.COM.AU> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Thierry Thelliez We are attempting to implement XML for one of our projects. There is a need for our users to cross reference documents/data. We were looking for a way to generate/format a universal ID. FPI seems to solve this issue but: 1- Why having yet another syntax ? I mean -//myOrg//myDocType myDocName//en could be: No myOrg myDocType myDocName en It could be, but then you couldnt use it inside attributes (unless you put in a processor to parse tags) or thePUBLIC identifier field of an entity declaration (unless ditto). The question is the same as "why aren't URLs marked up using element syntax?" Various previous DTDs have tried to do this, and they have not been as successful. I think the reason can be explained by the software engineering concept of "cohesion and coupling": some kinds of data so naturally cohere to each other (i.e. in the minds of users) that it is wise to couple them (i.e. in their syntax) strongly. In particular, some strings have certain qualities where our minds accept them as names: I think URLs, FPIs and MIME types are such. In my book on document patterns I discuss this. I would also mention that these kind of compound names correspond to the "natural document" pattern, in that they have ( metadata, data, annotations ). When there is one natural document embedded in a different type of document (i.e. code inside text, FPI inside attribute) it seems that humans appreciate this being flagged: especially if no formatting is available, a change of notation will be used. Why does CSS not use instance notation (apart from not upsetting dumb HTML browsers)? I think it is exactly this reason that an embedded document of a completely different document type (as far as its function is concerned) is best marked up by clearly flagging it by using a differnet notation. In other words is not the same as but I think XMLers should not go too far in saying that instance syntax is always preferable to little languages (embedded notations), in particular when the function of the embedded language is not structural markup but for naming or locating or stylesheets. 2- Where can I find more info about FPIs ? I spend a long time with a web search engine but got only few interesting documents. Where can I find ISO 9070 related documents ? The ISO web site is not very user friendly for a first timer. Several (most?) SGML books have information on FPI syntax. Online try Robin Cover's SGML site first. 3- Assuming that we keep this syntax, would it be valid to have something like: -//anOrg::anAuthor//aDocType aDocName::aVersionNumber//en or even worse: -//aCountry::anOrg::aDepartment::anAuthor//aDocType::aDocTypeVersionNumb er aDocName::aDocVersionNumber//en After the "-//" you can use any convention you want for the "owner of FPI" and "name" field. the syntax is -//owner of FPI//type name//lang where the "type" is defined in the SGML standard: e.g. DTD, ENTITIES, NOTATION, TEXT, NONSGML (capitals) and the "lang" (capitals) is the language code of the FPI (and therefore probably of the resource). Why "even worse"? If that is what is required to specify it exactly enough, that is great. ISBN and IDN (Internet Domain Name) "owners" may use the form +//ISBN number//type name//lang +//IDN addess//type name//lang Rick Jelliffe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981016/8afeaac1/attachment.htm From M.H.Kay at eng.icl.co.uk Fri Oct 16 11:00:41 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:48 2004 Subject: What is PI data exactly? Message-ID: <003401bdf8e2$d7e68cb0$7008e391@bra01wmhkay.bra01.icl.co.uk> From: John Cowan > >> So if a PI has a target and data, what is the data in the following scenarios? >> >> >> >> >> Is the first null data and the second a string of spaces? > >The first case is definitely null data. Production 16 says that >the optional data is prefixed by one or more whitespace characters >which are not part of it Are you reading the same spec as me? My version of production 16 doesn't mention "data" at all; all it says is that if there are characters after the PITarget, the first one must be white space. As it doesn't mention data, I don't see how it can tell me whether or not the white space is part of the data. Actually I think the notion of "data" in a PI is a SAX notion, not an XML one. Meta-comment: we're suddenly getting a spate of comments that point to little inconsistencies or ambiguities in the spec, reflecting the fact that it is written very informally. I think the problems are particularly acute when the spec tries to talk about the actions of "XML processors" or "applications" because these notions are very fuzzy. There's good scope for a researcher to add value by producing a formal spec of XML+SAX which tells me definitively which documents are well-formed, which are valid, and what the SAX calls will be for any given document (or non-document). Anyone who is spending time writing yet another XML parser would be adding a lot more value to the community if they spent their time on producing a formal specification instead. 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 ricko at allette.com.au Fri Oct 16 11:28:21 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:48 2004 Subject: What is PI data exactly? In-Reply-To: <003401bdf8e2$d7e68cb0$7008e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <000901bdf8e7$7c3dca40$c5e987cb@NT.JELLIFFE.COM.AU> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Michael Kay > From: John Cowan > > >> So if a PI has a target and data, what is the data in the following > scenarios? > >> > >> > >> > >> > >> Is the first null data and the second a string of spaces? > > > >The first case is definitely null data. Production 16 says that > >the optional data is prefixed by one or more whitespace characters > >which are not part of it > > Are you reading the same spec as me? As a side note, if you want to send whitespace in a PI, then you should not use but or something similar, according to whatever tokenizing notation you define for Foo. Processing instructions should use some processing instruction language, i.e. one which is tokenized with spaces and delimiters, as is ubiquitous. They were not designed to transport "data" which could include significant initial spaces. IMHO, people should try to use attribute syntax and conventions if at all possible. 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 xml at bova.goodnet.com Fri Oct 16 14:31:52 1998 From: xml at bova.goodnet.com (xml@bova.goodnet.com) Date: Mon Jun 7 17:05:48 2004 Subject: unsubscribe Message-ID: <9810160731.AA168892@otoson> Please unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Fri Oct 16 15:06:25 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:05:48 2004 Subject: MSIE5 Beta 2 + XML References: <3.0.32.19981014175221.00a24e90@pop.intergate.bc.ca> Message-ID: <362760CB.1F4FCC90@mecomnet.de> this access imperative seems especially important if the "browser" is to be able to report changes back to the server. is there anything anywhere "on paper" about using styling facilities in a "not-browsing-only" front end? Tim Bray wrote: > > At 08:51 PM 10/14/98 -0400, Frank Boumphrey wrote: > >I am using a simple script and the DOM to transform XML to HTMLon the fly, > >and style it with a CSS style sheet. > > You're doing this to achieve effects not available via CSS alone, I > assume? In principle it would be better to do it with XML+CSS alone so > that a programmer could have read/manipulate access to the XML stuff > through the DOM without the transform getting in the way... > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 16 16:01:32 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:48 2004 Subject: What is PI data exactly? References: <003401bdf8e2$d7e68cb0$7008e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <362751AE.4D21712C@locke.ccil.org> Michael Kay wrote: > Are you reading the same spec as me? My version of production 16 doesn't > mention "data" at all; all it says is that if there are characters after the > PITarget, the first one must be white space. Granted, but it does use "S", which is used throughout the XML recommendation to mean "semantically insignificant whitespace". There is an implicit separation between the one-or-more whitespace characters expressed by "S" and the remaining characters. What you said would be better represented by ((#x20 | #x9 | #xD | #xA) (Char* - (Char* '?>' Char*)))? > Anyone who > is spending time writing yet another XML parser would be adding a lot more > value to the community if they spent their time on producing a formal > specification instead. I firmly believe that it is only the experience of implementation that shakes out these deficiencies. A formal specification is essentially a piece of code that the creator believes has been debugged when it has been desk-checked. "Almost all theorems are correct, but almost all proofs have bugs." -- A mathematician of my acquaintance -- 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 grove at infotek.no Fri Oct 16 16:11:24 1998 From: grove at infotek.no (Geir Ove Gronmo) Date: Mon Jun 7 17:05:48 2004 Subject: xmlarch: version 0.20 released Message-ID: <199810161409.QAA25535@mail.infotek.no> xmlarch: An XML architectural forms processor written in Python Version: 0.20 Released: October 16th 1998 Author: Geir Ove Gr?nmo Email: grove@infotek.no Homepage: http://www.infotek.no/~grove/software/xmlarch/index.html --- What is xmlarch? The xmlarch.py module contains an XML architectural forms processor written in Python. It allows you to process XML architectural forms using any parser that uses the SAX interfaces. The module allow you to process several architectures in one parse-pass. Architectural document events for an architecture can even be broadcasted to multiple DocumentHandlers. What's new? - The module is better documented. Class reference documentation has been generated (pythondoc) and is included in the distribution. - Added full support for renaming. This includes support for #CONTENT, #ARCCONT, #DEFAULT and #MAPTOKEN. - Added the possibility to get information about the original events (EventTracker). This means e.g. that it is possible to find out what element was used in the client document. A more complete and higher level api will be provided later. - Normalizer has been renamed to Prettifier. It is now more complete and generates "prettified" output. Fixes: - Suppressor attributes should apply to the element's descendants, not itself. - Some minor ones --- Enjoy! Geir Ove Gr?nmo xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From creitzel at mediaone.net Fri Oct 16 16:37:52 1998 From: creitzel at mediaone.net (Charles Reitzel) Date: Mon Jun 7 17:05:49 2004 Subject: Namespaces need versioning Message-ID: <199810161437.KAA01894@chmls06.mediaone.net> I missed a week and was just catching up. I came across this from Andrew Layman and felt a need to respond. > >Namespaces need versioning. URIs can easily include date > >codes like "02Nov1997"; W3C itself uses such a scheme, as > >you can see by looking at versions of the namespace spec. Yes, the FPI and/or URL needs versioning. With a decent namespace spec, the prefix used in documents should not. The fact that the prefix is, for all practical purposes, a public identifier, controlled by the DTD author, and tied to a specific verion of the DTD, prevents document authors from changing DTD versions without rewriting their documents. - Not useful. The original namespace WD did not have these flaws. About once a week, a new side effect of the current namespace WD causes grief among folks on this list. I would breathe a sigh of relief if the syntax from the original WD was reinstated, with the addition of scoping rules per the second WD. Better yet, incorporate namespaces into XML proper (Wither 1.1?) with a tag. The document author should be able use the prefix as shorthand for a specific DTD fragment by declaring it once within a local DTD file. The author can then manage the version of an external DTD fragment used by a whole document base by changing a single line in that file! - Useful. Best regards, Charles Reitzel Independent Consultant xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at sunsite.unc.edu Fri Oct 16 16:39:36 1998 From: elharo at sunsite.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:05:49 2004 Subject: A call for open source DTDs In-Reply-To: <362640A0.7E263CB3@locke.ccil.org> References: Scott Vanderbilt's message of "Wed, 14 Oct 1998 13:50:49 -0700" <000201bdf651$e6c165e0$d3228018@jabr.ne.mediaone.net> Message-ID: At 2:36 PM -0400 10/15/98, John Cowan wrote: >This would reject your first case (DTD as internal subset) but accept >the second case (link to local copy) as well as the third case >(link to standard copy). > >I'm passing this question to the Open Sourcerers. > The GPL, LGPL, NPL, and similar are all about software. We're not talking about software. There may be hints of what we need there, but I very much doubt we can really adopt these without modification. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@sunsite.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML: Extensible Markup Language (IDG Books 1998) | | http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Oct 16 16:48:15 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:49 2004 Subject: What is PI data exactly? Message-ID: <3.0.32.19981016074448.00b4bd40@pop.intergate.bc.ca> At 09:56 AM 10/16/98 +0100, Michael Kay wrote: > Actually I think the notion of "data" in a PI is a SAX notion, not an >XML one. Right, the spec just defines the "Target" part. >Meta-comment: we're suddenly getting a spate of comments that point to >little inconsistencies or ambiguities in the spec, reflecting the fact that >it is written very informally. Yes, we are finding little problems. No, this is not a result of writing it informally, it's a result of the committee not having infallible predictive powers. While W3C rules prevent me giving details, I can say that the long-missing XML 1.0 errata document will soon come to exist, and patch some of the typos and thinkos. The W3C is also, in a separate effort, addressing the question of what exactly is the data and what isn't. >I think the problems are particularly acute >when the spec tries to talk about the actions of "XML processors" or >"applications" because these notions are very fuzzy. That is not true at all. The processor and the application are cleanly defined. The fuzzy spots are in the area of what exactly the processor passes to the application. -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 eliot at dns.isogen.com Fri Oct 16 17:20:04 1998 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:05:49 2004 Subject: What is PI data exactly? In-Reply-To: <003401bdf8e2$d7e68cb0$7008e391@bra01wmhkay.bra01.icl.co.uk > Message-ID: <3.0.5.32.19981016101751.008b8bf0@amati.techno.com> At 09:56 AM 10/16/98 +0100, Michael Kay wrote: >Meta-comment: we're suddenly getting a spate of comments that point to >little inconsistencies or ambiguities in the spec, reflecting the fact that >it is written very informally. I think the problems are particularly acute >when the spec tries to talk about the actions of "XML processors" or >"applications" because these notions are very fuzzy. Several of us on the Working Group complained about this at the time. This was always a problem with the SGML spec and was, in my opinion, made worse in XML by reference to "processors" rather than "parsers". The problem is that XML (like SGML) only defines a syntax, not an abstraction constructed from that syntax. In SGML, we got part of the way there by defining the SGML property set that defines the normative form for parsed SGML documents, but we *didn't* formally define the "grove construction process" by which you go from the syntax to the abstraction--that was mostly implicit in the property set definition and explicit in a few places, but ultimately underspecified (but we did have a reference implementation in James Clark's Jade processor). For XML, we need to have the same thing: a normative definition of the abtraction you get by parsing an XML document and a normative definition of the algorithm for going from the syntax to the abstraction (ideally the abstraction should be consistent with SGML's). That is, an abstract data model and construction algorithm. Note that the DOM is not this as it is an implementation-specific *object model* for a particular class of XML processor, not an abstract *data model* divorced from any specific implementation or type of processor. Until this is done, there will always be inconsistencies and ambiguities in the XML specification because there is no way to formally define what an "XML processor" is. 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 cowan at locke.ccil.org Fri Oct 16 17:49:42 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:49 2004 Subject: What is PI data exactly? References: <3.0.5.32.19981016101751.008b8bf0@amati.techno.com> Message-ID: <36276B6B.F77E538D@locke.ccil.org> W. Eliot Kimber scripsit: > Note that the DOM is not this as it is > an implementation-specific *object model* for a particular class of XML > processor, not an abstract *data model* divorced from any specific > implementation or type of processor. Can you expatiate on this distinction, please? -- 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 roddey at us.ibm.com Fri Oct 16 19:51:32 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:49 2004 Subject: A call for open source DTDs Message-ID: <5030300026373672000002L022*@MHS> >Let me elaborate a little on the problem. Let us suppose we have a DTD for >plumbing. This DTD is copyright 1998 International Plumbers Association. >Can I legally place the DTD is an XML document of my own creation? The >answer is no. That would be the same as including an entire poem or other >work in my document rather than quoting a part of it. > Irregardless of the legal issues, couldn't you make the practical argument that anyone wishing to set themselves up as the all seeing all knowing metadocument in some heavily travelled area, and making their DTD the ubiquitous and offical referent would pretty much have to allow all of the uses that you mention? If they don't, i.e. they limit its use or people's ability to freely embed it as required, they the rest of the world is likely to just end run them and develop their own most likely? I have a hard time imagining any DTD which is so complex that if a lot of people needed it and one person had one with onerous usibility constraints, that ten other people or organizations wouldn't just in and fix the problem. So maybe some of these worries might be more technical than practical perhaps? I would think that if I were that organization, and I wanted my DTD to be ubiquitous, I'd allow any quoting or reference or embedding, with a requirement to maintain a statement of my authorship and not to distribute mo dified copies of it without making that clear. Does anyone think that DTDs are going to be such a source of income that issues other than retaining intellectual credit and control of content is going to be really big issues? Just a thought... but then again I'm a pinko commie shareware author :-) ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Fri Oct 16 20:00:14 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:49 2004 Subject: XML formality (was: What is PI data exactly?) Message-ID: <017501bdf92e$306996c0$7008e391@bra01wmhkay.bra01.icl.co.uk> >>I think the problems are particularly acute >>when the spec tries to talk about the actions of "XML processors" or >>"applications" because these notions are very fuzzy. > >That is not true at all. The processor and the application are cleanly >defined. The definition of conforming validating and non-validating processors in section 5 is reasonably OK, subject to "a reasonable man's" interpretations of certain words, especially the verbs "to report" (is an XML processor allowed to allow the application to suppress the error reports?) and "to process" (is the XML processor required to reveal the results of its processing or can it throw it all away, or mangle it in some way after processing?). A formal spec of an API such as SAX or DOM would be much cleaner. By contrast the defining occurrences of the terms processor and application in section 1 (to which hyperlinks point) are hopeless, since they don't define the boundary between the XML processor and the application: they don't tell me, for example, whether my SAXON library is part of the XML processor or part of the application. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Oct 16 20:23:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:49 2004 Subject: A call for open source DTDs References: <5030300026373672000002L022*@MHS> Message-ID: <36278F72.C24480E@locke.ccil.org> Dean Roddey wrote: > I would think that if I were that organization, and I wanted > my DTD to be ubiquitous, I'd allow any quoting or reference or > embedding, with a requirement to maintain a statement of my authorship > and not to distribute modified copies of it without making that clear. Okay, that's what ya want, huh? Then consider the following: The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications.
Package
The collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification.
Standard Version
A Package that has not been modified, or has been modified in accordance with the wishes of the Copyright Holder.
Copyright Holder
Whoever is named in the copyright or copyrights for the package.
You
You, if you're thinking about copying or distributing this Package.
Reasonable copying fee
Whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.)
Freely Available
No fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it.
  • You may make and give away verbatim copies of the the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers.
  • You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version.
  • You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:
  • Place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.
  • Use the modified Package only within your corporation or organization.
  • Rename any non-standard files so the names do not conflict with standard files which must also be provided, and provide separate documentation for each non-standard file that clearly documents how it differs from the Standard Version. This includes generating new Formal Public Identifiers for the Package and any modified contents, unless the Package or its contents had no such identifiers to begin with.
  • Make other distribution arrangements with the Copyright Holder.
  • You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) files as part of a larger (possibly commercial) publication provided that you do not advertise this Package as a product of your own.
  • The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission.
  • THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
    • -- 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 Oct 16 20:28:58 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:50 2004 Subject: A call for open source DTDs References: <5030300026373672000002L022*@MHS> <36278F72.C24480E@locke.ccil.org> Message-ID: <362790B6.8794B631@locke.ccil.org> I blunderingly wrote: >
  • The name of the Copyright Holder may not be used > to endorse or promote products derived from this software > without specific prior written permission. >
    • For "software" read "Package". -- 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 db at Eng.Sun.COM Fri Oct 16 22:49:21 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:50 2004 Subject: XML formality (was: What is PI data exactly?) References: <017501bdf92e$306996c0$7008e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <3627B07D.E90B06F7@eng.sun.com> Michael Kay wrote: > > By contrast the defining occurrences of the terms processor and application > in section 1 (to which hyperlinks point) are hopeless, since they don't > define the boundary between the XML processor and the application: they > don't tell me, for example, whether my SAXON library is part of the XML > processor or part of the application. Seconded. Tim Bray wrote: > That is not true at all. The processor and the application are cleanly > defined. The fuzzy spots are in the area of what exactly the processor > passes to the application. And what about software "between" the processor and the application, which is where most utility code belongs? Tim, you're reinforcing Michael's point about fuzziness! - 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 emberson at faslab.com Sat Oct 17 00:50:29 1998 From: emberson at faslab.com (Richard Emberson) Date: Mon Jun 7 17:05:50 2004 Subject: UTF-8 Message-ID: <199810162248.PAA13981@edinburgh.faslab.com> Does the UTF-8 encoding require that the minimum byte count be used when a character is encoded. Recall that the form of a UTF-8 encoding is: 0xxxxxxx 110xxxxx 10xxxxxx 1110xxxx 10xxxxxx 10xxxxxx 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx So one could, for example, claim that: 00111111 and 11000000 10111111 represent the same character, #x3F, or 11110001 10111111 10111111 10111111 and 11111000 10000001 10111111 10111111 10111111 represent #x7FFFF (note: x10000 < x7FFFF < x10FFFF as so is legal). The reason I ask is whether an XML parser has to worry about 5 and 6 byte UTF-8 encodings or can it *allways* assume that the values represented by such encoding are not legal unicode characters. Thanks. Richard Emberson xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Sat Oct 17 02:19:08 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:05:50 2004 Subject: UTF-8 In-Reply-To: Richard Emberson's message of Fri, 16 Oct 1998 15:48:38 -0700 Message-ID: <5375.199810162331@doyle.cogsci.ed.ac.uk> > Does the UTF-8 encoding require that the minimum byte count > be used when a character is encoded. Yes it does, which has the fortunate effect of making the encoding invertable. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From db at Eng.Sun.COM Sat Oct 17 03:09:58 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:50 2004 Subject: REC-xml-19980210: whitespace References: <199810152125.OAA12011@edinburgh.faslab.com> Message-ID: <3627ED51.E675D113@eng.sun.com> Richard Emberson wrote: > > At a minimum, Section 3.3.3 Attribute-Value Normalization > and other places where white space is discussed seems a little > short of exact. Clarity is also an issue. There's the bit about expanding based on the entity replacement values, but needing to keep the literal entity value to distinguish one special case. It turns out that you can avoid doing that if you convert CRLF to LF on input (per 2.11) but otherwise ... - 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 db at Eng.Sun.COM Sat Oct 17 03:38:48 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:50 2004 Subject: Namespaces need versioning References: <199810161437.KAA01894@chmls06.mediaone.net> Message-ID: <3627F457.F3FE6277@eng.sun.com> Charles Reitzel wrote: > > I missed a week and was just catching up. I came across this from Andrew > Layman and felt a need to respond. Actually, the quote was from me. > > >Namespaces need versioning. URIs can easily include date > > >codes like "02Nov1997"; W3C itself uses such a scheme, as > > >you can see by looking at versions of the namespace spec. > > Yes, the FPI and/or URL needs versioning. With a decent namespace spec, the > prefix used in documents should not. The fact that the prefix is, for all > practical purposes, a public identifier, controlled by the DTD author, and > tied to a specific verion of the DTD, prevents document authors from > changing DTD versions without rewriting their documents. - Not useful. > > The original namespace WD did not have these flaws. I don't see what you're saying. All versions of the namespace spec have used the URL as _just_ an identifier. The identifiers need to reflect an exact set of meanings, hence they need versioning. The prefix was chosen and used by the document author, hence needed no more versioning than the document itself: "this version", versus the case of the namespace URI (meaning defined by a third party, and updated/maintained/changed over time), "the version before that big incompatible change". That is, I don't see an issue that's tied only to the _new_ draft of namespace support, or even one that could be removed. - 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 thillai at ix.netcom.com Sat Oct 17 06:29:27 1998 From: thillai at ix.netcom.com (Thillai) Date: Mon Jun 7 17:05:51 2004 Subject: Reading a XML document embeeded in a logfile Message-ID: <01BDF964.8EAEAD20@thillai> Hi, I have a scenario where one thread or process will keep on creating XML documents and append it in a logfile. Another thread might be interested in reading the XML documents from the log file sequentially. The problem is if the logfile has two XML documents then the file content will become an invalid document.     xyz abc I can introduce a root element called Logfile and append all the documents as a child. But whenever I append a XML document I have to reposition the pointer to rewrite XML document root tag. Is there any way I can instruct the parser not to read the complete file, but read the file upto the first element A and its contents and next it has to return second element and its content. Parser.readStream( ) is giving error when it finds a scenario like this because it reads the whole file. Is it possible to create Document node from a "XML Document String in memory" instead of stream or file. Basically I like to use XML for a logfile where either I should be able to embed the XML document within the logfile, or multiple XML documents will be appended to the logfile continously and I must be able to read the XML docs one by one, or I want to read the embeded XML document into memory and parse it to Document node. Any idea will be appreciated. Thanks for your time. Thillai AT&T, Middletown, NJ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From thillai at ix.netcom.com Sat Oct 17 06:31:23 1998 From: thillai at ix.netcom.com (Thillai) Date: Mon Jun 7 17:05:51 2004 Subject: XML document indentation Message-ID: <01BDF964.8C8DF000@thillai> Hi, I was trying the IBM XML parser to create XML documents in my application. I like to know how to format the XML document properly with indentations (tabs) for better readability. For e.g when I create an Element A and A is having a child element B and when I write the document in a file using document.print(java.io.Writer) I am getting xxx Instead of a format like this I want to get something like xxx I tried method printWithFormat also. It is also not creating in a format in which I expect. Anybody knows solution for this or whether any other parser does formatting. Any suggestion will be useful. Thanks for the time. Thillai AT&T, Middletown, NJ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Oct 17 11:35:02 1998 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:05:51 2004 Subject: Reading a XML document embeeded in a logfile Message-ID: <025d01bdf9b1$68dfd8b0$432e0318@cc221812-a.hwrd1.md.home.com> If you can use C++, take a look at the XML classes in the freeware Win32 Foundation Classes (WFC). They will do what you want. You can stop parsing by setting a callback for the element type you want. For example, give the parser a function to be called every time an "A" element has been parsed. If this callback returns FALSE, the parsing of the document will be stopped. Also, it will perform the indentation you described in your other message. WFC is distributed in source code form. It took me about a day to port it to Unix for one of my customers. Sam http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm -----Original Message----- From: Thillai To: 'xml-dev' Date: Saturday, October 17, 1998 12:31 AM Subject: Reading a XML document embeeded in a logfile >Hi, > >I have a scenario where one thread or process will keep on creating >XML documents and append it in a logfile. > >Another thread might be interested in reading the XML documents from >the log file sequentially. > >The problem is if the logfile has two XML documents then the file content >will become an invalid document. > >xyz > > > >abc > > >I can introduce a root element called Logfile and append all the documents >as a child. But whenever I append a XML document I have to reposition >the pointer to rewrite XML document root tag. > >Is there any way I can instruct the parser not to read the complete file, >but read the file upto the first element A and its contents and next it has >to return second element and its content. Parser.readStream( ) is giving >error when it finds a scenario like this because it reads the whole file. > >Is it possible to create Document node from a "XML Document String in >memory" instead of stream or file. > >Basically I like to use XML for a logfile where either I should be able to >embed the XML document within the logfile, or multiple XML documents >will be appended to the logfile continously and I must be able to read the >XML docs one by one, or I want to read the embeded XML document into >memory and parse it to Document node. > >Any idea will be appreciated. Thanks for your time. > >Thillai >AT&T, Middletown, NJ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Sat Oct 17 11:38:06 1998 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:05:51 2004 Subject: Conference Announcement:XML at the International Python Conference Message-ID: <3.0.6.32.19981017101800.0091f5c0@gpo.iol.ie> As subscribers to this list will know, the Python programming language is becoming increasingly popular for XML development work. This years International Python Conference takes place November 10-13, 1998 at the South Shore Harbour Resort in Houston, Texas. There is a half-day XML tutorial prior to the conference proper co-presented by Paul Prescod and I. During the conference proper I will be presenting a paper on high volume electronic publishing using XML and Python. The conference Web pages at: http://www.foretec.com/python/workshops/1998-11/ Fee Structure Tutorials Tues., Nov. 10 $250 Paper Sessions Wed.-Thurs., Nov. 11-12 $325 Developers' Day Fri., Nov. 13 $125 Add $50 for non-PSA members. Add $75 for late registration. Student discount: Full-time students pay $100 for the Paper Sessions and $50 for Developers' Day. There is no discount for the tutorials. Hope to see you in Houston, Sean Mc Grath def Get_URI_Of_Superlative_Scripting_Language(): return "http://www.python.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 Sat Oct 17 12:42:06 1998 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:05:51 2004 Subject: DTD Question Message-ID: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> I just attended a briefing about XML. One of the things that struck me was, if I understand the presenter, DTD thinks the world is flat. Is it possible for DTD to describe elements of the same name but have different meaning? Consider the following: Sam Blackburn 99.409 2091.7785 Is it possible in DTD to say that NAME.FIRST is a string and ROUTE.FIRST is a number? TIA, Sam http://ourworld.compuserve.com/homepages/sam_blackburn xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Sat Oct 17 13:01:11 1998 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:05:51 2004 Subject: DTD Question Message-ID: <01BDF9CD.9A1F33F0@grappa.ito.tu-darmstadt.de> Samuel R. Blackburn wrote: > I just attended a briefing about XML. One of the things > that struck me was, if I understand the presenter, DTD > thinks the world is flat. Is it possible for DTD to describe > elements of the same name but have different meaning? > > Consider the following: > > > Sam > Blackburn > > > 99.409 > 2091.7785 > > > Is it possible in DTD to say that NAME.FIRST is a string > and ROUTE.FIRST is a number? No. DTDs cannot describe the data type of non-attribute data. It is always character. There are various schema languages floating around, some of which (DCD, SOX), support data types. However, these do not support multiple types for the same element -- that is, you would need FIRST1 and FIRST2 in your example. The only way to apply the constraints you want is in the application. This is possible in your example because the parents of FIRST are different in each case. -- 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 sblackbu at erols.com Sat Oct 17 13:21:18 1998 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:05:51 2004 Subject: DTD Question Message-ID: <000e01bdf9c0$396ddbe0$432e0318@cc221812-a.hwrd1.md.home.com> Many thanks. I was afraid of that. It seems that trying to force a "flat" typing paradigm onto somethings that is inherently nested is doomed. It is like having a programming language where all variables are global (they cannot be scoped to specific functions). I'm new to all of this and trying to make sense of it. Am I missing something tremendously obvious? Sam -----Original Message----- From: Ronald Bourret To: xml-dev@ic.ac.uk Date: Saturday, October 17, 1998 7:03 AM Subject: RE: DTD Question No. DTDs cannot describe the data type of non-attribute data. It is always character. There are various schema languages floating around, some of which (DCD, SOX), support data types. However, these do not support multiple types for the same element -- that is, you would need FIRST1 and FIRST2 in your example. The only way to apply the constraints you want is in the application. This is possible in your example because the parents of FIRST are different in each case. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Sat Oct 17 15:05:44 1998 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:05:51 2004 Subject: DTD Question Message-ID: <01BDF9DF.02C48A20@grappa.ito.tu-darmstadt.de> You are not missing anything tremendously obvious, although you might want to take a look at the namespaces proposal (http://www.w3.org/TR/WD-xml-names). This allows scoping, although not as easily as in your average programming language. (Sorry -- I forgot to mention it before.) I'm not convinced that having only global variables dooms a language. It might make it more difficult to use, but I don't think there are any programs that can be written with locally scoped variables that can't be written with only global variables. I'm also not convinced that document languages have the same requirements as programming languages. HTML might not be the best document language in the world, but it is limited to global variables and it has enjoyed a rather modest success ;) -- Ron Bourret ---------- From: Samuel R. Blackburn Sent: Saturday, October 17, 1998 1:21 PM To: Ronald Bourret; xml-dev@ic.ac.uk Subject: Re: DTD Question Many thanks. I was afraid of that. It seems that trying to force a "flat" typing paradigm onto somethings that is inherently nested is doomed. It is like having a programming language where all variables are global (they cannot be scoped to specific functions). I'm new to all of this and trying to make sense of it. Am I missing something tremendously obvious? Sam xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 17 15:15:27 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:51 2004 Subject: DTD Question In-Reply-To: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> References: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> Message-ID: <13864.39027.494046.595105@localhost.localdomain> Samuel R. Blackburn writes: > I just attended a briefing about XML. One of the things > that struck me was, if I understand the presenter, DTD > thinks the world is flat. Is it possible for DTD to describe > elements of the same name but have different meaning? > > Consider the following: > > > Sam > Blackburn > > > 99.409 > 2091.7785 > > > Is it possible in DTD to say that NAME.FIRST is a string > and ROUTE.FIRST is a number? It's not possible for the DTD to say anything about character-data, except that it's allowed or forbidden. Data typing is not part of XML 1.0 DTDs (though there is some very crude typing for attribute values). 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 rajesh_n1 at verifone.com Sat Oct 17 16:43:23 1998 From: rajesh_n1 at verifone.com (rajesh_n1@verifone.com) Date: Mon Jun 7 17:05:51 2004 Subject: help on expat parser.. Message-ID: hi, I am trying to figure out how to use James Clark's expat parser. I want the parser to be made dtd aware. That is if the xml document contains something like, then I want to do some initialisations based on the information in the file filename.dtd I guess, I should be able to define a function that will do what I want and the parser can be made to invoke that function by setting it as one of the handlers (which one??) I tried setting it as the ExternalEntityReferenceHandler. But that doesn't seem to invoke the function on encountering the above line. If I set this function as a DefaultHandler, then it is invoked everytime (for example, I have a different PI handler set, still this function is invoked prior to the actual PI Handler) Any idea, how to make the parser read the DTD file? I am working on HPUX platform. Thanks for any help, Rajesh N xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sat Oct 17 18:54:11 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:51 2004 Subject: DTD Question In-Reply-To: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> from "Samuel R. Blackburn" at Oct 17, 98 06:41:48 am Message-ID: <199810171709.NAA24104@locke.ccil.org> Samuel R. Blackburn scripsit: > Is it possible in DTD to say that NAME.FIRST is a string > and ROUTE.FIRST is a number? There are two questions here. 1) Is it possible for the content model of FIRST to vary depending on its context? Answer: No. 2) Is it possible to restrict the content of FIRST to be a number as opposed to a general string? Answer: No. -- 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 db at Eng.Sun.COM Sat Oct 17 19:35:37 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:51 2004 Subject: DTD Question References: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> Message-ID: <3628D48E.5681DEE1@eng.sun.com> Samuel R. Blackburn wrote: > > > Sam > Blackburn > > > 99.409 > 2091.7785 > > > Is it possible in DTD to say that NAME.FIRST is a string > and ROUTE.FIRST is a number? The DTD doesn't represent data typing; that's the job of some component that interprets information encoded in XML. Your overloading of a "flat" namespace makes that hard. You could have chosen other validatable ways to do this: Sam ... 99.409 ... Or with namespaces (the "xmlns:" decarations go best in the DTD, IMHO): Sam ... 99.409 ... Or even just have the rules that applications must follow implicitly, based on context (and probably making validation hard/impossible over time). I'd use an explicit approach, since context is so easily lost. - 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 anderst at toolsmiths.se Sat Oct 17 19:38:42 1998 From: anderst at toolsmiths.se (Anders W. Tell) Date: Mon Jun 7 17:05:52 2004 Subject: DTD Question References: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> Message-ID: <36273B9D.38D1522@toolsmiths.se> "Samuel R. Blackburn" wrote: > I just attended a briefing about XML. One of the things > that struck me was, if I understand the presenter, DTD > thinks the world is flat. Is it possible for DTD to describe > elements of the same name but have different meaning? > > Consider the following: > > > Sam > Blackburn > > > 99.409 > 2091.7785 > > > Is it possible in DTD to say that NAME.FIRST is a string > and ROUTE.FIRST is a number? > > TIA, There are at least two ways of solving this type of problems which arise when trying to "encode" C/C++/Corba/RPC data structures in XML. Example: struct NAME { char FIRST[10]; char LAST[10]; } struct ROUTE { char FIRST[10]; char LAST[10]; } ** 1 ** Sam Blackburn 99.409 2091.7785 Now the NAME's and LAST's have different definitions and may be handle differently the applications.Still the DTD does don recognise the datatype difference. ** 2 ** Sam Blackburn Here you have both names and datatypes available in a simple manor, with no name clashing and and DTD that handles datatypes. This is what I personally use for primitive datatype which cannot be divided. Best /Anders -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ / Financial Toolsmiths AB / / Anders W. Tell / /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From emberson at faslab.com Sun Oct 18 00:20:18 1998 From: emberson at faslab.com (Richard Emberson) Date: Mon Jun 7 17:05:52 2004 Subject: Character Range: surrogate blocks Message-ID: <199810172218.PAA14442@edinburgh.faslab.com> To extend the available characters in Unicode one can use to 16 bit characters with surrogate blocks. Now in production rule #2 titled Character Range surrogate blocks are explicitly excluded (along with FFFF and FFFE). Does that mean that if one were reading a character stream that included characters not in the basic set of Unicode characters (those not using surrogate blocks) that it would be a wellformedness violation? There are the extra, beyond 16-bit, characters specified by the spec in production rule #2 as "[x10000-#x10FFFF]". Is this how Unicode characters that use the surrogate blocks get represented in an XML document? Is there an algorithm for the convertions defined somewhere? Short of getting a copy of the Unicode 2.0 spec, is there anywhere where the conversion algorithm is documented? Why was it decided to exclude the uses of surrogate block-base Unicode characters within XML documents? Thanks. Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sun Oct 18 00:42:10 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:52 2004 Subject: Character Range: surrogate blocks In-Reply-To: <199810172218.PAA14442@edinburgh.faslab.com> from "Richard Emberson" at Oct 17, 98 03:18:23 pm Message-ID: <199810172257.SAA03244@locke.ccil.org> Richard Emberson scripsit: > To extend the available characters in Unicode one > can use to 16 bit characters with surrogate blocks. Well, no. One uses the 16-bit *codes* in the surrogate blocks. They aren't *characters* (what in Unicode is called *abstract characters*) at all. > Now in production rule #2 titled Character Range > surrogate blocks are explicitly excluded (along > with FFFF and FFFE). Correct, because these codes do not represent characters. > Does that mean that if one were reading a character > stream that included characters not in the basic > set of Unicode characters (those not using surrogate > blocks) that it would be a wellformedness violation? I don't understand this question. Is there an extra "not" somewhere? > There are the extra, beyond 16-bit, characters specified > by the spec in production rule #2 as "[x10000-#x10FFFF]". > Is this how Unicode characters that use the surrogate > blocks get represented in an XML document? In UTF-16 (= Unicode) representation, yes. In UTF-8 representation they are represented as the appropriate 4-byte sequences. > Is there > an algorithm for the convertions defined somewhere? Same as Unicode or ISO 10646 UTF-16, namely: a codepoint in the range D800-DBFF followed by one in the range DC00-DFFF represents the character whose code is (first-D800)*400+(second-DC00)+10000 (hex arithmetic). > Short of getting a copy of the Unicode 2.0 spec, is there > anywhere where the conversion algorithm is documented? http://www.cm.spyglass.com/unicode/standard/wg2n1035.html#x10 > Why was it decided to exclude the uses of surrogate > block-base Unicode characters within XML documents? What is excluded is surrogate characters appearing in unpaired form. These could be generated, e.g. by UTF-8 ED A0 80 = U+D800. -- 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 tbray at textuality.com Sun Oct 18 03:50:25 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:52 2004 Subject: Character Range: surrogate blocks Message-ID: <3.0.32.19981017184828.00b3a130@pop.intergate.bc.ca> At 03:18 PM 10/17/98 -0700, Richard Emberson wrote: >Now in production rule #2 titled Character Range >surrogate blocks are explicitly excluded (along >with FFFF and FFFE). There are no Unicode characters whose numeric values are those which appear in the surrogate blocks; the blocks exist only to ensure the possibility of encoding non-BMP characters unambiguously. The productions in the spec describe the characters themselves, not any particular encoding of them. >There are the extra, beyond 16-bit, characters specified >by the spec in production rule #2 as "[x10000-#x10FFFF]". >Is this how Unicode characters that use the surrogate >blocks get represented in an XML document? Yes. For example, it's legal to have 𐀁 >Short of getting a copy of the Unicode 2.0 spec, is there >anywhere where the conversion algorithm is documented? I strongly recommend getting a copy of the spec. It's fairly priced and a very fine piece of work. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Oct 18 10:31:13 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:52 2004 Subject: Private-Use Characters (RE: Character Range: surrogate blocks) In-Reply-To: <199810172218.PAA14442@edinburgh.faslab.com> Message-ID: <000001bdfa71$ddc84520$b1e987cb@NT.JELLIFFE.COM.AU> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Richard Emberson > To extend the available characters in Unicode one > can use to 16 bit characters with surrogate blocks. If you want to extend the available characters with your own, use the "Private-Use" or "user-defined" character block. The surrogates are codepoints reserved for messing up software later as more registered national characters sets are added; they are not for private use; implementors of current systems can ignore them at least for the next year, as far as I know. FIRST check that your character could not be represented by using an existing ISO 10646 character with some appropriate attribute on the element. In particular, if it is a regional variant of a character, try to use the xml:lang attribute. Note that a "language" includes far more than just simple regional language: I could have xml:lang='en-US-legal' to indicate US legalese; or it could be xml:lang='x-physics' to indicate that it is using the language of physics, but this language has not been recognised by IANA: in this case, your stylesheet can say "Oh, this is an X, but an X to be rendered as physicists will want it rendered." NEXT note that if you need mathematical characters, check out MML http://www.w3.org/TR/REC-MathML/chapter6.html first. FINALLY there are two contradictory needs for a user-defined character: searching (collation) and display. Which fits you?-- If your primary need is DISPLAY, then it is better to use an entity reference for the character. The corresponding entity contains an element with a hypertext reference to the glyph of the character: e.g. "> If your system is smart, you could use content-negotiation to get the best form: GIF or whatever. (And it lets you tie into some Web fonts system, as that becomes available.) If you also need a little bit of collatability, you could add an attribute to indicate collation sequence posisition. If your primary need is for simple SEARCHING (collation) rather than presentation, then use the Private-Use area. (In the Private-Use characters, avoid using E200-E600; MML uses them.) You should always enter any of the Private-Use area characters using a numeric character reference (or, if you use these characters more than once, or want to provide a modicom of documentation, define an entity for them and use an entity reference)-- this will prevent possible transcoding errors later, and also makes the text more readable in editors which do not allow private-use characters to be added. (Western readers may be surprised that allowing user-defined characters is not uncommon in CJK publishing software, since the standard sets only go so far, even though it is almost unheard of in the West.) Rick Jelliffe XXX xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 18 11:41:47 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:52 2004 Subject: Character Range: surrogate blocks In-Reply-To: <199810172218.PAA14442@edinburgh.faslab.com> Message-ID: <000101bdfa7b$b6738f70$b1e987cb@NT.JELLIFFE.COM.AU> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Richard Emberson > Why was it decided to exclude the uses of surrogate > block-base Unicode characters within XML documents? It makes no sense to allow numeric character references to surrogates. You can directly use a numeric character reference to the character which the surrogate-pair encodes! Every character in a document on a computer is in some encoding. In particular:-- * When stored in a file, an XML document may be encoded in any encoding that IANA accepts (providing it has most of the ASCII characters), including Unicode. * When made available through DOM, an XML document is encoded using Unicode. All characters (except Private-Area characters, by their nature) are interpreted according to ISO 10646 specifications, regardless of their encoding. A surrogate is not a character, in the abstract: it is an encoding of a future ISO 10646 character with a value greater than (2^16)-1. Before the addition of surrogates, Unicode characters took one codepoint, and it was possible to speak loosely of ISO 10646 characters and Unicode codepoints as if they were the same thing (more or less). That was one of the charms of Unicode. But with the addition of surrogates, this convenience does not apply (to the surrogate area) and life is more complicated. Personally, I think we should aim at allowing *more* character encodings, not fewer, in XML documents. Encoding is a compression optimized for a locale. As long as the encoding of a document is clearly labelled, and the transcoding of that encoding to ISO10646 is established, and as long as the distinctions of codepoints/characters and standard/private characters is kept, I can only think that multiple encodings do not represent a "mess", but something of great value. However, this value probably does not extend to text when it is inside an XML application: so the fact that DOM uses Unicode, and not some more generic char* or wchar_t*, is to be applauded, IMHO. 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 ginnyi at email.msn.com Sun Oct 18 20:26:04 1998 From: ginnyi at email.msn.com (virginia iandiorio) Date: Mon Jun 7 17:05:52 2004 Subject: XML usage in/for libraries Message-ID: <000101bdfac4$875572a0$b59e2299@virginii> I am a graduate student of library and information science and am writing a paper on the use of XML in and for library applications. I would appreciate any information from list subscribers about any existing sites or projects under development. Gratefully, Ginny Iandiorio xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From thillai at ix.netcom.com Mon Oct 19 03:20:32 1998 From: thillai at ix.netcom.com (Thillai) Date: Mon Jun 7 17:05:52 2004 Subject: What is the error in this XML doc. Message-ID: <01BDFADC.93704700@thillai> I have a XML file called x.xml and the content is ]> &ref; and y.xml, the content is 123 456 I am able to parse the Document with root node as A and two children nodes B. No error. If I change the XML file x.xml to ]> &ref; and when I read the x.xml using readStream(buf) I am getting the following error. c:\proj\x.xml: 9, 5: Content mismatch in `'. Content model is ``(B)*'. I am not sure whether it is a valid XML doc or not. I belive without those two lines in the DTD it is a well formed document. But when add those two rules it becomes an invalid document. Basically what I am trying to do is x.xml will have root element and y.xml will have the contents of the root element A. Please give me an idea what I am doing wrong and how it should be. (I am using IBM XML parser.) Thillai AT&T, Middletown, NJ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From thillai at ix.netcom.com Mon Oct 19 03:23:07 1998 From: thillai at ix.netcom.com (Thillai) Date: Mon Jun 7 17:05:52 2004 Subject: XML document indentation Message-ID: <01BDFADC.98599A00@thillai> Sorry. printWithFormat is working as expected. I was doing a mistake. That is why it was not working. Thanks. Thillai ---------- From: Thillai Sent: Saturday, October 17, 1998 12:24 AM To: 'xml-dev' Subject: XML document indentation Hi, I was trying the IBM XML parser to create XML documents in my application. I like to know how to format the XML document properly with indentations (tabs) for better readability. For e.g when I create an Element A and A is having a child element B and when I write the document in a file using document.print(java.io.Writer) I am getting xxx Instead of a format like this I want to get something like xxx I tried method printWithFormat also. It is also not creating in a format in which I expect. Anybody knows solution for this or whether any other parser does formatting. Any suggestion will be useful. Thanks for the time. Thillai AT&T, Middletown, NJ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From kent at trl.ibm.co.jp Mon Oct 19 07:36:59 1998 From: kent at trl.ibm.co.jp (TAMURA Kent) Date: Mon Jun 7 17:05:52 2004 Subject: What is the error in this XML doc. In-Reply-To: Thillai's message of "Sun, 18 Oct 1998 21:16:23 -0400" <01BDFADC.93704700@thillai> References: <01BDFADC.93704700@thillai> Message-ID: <199810190534.OAA27512@ns.trl.ibm.com> > and when I read the x.xml using readStream(buf) I am getting the following error. > c:\proj\x.xml: 9, 5: Content mismatch in `'. Content model is ``(B)*'. > idea what I am doing wrong and how it should be. (I am using IBM XML parser.) Your x.xml with y.xml is valid. Maybe XML4J has a bug in content model matching ;-( -- TAMURA, Kent @ Tokyo Research Laboratory, IBM Japan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Mon Oct 19 10:59:35 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:52 2004 Subject: Reading a XML document embeeded in a logfile Message-ID: <003201bdfb3e$27fe8e20$7008e391@bra01wmhkay.bra01.icl.co.uk> Thillai asked: >I have a scenario where one thread or process will keep on creating >XML documents and append it in a logfile. > >Is there any way I can instruct the parser not to read the complete file? There will not always be a one-to-one mapping between XML documents and files. This is why SAX allows you to provide your own character or byte stream to the parser, as an alternative to supplying a URL. So the solution is to attach your own Reader to the log file, and supply that Reader to the parser rather than supplying the raw file. The problem in your case is detecting "end of document" so you can signal "end of input stream" to the parser. I think you can do that by having your application tell the Reader when the number of end tags notified by the parser is equal to the number of start tags. How your Reader decides where to start reading is a different problem: you haven't given enough information about your scenario to answer it. 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 M.H.Kay at eng.icl.co.uk Mon Oct 19 11:24:12 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:53 2004 Subject: ANN: SAXON 3.1 Message-ID: <00a101bdfb41$9822deb0$7008e391@bra01wmhkay.bra01.icl.co.uk> SAXON version 3.1 is now available at http://home.iclweb.com/icl2/mhkay/saxon.html There are a lot of small enhancements, mostly requested by users, but nothing that radically changes the scope. The changes are described in a changes.html file within the download. SAXON is a java class library that sits on top of a SAX Parser or DOM implementation, providing a variety of facilities that help the application to process an XML document. It is designed primarily to support applications handling specific document types (as opposed to general-purpose tools), especially applications doing XML-to-HTML or XML-to-XML transformations. SAXON works in principle with any SAX 1.0 conformant parser (the latest version is tested with xp, xml4j, SUN XML Library, aelfred) or with any implementation of the latest DOM specification (tested with docuverse and xml4j; should work with SUN again when they upgrade to the latest spec). The download includes source and object code, documentation, and sample applications. One of the sample applications is a DTD Generator which has proved popular in its own right. 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 richard at cogsci.ed.ac.uk Mon Oct 19 14:48:24 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:05:53 2004 Subject: Reading a XML document embeeded in a logfile In-Reply-To: Thillai's message of Sat, 17 Oct 1998 00:24:41 -0400 Message-ID: <199810191248.NAA24069@cogsci.ed.ac.uk> > I can introduce a root element called Logfile and append all the documents > as a child. But whenever I append a XML document I have to reposition > the pointer to rewrite XML document root tag. I don't know if it would work in your particular case, but you might be able to avoid this by having the document consist of something like this: ]> &logentries; and appending elements to the logentries external entity rather than to the logfile itself. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From james_grimm at credence.com Mon Oct 19 16:29:33 1998 From: james_grimm at credence.com (James Grimm) Date: Mon Jun 7 17:05:53 2004 Subject: Reading a XML document embeeded in a logfile References: <199810191248.NAA24069@cogsci.ed.ac.uk> Message-ID: <362B4B13.45A1D150@credence.com> Richard Tobin wrote: > > > I can introduce a root element called Logfile and append all the documents > > as a child. But whenever I append a XML document I have to reposition > > the pointer to rewrite XML document root tag. > > I don't know if it would work in your particular case, but you might > be able to avoid this by having the document consist of something > like this: > > > ]> > &logentries; > > and appending elements to the logentries external entity rather than > to the logfile itself. I really like this solution (and pardon me if I reuse the idea), but there is still the little problem of locking the "logentries" file. The logentries file won't be well-formed, even with this wrapper, if the parser reads the logfile while another thread/program is adding a new log_entry. Anybody know of any tools to help with locking sections of an xml document? I suppose it wouldn't be too difficult to add transaction concepts on top of a DOM implementation. Perhaps a nice tool vendor has already done this? Any other ideas? -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 cowan at locke.ccil.org Mon Oct 19 17:01:13 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:53 2004 Subject: Reading a XML document embeeded in a logfile References: <199810191248.NAA24069@cogsci.ed.ac.uk> <362B4B13.45A1D150@credence.com> Message-ID: <362B541D.86B3EABB@locke.ccil.org> James Grimm wrote: > I really like this solution (and pardon me if I reuse the idea), but > there is still the little problem of locking the "logentries" file. That's a problem with every logfile. About all you can do is use an atomic system call like write() and hope for the best. (Obviously, don't make the entry too vulgar big, either.) -- 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 Sung_Nguyen at datacard.com Mon Oct 19 17:22:22 1998 From: Sung_Nguyen at datacard.com (Sung Nguyen) Date: Mon Jun 7 17:05:53 2004 Subject: XML and DTD pasring Message-ID: <00142EE9.3096@datacard.com> Hello all: With IBM Alpha Parser, It is working fine with both DTD and XML in the same files. But, when I have DTD in a separated file stored in a buffer - also the XML file is stored in a buffer too. The parser doen't provide the API to do that job. Anyone has encounter this ? Please give me some ideas. Thanks, Sung Nguyen Software Engineer DataCard 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 james_grimm at credence.com Mon Oct 19 17:30:48 1998 From: james_grimm at credence.com (James Grimm) Date: Mon Jun 7 17:05:53 2004 Subject: Transaction-based DOM Implementations References: <199810191248.NAA24069@cogsci.ed.ac.uk> <362B4B13.45A1D150@credence.com> <362B541D.86B3EABB@locke.ccil.org> Message-ID: <362B5AFC.5817E993@credence.com> I have changed the subject from "Reading a XML document embeeded in a logfile". I mentioned this question under the other subject heading: Does anyone know of any tools to help construct/modify documents through DOM using transaction concepts? I would like to be able to lock subtrees of the document while performing critical operations. -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 david at megginson.com Mon Oct 19 17:37:05 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:53 2004 Subject: XML and DTD pasring In-Reply-To: <00142EE9.3096@datacard.com> References: <00142EE9.3096@datacard.com> Message-ID: <13867.23480.801109.99263@localhost.localdomain> Sung Nguyen writes: > With IBM Alpha Parser, It is working fine with > both DTD and XML in the same files. But, when I have > DTD in a separated file stored in a buffer - also the > XML file is stored in a buffer too. The parser doen't > provide the API to do that job. I haven't tested the SAX support in XML4J recently, but if it supports EntityResolvers correctly, you can simply make up a URI for the external DTD, and then supply your own Reader for the buffer when you see the URI. For more information, see http://www.megginson.com/SAX/javadoc/org.xml.sax.EntityResolver.html It is possible to use entity resolvers in quite clever ways -- you can also pull information out of a database, request user input in a dialog box, etc. I wish that I could take credit for the idea, but I think that the original suggestion came from James Clark. 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 ricko at allette.com.au Mon Oct 19 19:59:00 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:53 2004 Subject: STX: Short-Tag Compression utilities beta available In-Reply-To: <13867.23480.801109.99263@localhost.localdomain> Message-ID: <000301bdfb8a$512e9d70$73e887cb@NT.JELLIFFE.COM.AU> STX (short-tagged XML) is a compression scheme for XML documents, using ISO 8879 short-tag ommission. I have made a compression and decompression utility for these, stx and unstx. These are now available in beta for anyone who wants to try them, as vanilla C source code or Win32 shell executables (gcc, CygWIN32). I have tested them on James Clark's test archive, Jon Bosak's OT, and the XML spec. (I used xmlwf -d, which is James' great "canonical XML" converter, and diff to test differences.) Compression gains are modest (2% to 6%), but these gains seem to survive survive gzip (deflate) compression (and may indeed improve compressibility). It is easy to create documents which exhibit 80% or more compression, but such documents are artificial. I would be surprised if the general rate of compression for well-suited documents was much more than 25%. These rates are small, but this kind of compression does not seem to disrupt further compressions to binary forms. Furthermore, the compressed data is still editable text, and may be accepted by conforming WebSGML applications. This kind of compression is suited for use as an end-to-end compression: with the ubiquity of intermediate point-to-point compression (e.g. modem-to-modem), it is possible that binary end-to-end compression methods are no more effective than this. I am interested in getting test results from WWW documents which use namespaces heavily, in particular database dumps and RDF. Please email me if you are interested in trying them out. The source code uses Mozilla license. Current version of the software should handle most character encodings on UNIX hosts (not shift-JIS): EBCDIC and wide encodings are passed through without alteration. On Win32, the 16-wide encodings and shift-JIS will have problems. Example of STX encoding. ========================

    blah

    blahblahblah

    blah

    blah

    blah

     will be compressed as:

    blah <>blahblahblah <>blah

    blah

    <>

    blah 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 Per-Ake.Ling at uab.ericsson.se Mon Oct 19 20:27:02 1998 From: Per-Ake.Ling at uab.ericsson.se (Per-Ake Ling) Date: Mon Jun 7 17:05:53 2004 Subject: No subject Message-ID: <199810191826.UAA15261@uabs05.eua.ericsson.se> unsubscribe xml-dev xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From per-ake.ling at ericsson.com Mon Oct 19 20:31:19 1998 From: per-ake.ling at ericsson.com (Per-Ake Ling) Date: Mon Jun 7 17:05:53 2004 Subject: Error in greeting [ADMIN] Message-ID: <362B8502.C001F135@ericsson.com> Sorry to disturb the list, but I did not find a suitable address for administrative matters. Minor nitpicking: I have recently resubscribed to the list (due to email change) and noticed that in the greeting received from majordomo there is a http address to Robin Cover's old address (www.sil.org) instead of the new one (http://www.oasis-open.org/cover/). Regards, Per-?ke -- Per-?ke Ling (note: Per-Åke, transliteration Per-Ake) email: Per-Ake.Ling@ericsson.com L M Ericsson Data AB phone: +46 8 5853 2453 Torshamnsgatan 36 mobile: +46 70 583 2453 SE-125 82 Stockholm, Sweden fax: +46 8 404 6668 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Sung_Nguyen at datacard.com Mon Oct 19 21:22:09 1998 From: Sung_Nguyen at datacard.com (Sung Nguyen) Date: Mon Jun 7 17:05:53 2004 Subject: No subject Message-ID: <00143456.3096@datacard.com> Hello all: With IBM Alpha Parser, It is working fine with both DTD and XML in the same files. But, when I have DTD in a separated file stored in a buffer - also the XML file is stored in a buffer too. The parser doen't provide the API to do that job. Anyone has encounter this ? Please give me some ideas. Thanks, Sung Nguyen Software Engineer DataCard 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 james_grimm at credence.com Tue Oct 20 00:01:33 1998 From: james_grimm at credence.com (James Grimm) Date: Mon Jun 7 17:05:54 2004 Subject: Entity References (trivial question) Message-ID: <362BB69A.E3ADBA58@credence.com> I have a (hopefully) trivial question. I am trying to use entity references to abstract my documents from their storage locations as follows: %SpecificDocumentType; The XML is: When I run the parser (the Java version of MSXML) from D:\Development\xml\doc, I get the following error: Error opening input stream for "file:/D:/Development/xml/config/%DtdBase;specific_document_type.dtd": java.io.FileNotFoundException: \D:\Development\xml\config\%DtdBase;specific_document_type.dtd Location: Parsing(0,0) Context: Would someone please help me spot my (probably stupid) mistake? Thanks, 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 creitzel at mediaone.net Tue Oct 20 01:15:35 1998 From: creitzel at mediaone.net (Charles Reitzel) Date: Mon Jun 7 17:05:54 2004 Subject: Namespaces need versioning Message-ID: <199810192315.TAA20249@chmls06.mediaone.net> From: David Brownell Date: Fri, 16 Oct 1998 18:35:19 -0700 Subject: Re: Namespaces need versioning David Brownell wrote: > Actually, the quote was from me. Oops. Thanks for the correction. >>David Brownell wrote: >> > >Namespaces need versioning. URIs can easily include date >> > >codes like "02Nov1997"; W3C itself uses such a scheme, as >> > >you can see by looking at versions of the namespace spec. >> >> Charles Reitzel wrote: >> Yes, the FPI and/or URL needs versioning. With a decent namespace >> spec,the prefix used in documents should not. The fact that the prefix >> is, for all practical purposes, a public identifier, controlled by the >> DTD author, and tied to a specific verion of the DTD, prevents document >> authors from changing DTD versions without rewriting their documents. >> - Not useful. >> >> The original namespace WD did not have these flaws. > >I don't see what you're saying. All versions of the namespace spec >have used the URL as _just_ an identifier. The identifiers need to >reflect an exact set of meanings, hence they need versioning. The >prefix was chosen and used by the document author, hence needed no >more versioning than the document itself: "this version", versus >the case of the namespace URI (meaning defined by a third party, and >updated/maintained/changed over time), "the version before that big >incompatible change". > >That is, I don't see an issue that's tied only to the _new_ draft >of namespace support, or even one that could be removed. The difference is that for a prefix to be set in a DTD it has to be a #FIXED attribute of the element and is, therefore, defined by the author of the DTD and *not* the document. If the prefix is set by the document author, then the exact, version-specific URL must also be included with each instance of the element using the prefix. In the first case, the prefix must also be version specific and, therefore, cannot be used as a mechanism to insulate documents from changes in the DTD version. In the second case, when the DTD version changes, every instance of its use must be updated to refer to the new version of the DTD fragment. Remember, the purpose here is to define standard libraries of DTD fragments which can be used for industry specific EDI transactions, standard data types, and the like. Such DTD fragments will occasionally undergo updates which will be, by and large, backward compatible - much like standard function libraries. Typically, only a small number existing elements would be "broken" by the new DTD fragment. The document author simply has to change the prefix declaration to point to the new version of the DTD fragment and run the documents through the parser and/or application. With a well designed and maintained DTD fragment, only a few elements will be kicked out. With the old spec, the prefix is associated with a URL uniquely within a document and cannot mean different things for different elements. The prefix declaration occurs in the document prolog, possibly in an external entity (i.e. DTD fragment). Currently, the NS processing instruction is allowed as a custom, non-standard feature and may well not be inter-operable with other XML parsers or applications. That said, the processing instruction is *required* for validation to work (i.e. for an element instance to be correctly associated with its declaration by its qualified name). But all of this ground was well-trod by xml-dev'ers when the revised NS spec came out. See what I mean? Best regards, Charlie Reitzel Independent Consultant P.S. I sense a great deal of hesiation among industry groups hoping to base data exchange standards on XML DTD's due to this issue. Is everybody giving up on validation and moving to DCD instead? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 20 03:21:56 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:54 2004 Subject: Listrivia: xml-dev digest Message-ID: <3.0.32.19981019182132.00b4ec10@pop.intergate.bc.ca> Hi - I'm getting the xml-dev digest by email every day. It's pretty big. Must I have asked for this? Is there a way to stop it? -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Oct 20 07:55:44 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:54 2004 Subject: Entity References (trivial question) In-Reply-To: <362BB69A.E3ADBA58@credence.com> from "James Grimm" at Oct 19, 98 03:00:58 pm Message-ID: <199810200611.CAA22106@locke.ccil.org> James Grimm scripsit: > I have a (hopefully) trivial question. > > I am trying to use entity references to abstract my documents from their > storage locations as follows: > > > > "%DtdBase;specific_document_type.dtd"> Parameter entity references aren't interpreted inside system literals. -- 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 RJA at dip.co.uk Tue Oct 20 09:38:16 1998 From: RJA at dip.co.uk (RJA@dip.co.uk) Date: Mon Jun 7 17:05:54 2004 Subject: Valid XML Question - 017.XML Message-ID: <802566A3.00295D5B.00@dip.co.uk> Richard J. Anderson@DI 10/20/98 08:38 AM Hi, I've been recently testing my XML C++ parser against J Clarks XML test cases. Whilst testing against valid/sa/017.xml I found a problem in the XML file, or more likely my parser. Here is the file: ]> On the 4th line, the second PI has no name, which according to the spec is not valid. Is this valid ? Is it even a PI ? Have I overlooked something in the spec !?!?! Whilst on the subject of test cases, are there any more XML testbeds I could use too ? Kind Regards, Richard 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 ht at cogsci.ed.ac.uk Tue Oct 20 09:56:26 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:05:54 2004 Subject: Reading a XML document embeeded in a logfile In-Reply-To: James Grimm's message of "Mon, 19 Oct 1998 07:22:11 -0700" References: <199810191248.NAA24069@cogsci.ed.ac.uk> <362B4B13.45A1D150@credence.com> Message-ID: James Grimm writes: > there is still the little problem of locking the "logentries" file. The > logentries file won't be well-formed, even with this wrapper, if the > parser reads the logfile while another thread/program is adding a new > log_entry. Standard solution at this level is to copy the "logentries" file, add your entry, then move it back. Reduces the chances of collision, and also some operating systems (e.g. UNIX) will do their best to let any reading underway at the time of move back complete with the old version. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Tue Oct 20 10:13:35 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:05:54 2004 Subject: Valid XML Question - 017.XML In-Reply-To: <802566A3.00295D5B.00@dip.co.uk> Message-ID: <3.0.5.32.19981020100129.00b93100@post.step.de> * RJA@dip.co.uk | | I've been recently testing my XML C++ parser against J Clarks XML test | cases. I've been away for a couple of weeks, so I seem to have missed this. Is it released somewhere? | | ]> | | | On the 4th line, the second PI has no name, which according to the spec is | not valid. Is this valid ? Is it even a PI ? Have I overlooked something | in the spec !?!?! You've overlooked something in the document, more likely. :-) ^^ ^^ start end In other words: there's just one PI, not two. :-) If you look at production 16 in the spec you'll see that WS is not allowed between the ? and the > that closes a PI, while individual ?s and >s are allowed in the PI data. | Whilst on the subject of test cases, are there any more XML testbeds I | could use too ? James Tauber has a list at --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 rbourret at ito.tu-darmstadt.de Tue Oct 20 11:21:53 1998 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:05:54 2004 Subject: XSchema: Final review Message-ID: <01BDFC1A.F2062480@grappa.ito.tu-darmstadt.de> The final review version of XSchema is available at: http://www.simonstl.com/xschema/spec/xscspecv4.htm The review period lasts until Sunday, 25 October and covers sections 4 and 5, appendix C, and those parts of sections 1-3 that have changed since the last version. (The rest of sections 1-3 are frozen.) If no technical questions are raised, the spec will be considered final on Monday, 26 Oct. -- Ron Bourret Changes since 23 Sept draft: * Added ElementNS attribute to XSchema, Mixed, Choice, Seq, Ref, AttGroup, and AttDef. ElementNS is needed to refer to elements in a two-part (namespace, name) naming system. * Removed Model from the content model of Model. (It is still allowed in Choice and Seq.) * Clarified the description of Mixed. * Created Enumeration element and added to the content models of AttDef and XSchema. * Rewrote 2.4.0 (Attribute Declarations) to clean up existing material and incorporate ElementNS attribute. * Added Doc and More to content model of UnparsedEntity. * Added information to section 3.0 about how to construct XSchema documents that can be used in both namespace-aware and -unaware environments. * Rewrote section 3.2 (Namespaces of Elements and Attributes Being Defined) to incorporate ElementNS attribute. * In section 4.1 (DTDs in XSchema Documents), stated that, if an XSchema document includes a DTD, the doctype must be XSchema and any user-specific markup declarations cannot override anything in the XSchema DTD. * In section 4.3 (Converting Between XSchema Documents and DTDs), stated that converters can generate comments at will. * PIs are discarded when converting from DTDs to XSchema documents. * Added public identifier to XSchema PI, made system identifier mandatory, and fixed names and capitalization. * Mentioned FileExtension attribute in section 5.2.7 (Authoring). * Added Appendix C (XSchema in XSchema). xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Tue Oct 20 12:29:04 1998 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:05:54 2004 Subject: Namespaces need versioning Message-ID: <019501bdfc14$5d0e36c0$bcbc77c1@sgml.u-net.com> Charlie Reitzel wrote: >I sense a great deal of hesiation among industry groups hoping to base data exchange standards on XML DTD's due to this issue. Is everybody giving up on validation and moving to DCD instead? Hopefully not: but validation of dynamic DTDs is always going to be a problem:-( In an earlier message he said: >>The fact that the prefix >> is, for all practical purposes, a public identifier, controlled by the >> DTD author, and tied to a specific verion of the DTD, prevents document >> authors from changing DTD versions without rewriting their documents. >> - Not useful. I would have said very useful. Authors don't want users to change the DTD after the document instance has been written. >The difference [from the old method of using PIs] is that for a prefix to be set in a DTD it has to be a #FIXED attribute of the element and is, therefore, defined by the author of the DTD and *not* the document. Remember that you only need to use #FIXED if you need to ensure the value never changes. The alternative is to provide a default value that will be used unless the author makes a concious choice to override it. > If the prefix is set by the document author, then the exact, version-specific URL must also be included with each instance of the element using the prefix. Why is this necessarily wrong? Once the instance is created the document type used for its creation should never need to be changed. It is only when you want to revise the instance and, as part of the revision, make it conform to a revised version of the DTD, that you need to consider changing the markup of the instance. If the version information gets associated with a local namespace declaration, e.g. it will allow authors to mix two versions of the declarations for the same thing in a single instance, if they really want to do so, whereas, would force them to use the correct models in the correct place >In the first case, the prefix must also be version specific and, therefore, cannot be used as a mechanism to insulate documents from changes in the DTD version. Again I am lost. By using local namespace declarations in the instance, as shown above, you can certainly insulate document instances from future changes in the DTD, which is what I thought was wanted. > In the second case, when the DTD version changes, every instance of its use must be updated to refer to the new version of the DTD fragment. No: All the existing instances remain referencing the old version of the DTD. What you need to do is to change the identifier of the updated version so that it can be differentiated from that of the old version. Why should existing document instances need to point to the revised DTD until they need to be revised? >Remember, the purpose here is to define standard libraries of DTD fragments which can be used for industry specific EDI transactions, standard data types, and the like. Such DTD fragments will occasionally undergo updates which will be, by and large, backward compatible - much like standard function libraries. Typically, only a small number existing elements would be "broken" by the new DTD fragment. Again my question is "why do old transactions need to be validated against new DTDs?" (New XSL style sheets I understand the need for!) > The document author simply has to change the prefix declaration to point to the new version of the DTD fragment and run the documents through the parser and/or application. With a well designed and maintained DTD fragment, only a few elements will be kicked out. With the local namespace approach he has the advantage of only having to add a new xmlns attribute to every element the parser kicked out. I don't see how any simpler method could be devised. >With the old spec, the prefix is associated with a URL uniquely within a document and cannot mean different things for different elements. Now we come to the real nub of the problem, which is to stop users applying the same namespace names twice if validation is to take place. But this cannot happen because if the user tries to do it the parser will reject the DTD as it will contain two definitions for the same element. If the element is one whose role has not changed all you need to do is to remove the duplicated definition. If it is one that has changed then to validate it using the revised definition you must assign it a unique namespace qualifier to the revised definition and use the extended name in all occurrences of the revised element in the revised instance. It seems to me that exactly the same problem occurs as that which occurs when you are using processing instructions to define name spaces within a DTD and then fail to qualify sublement definitions correctly. Its just that you get more chances for it to happen. In what way do you see the two processes as differing? > The prefix declaration occurs in the document prolog, possibly in an external entity (i.e. DTD fragment). Or it can occur in the local subset as a set of additional attribute definitions for the elements affected. (To my mind this is by far the best place to manage namespaces. Namespaces declared in external entities must have their versions controlled from the relevant parameter entity declaration, which is dangerous and prone to error.) > Currently, the NS processing instruction is allowed as a custom, non-standard feature and may well not be inter-operable with other XML parsers or applications. That said, the processing instruction is *required* for validation to work (i.e. for an element instance to be correctly associated with its declaration by its qualified name The whole point is that the revised spec, because it is based solely on attributes, will be accessible using SGML tools as well as XML tools. The PI specific one requires the addition of a specialized PI processor to any tool that is going to use it. Martin Bryan The SGML Centre xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Tue Oct 20 14:28:19 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:05:55 2004 Subject: XSchema: Final review Message-ID: <3.0.32.19981020082819.006a91e0@polaris.net> At 11:15 AM 10/20/98 +0200, Ronald Bourret wrote: >The final review version of XSchema is available at: > >http://www.simonstl.com/xschema/spec/xscspecv4.htm Thanks so much to Ron and Simon for pulling together the XSchema spec (and to everyone who contributed to it, as well). When Simon first pushed the idea, he was proposing to complete it by July 1. That it actually took as long as it did reflects the care and thoroughness they took to get it right through several review phases -- to say nothing of their determination to include e.g. namespaces. Well done, guys. ============================================================= John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Tue Oct 20 14:48:52 1998 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:05:55 2004 Subject: XSchema: Final review Message-ID: <01BDFC38.2AADE710@grappa.ito.tu-darmstadt.de> John Simpson wrote: > Thanks so much to Ron and Simon for pulling together the XSchema spec (and > to everyone who contributed to it, as well). And don't forget John Cowan, without whose technical wizardry we never would have survived. -- 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 thillai at ix.netcom.com Tue Oct 20 16:18:28 1998 From: thillai at ix.netcom.com (Thillai) Date: Mon Jun 7 17:05:55 2004 Subject: Document toString Message-ID: <01BDFC12.5FCB1EC0@thillai> Hi, Is there anyway I can convert a Document (it's contents) to String. Basically after creating a document I have to display it in the screen as text. (I don't want to read from a file after writing it in a stream) Anybody who is familiar with MS XML parser (java) or IBM XML parser (java) or anyother parser please let me know whether it is possible. Otherwise I have to write a toString function for different types of nodes. Thillai AT&T, Middletown, NJ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From petsa at us.ibm.com Tue Oct 20 16:43:50 1998 From: petsa at us.ibm.com (petsa@us.ibm.com) Date: Mon Jun 7 17:05:55 2004 Subject: Document toString Message-ID: <852566A3.00509D97.00@us.ibm.com> Here's what I do to display a document in a Swing TextArea: public class XMLText extends JPanel { TXDocument doc; JTextArea textArea; /** * Resets the text in the panel */ public void refresh() { ByteArrayOutputStream outputStream = new ByteArrayOutputStream(); try { doc.print(new PrintWriter(new OutputStreamWriter(outputStream)));} catch (IOException e) { System.out.println ("IO Exception in XMLText:refresh");} String XMLText = outputStream.toString(); textArea.setText(XMLText); repaint(); } Regards, Ashok xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Tue Oct 20 16:56:50 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:05:55 2004 Subject: Entity References (trivial question) In-Reply-To: John Cowan's message of Tue, 20 Oct 1998 02:11:43 -0400 (EDT) Message-ID: <199810201456.PAA16413@cogsci.ed.ac.uk> > > > > > > > "%DtdBase;specific_document_type.dtd"> > Parameter entity references aren't interpreted inside system literals. Also you didn't want the SYSTEM keywords in at least the first two declarations. You can achieve the effect you want by having a parameter entity expand to the whole entity declaration: "> %SpecificDocumentTypeDecl; %SpecificDocumentType; -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Oct 20 17:03:44 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:55 2004 Subject: Document toString In-Reply-To: <01BDFC12.5FCB1EC0@thillai> References: <01BDFC12.5FCB1EC0@thillai> Message-ID: <13868.42349.187349.881351@localhost.localdomain> Thillai writes: > Is there anyway I can convert a Document (it's contents) to String. > Basically after creating a document I have to display it in the screen > as text. (I don't want to read from a file after writing it in a stream) > Anybody who is familiar with MS XML parser (java) or IBM XML parser (java) > or anyother parser please let me know whether it is possible. Otherwise I > have to write a toString function for different types of nodes. I think that Michael Kay's SAXON tools [1] contain a SAX driver for iterating through a DOM tree, and I know that James Clark has a SAX application XMLTest [2] that produces a normalised form of XML called "Canonical XML" -- you could use the two of those together to convert any part of a DOM tree to text. That said, it would probably be easier and more efficient for you to create a generic DOMWriter -- it's really a one-hour exercise if you understand XML, the DOM, and Java well enough. All the best, David [1] http://home.iclweb.com/icl2/mhkay/saxon.html [2] http://www.jclark.com/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 roddey at us.ibm.com Tue Oct 20 20:06:55 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:05:55 2004 Subject: Whitespace in EMPTY model Message-ID: <5030300026488760000002L002*@MHS> Another whitespace related question... If the model is EMPTY, what happens to the whitespace between that element's begin/end tags? Is that defined anywhere? Should it always just be skipped? What if the element has the XML whitespace attribute or the parser was told to maintain ignorable whitespace? ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jbolles at homeaccount.com Tue Oct 20 20:41:28 1998 From: jbolles at homeaccount.com (Jack Bolles) Date: Mon Jun 7 17:05:55 2004 Subject: DTD Question References: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> Message-ID: <362CD9E0.78581DED@homeaccount.com> Putting aside the ability to specify datatypes, you could always make FIRST and LAST attributes of the respective elements. Also, aren't positional names (first, last) too presentational without describing the data? For instance, replace FIRST with GIVEN and LAST with FAMILY. (This might make the DTD more reusable in countries that don't order their names the same as most western countries as well.) Finally, would it make sense to encapsulate frequently used elements such as NAME within their own DTD? Regards, Jack --------------------------------------------------------------------- Jack Bolles Software Engineer http://users.homeaccount.com/~jbolles/CV.html --------------------------------------------------------------------- Samuel R. Blackburn wrote: > I just attended a briefing about XML. One of the things > that struck me was, if I understand the presenter, DTD > thinks the world is flat. Is it possible for DTD to describe > elements of the same name but have different meaning? > > Consider the following: > > > Sam > Blackburn > > > 99.409 > 2091.7785 > > > Is it possible in DTD to say that NAME.FIRST is a string > and ROUTE.FIRST is a number? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From support at bigriverinfotech.com Tue Oct 20 21:30:17 1998 From: support at bigriverinfotech.com (Raymond) Date: Mon Jun 7 17:05:55 2004 Subject: DTD Question References: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> <362CD9E0.78581DED@homeaccount.com> Message-ID: <362CE373.51A2F0F0@bigriverinfotech.com> > Putting aside the ability to specify datatypes, you could always make FIRST and LAST attributes of the respective elements. > > Also, aren't positional names (first, last) too presentational without describing the data? For instance, replace FIRST with GIVEN and LAST with FAMILY. (This might make the DTD more reusable in countries that don't order their names the same as most western countries as well.) It would be more acceptable to utilize FIRST with GIVEN NAME and LAST with SURNAME. We found the X.400 naming conventions to be internationally acceptable. Raymond xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From support at bigriverinfotech.com Tue Oct 20 21:32:05 1998 From: support at bigriverinfotech.com (Raymond) Date: Mon Jun 7 17:05:55 2004 Subject: DTD Question References: <000701bdf9ba$be90b5f0$432e0318@cc221812-a.hwrd1.md.home.com> <362CD9E0.78581DED@homeaccount.com> Message-ID: <362CE3CD.123510B5@bigriverinfotech.com> > Putting aside the ability to specify datatypes, you could always make FIRST and LAST attributes of the respective elements. > > Also, aren't positional names (first, last) too presentational without describing the data? For instance, replace FIRST with GIVEN and LAST with FAMILY. (This might make the DTD more reusable in countries that don't order their names the same as most western countries as well.) It would be more acceptable to utilize FIRST with GIVEN NAME and LAST with SURNAME. We found the X.400 naming conventions to be internationally acceptable. Raymond xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Oct 20 22:03:15 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:05:55 2004 Subject: Forest Automata formalism Message-ID: <362CB10D.4185A4F6@technologist.com> Several people have asked me about my paper on Forest Automata. Unfortunately, I haven't been able to find time to compile a decent bibliography, nor add the code examples I hoped to, but I'm going to release it anyhow. There is a partial(?) bibliography on Robin Cover's SGML/XML page. My paper (sans biblio) can be found at: http://www.prescod.net/forest/shorttut Forest Automata theory is a formalism for describing SGML/XML validation. The formalism makes clear some obvious extensions to SGML/XML validationand can be used as a source of ideas and answers relating to DTD parameterization, "data types" (lexical data types), validation-in-context, query languages etc. Hopefully I will find time or funding to expand this paper eventually, because there are many interesting highways and biways that it hints at but does not explore. Paul Prescod - http://itrc.uwaterloo.ca/~papresco 4'33" is rarely performed as an encore. - Steve Newcomb (for info about 4'33": http://www.lenzo.com/~sburke/stuff/cage_433.html http://www.intrex.net/rwgarr/johncage.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 crism at oreilly.com Tue Oct 20 22:09:20 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:05:56 2004 Subject: Whitespace in EMPTY model In-Reply-To: <5030300026488760000002L002*@MHS> (message from Dean Roddey on Tue, 20 Oct 1998 14:14:43 -0400) Message-ID: <199810202007.QAA23772@ruby.ora.com> [Dean Roddey] > If the model is EMPTY, what happens to the whitespace between that > element's begin/end tags? Is that defined anywhere? Should it always > just be skipped? What if the element has the XML whitespace > attribute or the parser was told to maintain ignorable whitespace? That's a good question. I was ready to reply that an EMPTY element must have nothing between the start- and end-tags, but that's not immediately clear upon reading the spec. Validity Constraint: Element Valid An element is valid if there is a declaration matching elementdecl where the Name matches the element type, and one of the following holds: 1. The declaration matches EMPTY and the element has no content. but it's not clear whether "no content" prohibits ignorable whitespace. -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 support at bigriverinfotech.com Tue Oct 20 23:12:18 1998 From: support at bigriverinfotech.com (Raymond) Date: Mon Jun 7 17:05:56 2004 Subject: DTD Question bypassSTGspamstuff Message-ID: <362CFB5E.2BBDCB11@bigriverinfotech.com> >> Putting aside the ability to specify datatypes, you could always make FIRST and LAST attributes of the respective elements. Also, aren't positional names (first, last) too presentational without describing the data? For instance, replace FIRST with GIVEN and LAST with FAMILY. (This might make the DTD more reusable in countries that don't order their names the same as most western countries as well.) << It would be more acceptable to utilize FIRST with GIVEN NAME and LAST with SURNAME. We found the X.400 naming conventions to be internationally acceptable. Raymond xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 21 01:24:48 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:56 2004 Subject: Whitespace in EMPTY model Message-ID: <3.0.32.19981020161516.00b1de40@pop.intergate.bc.ca> At 04:07 PM 10/20/98 -0400, Chris Maden wrote: >I was ready to reply that an EMPTY element must have nothing between >the start- and end-tags, but that's not immediately clear upon reading >the spec. You're right. You can have either or but not > 1. The declaration matches EMPTY and the element has no content. > >but it's not clear whether "no content" prohibits ignorable >whitespace. I think if you follow the definition chain it falls out. Content includes text, and text is made of characters. There is NO SUCH THING as ignorable whitespace in XML; the closest thing is WS between elements where you have a declared element (i.e. non-mixed) content. And that is not labeled "ignorable" or anything like it. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From james_grimm at credence.com Wed Oct 21 01:46:44 1998 From: james_grimm at credence.com (James Grimm) Date: Mon Jun 7 17:05:56 2004 Subject: Whitespace in EMPTY model References: <3.0.32.19981020161516.00b1de40@pop.intergate.bc.ca> Message-ID: <362D20A5.BFCC61AD@credence.com> Tim Bray wrote: > > At 04:07 PM 10/20/98 -0400, Chris Maden wrote: > >I was ready to reply that an EMPTY element must have nothing between > >the start- and end-tags, but that's not immediately clear upon reading > >the spec. > > You're right. You can have either or but > not > > In the version of MSXML I have (anyone know how to check the version of MSXML?), you can only have . Would seem to be a bug. -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 tbray at textuality.com Wed Oct 21 01:51:03 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:05:56 2004 Subject: Whitespace in EMPTY model Message-ID: <3.0.32.19981020164952.00b37e90@pop.intergate.bc.ca> At 04:45 PM 10/20/98 -0700, James Grimm wrote: >In the version of MSXML I have (anyone know how to check the version of >MSXML?), you can only have . Would seem to be a bug. If it's in IE4, it's known to be out of date, don't sweat it. If it's in an IE5 beta, you need to let MS know. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From james_grimm at credence.com Wed Oct 21 02:14:46 1998 From: james_grimm at credence.com (James Grimm) Date: Mon Jun 7 17:05:56 2004 Subject: Whitespace in EMPTY model References: <3.0.32.19981020164952.00b37e90@pop.intergate.bc.ca> Message-ID: <362D2744.6BF016A3@credence.com> Tim Bray wrote: > > At 04:45 PM 10/20/98 -0700, James Grimm wrote: > >In the version of MSXML I have (anyone know how to check the version of > >MSXML?), you can only have . Would seem to be a bug. > > If it's in IE4, it's known to be out of date, don't sweat it. If it's > in an IE5 beta, you need to let MS know. -Tim It's in IE4, so I'm not sweating (and no one else should either). Looks like it's time to bleed a bit more by downloading one more beta! -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 db at Eng.Sun.COM Wed Oct 21 06:49:10 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:05:56 2004 Subject: Document toString References: <01BDFC12.5FCB1EC0@thillai> Message-ID: <362D66EB.5F5932A2@eng.sun.com> Thillai wrote: > > Is there anyway I can convert a Document (it's contents) to String. > Basically after creating a document I have to display it in the screen > as text. (I don't want to read from a file after writing it in a stream) > Anybody who is familiar with MS XML parser (java) or IBM XML parser (java) > or anyother parser please let me know whether it is possible. Otherwise I > have to write a toString function for different types of nodes. If Sun's package doesn't do this for you, please let us know, since it's supposed to do that! (Beware of huge strings, of course...) That could change in a future release; comments? Document d = XmlDocumentbuilder.createDocument (...); String s = d.toString (); Similarly, the nodes in that version of DOM all implement an additional method: void write (Writer) which emits the node as XML (not pretty-printed though). That API should certainly change, though; it's a bit too XML-specific for such a general method name. - 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 walter.kriha at systor.com Wed Oct 21 12:02:31 1998 From: walter.kriha at systor.com (walter.kriha@systor.com) Date: Mon Jun 7 17:05:56 2004 Subject: Transaction-based DOM Implementations Message-ID: <412566A4.0037FCEB.00@ajr.systor.com> Hi, James wrote: >I mentioned this question under the other subject heading: >Does anyone know of any tools to help construct/modify documents through >DOM using transaction concepts? I would like to be able to lock >subtrees of the document while performing critical operations. -James one possible concept to a achieve this(without a lot of programming) would be to implement the DOM objects as Java Enterprise Beans running in a EJB server. The container policy would then take care of transaction issues. (separation of context principle) We are using IBMs Component Broker and are currently trying to map what I defined as "informational objects" to the persistence layers provided. (the informational objects are e.g. used to represent meta-information from repositories, log/trace information, global business information, dynamic TypeObject content) We also do not allow programming language constructs like "strings" to carry structured information - use informational objects instead) We found that we have to solve a couple of problems here: - which DOM classes should have independent identity? (and as a consequence: global visibility/concurrent use) - what other interfaces should those DOM classes implement? - do we need session AND entity DOM beans? - what kinds of guarantees with respect to update propagation can we make? - how do we transfer larger trees across the wire (possibly using lazy resolution techniques)? - what is the best physical database design for this mapping? - what is the proper entity management architecture (including workload managed information server front-ends,, FEDERATED entity managers etc.) - how do we use formal public identifiers within program code? - how do we make sure that we do not lose performance features like query push down when using dynamic patterns? More EJB related: - what are we going to do if a client (e.g. GUI) is not allowed to control a transaction? - what if we need extended transaction models (open-nested with compensation functions, forward progressing etc.)? More OO/architecture related: - How can I integrate the lose coupling that HyTime relations (links) provide into heavy-weight, static typed OO systems and languages that usually tend to represent any kind of associations WITHIN objects? And still have decent performance? Using Component Broker allows us at least to load-balance information servers almost without programming effort - assuming that most access will be read only. Cheers, Walter PS: I'd be very much interested in exchanging experiences in these areas. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RJA at dip.co.uk Wed Oct 21 15:14:09 1998 From: RJA at dip.co.uk (RJA@dip.co.uk) Date: Mon Jun 7 17:05:56 2004 Subject: C++ SAX Question Message-ID: <802566A4.00475420.00@dip.co.uk> Richard J. Anderson@DI 10/21/98 02:14 PM Hi, I'm currently working on some C++ SAX definitions has was wondering if I should be using references for strings or not. Take the following snippet from the definitions: class CSAXDocumentHandler { public: virtual void startDocument() = 0; virtual void endDocument() = 0; virtual void startElement( string sName, CSAXAttributeList& Attributes ) = 0; virtual void endElement( string sName ) = 0; virtual void processingInstruction( string sTarget, string sData ) = 0; virtual void characters( char ch[], int start, int length) = 0; virtual void setDocumentLocator( CSAXLocator &locator ) = 0; virtual void ignorableWhitespace( char ch[], int start, int length) = 0; //+------------------------------------------------------------------------ //+ additonal methods not supported by SAX //+------------------------------------------------------------------------ virtual void comment( string Comment ) = 0; }; Each method that accepts a string parameter is defined to accept it by value ( eg 'string' ) rather than by reference, ( eg 'string&' ). Is this a good or bad idea ? So far I can think of the following reasons why a reference would be better: 1. No additional/allocation is required for each element callback. 2. Passing by value can cause memory allocation issues. For example, in a dll, the string would be constructed by the caller of the function on their heap (eg. the parser), but deleted by the implemetor of the document handler class whose heap would probably raise an exception. ( I'm still pretty new to STL so maybe you can change the allocation mechanism or I'm completly mistaken :-) ). I would be interested in hearing some feedback on this subject, as I an hoping to publish my C++ SAX definitions in the next week or so. Kind Regards, Richard Anderson. *** This post is of a personal nature and does not in anyway represent the opinions or developments of data interchange plc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 21 15:47:38 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:05:56 2004 Subject: C++ SAX Question In-Reply-To: <802566A4.00475420.00@dip.co.uk> References: <802566A4.00475420.00@dip.co.uk> Message-ID: <13869.57724.155569.453365@localhost.localdomain> RJA@dip.co.uk writes: > I'm currently working on some C++ SAX definitions has was wondering if I > should be using references for strings or not. Yes, you should certainly be using references for strings (const references, actually); you should also use wstring rather than string, since XML requires Unicode support. I'm not a C++ guru, but I'd suggest starting with something like this for DocumentHandler: xml/sax/DocumentHandler: #ifndef __XML_SAX_DOCUMENTHANDLER #define __XML_SAX_DOCUMENTHANDLER 1 #include #include #include "Locator" #include "AttributeList" namespace org_xml_sax { class SAXDocumentHandler { public: virtual void setDocumentLocator (const Locator &locator) = 0; virtual void startDocument () = 0; virtual void endDocument () = 0; virtual void startElement (const wstring &name, const AttributeList &atts) = 0; virtual void endElement (const wstring &name) = 0; virtual void characters (const wchar_t ch[], size_t start, size_t length) = 0; virtual void ignorableWhitespace (const wchar_t ch[], size_t start, size_t length) = 0; virtual void processingInstruction (const wstring &name, const wstring &target) = 0; }; } #endif __XML_SAX_DOCUMENTHANDLER As for comments, you probably want to put non-SAX stuff in a separate or an extended interface so that other people can use your SAX interface as well, i.e. #include namespace rja_sax { class RJADocumentHandler : public org_xml_sax::DocumentHandler { public: virtual void comment (const wstring &data) = 0; }; } All the best, and thanks for taking the interest in building a SAX C++ interface. David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Wed Oct 21 15:49:11 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:05:56 2004 Subject: Coins/XObject BOF at '98 Message-ID: <002c01bdfcf9$83adbea0$ab026982@thing1.camb.opengroup.org> I am hosting a Birds of a Feather round table at '98 on Coins and would be delighted to include discussion on XObjects as well. Bill Here's the formal announcement: Do you need to learn more about XML? Are you ready to go beyond the hype and learn how to use XML today? Attend, '98, November 4-6 at the International Trade Center, Washington, DC. The event is produced by Xmlu.com and is shaping up to be the premier XML event of the year. For more program details, visit our web site, http://tag98.com or contact us directly at 1-766-7844. We are planning to hold a Birds of a Feather round table on COINS during lunch on Thursday, November 5th from 12:30 to 1:30. Bill Laforge founder of JXML and creator of COINS will be chairing this session. If you register for '98 and reference this announcement, you will receive a $50 discount. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Wed Oct 21 16:11:57 1998 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:05:56 2004 Subject: Forest Automata formalism In-Reply-To: <362CB10D.4185A4F6@technologist.com> Message-ID: <199810211410.QAA02363@sonne.darmstadt.gmd.de> Paul Prescod wrote at 20 Oct 98, 11:49: > Several people have asked me about my paper on Forest Automata. Paul's paper is excellent, it helped me to see the WHY in addidion to the WHAT. [2] has a very complete bibliography, but less would be more. Could anyone recommend some papers/textbooks other then listed in [1] ? I'm aiming for a quickstart, [2] is very longish ... Formalisms are no problem, but a bit motivation and examples would help more for a beginner. ++im [1] http://www.oasis-open.org/cover/topics.html#forestAutomata [2] http://l3ux02.univ-lille3.fr/tata/ -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From greynolds at datalogics.com Wed Oct 21 16:41:04 1998 From: greynolds at datalogics.com (Reynolds, Gregg) Date: Mon Jun 7 17:05:56 2004 Subject: Forest Automata formalism Message-ID: <51ED3F5356D8D011A0B1006097C30734014E5AB8@martinique> Thanks to Paul for making the paper available. I've been working on a tree query language that has ended up looking much like a forest/tree regexp language; I had not considered it from the dtd/schema perspective. Looks very promising! FYI: There is a bibliography of 144 items in "Handbook of Theoretical Computer Science Part B", Elsevier and MIT Press 1996, Chapter 4 "Automata on Infinite Objects" by Wolfgang Thomas. Part Two of the chapter is entitled "Automata on Infinite Trees." Caveat: very heavy sledding. Most of it sails way over my head, but on pages 165-166 there is a very concise account of tree concatenation etc., which I found understandable and useful. You can probably find this in a bookstore if you're in a major city. Two other good references: "Text Algorithms" by Maxime Crochemore and Wojciech Rytter, Oxford 1994 "Algorithms on Strings, Trees, and Sequences: Computer Science and Computational Biology", by Dan Gusfield, Cambridge U. Press 1997. Very cool book. Excellent and thorough treatment of suffix trees. - gregg > -----Original Message----- > From: Paul Prescod [SMTP:papresco@technologist.com] > Sent: Tuesday, October 20, 1998 10:50 AM > To: xml-dev; tigue@oz.net; macherius@darmstadt.gmd.de; Sean Mc Grath > Subject: Forest Automata formalism > > Several people have asked me about my paper on Forest Automata. > Unfortunately, I haven't been able to find time to compile a decent > bibliography, nor add the code examples I hoped to, but I'm going to > release it anyhow. There is a partial(?) bibliography on Robin Cover's > SGML/XML page. > > My paper (sans biblio) can be found at: > > http://www.prescod.net/forest/shorttut > > Forest Automata theory is a formalism for describing SGML/XML > validation. > The formalism makes clear some obvious extensions to SGML/XML > validationand can be used as a source of ideas and answers relating to > DTD > parameterization, "data types" (lexical data types), > validation-in-context, query languages etc. > > Hopefully I will find time or funding to expand this paper eventually, > because there are many interesting highways and biways that it hints > at > but does not explore. > > Paul Prescod - http://itrc.uwaterloo.ca/~papresco > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Vaiyapuri_Subramanian at rmic.com Wed Oct 21 16:51:24 1998 From: Vaiyapuri_Subramanian at rmic.com (Vaiyapuri Subramanian) Date: Mon Jun 7 17:05:56 2004 Subject: No subject Message-ID: Hello all, I just wrote an application which creates XML file from the table. All you hava to do is to to give the table name and it will generate the XML. My Question, i just wanted to know, whether the XML generated is correct. If there is any mistake, please do bear with me and any corrections and help is welcome. For your reference, i am attaching a generated XML file: ]> A Activate A PASSTEST 1998-02-23 09:44:00.000 E Re-Evaluate A PASSTEST 1998-02-23 09:44:00.000 F ReFund A PASSTEST 1998-02-23 09:44:00.000 G Migration A PASSTEST 1998-02-23 09:44:00.000 I Increase A PASSTEST 1998-02-23 09:44:00.000 R Renew A PASSTEST 1998-02-23 09:44:00.000 Thanks & Bye , Vaiyapuri Subramanian , ( O ) 800 / 933 - 7642 x 3278 . ( R ) 336 / 759 - 0777 x 614 . xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Wed Oct 21 17:32:57 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:57 2004 Subject: XML representation of a Table Message-ID: <002101bdfd07$69a52170$7008e391@bra01wmhkay.bra01.icl.co.uk> > I just wrote an application which creates XML file from the table. All you >hava to do is to to give the table name and it will generate the XML. My >Question, i just wanted to know, whether the XML generated is correct. Sounds a useful application, I'd like to know more about it (especially if you can do the reverse as well!). You can check whether the XML is "correct" (i.e. valid and well-formed) by putting it through any xml parser, I think xp is one of the strictest. Some test cases you need to check are your handling of non-ASCII characters and special characters such as "<" in your data. You also need to consider whether CR/LF characters in your data are significant: XML treats CR=LF=CRLF which may not be what you want. One observation, in your DTD all the columns of the table are declared mandatory, this gives you no way of handling null values (the obvious representation of a null value is to omit the relevant element). Another issue you may need to address is that not every SQL table and column identifier is a valid XML name. For example, SQL identifiers can contain spaces. You will also have to think about how to encode binary (blob) fields. For large tables your representation is very inefficient in space terms. Often we don't worry about this in XML work, but relational tables can reach gigabytes in size even without all these tags. An alternative I would consider for large tables is: etc AActivateAPASSTEST1998-02-23 09:44:00.000...
    I don't think the gurus would recommend using empty elements as separators like this, but it is a perfectly legitimate use of XML. Finally, a transfer format for relational tables also needs to be able to represent the metadata; my example heads in this direction. Regards, 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 petsa at us.ibm.com Wed Oct 21 18:05:54 1998 From: petsa at us.ibm.com (petsa@us.ibm.com) Date: Mon Jun 7 17:05:57 2004 Subject: XML representation of a Table Message-ID: <852566A4.00577E4E.00@us.ibm.com> Two points re. translating from relational tables to XML and back. 1. The example seems reasonable but the fun really starts when you want to represent 2 or more joined tables as an XML document. In general, you want to map a SQL view into a XML document and if you have more than 1 table in the view its not always clear how to structure the hierarchy. 2. Omitting a value is *not* the right way to represent a NULL value. SQL distinguishes between these 2 cases. A string column can have an empty string as a value or its value can be NULL. In DCD we recommend that you use a special attribute to represent that the value is NULL. Ashok Malhotra (Embedded image moved to "Michael Kay" file: 10/21/98 11:28 AM pic25949.pcx) Please respond to "Michael Kay" To: xml-dev@ic.ac.uk cc: (bcc: Ashok Malhotra/Watson/IBM) Subject: Re: XML representation of a Table > I just wrote an application which creates XML file from the table. All you >hava to do is to to give the table name and it will generate the XML. My >Question, i just wanted to know, whether the XML generated is correct. Sounds a useful application, I'd like to know more about it (especially if you can do the reverse as well!). You can check whether the XML is "correct" (i.e. valid and well-formed) by putting it through any xml parser, I think xp is one of the strictest. Some test cases you need to check are your handling of non-ASCII characters and special characters such as "<" in your data. You also need to consider whether CR/LF characters in your data are significant: XML treats CR=LF=CRLF which may not be what you want. One observation, in your DTD all the columns of the table are declared mandatory, this gives you no way of handling null values (the obvious representation of a null value is to omit the relevant element). Another issue you may need to address is that not every SQL table and column identifier is a valid XML name. For example, SQL identifiers can contain spaces. You will also have to think about how to encode binary (blob) fields. For large tables your representation is very inefficient in space terms. Often we don't worry about this in XML work, but relational tables can reach gigabytes in size even without all these tags. An alternative I would consider for large tables is: etc AActivateAPASSTEST1998-02-23 09:44:00.000...
    I don't think the gurus would recommend using empty elements as separators like this, but it is a perfectly legitimate use of XML. Finally, a transfer format for relational tables also needs to be able to represent the metadata; my example heads in this direction. Regards, 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: pic25949.pcx Type: application/octet-stream Size: 2427 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981021/07fa60c3/pic25949.obj From SMUENCH at us.oracle.com Wed Oct 21 21:54:52 1998 From: SMUENCH at us.oracle.com (Steve Muench) Date: Mon Jun 7 17:05:57 2004 Subject: XML representation of a Table Message-ID: <199810211954.MAA06058@mailsun3> You can tag things up in a generic row/column way, or in a way that makes the natural relationships speak themselves more directly. Pardon my ASCII art below, but if I have some tables in a database like: AUTHOR \|/ | /|\ BOOK \|/ | COURSE \|/ | TEACHER If I'm thinking of Courses, then I might want my data in XML to look like: XML Basics Joe Tags 50.00 Go, XML, Go! Dr. Seuss But if I'm thinking of Teachers I might want: Joe Tags XML Basics 50.00 Go, XML, Go! Dr. Seuss History of Markup 18.00 SGML, a History Sammy Jones 28.00 Zen and the Art of Markup Tao Bo Of course there's no strict need for the enclosing tags, but a browser trying to parse such a "datagram" might appreciate knowing that a group of something was about to start... Object relational databases have the ability to predefine a nested structure as an object and then make metadata about the structure of that object available to client programs via data dictionary tables so that they might be written to generically query and XML-format the data in an intelligent way. Oracle8 has a feature called Object Views which lets relational data be viewed as an object structure, so you could combine these ideas to have your data structuring and your logical data manipulation in whatever "shapes" make sense for your app. ____________________________________________________________________________ Steve | Consulting PM & XML Technology Evangelist | smuench@oracle.com Muench | Java Business Objects Dev't Team | geocities.com/~smuench -------------- next part -------------- An embedded message was scrubbed... From: petsa@us.ibm.com Subject: Re: XML representation of a Table Date: 21 Oct 98 09:03:34 Size: 9159 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981021/1961b04a/attachment.eml From pvelikho at cs.ucsd.edu Wed Oct 21 22:10:54 1998 From: pvelikho at cs.ucsd.edu (Pavel Velikhov) Date: Mon Jun 7 17:05:57 2004 Subject: XML representation of a Table References: <002101bdfd07$69a52170$7008e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <362E3CC4.D7BC1B7B@cs.ucsd.edu> Michael Kay wrote: > One observation, in your DTD all the columns of the table are declared > mandatory, this gives you no way of handling null values (the obvious > representation of a null value is to omit the relevant element). > > Another issue you may need to address is that not every SQL table and column > identifier is a valid XML name. For example, SQL identifiers can contain > spaces. > It seems that throwing relational attributes into XML attributes overcomes both problems - make all attributes optional, all that are missing are null.E.g. , everything that is not present is null. Not a space efficient representation however. > You will also have to think about how to encode binary (blob) fields. > For large tables your representation is very inefficient in space terms. > Often we don't worry about this in XML work, but relational tables can reach > gigabytes in size even without all these tags. An alternative I would > consider for large tables is: > > > > etc > > > > AActivateAPASSTEST1998-02-23 09:44:00.000 > ... >
    > > I don't think the gurus would recommend using empty elements as separators > like this, but it is a perfectly legitimate use of XML. > My subjective view is that with current XML tools (msxml parser for example) its a lot easier to process XML objects that store data in attributes rather than in subobjects. Empty elements and PCDATA interleaved makes life complicated for no good reason. Plus you have to care for order when creating tables in XML, instead of just setting attributes in an arbitrary fashion. > Finally, a transfer format for relational tables also needs to be able to > represent the metadata; my example heads in this direction. > Is there a standard under development for such a thing? I.e. full scale transfer format for relational tables in XML? > Regards, > Mike Kay Thanks Pavel Velikhov xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Oct 21 22:22:33 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:57 2004 Subject: DTD Question In-Reply-To: <362CD9E0.78581DED@homeaccount.com> from "Jack Bolles" at Oct 20, 98 02:43:44 pm Message-ID: <199810212038.QAA06939@locke.ccil.org> Jack Bolles scripsit: > Also, aren't positional names (first, last) too presentational without describing the data? For instance, replace FIRST with GIVEN and LAST with FAMILY. (This might make the DTD more reusable in countries that don't order their names the same as most western countries as well.) Indeed. In fact, the Right Thing turns out to be CommonName and Surname; my CommonName is "John Cowan" and my Surname is "Cowan". See the X.500 Person schema. -- 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 dent at highway1.com.au Thu Oct 22 00:17:39 1998 From: dent at highway1.com.au (Andy Dent) Date: Mon Jun 7 17:05:57 2004 Subject: DTD Question In-Reply-To: <199810212038.QAA06939@locke.ccil.org> References: <362CD9E0.78581DED@homeaccount.com> from "Jack Bolles" at Oct 20, 98 02:43:44 pm Message-ID: At 4:38 AM +0800 22/10/98, John Cowan wrote: >Jack Bolles scripsit: > >> Also, aren't positional names (first, last) too presentational Agreed >Indeed. In fact, the Right Thing turns out to be CommonName and Surname; >my CommonName is "John Cowan" and my Surname is "Cowan". What about alternate names? Many Chinese have a 'Western CommonName' but would still write their formal name as something like WONG Jing Ping and be known as Alan in conversation and casual reference. Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.highway1.com.au/adsoftware/crossplatform.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 ffarahbo at informix.com Thu Oct 22 02:11:08 1998 From: ffarahbo at informix.com (Farzad Farahbod) Date: Mon Jun 7 17:05:57 2004 Subject: No subject Message-ID: <199810220009.RAA25563@olympus.oak.informix.com> Hi, Can someone point me to a (free) stock quote site that supports xml? Thanks xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gouders at spp.hpc.fujitsu.co.jp Thu Oct 22 02:45:26 1998 From: gouders at spp.hpc.fujitsu.co.jp (Dirk GOUDERS) Date: Mon Jun 7 17:05:58 2004 Subject: No subject In-Reply-To: Your message of "Wed, 21 Oct 1998 10:57:17 -0400." Message-ID: <199810220045.JAA13006@snuffy.spp.hpc.fujitsu.co.jp> I noticed that in message , vaiyapuri_subrama nian@rmic.com wrote: > Hello all, > > I just wrote an application which creates XML file from the table. All you > hava to do is to to give the table name and it will generate the XML. My > Question, i just wanted to know, whether the XML generated is correct. If > there is any mistake, please do bear with me and any corrections and help is > welcome. I don't understand the tool you built, at all, but why don't you use one of the several available XML parsers to check if the generated documents are XML documents? Some people already spent some effort to build such tools. Please let me know if you don't know where to get them. 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 james_grimm at credence.com Thu Oct 22 03:21:55 1998 From: james_grimm at credence.com (James Grimm) Date: Mon Jun 7 17:05:58 2004 Subject: DTD for DTD's Message-ID: <362E8897.99969E9C@credence.com> In Neil Bradley's _The XML Companion_, he does a "Case Study" of a DTD for DTD's (pages 174-179). Anybody played with this idea? I would love to find/write XSL stylesheets for this DTD to generate 1) a DTD, and 2) BNF. I document most of my language design using BNF, and I am getting tired of essentially retyping the same information into a DTD and BNF documentation. (Perhaps I should just make people read the source?) -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 james_grimm at credence.com Thu Oct 22 03:40:31 1998 From: james_grimm at credence.com (James Grimm) Date: Mon Jun 7 17:05:58 2004 Subject: DTD for DTD's References: <362E8897.99969E9C@credence.com> Message-ID: <362E8CE4.E4134FB9@credence.com> Please ignore my previous message. Curt Arnold pointed out that two efforts exist for handling my problem: XSchema and DCD. (And this is *not* a request for appraisals of those two.) So, my question was a simple RTFM. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Oct 22 08:12:11 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:05:58 2004 Subject: DTD Question In-Reply-To: <199810212038.QAA06939@locke.ccil.org> Message-ID: <000a01bdfd83$1a373250$93e887cb@NT.JELLIFFE.COM.AU> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > John Cowan > Indeed. In fact, the Right Thing turns out to be CommonName and Surname; > my CommonName is "John Cowan" and my Surname is "Cowan". See the > X.500 Person schema. That is probably as good a system as any: trying to break names down into parts that have international usefulness is a mug's game. Here in Taiwan they use name-of-family (comes first) and then name-in-family, but people very commonly adopt a Western name. I had a Japanese friend who had 6 different aliases he used in different contexts (including "Cindy" as in Cindy Crawford, which was a little perplexing). In some South-East Asian countries sometimes people only have one name, and dont use name-of-family. And, of course, in North Europe in times past people derived their surname from their father's name or their location: probably that still goes on somewhere in the world. In the West, women often retain their maiden names for work. Westerners with unhyphenated double-barrelled names often only use one (e.g. Mr John Price Pontifex might always use Mr John Price except in official documents). So the idea of just allowing ... Rick Jelliffe Jelliffe Rick Jelliffe, Richard Alan The King of Bubble and Skank Papa Shakey Brunopoly Jeff Jolly Lick Jellyfish Rick, Jelly Furry I think this example also demonstrates the difference between a DTD and a schema. The DTD mainly gives information related to markup parsing and moving constants into a header (e.g. internal entities, FIXED and default attribute values): in particular, for XML the information it gives is that the type attribute should be interpreted as a list of tokens. The comment allows interesting parts of the schema to be written down. But there may always constraints such as "every person must have an official name beginning with J and be sorted in alphabetical order" which are not expressible by DTDs, and could only be expressed in a schema language which has access to the DOM (e.g. using XLL) and can pattern match and can save values: in other words, a fairly general purpose expression language. In fact, I doubt that the idea of "a schema" for a document is the way to go. It seems to me that every different use of a document might require some schema optimized for that use. Data entry requires lexical validation schema (e.g. to make sure a date is in a particular format). Text processing requires another (e.g. that the document is valid against a DTD so that all required elements are found and in the expected positions, or that the data has been sorted). Data delivery might require another (e.g. that the "html:alt" attribute value for an image is generated in the language of the recipient, or that the bounding box of an image is not greater than the column width it has to fit into). Perhaps these can fit into "data typing", "document typing" and "publication typing", where DCD, DTD and XSL can fit the bills. Too early to say. 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 M.H.Kay at eng.icl.co.uk Thu Oct 22 11:18:39 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:05:58 2004 Subject: HTML Rendition of New Testament Message-ID: <003b01bdfd9c$51db6460$7008e391@bra01wmhkay.bra01.icl.co.uk> FYI: I have produced an HTML rendition of Jon Bosak's XML New Testament text, which I have placed on some borrowed webspace at http://www.wokchorsoc.freeserve.co.uk/bible-nt/index.html (It's a good read, by the way). This was produced using a SAXON application, about 200 lines of java, which you can find at http://home.iclweb.com/icl2/mhkay/RenderBible.java.txt I intend to include this as a sample application in the next SAXON release. The program will also render the Old Testament, but if you want to see the result you will have to run it yourself. The source XML is Jon Bosak's rel200 package which is available at http://sunsite.unc.edu/pub/sun-info/xml/eg/rel200.zip though I got a faster download from the mirror site at http://doc.ic.ac.uk Some observations: * Rendering the text once and putting the generated HTML on the web server seems the right architectural approach in this case. As a very minimum, breaking up the XML into page-sized chunks seems essential. * I don't see any support in XSL for generating a hyperdocument of this kind. Is this on the agenda? * Although I've written 200 lines of code, there's very little procedural logic. Only 4 elements require any custom logic, and with a few more primitives these could be done declaratively as well. If I ever have time, I think it's quite feasible to generate this SAXON application from a sufficiently expressive stylesheet language. * Anyone else want to volunteer alternative approaches to achieving the same effect, so we can compare? * Thanks to Jon Bosak for making the text available, I hope what I have done is within the spirit of your intended use. Sorry I didn't have space to mount all four texts, so I chose the one I am most at home with. Regards, Mike Kay, ICL xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Oct 22 11:47:02 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:05:58 2004 Subject: HTML Rendition of New Testament Message-ID: <003b01bdfda0$90731de0$2c6167cb@ntwork.harvestroad.com.au> -----Original Message----- From: Michael Kay >I have produced an HTML rendition of Jon Bosak's XML New Testament text, >which I have placed on some borrowed webspace at >http://www.wokchorsoc.freeserve.co.uk/bible-nt/index.html (It's a good read, >by the way). Wonderful. Hopefully, it will soon be complemented by something I'm working on: the Greek New Testament. Hmmm, I smell parallel corpora. [...] >* I don't see any support in XSL for generating a hyperdocument of this >kind. Is this on the agenda? I would imagine XSL will eventually let you generate multiple scroll objects so you'll be able to do this. I've already put in a request that a tree control formatting object be included for this sort of application. I'm doing some research into the whole question of separation of web content from navigation systems. It would be nice if it were achievable in a standard declarative way. >* Anyone else want to volunteer alternative approaches to achieving the same >effect, so we can compare? I'll see how I go with the GNT. 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 amitr at abinfosys.com Thu Oct 22 14:29:22 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:58 2004 Subject: Regarding XSchema element Message-ID: <02a201bdfdb7$43a0dc20$0101a8c0@server.abinfosys.com> Hello, The XSchema DTD suggests that I could very well have a element within the root element. In this case how would I associate the with it's ? For eg. :- From amitr at abinfosys.com Thu Oct 22 14:31:04 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:05:58 2004 Subject: About URI,URN,URL and FPIs Message-ID: <028c01bdfdb2$709ee730$0101a8c0@server.abinfosys.com> Hello, After having gone through the URI specs at the w3c site I wanted to confirm a few doubts. I'd be grateful if anyone would kindly help. DOUBT 1 :- URNs at this point are not widely used since there is no generally available resolution service. In case a resolution infrastructure comes up in time :- * Where would the service reside(client/server)? * Would the server simply serve all the docs that contain FPIs to the client or would it resolve the FPIs to system IDs before serving the docs to the client or would it "selectively" serve files depending upon the FPIs it can resolve? * Would the client in anyway be involved in resolving the FPI -> Sys ID? DOUBT 2 :- URN simply stated refers to a globally unique, persistent name from a NameSpace. This name could be used to provide a label to resources. * Could a URN also label a resource which may not necessarily be residing on the web? ( I could label a resource with a URN ,and the resource could very well be a set of paper documents! This could happen in a scenario where 2 parties provide a paper resource with a URN and transmit only the URN in their XML files to each other. The resource could be transmitted on paper since it is a set of paper documents ) DOUBT 3 :- Talking in terms of URI, if a URI is not a URLthen it HAS to be a URN and vice versa. Am I right? DOUBT 4:- In HTML, I am allowed to include . * How should browsers parse the HTML FPI, do they leave it untouched? * I feel the HTML FPI is resolved that is HTML FPI -> local path of the HTML DTD, is done within the browser. Am I right? * If the above is true then each HTML browser will store a local copy of the HTML DTD which it will use to validate the HTML instance against. Is this correct? Thanks in advance for any answers , 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 rbourret at ito.tu-darmstadt.de Thu Oct 22 14:44:08 1998 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:05:58 2004 Subject: Regarding XSchema element Message-ID: <01BDFDC9.D4AB1E80@grappa.ito.tu-darmstadt.de> Amit Rekhi wrote: > The XSchema DTD suggests that I could very well have a > element within the root element. In this case how would I > associate the with it's ? At this point in time, you can't. The same is true when AttDef/AttGroup elements that do not have an Element attribute and Enumeration elements are placed directly under the XSchema element. The purpose of such elements under XSchema is to allow an XSchema element to act as a container of free-floating definitions. These can then be reused, using a mechanism we hope to specify later (probably XLinks). For more information, see sections 5.2.4 and 5.2.6. -- 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 tallen at sonic.net Thu Oct 22 15:56:13 1998 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 17:05:58 2004 Subject: re URN, URL, URI Message-ID: <199810221355.GAA10956@bolt.sonic.net> Amit Rekhi wrote: | Hello, | After having gone through the URI specs at the w3c site I wanted | to confirm a few doubts. I'd be grateful if anyone would kindly help. Assuming these are the current versions of the specifications from the IETF, where the URN work is done: | DOUBT 1 :- URNs at this point are not widely used since there is no | generally available resolution service. In case a resolution infrastructure | comes up in time :- There is a generally available resolution mechanism, through DNS, but it has not implemented except on a test basis so far as I know. URNs, of course, may be useful within more constrained contexts. Note that URN resolution won't happen for you without some effort on your part. | * Where would the service reside(client/server)? You would want to have resolution hints on the client end, and be able to check your cache for documents you already have; otherwise consult RFC 2168 for the DNS approach. | * Would the server simply serve all the docs that contain FPIs to the client | or would it resolve the FPIs to system IDs before serving the docs to the | client or would it "selectively" serve files depending upon the FPIs it can | resolve? A URN resolution service will only resolve URNs. It might be coupled with a document server, but that's another matter. RFC 2168 indicates the possible services that could be specified (N2N, N2L), but there is no requirement that a resolution services support any particular one of them, I believe. An FPI as it stands is not a URN, but were an FPI name space defined for URN use, FPIs can be escaped and encoded as URNs. | * Would the client in anyway be involved in resolving the FPI -> Sys ID? If the URN resolution service returns a URL, presumably you'd want the client to resolve the URL. | DOUBT 2 :- URN simply stated refers to a globally unique, persistent name | from a NameSpace. This name could be used to provide a label to resources. | | * Could a URN also label a resource which may not necessarily be residing on | the web? | ( I could label a resource with a URN ,and the resource could very well be a | set of paper documents! | This could happen in a scenario where 2 parties provide a paper resource | with a URN and transmit only the URN in their XML files to each other. The | resource could be transmitted on paper since it is a set of paper | documents ) Yes. This is not a bug. | DOUBT 3 :- Talking in terms of URI, if a URI is not a URLthen it HAS to be a | URN and vice versa. Am I right? At this point, yes. URCs were talked about, but those interested in URCs are now mostly doing RDF. regards, Terry Allen Terry Allen Veo Systems, Inc. Business Language Designer 2440 W. El Camino Real tallen[at]sonic.net Mountain View, Calif., 94040 Common Business Library - available at http://www.veosystems.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Thu Oct 22 17:16:39 1998 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:05:59 2004 Subject: re URN, URL, URI In-Reply-To: <199810221355.GAA10956@bolt.sonic.net> Message-ID: <3.0.5.32.19981022100951.008eba30@amati.techno.com> At 06:55 AM 10/22/98 -0700, Terry Allen wrote: >| DOUBT 1 :- URNs at this point are not widely used since there is no >| generally available resolution service. In case a resolution infrastructure >| comes up in time :- > >There is a generally available resolution mechanism, through DNS, but >it has not implemented except on a test basis so far as I know. URNs, >of course, may be useful within more constrained contexts. Note that >URN resolution won't happen for you without some effort on your part. In thinking about URN resolution and how it might work in practice, my conclusion is that if, for example, the DNS-based approach were implemented in generally-available places, then as part of your client configuration you would define what URN-resolution servers you want to use, just as you define DNS servers when you configure your IP network set up. Your client would then use these servers to determine what server or servers handle a particular URN name space. The browser would also have to know now to communicate with resolvers for particular URN name spaces, but this could be handled through simple plug-ins. For example, say I set up a URN namespace resolver on drmacro.com and an FPI resolution server on planetsizedbrains.com. A typical URN resolution session might go something like this: 1. On your client, declare "urnres.drmacro.com" as your URN namespace resolver 2. Your browser sees a URI like: "urn:fpi:+//IDN%20me.com//DOCUMENT%20mydoc//EN" and tries to resolve it to a resource. 3. Your client sees that the URI is in fact a URN (as indicated by the "urn:" prefix). It looks in its own configuration tables to see if any URN namespace resolvers are defined. It finds urnres.drmacro.com. 4. It sends the URN to urnres.drmacro.com using the DNS extensions outlined in RFC 2168. The URN namespace resolver looks up the namespace name "fpi" in its table and finds "fpires.planetsizedbrains.com". It returns this location to the client [at this point I'm not sure if the client or the URN resolver does the next part, but I think the intent is for clients to at least expect to be able to handle this part.] 5. The client sends the FPI to fpires.planetsizedbrains.com, using whatever protocol the resolver uses (but not HTTP). The FPI resolver looks up the FPI in its table and returns the URL of the resource to the client, assuming it finds it. 6. The client uses normal HTTP communication to attempt to resolve the returned URL to a resource. If I understand the URN mechanism, each URN namespace is responsible for defining the protocol for how resolution is done, i.e., the functional equivalent of HTTP. If I understand how these things are generally done, you would expect to define a socket-based service on some conventional port [but I'm really out of my depth at this point]. Viewed this way, it doesn't seem like it should be that big a deal to set up useful URN resolvers and services for resolving specific URN name spaces. The biggest barrier seems to be support on the client side for handling URNs to begin with. As various URN name spaces became more widely used and conventions develop, browsers would come with more built-in configurations for different name spaces, relieving users of the need to do the configuration themselves. I would expect browsers to provide a plug-in architecture for adding support for specific URN name spaces--how hard can it be? Am I totally off my nut here? Have I missed some critical detail that makes URN resolution harder than it appears to be by this analysis? I can't speak for Oasis, but it has already started exploring providing a Web-based FPI resolver--seems like there might be some resources there that could fund developing extensions to say Mozilla and a DNS server to provide the client/server binding you need for full URN resolution. It can't represent more than a week of programming time for someone who knows what they're doing (Joe Alfonso, where are you?). Note that in the case of pure FPIs in an XML context, the same infrastructure described above could still be used. The client would know that anything that is a public identifier that starts with "ISO", "+//" or "-//" is a public identifier and can use the same mechanism to look up the resolver for FPIs (assuming that a URN name space for FPIs has been registered or defined by convention). Or they might provide a mechanism for configuring FPI resolver services directly. 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 jbolles at homeaccount.com Thu Oct 22 17:52:31 1998 From: jbolles at homeaccount.com (Jack Bolles) Date: Mon Jun 7 17:05:59 2004 Subject: DTD Question References: <199810212038.QAA06939@locke.ccil.org> Message-ID: <362F551E.5CE04B7E@homeaccount.com> I think we are examining the bark on the trees and not seeing the forest. How you define the NAME element is up to you, depending on your needs. The point was to use a naming convention that meaningfully describes the data being encapsulated, rather than to describe aspects of their presentation. The last point in my original post was that it may be a good idea to have a utility NAME.dtd that the main dtd references for desribing names so that how a NAME is defined in a given instance can be changed to an appropriate model depending on the needs at the time. Jack --------------------------------------------------------------------- Jack Bolles Software Engineer http://users.homeaccount.com/~jbolles/CV.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 jmcdonou at library.berkeley.edu Thu Oct 22 17:57:41 1998 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:05:59 2004 Subject: re URN, URL, URI In-Reply-To: <199810221355.GAA10956@bolt.sonic.net> Message-ID: <3.0.5.32.19981022084813.010930b0@library.berkeley.edu> At 06:55 AM 10/22/98 -0700, Terry Allen wrote: >There is a generally available resolution mechanism, through DNS, but >it has not implemented except on a test basis so far as I know. URNs, >of course, may be useful within more constrained contexts. Note that >URN resolution won't happen for you without some effort on your part. > >| * Where would the service reside(client/server)? > >You would want to have resolution hints on the client end, and be >able to check your cache for documents you already have; otherwise >consult RFC 2168 for the DNS approach. > Just a further note on this resolution architecture issue: there appears to be a growing interest in an architecture in which a proxy sits between clients and DNS, in order to resolve certain URNs within a local context rather than the global one specified by DNS NAPTR records. Example: You're running a library, and have a client within the library trying to resolve an ISBN for a book that you hold in electronic format. The client contacts a resolution proxy that you run. The proxy first checks to see if the work is held locally, and if so, returns the URL for that copy. If there's no local copy, then the proxy contacts DNS for a NAPTR record for the official URN resolver(s) for the URN's namespace. Ron Daniel and Mike Mealling also developed this on an experimental basis in the work that Terry mentioned at Los Alamos, using Apache for the proxy services. Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......) Library Systems Office, 386 Doe, U.C. Berkeley | \ * * / Berkeley, CA 94720-6000 (510) 643-2058 | \ <> / "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 tallen at sonic.net Thu Oct 22 18:06:05 1998 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 17:05:59 2004 Subject: re URN, URL, URI etc. Message-ID: <199810221604.JAA14258@bolt.sonic.net> Eliot wrote: | >| DOUBT 1 :- URNs at this point are not widely used since there is no | >| generally available resolution service. In case a resolution infrastructure | >| comes up in time :- | > | >There is a generally available resolution mechanism, through DNS, but | >it has not implemented except on a test basis so far as I know. URNs, | >of course, may be useful within more constrained contexts. Note that | >URN resolution won't happen for you without some effort on your part. | | In thinking about URN resolution and how it might work in practice, my | conclusion is that if, for example, the DNS-based approach were implemented | in generally-available places, then as part of your client configuration | you would define what URN-resolution servers you want to use, just as you | define DNS servers when you configure your IP network set up. Your client Yes. and (in the long run) you might want to use different resolution services for different URN name spaces, as you determine what works best for you in practice. | would then use these servers to determine what server or servers handle a | particular URN name space. The browser would also have to know now to | communicate with resolvers for particular URN name spaces, but this could | be handled through simple plug-ins. | | For example, say I set up a URN namespace resolver on drmacro.com and an | FPI resolution server on planetsizedbrains.com. A typical URN resolution | session might go something like this: | | 1. On your client, declare "urnres.drmacro.com" as your URN namespace resolver for FPI URNs. | 2. Your browser sees a URI like: | "urn:fpi:+//IDN%20me.com//DOCUMENT%20mydoc//EN" and tries to resolve it to | a resource. (I think it would be more like urn:iso:stds:fpi ... and I think you have to escape the slashes, too, which makes ISO 9070 identifiers more attractive, but that's beside the point.) | 3. Your client sees that the URI is in fact a URN (as indicated by the | "urn:" prefix). It looks in its own configuration tables to see if any URN | namespace resolvers are defined. It finds urnres.drmacro.com. Yes. Although first it may consult your local (cache) resolution service (entity manager!) to see if you already have a copy. | 4. It sends the URN to urnres.drmacro.com using the DNS extensions outlined | in RFC 2168. The URN namespace resolver looks up the namespace name "fpi" | in its table and finds "fpires.planetsizedbrains.com". It returns this | location to the client [at this point I'm not sure if the client or the URN | resolver does the next part, but I think the intent is for clients to at | least expect to be able to handle this part.] | | 5. The client sends the FPI to fpires.planetsizedbrains.com, using whatever | protocol the resolver uses (but not HTTP). The FPI resolver looks up the The client already knows the FPI (assuming it can deencode it from the URN). I would think it would send the URN instead. | FPI in its table and returns the URL of the resource to the client, | assuming it finds it. I would think the resolver looks up the URN and returns the URL. | 6. The client uses normal HTTP communication to attempt to resolve the | returned URL to a resource. Yes. | If I understand the URN mechanism, each URN namespace is responsible for | defining the protocol for how resolution is done, i.e., the functional | equivalent of HTTP. If I understand how these things are generally done, | you would expect to define a socket-based service on some conventional port | [but I'm really out of my depth at this point]. The relevant document, "URN Namespace Definition Mechanisms", ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-nid-req-06.txt, is, I'm happy to say, in Last Call and apparently ready to become an RFC. When you register a URN name space, you're supposed to answer some questions, including in relevant part Process for identifier resolution: If a namespace is intended to be accessible for global resolution, it must be registerd in an RDS (Resolution Discovery System, see [RFC2276]) such as NAPTR. Resolution then proceeds according to standard URI resolution processes, and the mechanisms of the RDS. What this section should outline is the requirements for becoming a recognized resolver of URNs in this namespace (and being so-listed in the RDS registry). Answers may include, but are not limited to: . the namespace is not listed with an RDS; this is not relevant . resolution mirroring is completely open, with a mechanism for updating an appropriate RDS . resolution is controlled by entities to which assignment has been delegated so Eliot's summary is correct. Note that this doesn't preclude you (or anyone else) from providing other mechanisms of resolution. In the case of FPIs, were ISO to register a name space form them, it would presumably either set up the resolution service itself, delegate it to so responsible and capable organization such as GCA ..., or delegate resolution of parts of the FPI name space to the owners of the relevant FPIs. Or some combination. | Viewed this way, it doesn't seem like it should be that big a deal to set | up useful URN resolvers and services for resolving specific URN name | spaces. The biggest barrier seems to be support on the client side for | handling URNs to begin with. As various URN name spaces became more widely | used and conventions develop, browsers would come with more built-in | configurations for different name spaces, relieving users of the need to do | the configuration themselves. I would expect browsers to provide a plug-in | architecture for adding support for specific URN name spaces--how hard can | it be? I would think not too hard. | Am I totally off my nut here? Have I missed some critical detail that makes | URN resolution harder than it appears to be by this analysis? Nope. Note this wrinkle: in some contexts you don't have to resolve the URNs over the Internet at all. For example, for CBL my socat looks like this: -- SGML Open catalog for CBL Version 1.1 -- -- Terry Allen 9 September 1998 -- -- Copyright 1998 Veo Systems, Inc. -- SYSTEM "urn:x-veosystems:dtd:cbl:1.1:catalog:1.0" "catalog.dtd" SYSTEM "urn:x-veosystems:dtd:cbl:1.1:catentry:1.0" "catentry.dtd" SYSTEM "urn:x-veosystems:dtd:cbl:1.1:irequest:1.0" "irequest.dtd" (I had expected to use PUBLIC for the URNs, but nsgmls doesn't work that way, for reasons I have not investigated.) Thanks for studying the issue, Eliot! regards, Terry 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 cowan at locke.ccil.org Thu Oct 22 19:28:43 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:59 2004 Subject: Personal Names (was: DTD Question) References: <362CD9E0.78581DED@homeaccount.com> from "Jack Bolles" at Oct 20, 98 02:43:44 pm Message-ID: <362F6B2E.A6F27C44@locke.ccil.org> Andy Dent asked: > >Indeed. In fact, the Right Thing turns out to be CommonName and Surname; > >my CommonName is "John Cowan" and my Surname is "Cowan". > What about alternate names? > > Many Chinese have a 'Western CommonName' but would still write their formal > name as something like WONG Jing Ping and be known as Alan in conversation > and casual reference. In X.500 Person, both surname and commonName can be multiple-valued. Thus: commonName: Wong Jing Ping commonName: Jing-Ping Wong commonName: Alan Wong commonName: \uxxxx\uxxxx\uxxxx surname: Wong surname: \uxxxx -- 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 Oct 22 19:45:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:59 2004 Subject: Personal Names (was: DTD Question) References: <000a01bdfd83$1a373250$93e887cb@NT.JELLIFFE.COM.AU> Message-ID: <362F6F14.6D64B880@locke.ccil.org> Rick Jelliffe wrote: > In some South-East Asian > countries sometimes people only have one name, and don't use > name-of-family. _The New York Times_ is notoriously fanatical about attaching English-language titles to names however inappropriately. This produces such weirdness as "Mr. Suharto" for "Suharto" (one name, no family name) and "Mr. Oddsson" for "David Oddsson" (personal name and patronymic, no family name either), to mention only heads of state. > So the idea of just allowing > > > > Sequencing (i.e. alphabetizing in alphabetic languages) is so important that it's essential to carry around a sort key, which is what the "surname" attribute(s) represent. > The King of Bubble and Skank As opposed to Bubble and Squeak? > Jeff Jolly > Lick Jellyfish > Rick, Jelly Furry Excellent! > In fact, I doubt that the idea of "a schema" for a document is the way to > go. It seems to me that every different use of a document might require some > schema optimized for that use. Sounds like architectural forms to me! (Tell me again why we are obsessively reinventing the wheel?) -- 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 Oct 22 19:58:58 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:05:59 2004 Subject: About URI,URN,URL and FPIs References: <028c01bdfdb2$709ee730$0101a8c0@server.abinfosys.com> Message-ID: <362F7240.745F08C3@locke.ccil.org> Amit Rekhi wrote: > * Where would the [FPI resolution] service reside(client/server)? Probably some of each, like the DNS, but maybe not. My SocatResolver has nothing on the server except the actual catalog files, so it can use HTTP or FTP or whatever to fetch them by URL (= system id). > * Would the server simply serve all the docs that contain FPIs to the client > or would it resolve the FPIs to system IDs before serving the docs to the > client or would it "selectively" serve files depending upon the FPIs it can > resolve? Who can tell? I think providing FPI to URL mapping is the important thing, and the others are essentially optimization hacks. > * Could a URN also label a resource which may not necessarily be residing on > the web? > ( I could label a resource with a URN ,and the resource could very well be a > set of paper documents! Just so. Although it isn't official, *everybody* thinks that ISBNs and ISSNs are a paradigm case of URNs. > DOUBT 3 :- Talking in terms of URI, if a URI is not a URLthen it HAS to be a > URN and vice versa. Am I right? Almost. Theoretically there is something called an URC, which is a piece of metadata about a resource. But nobody has ever seen one. In practice works fine. > DOUBT 4:- In HTML, I am allowed to include HTML FPI .......">. For "SYSTEM" read "PUBLIC". > * How should browsers parse the HTML FPI, do they leave it untouched? Usually they ignore it. Non-browser tools sometimes check it for one of a number of known values such as "-//IETF//HTML 2.0" or "-//W3C//HTML 3.2" or "-//W3C//HTML 4.0". > * If the above is true then each HTML browser will store a local copy of > the HTML DTD which it will use to validate the HTML instance against. Is > this correct? AFAIK no existing browser validates any document. They have hard-wired knowledge of some variant of the HTML DTD, not necessarily or typically a standard one. -- 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 Oct 22 20:00:54 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:06:00 2004 Subject: Regarding XSchema element References: <02a201bdfdb7$43a0dc20$0101a8c0@server.abinfosys.com> Message-ID: <362F7272.E2D981B3@locke.ccil.org> Amit Rekhi wrote: > The XSchema DTD suggests that I could very well have a > element within the root element. In this case how would I > associate the with it's ? In the XSchema 1.0 standalone Models are not useful. They exist for future versions of XSchema to allow reuse. -- 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 Oct 22 20:05:11 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:06:00 2004 Subject: re URN, URL, URI References: <199810221355.GAA10956@bolt.sonic.net> Message-ID: <362F7383.E983AE81@locke.ccil.org> Terry Allen wrote: > There is a generally available resolution mechanism, through DNS, but > it has not implemented except on a test basis so far as I know. Furthermore, it is specified by an Experimental (non-standards-track) RFC IIRC. -- 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 Oct 22 21:15:23 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:06:00 2004 Subject: X.500 (was: DTD Question) References: <199810212038.QAA06939@locke.ccil.org> <362F83A1.A243EA18@mecomnet.de> Message-ID: <362F842E.BEBB033F@locke.ccil.org> In a private mail I was asked for references on the X.500 schema. The best short introduction I know is by Paul Barker at UCL: http://homes.ukoln.ac.uk/~lisap/ccsap/Directory/Docs/prep.html . RFC 1274 (http://www.isi.edu/in-notes/rfc1274.txt) gives the whole deal for all the various ISO, Quipu, and Pilot object classes. Note that "classes" in X.500 are more like Java interfaces: they allow multiple inheritance, and an entry can belong to more than one class. Attributes are multiple-valued, can be mandatory (not null) or optional (may be null). "Attribute types" are essentially like Notations; they specify the classes to which (immutable) values like names, numbers, etc. belong. Finally, RFC 2256 (http://www.isi.edu/in-notes/rfc2256.txt) gives attribute-by-attribute guidance on meaning and usage for ISO object classes. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matt at veosystems.com Fri Oct 23 02:07:31 1998 From: matt at veosystems.com (matt@veosystems.com) Date: Mon Jun 7 17:06:00 2004 Subject: DTD for DTD's In-Reply-To: <362E8CE4.E4134FB9@credence.com> from "James Grimm" at Oct 21, 98 06:39:48 pm Message-ID: <19981023000653.7442.qmail@veosystems.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 738 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981023/23b42392/attachment.bat From Jon.Bosak at eng.Sun.COM Fri Oct 23 04:06:16 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:06:00 2004 Subject: WWW8 Call for Papers Message-ID: <199810230202.TAA20280@boethius.eng.sun.com> The organizers of the WWW8 Conference have asked me to bring this call for papers to the attention of the XML community. Jon ======================================================================== WWW8 - Eighth International Conference on the World Wide Web Toronto, May 11-14, 1999 CALL FOR PAPERS Web Site: http://www8.org Paper Submission Web Site: http://witanweb.iit.nrc.ca/www8/ Paper submission deadline: November 23, 1998 Author notification: February 1, 1999 Paper final version due: March 1, 1999 Conference: May 11-14, 1999 The WWW8 Conference, sponsored by the International World Wide Web Conference Committee (IW3C2) and managed by Foretec Seminars, will consist of refereed technical papers, tutorials, workshops, posters, a W3C track, and a Developer's Day track. Technical papers present original reports of substantive new work in areas that can be theoretical (models, analysis techniques, semantics), empirical (experiments, case studies), or implementation-oriented (new systems, tools, methodologies, user interfaces). Papers should properly place the work within the field, cite related work, and clearly indicate the innovative aspects of the work and its contribution to the development of the WWW. Papers will be refereed by an international Program Committee. The following is a non-exhaustive list of topics of interest: WWW Performance - Caching - Replication - Fault tolerance - Performance monitoring - Benchmarking - Multimedia delivery - Networking issues Browsers and Tools - Browsers - Authoring tools - Web site management tools - Application development tools - Programming languages Hypertext and Hypermedia - Metadata: XML/XSL, RDF, ... - Designing documents and sites - Hyperdocument visualization - Navigation techniques - Web models User Interfaces - Novel interfaces - Multimedia interfaces - Interfaces for hand-held/mobile devices - Virtual Reality on the Web - Support for collaborative work - Accessibility issues Searching, Querying, and Indexing - Information retrieval on the web - Query mechanisms - Web/database system interactions Electronic Commerce and Security - Web transactions - Charging and payment protocols - Security To submit a paper, go to http://witanweb.iit.nrc.ca/www8/. Paper format: Papers should be no longer than 20 pages, with the main body set in a 12-point font. We will accept papers in HTML (browsable by any of the commonly used browsers), PostScript, or PDF formats. A note on accessibility issues: Whenever appropriate, authors are encouraged to comment on accessibility as it relates to their paper. Are the technologies, standards or practices you are discussing accessible to individuals who use alternative display or control systems (e.g., people who have disabilities)? For more information see URL: www.w3.org/WAI. If you wish to be placed on the WWW8 announcements mailing list, please send an e-mail message to info@www8.org +Conference Co-Chairs: Albert Vezza, CNRI Robert Cailliau, CERN Murray Maloney, Muzmo Communication Inc. +Program Committee Chair: Alberto Mendelzon, U. of Toronto, mendelzon@db.toronto.edu +Program Committee Vice-chairs: User Interfaces Ron Baecker, Mark Chignell, U. of Toronto WWW Performance Fred Douglis, AT&T Labs Searching, Querying, and Indexing Oren Etzioni, U. of Washington Browsers and Tools Hannes Marais, Compaq SRC Electronic Commerce and Security Doug Tygar, UC Berkeley Hypertext/Hypermedia Anne-Marie Vercoustre, INRIA +Tutorials Chair: Richard Binder, Foretec Seminars +Workshops Co-Chairs: Benay Dara-Abrams, Sholink Corporation Richard Binder, Foretec Seminars +Developer's Day Program Chair: Ian Graham, U. of Toronto +Posters Chair: Charles Clarke, U. of Toronto +Panels Co-Chairs: Michael Bieber, NJIT Carolyn Watters, Dalhousie Univ. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 23 09:27:04 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:06:00 2004 Subject: NS processing (was Re:URN, URL, URI) Message-ID: <001501bdfe4e$f8682180$0101a8c0@server.abinfosys.com> Eliot, >For example, say I set up a URN namespace resolver on drmacro.com and an >FPI resolution server on planetsizedbrains.com. A typical URN resolution >session might go something like this: [..... a series of points.......] Your "point wise description" of URN processing helped me understand how XML NSs might be processed. (Thanks). I just wanted to confirm whether what I think of NS processing is correct or not. I am new to the world of NSs, so in case my ques. is very basic, I'm sorry :-) If I have an XML file say :- From M.H.Kay at eng.icl.co.uk Fri Oct 23 11:07:06 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:00 2004 Subject: Architectural Forms (was Personal Names (was: DTD Question)) Message-ID: <000c01bdfe60$3e5008f0$7008e391@bra01wmhkay.bra01.icl.co.uk> >Sounds like architectural forms to me! (Tell me again why we are >obsessively reinventing the wheel?) Probably because architectural forms have been marketed so badly. A bit as if the inventor of the wheel had called it ... tries to think of a totally unhelpful and off-putting name ... an architectural form, perhaps? 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 dog at dog.net.uk Fri Oct 23 11:53:49 1998 From: dog at dog.net.uk (dog) Date: Mon Jun 7 17:06:00 2004 Subject: datatype specification (urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882/) Message-ID: <19981023104920.A8182@dog.net.uk> hiya i'm trying to find out more about the datatype urn and whether/how it can be applied in dtds (and if so, what degree of control over the typing it provides), or whether you need to use an xml schema mechanism (such as xml-data or xschema) to implement strong typing of xml elements. i've looked through all the documentation at w3c and a fair bit of other stuff, and although there are references to urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882/ there doesn't appear to be a definition of it anywhere, or any discussion of its usage. if anyone could provide any pointers i'd be most grateful. -- dog xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From grove at infotek.no Fri Oct 23 12:49:58 1998 From: grove at infotek.no (Geir Ove Gronmo) Date: Mon Jun 7 17:06:00 2004 Subject: Architectural Forms (was Personal Names (was: DTD Question)) In-Reply-To: <000c01bdfe60$3e5008f0$7008e391@bra01wmhkay.bra01.icl.co.uk > Message-ID: <3.0.6.32.19981023124847.00904100@post.step.de> At 09:36 23.10.98 +0100, Michael Kay wrote: >>Sounds like architectural forms to me! (Tell me again why we are >>obsessively reinventing the wheel?) > >Probably because architectural forms have been marketed so badly. A bit as >if the inventor of the wheel had called it ... tries to think of a totally >unhelpful and off-putting name ... an architectural form, perhaps? The irony is that the concept of architectual forms is very simple. The problem is more that there is not really any easily accessible information about it. What the world needs is tutorials, howtos and practical examples. Geir O. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 23 13:24:21 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:06:00 2004 Subject: Architectural Forms (was Personal Names (was: DTD Question)) Message-ID: <000701bdfe76$d7441040$0300000a@othniel.cygnus.uwa.edu.au> -----Original Message----- From: Geir Ove Gronmo >The irony is that the concept of architectual forms is very simple. The >problem is more that there is not really any easily accessible information >about it. What the world needs is tutorials, howtos and practical examples. Agree. We do, though, have David Megginson's excellent book and some good implementations, (SP, yours, etc) 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 nico at echange.fr Fri Oct 23 15:01:03 1998 From: nico at echange.fr (Nicolas MONNET) Date: Mon Jun 7 17:06:00 2004 Subject: Selective parsing of elements Message-ID: I want to parse select XML tags, and pass the remaining ones 'as-is'. Is there a way, or is there a certain parser, that will allow me to 'register', for example, the tags I'm interested in, and pass the rest as PCDATA? Is there anything wrong with this approach? I've looked at the SAXON library, but at first sight it's slightly overkill for my purpose. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Fri Oct 23 15:40:49 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:00 2004 Subject: Selective parsing of elements Message-ID: <002301bdfe8a$1938b290$7008e391@bra01wmhkay.bra01.icl.co.uk> >I want to parse select XML tags, and pass the remaining ones 'as-is'. Is >there a way, or is there a certain parser, that will allow me to >'register', for example, the tags I'm interested in, and pass the rest as >PCDATA? Is there anything wrong with this approach? > >I've looked at the SAXON library, but at first sight it's slightly >overkill for my purpose. Agreed, SAXON probably does a lot of things you don't need, but looking at it the other way, it also makes it very easy to do the thing you are asking for. I'm sorry if I've made it too complicated, that's one thing I was always trying to avoid, but creeping feature syndrome affects us all... 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 jgaffke at ou.edu Fri Oct 23 16:04:10 1998 From: jgaffke at ou.edu (Jonathan.D.Gaffke-1) Date: Mon Jun 7 17:06:00 2004 Subject: unsubscribe Message-ID: <36308CF4.26FF@ou.edu> somebody help, please! how do i get off this mailing list? (I didn't realize it was so active) reply to jgaffke@ou.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Fri Oct 23 16:17:33 1998 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:06:01 2004 Subject: Architectural Forms (was Personal Names (was: DTD Question)) In-Reply-To: <3.0.6.32.19981023124847.00904100@post.step.de> References: <000c01bdfe60$3e5008f0$7008e391@bra01wmhkay.bra01.icl.co.uk > Message-ID: <3.0.5.32.19981023091050.009466c0@amati.techno.com> At 12:48 PM 10/23/98 +0200, Geir Ove Gronmo wrote: >At 09:36 23.10.98 +0100, Michael Kay wrote: >>>Sounds like architectural forms to me! (Tell me again why we are >>>obsessively reinventing the wheel?) >> >>Probably because architectural forms have been marketed so badly. A bit as >>if the inventor of the wheel had called it ... tries to think of a totally >>unhelpful and off-putting name ... an architectural form, perhaps? > >The irony is that the concept of architectual forms is very simple. The >problem is more that there is not really any easily accessible information >about it. What the world needs is tutorials, howtos and practical examples. How about: , *A Tutorial Introduction to SGML Architectures* I can't disagree that the name is a poor one (the name was chosen before I got involved with the HyTime standard) and that the AFDR annex is not a very accessible document, for which I must take responsibility as the HyTime editor primarily responsible for managing the text. I hope the document above goes a little way towards undoing the damage. We (ISOGEN) also provide a one-day SGML Architectures course that we've taught at several conferences to what I think is reasonable success (everyone seemed to get the concepts). I think one of the problems with the architecture mechanism is that, like SGML, the basic idea is very simple but the simplicity is obscurred by the details of the mechanism, which is complicated by the need for automapping to make the use of architectures convenient for document authors. I think David Megginson's approach with architecture support on top of SAX does a good job of cutting down to the bare minimum you need to do something useful (however, there are some important things that you may need to do that you can't with David's implementation, in particular, multiple levels of architectural derivation). 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 M.H.Kay at eng.icl.co.uk Fri Oct 23 16:21:56 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:01 2004 Subject: X.500 (was: DTD Question) Message-ID: <004901bdfe8f$cd049550$7008e391@bra01wmhkay.bra01.icl.co.uk> >In a private mail I was asked for references on the X.500 schema. >The best short introduction I know is by Paul Barker at UCL: >http://homes.ukoln.ac.uk/~lisap/ccsap/Directory/Docs/prep.html . > There's quite a lot of information (oriented to ICL's i500 implementation) at http://www.iclsoft.com/ though I regret that it somehow manages to be both more commercial and more technical than you really want! Mike Kay, ICL xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RJA at dip.co.uk Fri Oct 23 16:24:19 1998 From: RJA at dip.co.uk (RJA@dip.co.uk) Date: Mon Jun 7 17:06:01 2004 Subject: Selective parsing of elements Message-ID: <802566A6.004E37C1.00@dip.co.uk> Richard J. Anderson@DI 10/23/98 03:23 PM >I want to parse select XML tags, and pass the remaining ones 'as-is'. Is >there a way, or is there a certain parser, that will allow me to >'register', for example, the tags I'm interested in, and pass the rest as >PCDATA? Is there anything wrong with this approach? Could you expand a little bit more on your requirements as its sounds quite like a project I'll working on. 1. Who are you passing the tags on to, another part of the your application ? 2. How do you want to locate the tags. eg. do you want the name tag within an person ala XSL ? 3. What langugue etc are you looking. Kind Regards, Richard Anderson *** This post is of a personal nature and does not in anyway represent the opinions or developments of Data Interchange Plc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mh97104 at glaxowellcome.com Fri Oct 23 17:08:47 1998 From: mh97104 at glaxowellcome.com (Hlordji, Michael) Date: Mon Jun 7 17:06:01 2004 Subject: Selective parsing of elements Message-ID: Hello, I'm thinking of doing a project in XML...where do I start from???. and what are some of the things I should be considering as part of the implementation?. > ---------- > From: RJA@dip.co.uk[SMTP:RJA@dip.co.uk] > Reply To: RJA@dip.co.uk > Sent: Friday, October 23, 1998 10:23 AM > To: xml-dev@ic.ac.uk > Subject: Re: Selective parsing of elements > > > > > > Richard J. Anderson@DI > 10/23/98 03:23 PM > > >I want to parse select XML tags, and pass the remaining ones 'as-is'. Is > >there a way, or is there a certain parser, that will allow me to > >'register', for example, the tags I'm interested in, and pass the rest as > >PCDATA? Is there anything wrong with this approach? > Could you expand a little bit more on your requirements as its sounds > quite > like a project I'll working on. > > 1. Who are you passing the tags on to, another part of the your > application > ? > 2. How do you want to locate the tags. eg. do you want the name tag > within > an person ala XSL ? > 3. What langugue etc are you looking. > > Kind Regards, > > Richard Anderson > > *** This post is of a personal nature and does not in anyway represent > the > opinions or developments of Data Interchange Plc > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 23 18:12:19 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:06:01 2004 Subject: About URI,URN,URL and FPIs References: <028c01bdfdb2$709ee730$0101a8c0@server.abinfosys.com> <362F7240.745F08C3@locke.ccil.org> Message-ID: <3630A9F6.3CDD70A0@eng.sun.com> John Cowan wrote: > > > * If the above is true then each HTML browser will store a local copy of > > the HTML DTD which it will use to validate the HTML instance against. Is > > this correct? > > AFAIK no existing browser validates any document. They have hard-wired > knowledge of some variant of the HTML DTD, not necessarily or typically > a standard one. The earliest versions of HotJava validated, but there's this evil thing called "bad HTML" that quickly reared its ugly head. No HTML browser can possibly afford to validate. Instead, they compete on how many violations of HTML syntax they can "add value to". Let's all do our bit to prevent this from happening with XML. Any time you see a tool accepting or generating illegal XML, yell at its vendor until its fixed! - 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 db at Eng.Sun.COM Fri Oct 23 18:40:47 1998 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:06:01 2004 Subject: Selective parsing of elements References: Message-ID: <3630B093.55ACC9A4@eng.sun.com> Nicolas MONNET wrote: > > I want to parse select XML tags, and pass the remaining ones 'as-is'. Is > there a way, or is there a certain parser, that will allow me to > 'register', for example, the tags I'm interested in, and pass the rest as > PCDATA? Is there anything wrong with this approach? Most Java parsers offer some such functionality, though details vary. For example, you could use a SAX parser and ignore DocumentHandler.element callbacks for the elements you're not concerned with. Sun's package, as well as others, support this. I think it's more typical that folk want to add special processing for specific tags, rather than ignore the others. In Sun's package you can define particular "XML Beans" to represent those tags, and customize processing in that way. To do that, you "register" element classes, which can have your custom code. Similar mechanisms exist in a number of other packages, and some standards will probably be forthcoming in this area. - 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 nico at echange.fr Fri Oct 23 19:55:19 1998 From: nico at echange.fr (Nicolas MONNET) Date: Mon Jun 7 17:06:01 2004 Subject: Selective parsing of elements In-Reply-To: <802566A6.004E37C1.00@dip.co.uk> Message-ID: On Fri, 23 Oct 1998 RJA@dip.co.uk wrote: > Could you expand a little bit more on your requirements as its sounds quite > like a project I'll working on. > > 1. Who are you passing the tags on to, another part of the your application > ? Hm, nope, another XML app or HTML files/cgi/servlets > 2. How do you want to locate the tags. eg. do you want the name tag within > an person ala XSL ? Ah, well, I don't think I understand this. Do you mean, if I want to handle element , do I want it only from inside
    ? Well, I don't really care. > 3. What langugue etc are you looking. Hm ... I don't see that as an issue? Lemme detail this: Well basically the idea is to have a sort of server-side includes on steroids. Currently, I'm using a handcrafted perl parser to do the following: Print some stuff Print some other stuff etc ... etc ... and have my lib fill in the stuff. I want to be able to add sensible tags, handle server-side form entry verification in the template, etc. Now, when I want to be able to have this (or something along those lines):
    Your name is :
    The program would handle FORM, FORM/INPUT, and pass BODY, B, and the rest 'as is', with the SAME whitespace in the tag, for example. Comments? But I guess I'll go for saxon, as soon as I can understand 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 simonstl at simonstl.com Sat Oct 24 03:37:14 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:06:01 2004 Subject: XLink and XPtr - MIA? Message-ID: <199810240137.VAA14108@hesketh.com> It's been a very long time since there's been any real news on the XLink and XPointer fronts, and those of us outside the W3C don't have any way (that I can find - is there a mailing list?) of getting any official news from the W3C on these projects. Are XLink and XPointer still alive? Are people still working on them? Just curious. In the meantime, I'm having lots of fun building some simple apps based on the March 1998 draft, but I'd kind of like to here if I'm what I'm working on is still breathing. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 tbray at textuality.com Sat Oct 24 04:03:04 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:06:01 2004 Subject: XLink and XPtr - MIA? Message-ID: <3.0.32.19981023190140.00aefa80@pop.intergate.bc.ca> At 09:38 PM 10/23/98 -0400, Simon wrote: >Are XLink and XPointer still alive? Are people still working on them? Stand by for some announcements from the W3C real soon I mean REAL SOON now. -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 david at megginson.com Sat Oct 24 14:19:07 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:01 2004 Subject: XLink and XPtr - MIA? In-Reply-To: <199810240137.VAA14108@hesketh.com> References: <199810240137.VAA14108@hesketh.com> Message-ID: <13873.50555.523975.467445@localhost.localdomain> Simon St.Laurent writes: > Are XLink and XPointer still alive? Are people still working on them? Yes -- it's now official that the W3C membership has chartered an XML Linking WG, chaired by Bill Smith from Sun. I think that we will all be thankful that there is now a WG that can devote its full attention to XPointer and XLink, without distractions from other work items. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Oct 24 16:06:32 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:06:01 2004 Subject: Netscape is running an XML app! In-Reply-To: <3.0.32.19981023190140.00aefa80@pop.intergate.bc.ca> Message-ID: <3.0.5.32.19981024070514.00ce4690@scripting.com> Yesterday I got an email from Jeff Veen at Wired pointing me to the server that Netscape is running its What's Related? application on. This is the project they did with Alexa, and it's the back-end for the What's Related? feature in Netscape 4.5. I had a little time to kill, was looking for a diversion, so I sent a message to Netscape's server via script and I was blown away. It's XML! Yes it is. And why, oh why, didn't they tell anyone? (Or did I miss something?) Anyway, I wrote an app that talks to their server. It interfaces thru an HTML form, you enter the URL of a site, and I'll find out what's related, with a twist. The URL to the related site links back to the form, and I do a lookup on *that* site, allowing you to interactively walk their tree of relationships between sites. This is just a demonstration. I'm not trying to put an extra load on Netscape's server, I just want to be sure that people interested in building XML apps have a way to experience the XMLness of what Netscape has done, which is very interesting, for sure. Here's the link to my app: http://nirvana.userland.com/whatsRelated/ Hope you like it! Dave Winer UserLand Software PS: I'm caching the results on my server, so the second time a request is made for a specific site, I don't have to call Netscape. It just occurred to me that if their idea catches on, this caching service would be valuable to corporate web users. Interesting! Could this be synergy? -------------------------------------- http://www.userland.com/directory.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Oct 24 20:58:34 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:06:01 2004 Subject: Source for Netscape-XML app Message-ID: <3.0.5.32.19981024115728.00ba5a20@scripting.com> By popular demand I've posted the source code for the app that calls Netscape's XML server. Feel free to port it to other environments, platforms etc. http://nirvana.userland.com/docs.root/stories/whatsRelatedRoot Dave -------------------------------------- http://www.userland.com/directory.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 Jacco.J.Vrijland at opc.shell.com Mon Oct 26 09:04:53 1998 From: Jacco.J.Vrijland at opc.shell.com (Vrijland, Jacco TRC-OGRS/2) Date: Mon Jun 7 17:06:01 2004 Subject: Content v. attribute Message-ID: Hello, I am working on an XML-based data formatting standard and I've got the following problem. Inside the top element of the document I wish to declare some metadata on the other elements. So far, I've come up with this structure: Now, the problem is the following. In this previous structure I have not yet incorporated a general description of the data (possibly quite a long string). At the moment I can think of two options: 1. include this as another attribute inside the METADATA element 2. put the description as content between the start- and endtag. The first would provide me with an easy mechanism to check whether it has been provided or not, the second seems more natural. Using the first option is more consistent, though, I can think of no reason why the description should be treated differently from the other attributes. Maybe you can provide me with some reasons why one of the two would be preferable over the other. Or with references as to where I can find out myself. I have only started studying XML last week, I have been following this mailinglist since then, I have found lots of references to interesting documents, but nothing to answer my question yet. However, if it would be inappropriate to ask this question here, I apologise. Thanks in advance, Regards, >Jacco Vrijland >Shell Research and Technology Centre, Thornton (TRC-OGRS/2) >++44(0)151 373 5106 >e-mail: Jacco.J.Vrijland@opc.Shell.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Mon Oct 26 12:19:10 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:06:01 2004 Subject: Java One and XML Message-ID: <000901be00da$fafe6880$ab026982@thing1.camb.opengroup.org> I was just glancing over the session tracks for Java One and saw nothing on XML. http://java.sun.com/javaone/javaone98/tracksTOC.html I was thinking about a Birds of a Feather, but I was wondering if there was enough interest to do a pannel discussion or something. Proposals are due October 30th: http://java.sun.com/javaone/javaone99/call.html 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 papresco at technologist.com Mon Oct 26 12:44:11 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:06:01 2004 Subject: Content v. attribute References: Message-ID: <36345EA9.BACF9F8B@technologist.com> "Vrijland, Jacco TRC-OGRS/2" wrote: > > Maybe you can provide me with some reasons why one of the two would be > preferable over the other. Or with references as to where I can find out > myself. http://www.oasis-open.org/cover/elementsAndAttrs.html "A perennial question arising in the mind of SGML/XML DTD designers is whether to model and encode certain information using an element, or alternatively, using an attribute. For example, given some information about the 'title' of a work and the goal of encoding this information in markup, which of the two encodings is preferable, and what principles can be used to decide?" Paul Prescod - http://itrc.uwaterloo.ca/~papresco Marge: "It's almost as if Snake is killing from beyond the grave." Lisa: "I told you that capital punishment isn't a deterrent." - Simpson's halloween special xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at isogen.com Mon Oct 26 14:47:04 1998 From: robin at isogen.com (robin@isogen.com) Date: Mon Jun 7 17:06:01 2004 Subject: Content v. attribute Message-ID: <199810261446.IAA13435@grind> Re: ---------- So far, I've come up with this structure: ---------- I can think of several reasons why it's probably not a good idea to try to model the "title" of an authored work as an XML (SGML) attribute, given that the datatype of XML's "attribute" is just (flat) 'string'. In particular, machine processing of "title" information should be sensitive to the languages present in a work title, which is most easily given in a "language" attribute. So, for example, think about the markup for these titles: Comentarios al "Mein kampf" Eclaircissements sur Mein Kampf: la doctrine d'Adolf Hitler Hitler's Mein Kampf in Britain and America. A publishing history, 1930-39 These are "real titles" and, depending upon the language of discourse in the broader work which references these works, one would need two or three levels of nesting to capture the fact that 'Mein kampf' is a title, in German, and that the embedding string is a title, in some other language, and that the larger discourse unit is XXX, in some third language. This is not a rare event - multilingualism "happens" in the real world millions of time a day. In my personal judgment, it also makes no sense to model a "title" of a work (a document, a "chapter," a "section" or whatever) as "metadata." By whose definition of "metadata"? It's pretty difficult to find a definition of metadata that will hold up, especially in terms of articulating diagnostic/distinguishing features of "metadata" vis-a-vis "data" which determine the best modeling construct in SGML/XML. Whether you want the information to be "presented in the view" should not be relevant, since XML encoding should be free of assumptions about processing-level semantics. Stylesheet contols should dictate wheher/how some information is presented or suppressed in a particular view. Whether the (rest of) "content" *could be understood* without reference to the candidate information in question is equally unhelpful: a novel is "understandable" without the volume title and chapter titles, and it would be understandable with every 12th word removed (if a bit rough in places) as well. To the extent that consciously introducing a distinction between "data" and "metadata" into document encoding means hard-coding a perspective, it may be a bad idea. We already have encough problems dealing with the fact that a particular (privileged) hierarchical modeling of a problem domain introduces a certain distortion (selected analytical perspectve) of the problem domain. Neutral encoding in search of data independence would try to eliminate these particularized interpretations from the encoding model. And finally, to wit (credits Steve DeRose): "your 'metadata' is always someone else's 'data.' I would add: what you think is 'metadata' today will be your 'data' tomorrow - you'll probably be sorry that you modeled the distinction in markup. Just my 2 cents... many will disagree, of course. rcc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Oct 26 15:47:21 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:06:01 2004 Subject: Content v. attribute References: Message-ID: <36349975.2F3F06C1@locke.ccil.org> Vrijland, Jacco TRC-OGRS/2 wrote: > In this previous structure I have not > yet incorporated a general description of the data (possibly quite a > long string). One good reason for modeling long descriptions as character data rather than attribute values is to incorporate markup into it. Descriptions are often the better for a bit of rich text: they need things like emphasis and even hyperlinks. For a DTD building block that provides such things, see http://www.ccil.org/~cowan/XML/ibtwsh.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 dave at userland.com Mon Oct 26 16:04:32 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute In-Reply-To: <36349975.2F3F06C1@locke.ccil.org> References: Message-ID: <3.0.5.32.19981026080255.014514f0@scripting.com> I consider it a flaw of XML that it has two ways to do hierarchy, one much more powerful than the other. In working with other companies about formats you can get into endless meaningless debates about whether it's better to use attributes or just stick with structures. When I design XML forms for our own internal applications, I have generally found that if I use attributes, I end up regretting it and switch over to straight tag hierarchy. You always have the option of adding a structure where a scalar used to be when you go that way. With attributes, you're at the end of the road, no way to have structure, so I agree with John Cowan entirely, you never know what's coming down the road, so it's better to leave some room on either side. Dave At 10:47 AM 10/26/98 -0500, you wrote: >Vrijland, Jacco TRC-OGRS/2 wrote: > >> In this previous structure I have not >> yet incorporated a general description of the data (possibly quite a >> long string). > >One good reason for modeling long descriptions as character data >rather than attribute values is to incorporate markup into it. >Descriptions are often the better for a bit of rich text: they >need things like emphasis and even hyperlinks. For a DTD building >block that provides such things, see >http://www.ccil.org/~cowan/XML/ibtwsh.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) > > -------------------------------------- http://www.userland.com/directory.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 jlapp at webMethods.com Mon Oct 26 16:33:37 1998 From: jlapp at webMethods.com (Joe Lapp) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute Message-ID: <3.0.32.19981026113417.00a8a304@gw1.webmethods.com> At 08:02 AM 10/26/98 -0800, Dave Winer wrote: >[..] When I design XML forms >for our own internal applications, I have generally found that if I use >attributes, I end up regretting it and switch over to straight tag >hierarchy. [...] So it has been with our document types, and in particular WIDL. Many values that were once attributes are now content in child elements. We tend to put values in content when the values might evolve over time or when they are open ended. We still use attributes though because they are more concise and we like to keep our documents as human-readable as possible. Even now we are contemplating moving still more attribute values to child elements. We don't want a proliferation of versions of our document types, so in the future you can bet that we'll be putting values in content far more often than we'll be putting them in attributes. Maybe this is a good rule of thumb: attributes for quick hacks, content for longevity. -- Joe Lapp, Senior Engineer | jlapp@webMethods.com webMethods, Inc. | Voice: 703-267-1726 http://www.webMethods.com | Fax: 703-352-0370 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 26 16:49:04 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute In-Reply-To: <3.0.5.32.19981026080255.014514f0@scripting.com> References: <36349975.2F3F06C1@locke.ccil.org> <3.0.5.32.19981026080255.014514f0@scripting.com> Message-ID: <13876.41880.167338.39445@localhost.localdomain> Dave Winer writes: > I consider it a flaw of XML that it has two ways to do hierarchy, > one much more powerful than the other. In working with other > companies about formats you can get into endless meaningless > debates about whether it's better to use attributes or just stick > with structures. When I design XML forms for our own internal > applications, I have generally found that if I use attributes, I > end up regretting it and switch over to straight tag hierarchy. You > always have the option of adding a structure where a scalar used to > be when you go that way. With attributes, you're at the end of the > road, no way to have structure, so I agree with John Cowan > entirely, you never know what's coming down the road, so it's > better to leave some room on either side. Dave There was a long-running debate in the old SGML world about whether attributes should be allowed at all. Personally, I like them -- although Len's point about my data being someone else's metadata is well-received, I still want to have the choice to use
    ...
    or Remember to close the panel. or Megginson Technologies rather than
    foo ...
    or confidential Remember to close the panel. or http://www.megginson.com There are, of course, many cases where the latter examples are preferable. I agree with all of the posters that in general using elements rather than attributes is a good design principle, but I do think that there are useful data/meta-data distinctions to be made, even if they are extremely fuzzy. One of the reasons data people jump to attributes is the fact that looks an awful lot like public interface Account { public abstract int getNumber (); public abstract int getType (); public abstract String getName (); public abstract String getCurrency (); public abstract boolean isCurrent (); public abstract float getBalance (); } or create table Account ( num int primary key, type int, name char(80), currency int, status bool, balance float ); It's not easy to start thinking differently. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Mon Oct 26 18:18:48 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute Message-ID: <012a01be010c$b34f3320$0300000a@othniel.cygnus.uwa.edu.au> -----Original Message----- From: Dave Winer >I consider it a flaw of XML that it has two ways to do hierarchy Bear in mind that XML was designed primarily for *document* interchange. The attribute vs element decision (which is really just a markup vs content decision) IMO, is a lot less clear in data-centric applications than it is in document-centric ones. XML might have looked quite different if the things people are doing nowadays with XML were thought up when SGML was being developed. 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 papresco at technologist.com Mon Oct 26 18:24:04 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute References: <3.0.5.32.19981026080255.014514f0@scripting.com> Message-ID: <3634A7EA.68FA148D@technologist.com> Dave Winer wrote: > > I consider it a flaw of XML that it has two ways to do hierarchy, one much > more powerful than the other. I agree somewhat. But we must find a way to preserve the best features of attributes before we phase them out. Attributes are random access, uniquely named, order independent and convenient to type. Can elements be tricked into having all of those features in the general case? I think so, and hope to present a proposal for that in the next few weeks. >... > You always have the option of adding a structure where a scalar > used to be when you go that way. With attributes, you're at the end of the > road, no way to have structure, so I agree with John Cowan entirely, you > never know what's coming down the road, so it's better to leave some room > on either side. Dave But the issue of upgradability and migration is much more subtle than that. If merely avoiding attributes made document types easy to upgrade, then nobody would use them. But in some cases, attributes make migration much, much easier. Let's say you have software that expects this form: and you extend it with: what should the software do with the copyright? That's hard to know in general. Sometimes the new sequence member should be discarded. Sometimes it should be recursively processed to find elements that we know how to handle (e.g. a paragraph). But if I add copyright as an *attribute* it's pretty easy to know what to do with it. Almost all software knows to discard attributes that it doesn't understand. Attributes present a "named data field" view of the world that coincides with how we think of objects and properties. Elemetns can be taught how to present that same view but they don't do it in XML-as-we-know-it. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Marge: "It's almost as if Snake is killing from beyond the grave." Lisa: "I told you that capital punishment isn't a deterrent." - Simpson's halloween special xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Oct 26 18:41:19 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute In-Reply-To: Message-ID: <000201be010b$0dc561a0$d6e987cb@NT.JELLIFFE.COM.AU> > From: Vrijland, Jacco TRC-OGRS/2 > The first would provide me with an easy mechanism to check whether it > has been provided or not, the second seems more natural. Using the first > option is more consistent, though, I can think of no reason why the > description should be treated differently from the other attributes. One approach is to make sure all your documents are clearly marked up to tell you which version of your DTD you are using (even if you never actually use a DTD, at least have a DOCTYPE declaration or Processing Intruction or top-level attribute to give you some kind of version numbering!). If you also have the freedom to rewrite your software, this gives you the ability to try attributes now, and shift over to elements later. Why should you care? Let experience with your particular data and applications be your guide. People often underestimate how complicated their data is, and they prematurely put things into attributes. But that is not bad, just natural. The opposite is to blanketly put everything into elements. There is a kind of metadata which is not "data about data" but "data about elements" (i.e. data about markup) which frequently is exactly what an attribute should be used for. Marking them up with elements would IMHO probable mess up the structure of data, or at least make a whole lot of ugly elements. In particular, ID attributes and the xml:lang attibute. If you are using DTDs, then NOTATION attributes and ENTITY attributes fit in there too. If you are not using these then you may find yourself uncompelled to use many attributes. Attributes are also available at the end of the start tag, which provides a nice and natural breathing point for setting up how to process the subsequent contents of the element. This is essential for practical stream processing. 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 cowan at locke.ccil.org Mon Oct 26 19:01:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute References: <000201be010b$0dc561a0$d6e987cb@NT.JELLIFFE.COM.AU> Message-ID: <3634C700.5510BE99@locke.ccil.org> Rick Jelliffe wrote: > If you are using DTDs, > then NOTATION attributes and ENTITY attributes fit in there too. Indeed, the *concept* of notation attributes ("The content of this element has some private syntax designated by this name") and entity attributes ("This element is a surrogate for some non-XML object which logically ought to be inserted here") make sense even when not expressed in a markup declaration. -- 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 jlapp at webMethods.com Mon Oct 26 20:09:02 1998 From: jlapp at webMethods.com (Joe Lapp) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute Message-ID: <3.0.32.19981026150953.00c293e4@gw1.webmethods.com> At 08:24 PM 10/26/98 MET, Elaine Brennan wrote: >[...]If there's one thing I've learned in the SGML/XML universe, it's that >once I've got data carefully and clearly described, I can transform it >into another representation with relatively little trouble. [...] My primary issue is with minimizing the number of different document types we have flying around. We'll create attributes now and two or six months later decide that going forward we actually need a structured value. Sure, we could migrate the unstructured values to the structured values, but we don't want our users having to constantly unlearn old syntax to learn new syntax. The idea behind starting with element content rather than attributes is to design an extensible document type to which we can add new element types without having to keep changing old element types. So our experience is that we've been burned by making something an attribute that ultimately needed to be element content, but we haven't yet been burned by making something element content that should have been an attribute. Besides, the attribute normalization rules that XML specifies have occassionally caught our engineers off guard. Sometimes we need whitespace to be significant in attribute values. But the conciseness of attributes in elements remains very enticing, so whenever we're certain that a value will forever fit into an attribute, we'll put it there. I'll grant that if you new that a document type would not evolve -- if you knew that the requirements were fixed and unchanging -- then you could partition data among attributes and content using whatever criteria you desire. -- Joe Lapp, Senior Engineer | jlapp@webMethods.com webMethods, Inc. | Voice: 703-267-1726 http://www.webMethods.com | Fax: 703-352-0370 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mike_Spreitzer.PARC at xerox.com Mon Oct 26 21:01:36 1998 From: Mike_Spreitzer.PARC at xerox.com (Mike_Spreitzer.PARC@xerox.com) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute In-Reply-To: <3.0.32.19981026150953.00c293e4@gw1.webmethods.com> Message-ID: <98Oct26.130104pst."53701(4)"@alpha.xerox.com> I agree with your reasoning. For the sake of completeness of discussion, however, let me point out an attribute-favoring argument I haven't noticed on this list. It is that well-formedness and validation can put more constraints on attributes (if you design your DTD to take advantage of this) than on element content. So you can express more of the semantics of your application via generic mechanisms this way. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Oct 26 21:01:40 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:06:02 2004 Subject: ANN: XML Tutorials in London Message-ID: <3.0.1.16.19981026210041.1b2f824a@pop3.demon.co.uk> I was asked whether it was appropriate to announce XML tutorials on XML-DEV, and I am happy to include the following announcement from Alan Paton. These tutorials appear to venture into uncharted waters (e.g. metadata) and so are in the spirit of XML-DEV. P. ---------------------------from Alan Paton------------------------------------- ============================= THREE XML TUTORIALS IN LONDON ============================= >From International experts Tim Bray and Henry Thompson (1) XML and Network Publishing Technologies 1 Day Tutorial, London, 23 November 1998, Presented by: Tim Bray (2) The XML Technology Bootstrap (Includes 'hands-on' session using XML) 1 Day Tutorial, London, 24 November 1998, Presented by: Tim Bray (3) Putting XML to Work: Style, Metadata and API 1 Day Tutorial, London, 25 November 1998, Presented by: Henry S. Thompson FOR FURTHER INFORMATION PLEASE CONTACT: Technology Appraisals Ltd +44 (0)181 893 3986 +44 (0)181 744 1149 Email: techapp@cix.compulink.co.uk URL: www.techapps.co.uk Please note fees apply to attend these tutorials ++++++++ +++++++ +++++++ +++++++ +++++++ XML AND NETWORK PUBLISHING TECHNOLOGIES: OUTLINE CONTENTS Design goals for network publishers * User-driven design goals * Management-driven design goals * Cost-driven design goals XML's role: the un-met needs of today's network publishers * SGML, HTML, and PDF: reasons to love and fear them * Coming over the horizon: VRML, multimedia, ActiveX, Java * XML's unfilled niche XML - a new business case and technology platform * Historical background and motivation * The ongoing XML specification process * A walk through the XML specification * How XML relates to SGML* How XML relates to HTML * How XML changes the SGML Business Case ++++++++ +++++++ +++++++ +++++++ +++++++ THE XML TECHNOLOGY BOOTSTRAP INCLUDES 'HANDS-ON' SESSION USING XML): OUTLINE CONTENTS History and context * The problems of SGML and HTML * The history and role of XML The XML standard * Introduction and goals * Logical and physical structure of documents * Well-formedness * Characters * Character data, binary data, and markup * Comments and processing instructions * CDATA Sections * Prolog and Document Type Declaration * Start-Tags and End-Tags * Element and Attribute Declarations * Conditional Sections * Character and Entity References * Entity Declarations * Run-time Treatment of Entities * Notation Declarations Hands-on: using XML * Creating well-formed documents * Introduction to Lark, an XML Processor * Compiling and running Java programs * A table-of-contents application * A statistical analysis application Writing an XML Processor * Construct recognition * Error handling * Validation * API Issues Attendance requirements This tutorial requires programming competence and some familiarity with parsing concepts. Experience with Java is not required, but exposure to some language in the "C" family (C, C++, Objective C) would be very helpful. The cost of the seminar includes the book Learn Java Now from Microsoft Press, which includes a CD-ROM version of Microsoft Visual J++, one of the leading development environments. ++++++++ +++++++ +++++++ +++++++ +++++++ PUTTING XML TO WORK: STYLE, METADATA AND API: OUTLINE CONTENTS Electronic Style * A brief history: the bad old days (wordprocessors); the recent past (proprietary systems); the present (HTML); the near future (a standards-based approach: structure (XML), linking (XLL) and appearance (XSL/CSS)). * Electronic style specificiation * The right tool for the job: three style standards * DSSSL: Document Style Semantics and Specification Language. * CSS: Cascading Style Sheets. * XSL: XML Style Language. * Which is right for what situation? * CSS tools and examples * An introduction to controlling HTML document appearance with CSS. * XSL tools and examples * An introduction to the draft XSL standard Constraining document structure An introduction to XML-Data: how does it allow you to say just as much about the structure of your documents as you wish, and no more? How inheritance allows specialisation of document structure while still allowing general-purpose tools to operate. Describing document content An introduction to RDF: how does it provide a standard way of telling the WWW what your document is about, who wrote it and who should read it. Relation to other standards, including PICS and Digital Signatures. Application access to documents An introduction to the DOM: how does it provide a parser (and programming language) independent API for standardised access to (HTML/XML) document content? What DOM-supporting tools are available already? Summary conclusions What should your company be doing about deploying XML? ++++++++ +++++++ +++++++ +++++++ +++++++ Tim Bray is the principal of Textuality, a consulting practice headquartered, in Vancouver, Canada. Tim is co-editor of the XML Specification and is currently a voting member of the World Wide Web Consortium's SGML Editorial Review Board. Tim has served as Manager of the New Oxford English Dictionary Project, and as a founder, Managing Director, and Senior Vice President of Open Text, a well-known player in the network publishing technology marketplace. Since departing Open Text, Tim, through Textuality, has provided consultancy to organizations including IBM, Merrill Lynch, the U.S. Department of Energy, Keio University, Jeppeson Sanderson, Diebold, and Encyclopedia Britannica. He is the author of Lark, the first generally available XML parser; Lark is implemented in the Java language. ++++++++ +++++++ +++++++ +++++++ +++++++ Henry S. Thompson is Reader in Artificial Intelligence and Cognitive Science at the University of Edinburgh, where he is chiefly engaged in research and research management in the Language Technology Group of the Human Communication Research Centre. He has published several language research corpora on CD-ROM, and has developed software systems for SGML and DSSSL. He was a member of the original W3C SGML Working Group, responsible for the first drafts of the XML standard. He was a co-author of the XML-Data proposal and the original XSL proposal and is now a member of the XSL working group. He is the author of XED, the first freely available XML editor, and XSLJ, an implementation of XSL on top of JADE. ++++++++ +++++++ +++++++ +++++++ +++++++ 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 jwilliams at Oceania.com Mon Oct 26 23:57:54 1998 From: jwilliams at Oceania.com (Jason Williams) Date: Mon Jun 7 17:06:02 2004 Subject: c++ parser for DOM Message-ID: Hello. I have a need for a c++ parser that can be used to build a DOM object that I can use as (or build into) a COM control. I know there are several parsers in Java that can be used to build a DOM, but I haven't located one in c++. From what I've read on this list, the msxml parser from IE 4.0 is outdated, so there's no need to look there. Thanks very much. Jason jwilliams@oceania.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 27 01:55:37 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute References: <012a01be010c$b34f3320$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <36352796.6659@hiwaay.net> James Tauber wrote: > > Bear in mind that XML was designed primarily for *document* interchange. The > attribute vs element decision (which is really just a markup vs content > decision) IMO, is a lot less clear in data-centric applications than it is > in document-centric ones. XML might have looked quite different if the > things people are doing nowadays with XML were thought up when SGML was > being developed. Interesting. Xerox sold a markup based system that did exactly that. Elements only; no attributes. It died on the vine. So, regardless of hindsight, historically, it didn't fly. The idea that might have made a difference to XML was the notion of an object with an interface and an implementation. Many of the things people are doing nowadays with XML were thought up in the context of programming languages. 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 Suli.Ding at geis.ge.com Tue Oct 27 04:02:52 1998 From: Suli.Ding at geis.ge.com (Ding, Suli (GEIS)) Date: Mon Jun 7 17:06:02 2004 Subject: DTD for X12 or EDIFACT Message-ID: I have sent out the following message some times ago. Some people sent me e-mail wants to know what my program does. I created a web page just for that. If you are interest, please visit http://www.geocities.com/EnchantedForest/Tower/2701 Regards, Suli Ding > ---------- > From: Ding, Suli (GEIS)[SMTP:Suli.Ding@geis.ge.com] > Reply To: Ding, Suli (GEIS) > Sent: Friday, October 09, 1998 9:42 AM > To: 'xmledi-list@lists.bizserve.com' > Subject: DTD for X12 or EDIFACT > > Is there a DTD defined for any document type of ANSI X12 or EDIFACT? Where > can it be found? > > I have a program can produce a XML document (well formatted) from almost > any > input data by a data definition file. I try it on some small interchanges > and UDF files. But I would like to apply it to ANSI X12 or EDIFACT. > > Thanks, > > Suli Ding > > > > ========================================== > XML/EDI Group members-only discussion list > Homepage = http://www.xmledi.com > > Brought to you by: Online Technologies Corporation > Home of BizServe - www.bizserve.com > > TO UNSUBSCRIBE: Send email to > Leave the subject blank, and > In the body of the message, enter ONLY: unsubscribe > > Questions/requests should be sent to: owner-xmledi-list@bizserve.com > To join the XML/EDI Group complete the form located at: > http://www.geocities.com/WallStreet/Floor/5815/mail1.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 donpark at quake.net Tue Oct 27 05:12:10 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute Message-ID: <00a501be0168$361c8d60$2ee044c6@arcot-main> I have just one question: What do we have to treat them differently? Given following XML fragment:
    1234 Park Avenue.
    Why not treat both city attribute and street element the same so that both of them can be accessed with following DOM script? String city = address.getAttribute("city") String street = address.getAttribute("street") or even simpler in ECMAScript: var city = address.city var street = address.street In other words, why not treat attributes as a specific type of child element: unique and childless? Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Oct 27 05:40:11 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute References: <00a501be0168$361c8d60$2ee044c6@arcot-main> Message-ID: <36354BA6.C78AFEE1@technologist.com> Don Park wrote: > > String city = address.getAttribute("city") > String street = address.getAttribute("street") > > or even simpler in ECMAScript: > > var city = address.city > var street = address.street > > In other words, why not treat attributes as a specific type of child > element: unique and childless? Your example elements being treated as a special kind of *attribute*. (getAttribute(...)). But how do you "attribute-ize" a content model like this: What does P.getAttribute( "B" ) return if there are three B s with four I s between them? Paul Prescod - http://itrc.uwaterloo.ca/~papresco Marge: "It's almost as if Snake is killing from beyond the grave." Lisa: "I warned you that capital punishment wouldn't be a deterrent." - The Simpson's halloween special: "Hell Toupee" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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.cook at platinum.com Tue Oct 27 05:52:17 1998 From: david.cook at platinum.com (david.cook@platinum.com) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute Message-ID: <482566AA.001F6DE8.00@platinum.com> The simplest principle I've found is: Content = human-readable Attribute = machine-readable. But even that is open to interpretation... the principle is based on the idea of an attribute affecting the content, not actually being output itself. HTML operates in that way: you don't 'see' HREFs or SRCs, but they surely affect the behavior of the tag, and it's the behavior I'm really interested in being variable, not the content... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Oct 27 06:00:09 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:06:02 2004 Subject: Content v. attribute Message-ID: <00d901be016e$e1f9afe0$2ee044c6@arcot-main> Paul, >What does P.getAttribute( "B" ) return if there are three B s with four I >s between them? SInce it makes no sense in Java, null seems appropriate. What I proposed makes no sense (except in ECMAScript where P.B is a collection and P.B[index] returns the element) if the information is not unique or complex. BTW, DTD designers seems to prefer using contents for flexibility and attributes for brevity. I forgot to mention in my previous message that it is awkward to access attributes stored as contents using DOM. getElementsByTagName is a rather expensive operation and returns NodeList. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Oct 27 07:59:57 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:06:03 2004 Subject: Orgcharts Message-ID: <36356D5A.8BF835A5@technologist.com> I'm thinking about the problems of representing graphics with XML. I know about PGML, VML, etc., but I want to think about subsets of graphics where the computer can completely handle layout. I want to just tell it what boxes, lines and labels I want and have it draw them. I don't want to give it X and Y coordinates for attachment points, boxes, etc. It seems to me like organization charts should be one such area where computers can handle the graphical layout themselves. Organization charts could be used to show corporation hierarchy, the components of a content model, the parts of an application and other types of hierarchical data. Even an XML document could be represented as an orgchart. My question is whether anyone knows of declarative descriptions for organizational charts or other types of graphical data where the computer can handle the layout. Are there DTDs, LaTeX packages, subsets of PDF, APIs etc. worth looking at? Thanks for any information, Paul Prescod - http://itrc.uwaterloo.ca/~papresco Marge: "It's almost as if Snake is killing from beyond the grave." Lisa: "I warned you that capital punishment wouldn't be a deterrent." - The Simpson's halloween special: "Hell Toupee" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RJA at dip.co.uk Tue Oct 27 08:27:13 1998 From: RJA at dip.co.uk (RJA@dip.co.uk) Date: Mon Jun 7 17:06:03 2004 Subject: c++ parser for DOM Message-ID: <802566AA.002E7248.00@dip.co.uk> Richard J. Anderson@DI 10/27/98 08:27 AM Hi Jason, I've got an Active-X SAX control which could be used to build a DOM control. The underlying XML parser used by the SAX control also supports a native DLL/C++SAX interface, so you could build a DOM control on top of that. ( Thats what I'm goingto do ) . I'll be publishing the C++ SAX definitions for free when I get some spare time. The XML support is not 100% yet, but it can parse most documents without external entities. I could send you the Active-X control along with a demo VB app. The app loads a document into a tree control, and shows the SAX events in a list control.. There is no documentation as of yet. Kind Regards, Richard. *** This post is of a personal nature and does not in anyway represent the opinions or developments of Data Interchange Plc *** xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Oct 27 08:53:13 1998 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:06:03 2004 Subject: Content v. attribute In-Reply-To: <98Oct26.130104pst."53701(4)"@alpha.xerox.com> References: <3.0.32.19981026150953.00c293e4@gw1.webmethods.com> Message-ID: <3.0.6.32.19981027084833.00948e80@gpo.iol.ie> Another important aspect of attributes - they can be layered on by the parser. I.e. defaulted. XLINK and AF's in general make use of this. In an attribute free world we would need an element only way of achieving the same thing. xref seealso ... Sean Mc Grath def Get_URI_Of_Superlative_XML_Scripting_Language(): return "http://www.python.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 david at megginson.com Tue Oct 27 14:20:04 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:03 2004 Subject: Content v. attribute In-Reply-To: <00a501be0168$361c8d60$2ee044c6@arcot-main> References: <00a501be0168$361c8d60$2ee044c6@arcot-main> Message-ID: <13877.44429.850069.233606@localhost.localdomain> Don Park writes: > In other words, why not treat attributes as a specific type of > child element: unique and childless? Actually, that might complicate processing far more than you think: 1. Attributes are inherently unordered and have no position relative to the element children; for any kind of iteration, you would have to provide fake positions for them and develop a rule to make those positions consistent across different processors (if you're thinking of specifying that they be sorted in alphabetical order, remember the L10N issues). 2. Attributes are often meant to be ignored unless needed. For example, if I have and then
    Small Section This is a small section.
    do I really want to have to iterate through 'html', 'id', 'security', and 'status' as well as 'title' and 'para' as my children? 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 ricker at xmls.com Tue Oct 27 14:33:09 1998 From: ricker at xmls.com (Jeffrey Ricker) Date: Mon Jun 7 17:06:03 2004 Subject: Orgcharts In-Reply-To: <36356D5A.8BF835A5@technologist.com> Message-ID: <199810271432.JAA16693@mail.his.com> XMLSolutions has created an org chart DTD for a client. However, it is completely focused on the actual reporting structure, not pretty boxes. It could serve as a base data and the pretty boxes comes from a transformation like XSL. Also, have you taken a look at Visio. Their drawing objects are completely object-oriented which may serve as a solid base for an drawing objects DTD. Ricker ricker@xmls.com At 01:51 AM 10/27/98 -0500, Paul Prescod wrote: >I'm thinking about the problems of representing graphics with XML. I know >about PGML, VML, etc., but I want to think about subsets of graphics where >the computer can completely handle layout. I want to just tell it what >boxes, lines and labels I want and have it draw them. I don't want to give >it X and Y coordinates for attachment points, boxes, etc. > >It seems to me like organization charts should be one such area where >computers can handle the graphical layout themselves. Organization charts >could be used to show corporation hierarchy, the components of a content >model, the parts of an application and other types of hierarchical data. >Even an XML document could be represented as an orgchart. > >My question is whether anyone knows of declarative descriptions for >organizational charts or other types of graphical data where the computer >can handle the layout. Are there DTDs, LaTeX packages, subsets of PDF, >APIs etc. worth looking at? > >Thanks for any information, > > Paul Prescod - http://itrc.uwaterloo.ca/~papresco > >Marge: "It's almost as if Snake is killing from beyond the grave." >Lisa: "I warned you that capital punishment wouldn't be a deterrent." > - The Simpson's halloween special: "Hell Toupee" > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricker at xmls.com Tue Oct 27 14:55:01 1998 From: ricker at xmls.com (Jeffrey Ricker) Date: Mon Jun 7 17:06:03 2004 Subject: Mailing addresses Message-ID: <199810271454.JAA00618@mail.his.com> I am looking for the existing standards for mailing addresses. What is the EDIFACT, X12 or X.500 standard for a mailing address? Are there others I should be asking about? It seems every database has a different way of creating a mailing address. It would be nice to establish a default (rather than endorsed) standard for putting mailing addresses in XML data stores. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at sunsite.unc.edu Tue Oct 27 16:51:53 1998 From: elharo at sunsite.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:06:03 2004 Subject: Orgcharts In-Reply-To: <36356D5A.8BF835A5@technologist.com> Message-ID: >I'm thinking about the problems of representing graphics with XML. I know >about PGML, VML, etc., but I want to think about subsets of graphics where >the computer can completely handle layout. I want to just tell it what >boxes, lines and labels I want and have it draw them. I don't want to give >it X and Y coordinates for attachment points, boxes, etc. > Back in grad school I used to use an X-Windows program called grtool that had a simple text based file format for drawing graphs. It certainly wasn't XML, but it was extremely useful when I needed to write C code that chunked out hundreds of pages of graphs for different parameter values. grtool is probably still out there somewhere. That job converted me to the text-based file format religion. It would have been much harder to do something similar on a Mac or PC using something like DeltaGraph with its binary file formats. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@sunsite.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML: Extensible Markup Language (IDG Books 1998) | | http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From alberto.reggiori at jrc.it Tue Oct 27 17:09:15 1998 From: alberto.reggiori at jrc.it (Alberto Reggiori) Date: Mon Jun 7 17:06:03 2004 Subject: Orgcharts in Javascript References: Message-ID: <3635FE10.93E621E6@jrc.it> Elliotte Rusty Harold wrote: > > >I'm thinking about the problems of representing graphics with XML. I know > >about PGML, VML, etc., but I want to think about subsets of graphics where > >the computer can completely handle layout. I want to just tell it what > >boxes, lines and labels I want and have it draw them. I don't want to give > >it X and Y coordinates for attachment points, boxes, etc. > > > > Back in grad school I used to use an X-Windows program called grtool that > had a simple text based file format for drawing graphs. It certainly > wasn't XML, but it was extremely useful when I needed to write C code that > chunked out hundreds of pages of graphs for different parameter values. > grtool is probably still out there somewhere. > > That job converted me to the text-based file format religion. It would > have been much harder to do something similar on a Mac or PC using > something like DeltaGraph with its binary file formats. > I was thinking to build a really simple implementation of VML (or some other XML-ish) in Javascript 1.1 using the xbm format (ASCII text) to draw simple shapes on the client side. I got this idea looking at the site http://www.hidaho.com/doodlepad/ The xbm is b/w but is trivial to implement. Any attempt in this direction ? Alberto xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From deke at tallent.com Tue Oct 27 17:18:30 1998 From: deke at tallent.com (Deke Smith) Date: Mon Jun 7 17:06:03 2004 Subject: GEDCOM to XML? Message-ID: <1302635435-21036693@tallent.com> There was some discussion on this list some time ago of expressing the GEDCOM format in XML. Has there been any progress made on that? Are there converters out there? Deke ----------------------------------------------------------------- Deke Smith Tallent Communications Group, Brentwood TN deke@tallent.com, 615-661-9878 ----------------------------------------------------------------- " The best way to predict the future is to invent it. " - Alan 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 RDaniel at DATAFUSION.net Tue Oct 27 17:28:23 1998 From: RDaniel at DATAFUSION.net (Ron Daniel) Date: Mon Jun 7 17:06:03 2004 Subject: Mailing addresses Message-ID: <0D611E39F997D0119F9100A0C931315C2E0D6B@datafusionnt1> There are a ton of different 'standards' for mailing addresses. vCard is another one you might want to look at. You can get info on it at www.imc.org. There is already a proposal for an XML encoding of vCard, and on my 'to-do' list is an item about seeing what an XML treatment of vCard would look like if it were based on RDF. (Of course, just because its on my to-do list doesn't mean it will actually happen - there are priorities as well and this item does not have a high priority for me. :-( Ron > -----Original Message----- > From: Jeffrey Ricker [SMTP:ricker@xmls.com] > Sent: Tuesday, October 27, 1998 6:47 AM > To: xml-dev@ic.ac.uk > Subject: Mailing addresses > > I am looking for the existing standards for mailing addresses. > What is the EDIFACT, X12 or X.500 standard for a mailing address? > Are there others I should be asking about? > > It seems every database has a different way of creating a mailing > address. > It would be nice to establish a default (rather than endorsed) > standard for > putting mailing addresses in XML data stores. > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From colds at nwlink.com Tue Oct 27 19:48:25 1998 From: colds at nwlink.com (Chris Olds) Date: Mon Jun 7 17:06:03 2004 Subject: Orgcharts Message-ID: <005401be01e2$9b448bf0$dc59fcc6@albert.salsa.walldata.com> For non-commercial use, there is GraphViz at http://www.research.att.com/sw/tools/graphviz/ It should be fairly easy to map XML to the language that dot (a graph drawing tool) accepts. These are generalized graph-drawing tools, so there is a lot to look at (but it is easy to get started). /cco xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From harvey at eccnet.eccnet.com Tue Oct 27 20:16:27 1998 From: harvey at eccnet.eccnet.com (Betty Harvey) Date: Mon Jun 7 17:06:03 2004 Subject: Orgcharts In-Reply-To: <36356D5A.8BF835A5@technologist.com> Message-ID: Take a look at a http://www.infosphere-inc.com/topaz/. Mark Roberts, Infosphere, has developed a program that can generate graphics in SGML, as well as import all versions of CGM (I-IV) to SGML. They have a JAVA plug-in for Netscape that renders the graphics and makes them interactive. Mark came to the Washington Area SGML Users Group meeting last week and demonstrated the Beta version of the product they are calling Topaz. It is really pretty cool and I see a lot of applications for it especially in the IETM area. The difference between what they are doing and what VML is doing is the graphic primitives are in elements rather than attributes and provide a lot more intelligence. He is working on creating a filter from the SGML graphic to VRML. The cool thing is that this is useful from Orgcharts all the way to complex 3D graphics. Schematics have always been a real problem in on-line presentation - this provides some interesting options for schematics and schematic type flowcharts. Betty /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 301-540-8251 FAX: 4268 Electronic Commerce Connection, Inc. | 13017 Wisteria Drive, P.O. Box 333 | Germantown, Md. 20874 | harvey@eccnet.eccnet.com | Washington,DC SGML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/sgmlug/ /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ On Tue, 27 Oct 1998, Paul Prescod wrote: > I'm thinking about the problems of representing graphics with XML. I know > about PGML, VML, etc., but I want to think about subsets of graphics where > the computer can completely handle layout. I want to just tell it what > boxes, lines and labels I want and have it draw them. I don't want to give > it X and Y coordinates for attachment points, boxes, etc. > > It seems to me like organization charts should be one such area where > computers can handle the graphical layout themselves. Organization charts > could be used to show corporation hierarchy, the components of a content > model, the parts of an application and other types of hierarchical data. > Even an XML document could be represented as an orgchart. > > My question is whether anyone knows of declarative descriptions for > organizational charts or other types of graphical data where the computer > can handle the layout. Are there DTDs, LaTeX packages, subsets of PDF, > APIs etc. worth looking at? > > Thanks for any information, > > Paul Prescod - http://itrc.uwaterloo.ca/~papresco > > Marge: "It's almost as if Snake is killing from beyond the grave." > Lisa: "I warned you that capital punishment wouldn't be a deterrent." > - The Simpson's halloween special: "Hell Toupee" > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 xenex.com Tue Oct 27 21:36:50 1998 From: rob at xenex.com (Rob Schoening) Date: Mon Jun 7 17:06:03 2004 Subject: XML-QL Message-ID: <006d01be01f1$d7c9b820$7dd63ace@dionysis> Hi- Does anyone know of any projects afoot to implement an parser XML-QL in Java? I was considering loading ANTLR and getting going, but if someone has done some work already I'd rather not re-invent the wheel. I'm not a whiz at putting the lexer together anyway. ;-) I'd appreciate any thoughts you have. Thanks, Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bsko at mit.miwon.co.kr Wed Oct 28 01:53:50 1998 From: bsko at mit.miwon.co.kr (=?EUC-KR?B?sO25/Lyu?=) Date: Mon Jun 7 17:06:03 2004 Subject: XML Filter or XML Converter Information? Message-ID: <363678B8.BC9291D3@mit.miwon.co.kr> An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19981028/9dbe2fe6/attachment.htm From jackpark at thinkalong.com Wed Oct 28 02:27:10 1998 From: jackpark at thinkalong.com (Jack Park) Date: Mon Jun 7 17:06:03 2004 Subject: Orgcharts in Javascript In-Reply-To: <3635FE10.93E621E6@jrc.it> References: Message-ID: <199810280226.SAA10841@mailhost.ap.net> At this URL: http://www.ics.uci.edu/pub/arch/uml/ There is source code for a really nifty UML layout tool (also writes Java code). It will eventually have the UML variant of XML built into it. I can't think of any reason why the other graphic widgets (boxes, etc) couldn't be hijacked to draw org charts. Shoot, why couldn't each block in an org chart be a UML Class? Jack Park At 06:08 PM 10/27/98 +0100, you wrote: >Elliotte Rusty Harold wrote: >> >> >I'm thinking about the problems of representing graphics with XML. I know >> >about PGML, VML, etc., but I want to think about subsets of graphics where >> >the computer can completely handle layout. I want to just tell it what >> >boxes, lines and labels I want and have it draw them. I don't want to give >> >it X and Y coordinates for attachment points, boxes, etc. >> > >> >> Back in grad school I used to use an X-Windows program called grtool that >> had a simple text based file format for drawing graphs. It certainly >> wasn't XML, but it was extremely useful when I needed to write C code that >> chunked out hundreds of pages of graphs for different parameter values. >> grtool is probably still out there somewhere. >> >> That job converted me to the text-based file format religion. It would >> have been much harder to do something similar on a Mac or PC using >> something like DeltaGraph with its binary file formats. >> > >I was thinking to build a really simple implementation of VML (or some >other XML-ish) in Javascript 1.1 using the xbm format (ASCII text) to >draw simple shapes on the client side. >I got this idea looking at the site http://www.hidaho.com/doodlepad/ > >The xbm is b/w but is trivial to implement. > >Any attempt in this direction ? > > > >Alberto > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 xenex.com Wed Oct 28 02:53:55 1998 From: rob at xenex.com (Rob Schoening) Date: Mon Jun 7 17:06:04 2004 Subject: XML-QL Follow up Message-ID: <000901be021f$510ed1c0$88a9b4d1@yak.ptld.uswest.net> XML-QL seems well suited to doing queries on single XML documents. However, it doesn't seem to be particularly well suited for searching through sets of documents. I'm thinking of a database that could treat DTDs the way relational databases treat their relations. Ideally I'd like to submit a query and retrieve a set of results corresponding to the XML documents (tuples) that satisfy the query. For instance, I'd like to be able to issue something like: select * from invoices where value() > 1000 or select * from musicians where name like 'Garcia' which might return URIs to the documents fitting the criteria. It would be a hybrid web/database server...kind of an dynamic ORDBMS. The clumsiness of ODBMS and ORDBMS systems could be eliminated since XML text is self-descriptive. The software and administrative overhead of getting data in and out of a database could be eliminated. Does this interest anyone? I'd like to start a project along these lines. Is this just a pipe dream? Practical? Impractical? Useful? Useless? I'd appreciate any comments. Rob xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Craig_Gingell at Dell.com Wed Oct 28 09:44:49 1998 From: Craig_Gingell at Dell.com (Craig_Gingell@Dell.com) Date: Mon Jun 7 17:06:04 2004 Subject: GEDCOM to XML? Message-ID: I have an entire genealogy website of over 1800 names powered by XML. The original site was designed earlier in the year, and does not make use of namespaces etc. I have written routines to convert GEDCOM to my XML and back again. There is only one drawback, in that I have functionality in my XML that I cannot express in GEDCOM (not that I know of) My XML encompasses geography, so that people in the same geographical area can be linked together. I have used Microsoft's MSXSL processor to create several different styles of pages from my XML. These include profile entries, ancestral trees, descendant trees, location lookups and image gallery. You can find my website at http://www.gingell.com and my XML file at http://www.gingell.com/data/gingell.txt I would very much like feedback on GEDCOM developments, as I have not seen many (if any) genealogy sites using XML Regards Craig Gingell http://www.gingell.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From huck at darmstadt.gmd.de Wed Oct 28 09:59:05 1998 From: huck at darmstadt.gmd.de (Gerald Huck) Date: Mon Jun 7 17:06:04 2004 Subject: XML-QL Follow up Message-ID: <01BE0262.151598A0.huck@darmstadt.gmd.de> At GMD-IPSI, we have a tool called Jedi which is able to perform SQL/OQL like queries based on internal DOM representations of XML documents. XML element constructors serve the construction of a new DOM in the select-clause. Embedding the query result elements within one result element and XML document constructor, this is all what is needed to generate a new XML document (which can be written to a file, stdout, ...). The from part defines where the data needs to be fetched from and offers join functionality. Join predicates or other selection predicates can be given in the where clause. Access to the queried XML document and its content is realized on top of DOM methods. These are either exposed directly or implement short hand operators, e.g. 'element.attribute' to access element attributes or 'element["name"]' to access the first child element named "name". In the following i give a fairly complex query which constructs a new XML document from three sources, combining local weather forecasts, traveling information and golfclub information to provide an 'integrated' view on multiple sources. The XML "records" of the original sources look like:
    Golf- und Land-Club Berlin Wannsee e.V. Golfweg 22 14109 Berlin 030-8067060 -80670610
    100 120 Die Anlage liegt in einer idyllischen markischen Landschaft und bietet fur Golfer jeder Spielstarke aufgrund des machtigen Baumbestandes und teilweise erheblichen Gelandeschwierigkeiten sowohl eine hohe sportliche Herausforderung als auch ein landschaftliches Erlebnis. Enge Bahnen erfordern einen prazisen geraden Drive. 18 6088 Gaste sind willkommen. Clubausweis mit eingetragenem Hdc (34) ist erforderlich. Gaste in Mitgliederbegleitung und nach Voranmeldung. 34 34     ------------------------------------------ 53757 93333 481.9 5375793333.gif ------------------------------------------ 87724 980922 15 10 9 11 ------------------------------------------ QUERY: XML.Document( // constructor for result element select // generates XML-Elements containing information about golf-links, // current weather information and travel information // setting attributes from original attributes // inserting original golfclub record children as new children golfclub.children(), // inserting information from other documents weather, route from route in ( // all routes which are less than 50km from start city select r from r in XML.Document("route.xml").descendants("route") // instantiates DOM and gets route elements where r["from"].text() == "50987" // Zipcode of city where travel starts and route["distance"].double() < 50.0 ), golfclub in ( // all golfclubs with a normal greenfee < 80 DM select g from g in XML.Document("golf.xml").descendants("golfclub") where g["address"]["zipcode"].text()==r["to"].text() // join with route and g["greenfee"]["normal"].int() < 80 ), weather in ( select w from w in XML.Document("weather.xml").descendants("weather") where w["zipcode"].text()==r["to"].text() ) ) ------------------------ USAGE We use this query language within a XML broker architecture. A Web demo will hopefully be available from our Web server soon (It requires IE5beta currently to render XML results - not used by everyone :-)) ------------------------ IMPORTANT NOTE The presented query facilities have NOT BEEN TAILORED to XML specifics. Rather, the presented query facilities are part of Jedi's scripting capabilities. Jedi offers flexible means to generate wrappers for arbitrary textual sources (based on a failure tolerant parser), as well as to other sources, e.g. accessible via JDBC. The query language is only a simple mean to provide (integrated) views. Therefore, Jedi supports other application scenarios as well: - extracting semi-structured data from text documents, modeling them in XML (used in a BIO-Informatics project) - accessing XML docs, storing them in a relational DBMS - converting relational data to XML documents - accessing Java objects - merging different modeling paradigms within one scripting language, offering uniform syntactic access to all of them. For further information, you can visit Jedi's homepage at: http://www.darmstadt.gmd.de/oasys/projects/jedi/index.html However, the available material concentrates on the built-in failure tolerant parser but detailed descriptions about the scripting facilities are still missing. ( The current language is simple, but proprietary - we try to adapt it to ECMA-Script as much as possible, but will keep query extensions and XML constructors for convenience. ) Gerald Huck German National Research Center for Information Technology (GMD-IPSI) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 28 10:18:12 1998 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:06:04 2004 Subject: XSchema: various Message-ID: <01BE0263.FA1FF9D0@grappa.ito.tu-darmstadt.de> In the last round of reviews, a couple of minor changes have been suggested. I list these below for review. If nobody objects by end of day Friday, I will add these to the current spec (along with some minor editorial changes) and publish a final, definitive, we're-done (really) version this weekend. 1) Remove Element and ElementNS from AttDef and AttGroup. Currently, you can define an attribute for an element in two ways: a) place the AttGroup/AttDef inside the ElementDecl, or b) place the AttGroup/AttDef directly under XSchema and have it point to the element through the Element and ElementNS attributes As several people have pointed out, method (b) is really a DTD-ism and should be removed. There are no technical reasons for it to exist and the rules governing inheritance of the ElementNS attribute are reason alone for it not to exist. AttGroup/AttDef will still remain under XSchema for defining global attributes. (This is the role they currently fulfill when the Element attribute is omitted.) 2) In the XSchema PI, add a Version pseudo-attribute so that a validator does not have to retrieve a file that uses a version it can't cope with. 3) When validating against an XSchema, the declaration of the root element must have a Root attribute of "Recommended" or "Possible". (Currently, only Recommended is allowed.) -- 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 tln at insect.sd.monash.edu.au Wed Oct 28 11:07:56 1998 From: tln at insect.sd.monash.edu.au (Thuy-Linh Nguyen) Date: Mon Jun 7 17:06:04 2004 Subject: DTD#printExternal in xml4j 1.1.4 Message-ID: Hi, I tried the DTD#printExternal for the HTML40strict.xml.dtd with default encoding. Something weird seems to happen. For eg the original declaration is changed to "> And is changed to etc. I also noticed similar changes also happened with version 1.0.4, although the changes appear differently. Why is that ? Thank you ! TL xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Wed Oct 28 11:50:48 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:04 2004 Subject: Content v. attribute Message-ID: <00b401be0268$75792300$7008e391@bra01wmhkay.bra01.icl.co.uk> Don Park wrote: >Why not treat both city attribute and street element the same so that both >of them can be accessed with following DOM script? > >String city = address.getAttribute("city") >String street = address.getAttribute("street") > >In other words, why not treat attributes as a specific type of child >element: unique and childless? > SAXON provides the ability to treat (unique childless order-independent) sub-elements as pseudo-attributes of the parent element, accessible using getAttribute() very much as described. I've found that this can simplify some applications a lot. 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 M.H.Kay at eng.icl.co.uk Wed Oct 28 11:56:20 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:04 2004 Subject: Orgcharts Message-ID: <00c701be0269$56fa52e0$7008e391@bra01wmhkay.bra01.icl.co.uk> >My question is whether anyone knows of declarative descriptions for >organizational charts or other types of graphical data where the computer >can handle the layout. Are there DTDs, LaTeX packages, subsets of PDF, >APIs etc. worth looking at? You might like to look at CDIF, which is concerned with interchanging diagrams such as entity-relationship models where the topology is more important than the physical layout, and where the physical layout may be defined with different degrees of precision. See www.cdif.org I last looked at the detail about 5 years ago, I'm sure it's moved on since then. They are working on an XML encoding of their existing data model (replacing an ASN.1 encoding, I believe) 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 M.H.Kay at eng.icl.co.uk Wed Oct 28 12:19:32 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:04 2004 Subject: XML-QL Follow up Message-ID: <010e01be026c$8e827370$7008e391@bra01wmhkay.bra01.icl.co.uk> > For instance, I'd like to be able to issue something like: >select * from invoices where value() > 1000 >or >select * from musicians where name like 'Garcia' > Yes I think there's a need for this. Some observations: * You need to be clear whether you are aiming for a "boolean" style of predicate (every document either matches it or doesn't) or a "relevance ranking" approach. Your two examples illustrate the two types. SQL doesn't extend neatly to relevance ranking, which is far more effective than boolean queries for information retrieval applications. * If you want to do boolean queries, one approach is to define a mapping from XML to an object structure (the DOM?) and then use OQL. However, this would probably lead to very complex queries, with a lot of "there exists" and "for all" qualifiers to handle repeated child elements. If you want to reduce the complexity, you need to define a lot of "intuitive interpretations", e.g. "name like 'Garcia'" means "there exist one or more child elements N such that N.tag='name' and N.content.islike('Garcia')". The danger is that these can trip people over if their intuition is wrong - e.g. what does "name not like 'Garcia'" mean? * The real need is to make XML documents accessible to web search engines, where (a) the query language is already defined, and (b) the vast majority of queries are extremely simple. So it's not a new query language that's needed, but an intelligent interpretation of an existing query language in an XML context. 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 M.H.Kay at eng.icl.co.uk Wed Oct 28 12:26:42 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:04 2004 Subject: GEDCOM to XML? Message-ID: <011701be026d$838561c0$7008e391@bra01wmhkay.bra01.icl.co.uk> >There was some discussion on this list some time ago of expressing the >GEDCOM format in XML. > >Has there been any progress made on that? >Are there converters out there? Some, and yes. See http://home.iclweb.com/icl2/mhkay/GedML.html My approach with GedML was to define an XML encoding of the existing GEDCOM data model. this gives you two-way convertibility, but it means all the limitations of the GEDCOM data model are still there, so all you really get is easier parsing. Others have experimented with extending the data model, but then you start to lose out on interoperability. As always with standards it's hard work to move something forward when there is a large existing user base. 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 grk at arlut.utexas.edu Wed Oct 28 18:25:35 1998 From: grk at arlut.utexas.edu (Glenn R. Kronschnabl) Date: Mon Jun 7 17:06:04 2004 Subject: ID and tag value uniqueness, how? Message-ID: <199810281825.MAA02360@ns1.arlut.utexas.edu> Hi, I am doing a simple xml document that contains a list of action items. I want each action item to have a *unique* number that can automatically be validated during the parser process. This unique number should facilitate file integrity (give me an error when run thru a processor if there are duplicate entries) and be printed out as the identifier colument (think of an excel spreadsheet) when I print out the list. The question I am wrestling with is how is the best way (or is there a way?) to automagically guarantee/enforce uniqueness? I thought I could use an ID attribute, and specify a number (see Method 1 below), of course THIS IS INCORRECT! (ID's must start with a 'Letter'). I don't want to do something like id="num1" because then I would have to parse it, etc. Method 2 is simple, but I can't automagically check for uniqueness unless I write special code. Is it possible to use XML and/or DTD and/or the parser to generate unique ID's - I would think that would solve my (part of the) problem. [Of course, the numbering would change if an item got deleted, which is probably a bad thing since once the number is assigned to an item it should never change.] Thanks for any ideas/comments. Method 1 Modify acceptance test plan UT to modify acceptance test to include additional tests 1998-10-15 Joe Bob Test plan modified and sumbitted for review 1998-10-15 Joe Bob Method 2 1 Modify acceptance test plan UT to modify acceptance test to include additional tests 1998-10-15 Joe Bob Test plan modified and sumbitted for review 1998-10-15 Joe Bob Cheers, Glenn -------------------- Glenn R. Kronschnabl Applied Research Laboratories | grk@arlut.utexas.edu (PGP/MIME ok) The University of Texas at Austin | http://www.arlut.utexas.edu/~grk PO Box 8029, Austin, TX 78713-8029 | (Ph) 512.835.3642 (FAX) 512.835.3808 10,000 Burnet Road, Austin, TX 78758 | ... but an Aggie at heart! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 28 19:10:12 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:04 2004 Subject: ID and tag value uniqueness, how? In-Reply-To: <199810281825.MAA02360@ns1.arlut.utexas.edu> References: <199810281825.MAA02360@ns1.arlut.utexas.edu> Message-ID: <13879.27371.46539.266577@localhost.localdomain> Glenn R. Kronschnabl writes: > I don't want to do something like id="num1" because then I > would have to parse it, etc. It's not that bad, really. Try id=n00001, id=n00002, etc., and just strip off the first character in your application (no significant parsing required). That said, if there is not an obvious way to represent a particular validation constraint using a DTD, you usually shouldn't try -- XML itself is just a representation syntax; it shouldn't become a Golden Hammer for every type of work. XML has to work together with other technologies to provide any real-world application. 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 Oct 28 20:28:05 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:06:04 2004 Subject: Building XML Applications, in Beta Message-ID: <199810282027.PAA13355@hesketh.com> _Building XML Applications_, a book (by myself and Ethan Cerami) describing the developmet of Java applets and applications that process XML, will be coming out from McGraw-Hill in December or January. While the copy editors edit and the presses roll, however, you can take a free look at the raw manuscript of the book. http://www.pbg.mcgraw-hill.com/betabooks/stlaurent/index.html Chapters 1, 4, 5, 6, and 7 (the intro to the book and the tutorial on XML syntax) are currently posted; more chapters will follow as their production staff gets to them. Please ignore the bullets on the cover mockup - it's just a mockup. (They even got my name wrong.) For real information about what the book will cover, visit: http://www.simonstl.com/buildxml/index.html Sample applets and more information will be posted there eventually, when my head returns to this time zone... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 Suli.Ding at geis.ge.com Thu Oct 29 01:24:32 1998 From: Suli.Ding at geis.ge.com (Ding, Suli (GEIS)) Date: Mon Jun 7 17:06:04 2004 Subject: DTD for X12 or EDIFACT Message-ID: I have just move my home page to http://www.geocities.com/SiliconValley/Platform/4871/ Please make a note and update your link. Best regards, Suli Ding > ---------- > From: Ding, Suli (GEIS)[SMTP:Suli.Ding@geis.ge.com] > Reply To: Ding, Suli (GEIS) > Sent: Monday, October 26, 1998 10:56 PM > To: 'xmledi-list@lists.bizserve.com'; 'xml-dev@ic.ac.uk' > Subject: RE: DTD for X12 or EDIFACT > > I have sent out the following message some times ago. Some people sent me > e-mail wants to know what my program does. I created a web page just for > that. If you are interest, please visit > http://www.geocities.com/EnchantedForest/Tower/2701 > > Regards, > > Suli Ding > > > > > ---------- > > From: Ding, Suli (GEIS)[SMTP:Suli.Ding@geis.ge.com] > > Reply To: Ding, Suli (GEIS) > > Sent: Friday, October 09, 1998 9:42 AM > > To: 'xmledi-list@lists.bizserve.com' > > Subject: DTD for X12 or EDIFACT > > > > Is there a DTD defined for any document type of ANSI X12 or EDIFACT? > Where > > can it be found? > > > > I have a program can produce a XML document (well formatted) from almost > > any > > input data by a data definition file. I try it on some small > interchanges > > and UDF files. But I would like to apply it to ANSI X12 or EDIFACT. > > > > Thanks, > > > > Suli Ding > > > > > > > > ========================================== > > XML/EDI Group members-only discussion list > > Homepage = http://www.xmledi.com > > > > Brought to you by: Online Technologies Corporation > > Home of BizServe - www.bizserve.com > > > > TO UNSUBSCRIBE: Send email to > > Leave the subject blank, and > > In the body of the message, enter ONLY: unsubscribe > > > > Questions/requests should be sent to: owner-xmledi-list@bizserve.com > > To join the XML/EDI Group complete the form located at: > > http://www.geocities.com/WallStreet/Floor/5815/mail1.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 Suli.Ding at geis.ge.com Thu Oct 29 03:07:16 1998 From: Suli.Ding at geis.ge.com (Ding, Suli (GEIS)) Date: Mon Jun 7 17:06:05 2004 Subject: FW: DTD for X12 or EDIFACT Message-ID: > I have just move my home page to > http://www.geocities.com/SiliconValley/Platform/4871/ > > Please make a note and update your link. > > Best regards, > > Suli Ding > > ---------- > From: Ding, Suli (GEIS)[SMTP:Suli.Ding@geis.ge.com] > Reply To: Ding, Suli (GEIS) > Sent: Monday, October 26, 1998 10:56 PM > To: 'xmledi-list@lists.bizserve.com'; 'xml-dev@ic.ac.uk' > Subject: RE: DTD for X12 or EDIFACT > > I have sent out the following message some times ago. Some people sent me > e-mail wants to know what my program does. I created a web page just for > that. If you are interest, please visit > http://www.geocities.com/EnchantedForest/Tower/2701 > > Regards, > > Suli Ding > > > > > ---------- > > From: Ding, Suli (GEIS)[SMTP:Suli.Ding@geis.ge.com] > > Reply To: Ding, Suli (GEIS) > > Sent: Friday, October 09, 1998 9:42 AM > > To: 'xmledi-list@lists.bizserve.com' > > Subject: DTD for X12 or EDIFACT > > > > Is there a DTD defined for any document type of ANSI X12 or EDIFACT? > Where > > can it be found? > > > > I have a program can produce a XML document (well formatted) from almost > > any > > input data by a data definition file. I try it on some small > interchanges > > and UDF files. But I would like to apply it to ANSI X12 or EDIFACT. > > > > Thanks, > > > > Suli Ding > > > > > > > > ========================================== > > XML/EDI Group members-only discussion list > > Homepage = http://www.xmledi.com > > > > Brought to you by: Online Technologies Corporation > > Home of BizServe - www.bizserve.com > > > > TO UNSUBSCRIBE: Send email to > > Leave the subject blank, and > > In the body of the message, enter ONLY: unsubscribe > > > > Questions/requests should be sent to: owner-xmledi-list@bizserve.com > > To join the XML/EDI Group complete the form located at: > > http://www.geocities.com/WallStreet/Floor/5815/mail1.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 peter at ursus.demon.co.uk Thu Oct 29 07:28:59 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:06:05 2004 Subject: XSchema: various In-Reply-To: <01BE0263.FA1FF9D0@grappa.ito.tu-darmstadt.de> Message-ID: <3.0.1.16.19981028225057.0a47218a@pop3.demon.co.uk> At 11:13 28/10/98 +0100, Ronald Bourret wrote: >In the last round of reviews, a couple of minor changes have been suggested. I list these below for review. If nobody objects by end of day Friday, I will add these to the current spec (along with some minor editorial changes) and publish a final, definitive, we're-done (really) version this weekend. This is excellent news , Ron - well done. I am looking forward to bolting this in to JUMBO where it will form a tool for editing XSchemas and also editing Documents. If there is a DTD2XChema converter - in Java - as well that would be wonderful. 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 jtauber at jtauber.com Thu Oct 29 08:51:03 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:06:05 2004 Subject: GEDCOM to XML? Message-ID: <00b701be0318$da8face0$0300000a@othniel.cygnus.uwa.edu.au> -----Original Message----- From: Deke Smith >There was some discussion on this list some time ago of expressing the >GEDCOM format in XML. > >Has there been any progress made on that? I've got Michael Kay's stuff referenced at http://www.schema.net/ and will add any more as I come across it. I'm particularly interested in this personally as I'm into genealogy. What we need now is a nice routine for producing pedigree charts in PGML or VML :-) 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 tony.mcdonald at newcastle.ac.uk Thu Oct 29 08:51:56 1998 From: tony.mcdonald at newcastle.ac.uk (Tony McDonald) Date: Mon Jun 7 17:06:05 2004 Subject: XML support to be rolled into PHP (a free, server-side, HTML embedded scripting language) Message-ID: Hi all, This is just to let you know that with the next version (3.06) of PHP (currently 3.05 http://www.php.net/ ) XML support using Expat will be rolled into the release. There's more details, including some preliminary documentation at http://www.guardian.no/~ssb/phpxml.html One thing - PHP is free, open source. I'm a *very* happy user of it, and very excited about soon being able to use PHP with XML. Some background: PHP is a server-side, cross-platform, HTML embedded scripting language. It can be rolled into a web-server as an Apache module or CGI It supports many databases (Oracle, MySQL, MSQL etc.) Active mailing lists and developers hth tone out. ------ Dr Tony McDonald, FMCC, The Medical School, Newcastle University Tel: +44 191 222 5888 Fax +44 191 222 5016 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Thu Oct 29 09:44:28 1998 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:06:05 2004 Subject: ID and tag value uniqueness, how? Message-ID: <01BE0328.746D2E00@grappa.ito.tu-darmstadt.de> Glenn R. Kronschnabl wrote > I want each action item to have a *unique* number that can > automatically be validated during the parser process. The other thing to consider is whether the parser will even enforce uniqueness. This is a validity constraint, and lots of parsers don't enforce validity. So your choice is either to always use a known, validating parser or write the enforcement code yourself. -- 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 ht at cogsci.ed.ac.uk Thu Oct 29 14:49:30 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:06:05 2004 Subject: there's empty, and then there's REALLY empty Message-ID: <20906.199810291449@mcilvanney.cogsci.ed.ac.uk> I'd be interested in reports from validating parsers wrt the following: ]> ∅     &space; You might be interested in trying to predict the results BEFORE running the parser. nsgmls -wxml -c .../xml.soc gives a surprising answer, which I'll post tomorrow. ht xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Oct 29 15:03:28 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:06:05 2004 Subject: there's empty, and then there's REALLY empty Message-ID: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> -----Original Message----- From: Henry S. Thompson [...] >You might be interested in trying to predict the results BEFORE >running the parser. > >nsgmls -wxml -c .../xml.soc > >gives a surprising answer, which I'll post tomorrow. But does nsgmls, even with -wxml and an appropriate SGML declaration, handle whitespace in an XML 1.0 REC conforming way? James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Associate Researcher, Electronic Commerce Network Curtin University of Technology, Perth, Western Australia xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Thu Oct 29 15:36:58 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:06:05 2004 Subject: there's empty, and then there's REALLY empty In-Reply-To: "James Tauber"'s message of "Thu, 29 Oct 1998 23:00:04 +0800" References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: "James Tauber" writes: > From: Henry S. Thompson > > >You might be interested in trying to predict the results BEFORE > >running the parser. > > > >nsgmls -wxml -c .../xml.soc > > > >gives a surprising answer, which I'll post tomorrow. Sorry, I'm being too abbreviated. It's nsgmls -s -wxml -c .../xml.soc that produces a surprising result, i.e. it's not the ESIS I'm surprised at, it's the error message(s). ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 29 16:26:39 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:06:05 2004 Subject: XML WG Reorganization questions Message-ID: <199810291626.LAA26917@hesketh.com> Between XML.com's report (http://www.xml.com/xml/pub/98/10/xmlgroups.html) and the XML Activity statement at the W3C (http://www.w3.org/XML/Activity.html) I feel like I have a decent grasp of where the W3C is headed with XML - better, at least, than I've had in a while. Two big questions, however: 1) I don't see where namespaces are listed as any of these groups' work, though the activity statement still mentions them as W3C work. 2) Is the Fragment Working Group the descendant of XPointer, or something else? XPointer started out with XLink, but seems to be migrating further and further away from its origins. Looks good! Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 Thu Oct 29 17:25:43 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:05 2004 Subject: XML WG Reorganization questions In-Reply-To: <199810291626.LAA26917@hesketh.com> References: <199810291626.LAA26917@hesketh.com> Message-ID: <13880.41944.974605.304126@localhost.localdomain> Simon St.Laurent writes: > Between XML.com's report > (http://www.xml.com/xml/pub/98/10/xmlgroups.html) and the XML > Activity statement at the W3C (http://www.w3.org/XML/Activity.html) > I feel like I have a decent grasp of where the W3C is headed with > XML - better, at least, than I've had in a while. Good -- it's a big reorganisation, and it had to be approved by the membership first, so it took a while for the W3C to be in a position to announce anything. > Two big questions, however: > > 1) I don't see where namespaces are listed as any of these groups' > work, though the activity statement still mentions them as W3C > work. Like that doll in the horror movies (what's its name?), namespaces won't go away. Sorry to be coy, but stay tuned... > 2) Is the Fragment Working Group the descendant of XPointer, or > something else? XPointer started out with XLink, but seems to be > migrating further and further away from its origins. It's something else. XPointer and XLink both belong to the XML Linking WG. Think of the XML Fragment WG as dealing with cut-and-paste (apologies to Paul Grosso for the disgusting over-simplification). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From db at Eng.Sun.COM Thu Oct 29 17:54:58 1998 From: db at Eng.Sun.COM (db@Eng.Sun.COM) Date: Mon Jun 7 17:06:05 2004 Subject: JavaOne and XML Message-ID: <199810291748.JAA09001@argon.eng.sun.com> [ Resend -- my Tuesday morning post didn't get out ] > From db Tue Oct 27 08:51:29 1998 > To: b.laforge@jxml.com, jp@ncfocus.com, xml-dev@ic.ac.uk > Subject: Re: JavaOne and XML > Cc: nklee > > > From: "Bill la Forge" > > To: "David Brownell" , , > > "JP Morgenthal" > > Subject: Java One and XML > > Date: Mon, 26 Oct 1998 07:20:05 -0500 > > > > I was just glancing over the session tracks for Java One and > > saw nothing on XML. > > That's right -- this year's JavaOne didn't have presentations on XML. > My group, and various other companies, had XML technology demos on the > show floor. (The XML conference up in Redmond, the same week, featured > mostly Java-centric development!) > > The tracks for next year's JavaOne (mid-June) are not yet known. > > > > I was thinking about a Birds of a Feather, but I was wondering if > > there was enough interest to do a pannel discussion or something. > > > > Proposals are due October 30th: > > http://java.sun.com/javaone/javaone99/call.html > > Please submit a proposal, then! BOFs can usually be done on short > notice, but talks and panel discussions are a bit different. > > That lead-time is a bit long; JavaOne is a huge show. There's also > the smaller XTech'99 conference in late March (or is it early April?), > sponsored by GCA and focussing on XML. It'll be in San Jose. That > hasn't yet issued its call for papers. > > - 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 peter at ursus.demon.co.uk Thu Oct 29 18:16:25 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:06:05 2004 Subject: LISTRIVIA In-Reply-To: Message-ID: <3.0.1.16.19981029084121.b5d70d86@pop3.demon.co.uk> At 13:57 28/10/98 -0500, Ding, Suli (GEIS) wrote (and crossposted to another list) : >I have just move my home page to > http://www.geocities.com/SiliconValley/Platform/4871/ > >Please make a note and update your link. And then quoted two large messages including the XML-DEV signature. Please avoid unnecessary postings and volume to XML-DEV. It should be used for matters of interest to XML developers. Other places to use are: - FAQs and other introductory material are available from http://www.ucc.ie/xml and http://www.oasis-open.org/cover - There are specialists lists for XSL, and RDF - There is a general list XML-L 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 cowan at locke.ccil.org Thu Oct 29 18:31:55 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:06:05 2004 Subject: there's empty, and then there's REALLY empty References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <3638B491.4D5923DF@locke.ccil.org> Henry S. Thompson wrote: > Sorry, I'm being too abbreviated. It's > > nsgmls -s -wxml -c .../xml.soc > > that produces a surprising result, i.e. it's not the ESIS I'm > surprised at, it's the error message(s). Well, I guess what surprises me is that there's only one error message rather than two. For whatever reason, nsgmls is totally ignoring zero-length CDATA sections rather than following the rules from clause 3.2.1. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Oct 29 19:09:38 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:05 2004 Subject: there's empty, and then there's REALLY empty In-Reply-To: <3638B491.4D5923DF@locke.ccil.org> References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> Message-ID: <13880.48044.200328.880424@localhost.localdomain> John Cowan writes: > Well, I guess what surprises me is that there's only one error > message rather than two. For whatever reason, nsgmls is totally > ignoring zero-length CDATA sections rather than following the rules > from clause 3.2.1. It doesn't surprise me that hammers cannot turn screws very well. Remember that NSGMLS, like the PSGML editor, is a general-purpose SGML tool that happens to be able to handle XML documents without gagging. XML imposes additional constraints beyond SGML, some of which are stated explicitly and some of which are implicit in the (very considerable) differences between the ISO 8879 and XML 1.0 syntactic productions. Since neither NSGMLS nor PSGML actually uses the XML 1.0 syntactic productions for parsing, both miss some XML-specific errors (and are thus non-conformant), though they shouldn't report spurious errors. If you're interested in purity-checking, you need to use a tool that is actually built on top of the XML 1.0 productions, like James's Expat. 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 philipr at webdialog.com.au Fri Oct 30 01:52:50 1998 From: philipr at webdialog.com.au (Philip Rutherford) Date: Mon Jun 7 17:06:05 2004 Subject: XPointer question Message-ID: <36391B67.9BFC5612@webdialog.com.au> Does anyone know how to specify elements relative to the current element using XPointer. For example in the following XML: Does child(1) refer to or does it refer to the first child of the whole document? Thanks -- Philip -------------------------------------------------------------- Philip Rutherford E-mail: philipr@webdialog.com.au webdialog pty.ltd. Tel: +61 2 96600165 PO Box 131, Annandale NSW 2038, Australia. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gotou at flab.fujitsu.co.jp Fri Oct 30 03:00:14 1998 From: gotou at flab.fujitsu.co.jp (Masatomo Goto) Date: Mon Jun 7 17:06:05 2004 Subject: XPointer question In-Reply-To: <36391B67.9BFC5612@webdialog.com.au> Message-ID: <4.0.1-J.19981030113801.010f93c0@pop.akashi.flab.fujitsu.co.jp> Hello, At 12:50 98/10/30 +1100, Philip Rutherford wrote: > Does anyone know how to specify elements relative to the current element > using XPointer. > For example in the following XML: > > > > > > Does child(1) refer to or does it refer to the first child of > the whole document? If element is a simple link and 'inline' attribute is 'true', you can point element by specifying like following: For more detail, But this representation is no meaning because inline resource is also the same element . And, as shown above my example, before specifying XPointer, you must write a connector(# or |). Unless, that string is recognized as a URI. See XLink draft '2. Locator Syntax'. - Masatomo Goto --- Masatomo Goto Information Service Architecture lab. Fujitsu Laboratories Ltd. Tel: +81-78-934-8249 Fax: +81-78-934-3312 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 30 07:00:05 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:06:05 2004 Subject: Java version of FOP now available Message-ID: <013001be03d2$85459d20$0300000a@othniel.cygnus.uwa.edu.au> I've spent the last week porting FOP (my formatting object to PDF translator) over to Java and it's now available. FOP takes the FO output of something like XT and produces a PDF file. Porting was made very easy by Python's integration with Java which enabled me to port a class at a time, testing all along the way. That having been said, FOP is still early alpha. The Java version (0.4.0) doesn't do any more than the Python version did. So it still supports a limited number of formatting objects and properties on those objects. Limited testing has been done and nothing is optimized. If you are interested in trying it out and letting me know what you'd like added to make it useful, please have a look at http://www.jtauber.com/fop/ where you can get a jar. You'll also need XP and SAX. 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 Craig_Gingell at Dell.com Fri Oct 30 09:39:44 1998 From: Craig_Gingell at Dell.com (Craig_Gingell@Dell.com) Date: Mon Jun 7 17:06:05 2004 Subject: GEDCOM to XML? Message-ID: Should we just mirror the functionality of GEDCOM in XML ? The GEDCOM standard does not exploit the power of publishing genealogical information to the web. Routines like GED2HTML do not generate good looking pages. I understand the dangers of veering from the spec, but I have found to my own experience that GEDCOM is kind of lacking in several areas. To this end, I prefer to maintain my ever growing genealogical database in XML and not GEDCOM. I can still import from, and export to the GEDCOM format. I have richer content, and can easily manage features like image galleries, email, hypertext links, and especially the geography aspect of the relationship between villages, towns, countries and people. I have encompassed pedigree charts to a certain extent using HTML tables, but I would be the first to admit it is a bit of a cludge. http://www.gingell.com/ancframe.html I would like to see GedML add value to GEDCOM, especially in the areas of web publishing. Regards Craig Gingell http://www.gingell.com - a website dedicated to anything and everything Gingell http://www.gingell.com/data/gingell.txt - my XML genealogy 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 larsga at ifi.uio.no Fri Oct 30 09:51:23 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:06:05 2004 Subject: GEDCOM to XML? In-Reply-To: Message-ID: <3.0.5.32.19981030105006.00bd18f0@post.step.de> * Craig_Gingell@Dell.com | | I would like to see GedML add value to GEDCOM, especially in the areas of | web publishing. Since GEDCOM is so widely deployed, wouldn't it be a good idea to have GedML as "the XML representation of GEDCOM", and then to overcome the limitations of the GedML/GEDCOM data model by developing an entirely new schema in XML? This should make it easier to convert between GEDCOM and XML, and also give the new standard much greater freedom. (Disclaimer: I don't know GEDCOM at all, but have been a little thinking about this lately.) --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 ht at cogsci.ed.ac.uk Fri Oct 30 10:15:29 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:06:06 2004 Subject: there's empty, and then there's REALLY empty In-Reply-To: 's message of "Thu, 29 Oct 1998 14:08:17 -0500 (EST)" References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> <13880.48044.200328.880424@localhost.localdomain> Message-ID: I offered: ]> ∅ &space; wrote: [Don't use nsgmls as a reference validator for XML] John Cowan writes: [both CDATA sections should be rejected] OK, so the cat is out of the bag, nsgmls does indeed generate ONE error, for the . I'm not under any illusions about nsgmls as a reference standard, it's really that I can't make sense of an interpretation of 3.2.1 which ALLOWS the two entity references and (what John and, if I read David's mesage correctly, David, expect, and as at least the online validating parser from Richard Goerwitz/the Brown Scholarly Technology Group does) disallows the two CDATA sections. [Note that expat is NOT a validating parser, and swallows the file without comment] The problem here is a fundamental one with respect to the very nature of validation and well-formedness, which I know the editors were aware of, but could not fully resolve at the time of publication. I think of it as the 'raw' versus 'cooked' problem. Most of the well-formedness constraints are on the raw document, that is, the input character sequence as such, pre-interpretation of e.g. entity references, marked or CDATA sections. Most of the validity constraints, in particular the content-model enforcing ones, are on the cooked document, that is, the effective character sequence AFTER interpretation of . . . well, that's the problem, isn't it. In order to make sense of a claim that the two entity references in my example are valid, but the two CDATA sections are not, we are left in the difficult position of saying that the validity constraint in question applies AFTER entity expansion but BEFORE CDATA section interpretation, which is really weird, because wrt e.g. mixed content models, the constraint clear applies AFTER CDATA section interpretation. So my conclusion is that in fact consistency requires that CDATA sections containing nothing but whitespace SHOULD be valid as part of the content of element-only content element types. In any case, I think this issue needs to be clarified in any corrigendum which may be forthcoming. ht Resource note: I tried all the online validators listed at http://www.oasis-open.org/cover/check-xml.html: * The STG one worked as discussed above; * the Koala one showed me blank pages no matter how I invoked it; * the xml.t2000.co.kr offers a bewildering array of (to me confused) choices, including validation with or without a DTD (?), but in any case rejected both the entity references and both the CDATA sections; * the WebTech validator appears to be using SP, but set up incorrectly for XML So from four 'validation services', four different answers. I rest my case. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Fri Oct 30 10:19:46 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:06 2004 Subject: ID and tag value uniqueness, how? Message-ID: <004101be03ee$287998f0$7008e391@bra01wmhkay.bra01.icl.co.uk> >> I want each action item to have a *unique* number that can >> automatically be validated during the parser process. >The other thing to consider is whether the parser will even enforce uniqueness. This is a validity constraint, >and lots of parsers don't enforce validity. So your choice is either to always use a known, validating parser or >write the enforcement code yourself. I've hit this problem myself. One thing I would like in SAX 2.0 is the ability to tell the parser that I expect it to do validation. In practice because I couldn't rely on the parser to check uniqueness, and because I was doing so much other "semantic" validation anyway (e.g. valid dates, etc), I decided that I might as well do the uniqueness check myself. I needed to build a dictionary of identifiers anyway to resolve IDREF references: a validating parser will tell you whether an IDREF is valid, but it won't necessarily tell you what it points to! Mike Kay PS. What confused me in the original question, however, was: >Is it possible to use XML and/or DTD and/or the parser to generate unique >ID's - I would think that would solve my (part of the) problem. Generating ID's during parsing is of course is a different question from validating IDs stored in the original XML. One easy way to get numbers generated during parsing is to use SAXON - there is an example in the automatic numbering of verses in the New Testament rendition I published recently on this list. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Oct 30 15:06:10 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:06:06 2004 Subject: The raw and the cooked (was: there's empty ...) References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> <13880.48044.200328.880424@localhost.localdomain> Message-ID: <3639D5D1.B83FF8C7@locke.ccil.org> Henry S. Thompson writes: > In order > to make sense of a claim that the two entity references in my example > are valid, but the two CDATA sections are not, we are left in the > difficult position of saying that the validity constraint in question > applies AFTER entity expansion but BEFORE CDATA section > interpretation, I don't know what "CDATA section interpretation" means. CDATA sections are not "interpreted", but merely scanned to find the end. In fact, CDATA elements can be returned to the application as specialized blocks (the DOM allows it, though SAX does not do so); an XML parser *never* needs to look inside a CDATA section after its terminator has been found. > which is really weird, because wrt e.g. mixed content > models, the constraint clear applies AFTER CDATA section > interpretation. I don't understand which constraint you are referring to in the case of mixed content models. Elements with element content can only have S between the tags, and CDATA elements aren't S. > So my conclusion is that in fact consistency requires that CDATA > sections containing nothing but whitespace SHOULD be valid as part of > the content of element-only content element types. In any case, I > think this issue needs to be clarified in any corrigendum which may be > forthcoming. > > ht > > Resource note: > > I tried all the online validators listed at > http://www.oasis-open.org/cover/check-xml.html: > > * The STG one worked as discussed above; > > * the Koala one showed me blank pages no matter how I > invoked it; > > * the xml.t2000.co.kr offers a bewildering array of (to me > confused) choices, including validation with or without a DTD (?), but > in any case rejected both the entity references and both the CDATA > sections; > > * the WebTech validator appears to be using SP, but set up incorrectly for XML > > So from four 'validation services', four different answers. I rest my > case. > > ht > -- > Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) -- 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 Philippe.Le_Hegaret at sophia.inria.fr Fri Oct 30 15:06:32 1998 From: Philippe.Le_Hegaret at sophia.inria.fr (Philippe Le Hégaret) Date: Mon Jun 7 17:06:06 2004 Subject: Netscape is running an XML app! References: <3.0.5.32.19981024070514.00ce4690@scripting.com> Message-ID: <3639D5C8.5D66B531@sophia.inria.fr> Dave Winer wrote: > > Yesterday I got an email from Jeff Veen at Wired pointing me to the server > that Netscape is running its What's Related? application on. This is the > project they did with Alexa, and it's the back-end for the What's Related? > feature in Netscape 4.5. > > I had a little time to kill, was looking for a diversion, so I sent a > message to Netscape's server via script and I was blown away. It's XML! Yes > it is. And why, oh why, didn't they tell anyone? (Or did I miss something?) Sorry but this is not an XML application. Netscape doesn't escape the ampersand character in their format : See the Rule 10 of the XML specification. Philippe. --------- Philippe Le Hegaret Philippe.Le_Hegaret@sophia.inria.fr -- http://www.inria.fr/koala/plh/ KOALA/DYADE/BULL @ INRIA - Sophia Antipolis xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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.foster at bt-sys.bt.co.uk Fri Oct 30 15:17:00 1998 From: paul.foster at bt-sys.bt.co.uk (Paul Foster) Date: Mon Jun 7 17:06:06 2004 Subject: XML CASE Structure Message-ID: I know the answer to this will probably be no but I thought I would check with the reflector anyway. When defining a structure in "some" programming languages it is possible to have alternate strutcure parts based upon a preceding attribute's value in the strutcure ie. the CASE statement. Is it possible to mimick a "CASE" type feature in a single XML DTD based upon the actual value of one of its elements. I think the answer is no. However, the way I am thinking of to achieve this functionality is to re-direct the XML application to another DTD when it comes across an element type called say "DTDReDirect", the value of which gives the location of the new DTD. Any alternatives and better ways of doing this would be appreciated. Regards Paul Foster BT Labs, UK xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 30 15:37:05 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:06 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: <3639D5D1.B83FF8C7@locke.ccil.org> References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> <13880.48044.200328.880424@localhost.localdomain> <3639D5D1.B83FF8C7@locke.ccil.org> Message-ID: <13881.55381.777990.483844@localhost.localdomain> So, Henry's asking whether this is valid: ]> I'd like to hear Tim Bray's opinion, unless I've missed it already in this thread (are you reading this, Tim, or alternatively, do you have an e-mail filter that looks for your name?). My hunch is that this example *is* valid -- after all, the "" means "go back to the regular delimiter-recognition mode": neither implies anything about the contents. Now, I'd like to reply to what John Cowan wrote: > In fact, CDATA elements can be returned to the application as > specialized blocks (the DOM allows it, though SAX does not do so); > an XML parser *never* needs to look inside a CDATA section after > its terminator has been found. This is an interesting interpretation, but it requires some clarification: 1. There is no such thing as a "CDATA element" -- CDATA sections are lexical. In fact, the XML 1.0 REC does make it clear that the function of a CDATA section is purely escaping, and that its contents are equivalent to character data (see clause 2.7). There is no explicit statement allowing parsers to treat CDATA sections specially (as there is for comments in clause 2.5), though there is no statement forbidding it either. 2. The XML 1.0 REC says nothing about what information the parser should deliver to the application when it encounters a CDATA section (the XML 1.0 REC is weak in this area generally, but we're working to fix the problem in the XML Information Set WG). Presumably, because of #1, the rule in clause 2.10 that "an XML processor must always pass all characters in a document that are not markup through to the application" applies here. 3. John's statement that the XML parser *never* needs to look inside a CDATA section after finding the terminator is not quite right -- all of the contents must match the production Char [2], so the parser has to check to make certain that there are no illegal characters within the section (such as form feeds). The version of AElfred that I wrote doesn't bother to do this checking, but it's non-conforming (I haven't checked Matt's latest versions). 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 ht at cogsci.ed.ac.uk Fri Oct 30 16:09:03 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:06:06 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: 's message of "Fri, 30 Oct 1998 10:36:00 -0500 (EST)" References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> <13880.48044.200328.880424@localhost.localdomain> <3639D5D1.B83FF8C7@locke.ccil.org> <13881.55381.777990.483844@localhost.localdomain> Message-ID: writes: > So, Henry's asking whether this is valid: > > > > > ]> > > > [good analysis deleted] What he said. The DOM made a serious mistake here in my opinion: it's stranded in no-person's-land between raw and cooked, without being either. It's not cooked, because it gives you EntityReference and CDATA nodes. It's not raw, because it DOESN'T give you character entity references. To John Cowan: My original illustrates the point: if you use the presence of the CDATA node in the DOM tree to argue against the validity of the above based on "Elements with element content can only have S between the tags, and CDATA elements aren't S" then why doesn't this apply to EntityReference elements as well, since THEY clearly aren't S either? ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at goon.stg.brown.edu Fri Oct 30 16:13:21 1998 From: richard at goon.stg.brown.edu (Richard L. Goerwitz III) Date: Mon Jun 7 17:06:06 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: <13881.55381.777990.483844@localhost.localdomain> from "david@megginson.com" at "Oct 30, 98 10:36:00 am" Message-ID: <199810301612.LAA03890@goon.stg.brown.edu> > So, Henry's asking whether this is valid: > > > > > ]> > Just for fun, try running this through our validator: http://www.stg.brown.edu/service/xmlvalid/ I'm sure you can spot the other (accidental) error, in addi- tion to the one we've been discussing. As for the marked section: By our interpretation, CDSects are atomic, and make up document content. They aren't the same thing as CharData: content ::= (element | CharData | Reference | CDSect | PI | Comment)* By our interpretation, comments, processing instructions, and whitespace are allowed in places where content is not, e.g., after the DTD, but before (or after) the top-level start/end tag of the document itself: Misc ::= Comment | PI | S By our interpretation also, comments, processing instructions, and whitespace may separate elements in cases like the above. Here's a brief rewrite that illustrates: Entities (which act a bit like preprocessor directives) may also take the place of comments, PIs, or whitespace, if they map to whitespace or an empty string. That at least is how we thought about things, and why we implemented our validator the way we did. Richard Goerwitz Scholarly Technology Group xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 30 16:24:22 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:06 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> <13880.48044.200328.880424@localhost.localdomain> <3639D5D1.B83FF8C7@locke.ccil.org> <13881.55381.777990.483844@localhost.localdomain> Message-ID: <13881.58727.329341.778923@localhost.localdomain> Henry S. Thompson writes: > writes: > > > So, Henry's asking whether this is valid: > > > > > > > > > > > ]> > > And I'll answer my original posting and say that it's not valid because it's not well-formed -- let's try ]> instead, and continue the discussion from there. > What he said. The DOM made a serious mistake here in my opinion: > it's stranded in no-person's-land between raw and cooked, without > being either. It's not cooked, because it gives you > EntityReference and CDATA nodes. It's not raw, because it DOESN'T > give you character entity references. The DOM level-one core serves two constituencies -- authoring tools that need to do horizontal transformations (XML=>XML, where the result replaces the original) and processing/rendering tools that need to do downstream processing (XML=>XML or XML=>X, where the original remains unaltered). Horizontal transformations will usually be somewhat lossy, and the DOM WG has clearly decided that only a few lexical features were important enough to give a good cost/benefit return on the effort required to specify and implement them. However, the point is that a specific DOM tree doesn't *have* to include nodes for comments, CDATA sections, and entity references -- they are there only to support very specialised applications and should be stripped out for ordinary XML processing. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Oct 30 16:33:03 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:06 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: <199810301612.LAA03890@goon.stg.brown.edu> References: <13881.55381.777990.483844@localhost.localdomain> <199810301612.LAA03890@goon.stg.brown.edu> Message-ID: <13881.59386.708534.971919@localhost.localdomain> Richard L. Goerwitz III writes: > Just for fun, try running this through our validator: > > http://www.stg.brown.edu/service/xmlvalid/ > > I'm sure you can spot the other (accidental) error, in addi- > tion to the one we've been discussing. Yes, my gray-coloured organic validator caught that one when I saw it quoted in Henry's post. I agree with Richard that comments and PIs are also allowed in element content (and I suspect that he's right about entity references as well), but I disagree that CDATA sections are atomic: remember that the XML 1.0 REC contains only syntactic productions, not a data model. To help the discussion, here is the relevant clause from the XML 1.0 REC: ====================8<====================8<==================== 2.7 CDATA Sections CDATA sections may occur anywhere character data may occur; they are used to escape blocks of text containing characters which would otherwise be recognized as markup. CDATA sections begin with the string "": CDATA Sections [18] CDSect ::= CDStart CData CDEnd [19] CDStart ::= '' Char*)) [21] CDEnd ::= ']]>' Within a CDATA section, only the CDEnd string is recognized as markup, so that left angle brackets and ampersands may occur in their literal form; they need not (and cannot) be escaped using "<" and "&". CDATA sections cannot nest. An example of a CDATA section, in which "" and "" are recognized as character data, not markup: Hello, world!]]> ====================8<====================8<==================== This doesn't really give us enough to go on, but one could choose to attach some weight to the statement in the opening paragraph that CDATA sections are used to "escape blocks of text", and to the statement that in the final example the contents of the section "are recognized as character data". 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 richard at cogsci.ed.ac.uk Fri Oct 30 16:36:38 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:06:06 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: Henry S. Thompson's message of 30 Oct 1998 16:08:45 +0000 Message-ID: <199810301634.QAA23671@cogsci.ed.ac.uk> > What he said. The DOM made a serious mistake here in my opinion: it's > stranded in no-person's-land between raw and cooked, without being > either. It's not cooked, because it gives you EntityReference and > CDATA nodes. It's not raw, because it DOESN'T give you character > entity references. Note that the XML 1.0 recommendation requires that character and internal entities be expanded before passing the data to the application. Of course, this just illustrates that a conforming processor isn't always what you want. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Oct 30 16:46:31 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:06 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: <199810301634.QAA23671@cogsci.ed.ac.uk> References: <199810301634.QAA23671@cogsci.ed.ac.uk> Message-ID: <13881.60442.679503.174417@localhost.localdomain> Richard Tobin writes: > Note that the XML 1.0 recommendation requires that character and > internal entities be expanded before passing the data to the > application. It doesn't forbid the parser from informing the application about what has been expanded. In an event-based API, for example, for text &foo; text the parser could deliver an event stream like characters("text ") startEntityRef("foo") characters("entity value") endEntityRef("foo") characters(" text") For normal downstream processing, this level of reporting is simply a waste of resources, but it could be essential for authoring tools. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Oct 30 17:15:19 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:06:06 2004 Subject: CDATA by any other name... (was The raw and the cooked) Message-ID: <000701be0428$675cf1e0$0300000a@othniel.cygnus.uwa.edu.au> -----Original Message----- From: Henry S. Thompson >What he said. The DOM made a serious mistake here in my opinion: it's >stranded in no-person's-land between raw and cooked, without being >either. It's not cooked, because it gives you EntityReference and >CDATA nodes. It's not raw, because it DOESN'T give you character >entity references. Notwithstanding your main point, it is worth noting that entity references and character references are handled differently (q.v. literal entity value versus replacement text) so at least in this regard, a cooked-raw distinction isn't fine enough. 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 cowan at locke.ccil.org Fri Oct 30 17:25:04 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:06:07 2004 Subject: CDATA by any other name... (was The raw and the cooked) References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> <13880.48044.200328.880424@localhost.localdomain> <3639D5D1.B83FF8C7@locke.ccil.org> <13881.55381.777990.483844@localhost.localdomain> Message-ID: <3639F66E.10EC3445@locke.ccil.org> david@megginson.com wrote: > This is an interesting interpretation, but it requires some > clarification: Hey, I like that: a polite way of saying "You're all wet." > 1. There is no such thing as a "CDATA element" A mere blunder for "CDATA section". > [A] CDATA section['s] > contents are equivalent to character data (see clause 2.7). You're kicking the ball through your own goalposts here. Clause 3.2.1 says: # [E]lement content [...] must contain only child elements # (no character data), optionally separated by white space # (characters matching the nonterminal S). So if CDATA sections are equivalent to character data, they are unequivocally forbidden. Only whitespace is permitted. To suppose otherwise is to suppose that CDATA sections with whitespace are allowable anywhere that whitespace is allowable, which is absurd: "bar=baz>" anyone? (I realize this argument may prove too much, and exclude the whitespace/empty entity references as well.) > Presumably, because of #1, the rule in clause 2.10 that "an XML > processor must always pass all characters in a document that are > not markup through to the application" applies here. I take that merely to mean that none of the content of the CDATA section can be elided, not that the parser is forbidden to mark content coming from a CDATA section as such. > [A]ll of the contents must match the production Char [2], Picky, picky, picky. *Everything* in a parsed entity must match the production Char, no? -- 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 jtauber at jtauber.com Fri Oct 30 17:33:57 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:06:07 2004 Subject: CDATA by any other name... (was The raw and the cooked) Message-ID: <005b01be042a$db81b180$0300000a@othniel.cygnus.uwa.edu.au> -----Original Message----- From: John Cowan >So if CDATA sections are equivalent to character data, they are >unequivocally forbidden. Only whitespace is permitted. To suppose >otherwise is to suppose that CDATA sections with whitespace are >allowable anywhere that whitespace is allowable, which is absurd: >"bar=baz>" anyone? This doesn't follow because the productions explicitly say where CDATA sections can occur for the document to be well-formed. 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 david at megginson.com Fri Oct 30 17:58:09 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:07 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: <3639F66E.10EC3445@locke.ccil.org> References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> <13880.48044.200328.880424@localhost.localdomain> <3639D5D1.B83FF8C7@locke.ccil.org> <13881.55381.777990.483844@localhost.localdomain> <3639F66E.10EC3445@locke.ccil.org> Message-ID: <13881.64319.417864.178815@localhost.localdomain> John Cowan writes: > > [A] CDATA section['s] > > contents are equivalent to character data (see clause 2.7). > > You're kicking the ball through your own goalposts here. Clause > 3.2.1 says: > > # [E]lement content [...] must contain only child elements > # (no character data), optionally separated by white space > # (characters matching the nonterminal S). Actually, I think that the game might have to be called off on account of inconsistent terminology in the spec. For example, clause 2.4 says that All text that is not markup constitutes the character data of the document. In other words, the "characters matching the nonterminal S" *are* character data. OOPS! I wonder if this is already on the XML 1.0 errata list. > So if CDATA sections are equivalent to character data, they are > unequivocally forbidden. No, unfortunately for parser writers, they're only equivocally forbidden. Like most religious texts, the XML 1.0 spec has proven itself internally-inconsistent, so we're going to have to invent some kind of exegetical method now to show how it's really all an allegory. > Only whitespace is permitted. To suppose otherwise is to suppose > that CDATA sections with whitespace are allowable anywhere that > whitespace is allowable, which is absurd: " ]]>bar=baz>" anyone? No, fortunately things aren't that bad. As clause 2.4 makes clear, character data appears only outside of markup. > > Presumably, because of #1, the rule in clause 2.10 that "an XML > > processor must always pass all characters in a document that are > > not markup through to the application" applies here. > > I take that merely to mean that none of the content of the CDATA > section can be elided, not that the parser is forbidden to mark > content coming from a CDATA section as such. Quite correct -- as I've pointed out in another posting, there is no explicit upper limit on the amount of information a parser may report. The real problem here is simply that the spec cannot answer my (originally, Henry's) question, and will have to be fixed. 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 M.H.Kay at eng.icl.co.uk Fri Oct 30 18:48:48 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:06:07 2004 Subject: CDATA by any other name... (was The raw and the cooked) Message-ID: <00e201be0435$4cc46630$7008e391@bra01wmhkay.bra01.icl.co.uk> >Quite correct -- as I've pointed out in another posting, there is no >explicit upper limit on the amount of information a parser may report. > >The real problem here is simply that the spec cannot answer my >(originally, Henry's) question, and will have to be fixed. This whole thread just reconfirms my view, stated a couple of weeks ago, that the current spec is hopelessly informal and we need some PhD student to sit down and produce a version in Z or something similar. Incidentally, if we want to be picky (and we do), a corrollory of the first assertion above is that a parser (read XML processor) is not required to distingush the data it is passing to the application because the XML-REC says it must, from data that it's passing to the application because it's having a bad day. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Oct 30 18:59:26 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:07 2004 Subject: Is XML 1.0 underspecified? (was: Re: CDATA by any other name...) In-Reply-To: <00e201be0435$4cc46630$7008e391@bra01wmhkay.bra01.icl.co.uk> References: <00e201be0435$4cc46630$7008e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <13882.2829.28975.375778@localhost.localdomain> Michael Kay writes: > This whole thread just reconfirms my view, stated a couple of weeks > ago, that the current spec is hopelessly informal and we need some > PhD student to sit down and produce a version in Z or something > similar. That's probably too harsh. I am actually quite fond of the XML 1.0 REC, and believe that it has worked for the most part. There are certainly some examples of fuzzy thinking -- making the expansion of external entities optional is the worst example, stemming from a fundamental confusion between linking and storage -- but many people have managed to implement reasonably-interoperable XML tools quickly and easily using the REC in its current state. Some cleanup is required, but that's inevitable with a 1.0. > Incidentally, if we want to be picky (and we do), a corrollory of the first > assertion above is that a parser (read XML processor) is not required to > distingush the data it is passing to the application because the XML-REC > says it must, from data that it's passing to the application because it's > having a bad day. Presumably, the application would be able to distinguish, since the application writer would know (for example) that comments are optional while character data is required. 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 greynolds at datalogics.com Fri Oct 30 19:41:54 1998 From: greynolds at datalogics.com (Reynolds, Gregg) Date: Mon Jun 7 17:06:07 2004 Subject: Is XML 1.0 underspecified? (was: Re: CDATA by any other name. ..) Message-ID: <51ED3F5356D8D011A0B1006097C30734014E5B26@martinique> I would agree we shouldn't be too harsh on the standard as written; the W3C intentionally does things fast, which is good on the whole, but it means pragmatism wins out over aesthetics sometimes. But I also agree using Z would be a very big step forward. -----Original Message----- From: david@megginson.com [mailto:david@megginson.com] Sent: Friday, October 30, 1998 12:58 PM To: XML Dev Subject: Is XML 1.0 underspecified? (was: Re: CDATA by any other name...) Michael Kay writes: > This whole thread just reconfirms my view, stated a couple of weeks > ago, that the current spec is hopelessly informal and we need some > PhD student to sit down and produce a version in Z or something > similar. That's probably too harsh. I am actually quite fond of the XML 1.0 REC, and believe that it has worked for the most part. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 30 20:32:45 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:06:07 2004 Subject: Is XML 1.0 underspecified? (was: Re: CDATA by any other name...) In-Reply-To: <13882.2829.28975.375778@localhost.localdomain> References: <00e201be0435$4cc46630$7008e391@bra01wmhkay.bra01.icl.co.uk> <00e201be0435$4cc46630$7008e391@bra01wmhkay.bra01.icl.co.uk> Message-ID: <199810302032.PAA14098@hesketh.com> At 01:58 PM 10/30/98 -0500, David Megginson wrote: >Michael Kay writes: > > > This whole thread just reconfirms my view, stated a couple of weeks > > ago, that the current spec is hopelessly informal and we need some > > PhD student to sit down and produce a version in Z or something > > similar. > >That's probably too harsh. I am actually quite fond of the XML 1.0 >REC, and believe that it has worked for the most part. There are >certainly some examples of fuzzy thinking -- making the expansion of >external entities optional is the worst example, stemming from a >fundamental confusion between linking and storage -- but many people >have managed to implement reasonably-interoperable XML tools quickly >and easily using the REC in its current state. Some cleanup is >required, but that's inevitable with a 1.0. Abstraction and precision are delightful, but I'd really prefer to see the W3C focus on the intelligibility of its specifications as well as their precision. There seems to be a tendency in computing to write things as unintelligibly as possible, culminating in specifications that affect an enormous number of people who have no way to read them. While to a certain extent that's the result of precise technical language, it doesn't seem wise to write things so that even programmers and computer science devotees have a hard time decoding them. Has anyone looked at the CSS2 spec? (Or CSS1?) For some reason, those specs are written in _English_, readable by a far larger number of people. They even make sense. (Unless, of course, you want to read them in French, German, or any other language.) A lot of things could have been done differently with the XML 1.0 spec. Hopefully, David's group's work at the W3C pinning down meanings for a lot of the words we use from experience will help clear up some of these issues, and I know the syntax group will contribute as well. At the same time, I hope somebody in the WG (or the W3C) is making certain the specs are readable as well as precise. I make a good living translating the XML specs into reasonably clear English, but I'd rather focus on what you can do with XML rather than what exactly the specs are trying to say. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) Building XML Applications (December) 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 tbray at textuality.com Fri Oct 30 22:22:25 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:06:07 2004 Subject: XML WG Reorganization questions Message-ID: <3.0.32.19981030123207.00d42054@pop.intergate.bc.ca> At 11:28 AM 10/29/98 -0500, Simon St.Laurent wrote: >1) I don't see where namespaces are listed as any of these groups' work, >though the activity statement still mentions them as W3C work. Stay tuned. >2) Is the Fragment Working Group the descendant of XPointer, or something >else? XPointer started out with XLink, but seems to be migrating further >and further away from its origins. No, Fragment is new. XPointer is still in the Linking group. -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 clovett at microsoft.com Sat Oct 31 03:05:24 1998 From: clovett at microsoft.com (Chris Lovett) Date: Mon Jun 7 17:06:07 2004 Subject: CDATA by any other name... (was The raw and the cooked) Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C08743ECF@RED-MSG-56> For what it's worth, the MS-XML parser also fails to validate the CDATA example because it takes the view that '' is not a replacement-text-entity and therefore the characters ' MSXML will will validate. The reason is that we figured that we have to expand entities anyway for validation purposes because you can also do the following: "> ]> &ent; It doesn't make any sense to think of the contents of a CDATA section in terms of "replacement-text" because then you'd have to wonder about validating ]]> which was NOT the point of CDATA sections. The point of CDATA was to treat as UNPARSED text. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Oct 31 03:12:39 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:07 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: <2F2DC5CE035DD1118C8E00805FFE354C08743ECF@RED-MSG-56> References: <2F2DC5CE035DD1118C8E00805FFE354C08743ECF@RED-MSG-56> Message-ID: <13882.32682.240266.691097@localhost.localdomain> Chris Lovett writes: > It doesn't make any sense to think of the contents of a CDATA section in > terms of "replacement-text" because then you'd have to wonder about > validating ]]> which was NOT the point of CDATA sections. > The point of CDATA was to treat as UNPARSED text. Precisely -- it's a matter of escaping. That doesn't really solve the first problem, though, since validation can (must?) take place after delimiter recognition. 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 ricko at allette.com.au Sat Oct 31 06:30:00 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:06:07 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: Message-ID: <000001be0498$180e4100$b3e887cb@NT.JELLIFFE.COM.AU> Henry Thompson wrote: > The DOM made a serious mistake here in my opinion: it's > stranded in no-person's-land between raw and cooked, without being > either. It's not cooked, because it gives you EntityReference and > CDATA nodes. It's not raw, because it DOESN'T give you character > entity references. CHARACTER REFERENCES I think Henry means "numeric character reference", and this is the heart of the matter. A numeric character is not an entity, any more than a directly-entered character is. It is just an alternative encoding of the character, and should be of no more interest to a general API than the charset encoding of the document was. (I am putting words into his mouth: or does Henry mean the [XMLs4.6] predefined entities?) Even if you make The numeric character is not an entity: it is the value of an entity with the name "example". MARKED SECTIONS On the subject of marked sections, I personally think that (in SGML) marked sections should do more than just alter delimiter recognition: I think they delimit anonymous inline entities, and label the entity with text-type information. Unerlying this is that, marked sections actually mark up notations: at ISO there has been discussion of whether to allow something like (for example) This is not something that I would expect to make its way into XML (and I think the ISO people are now more keen to help XML/WebSGML than on tidying up SGML) but I think the idea that a marked section not only alters delimiter recognition but also labels the data can be seen (in embryo or residually) in DOMs elevation of CDATAsection to node-worthiness, which has so perplexed Henry. If you take the view that CDATA section labels the data as character data (i.e. not ignorable whitespace) then is clearly invalid in Henry's example: because the " " is marked as data and data is not allowed. But that is emphera: what does the spec say? I think the answer is clear from the spec: [43] content ::= (element | CharData | Reference | CDSect | PI | Comment)* so a CDSect is not CharData. Therefore a CDSect is only valid in mixed content, even though it is well-formed to have it in element content. I think this is doubly clear from the discussion of "white-space" in [XML 2.10]: white-space for xml:space considerations (in element content) is space added for "greater readability". does not do this!! It disrupts readability. So from the purpose of valid whitespace in element content it is clear that is not legitimate. The text is just as important as the productions. SPACES Henry's problem brings up a further important consideation. XML gives an attribute "xml:space" by which an application can know whether white:space may be collapsed or not. Can be used to override xml:space=default? The answer is NO, because * an application is free to decide whether collapse spaces inside CDATA marked sections or not; * in PCDATA, ISO 10646 provides a specific character to indicate non-collabsible whitespace: IDEOGRAPHIC SPACE 　 * outside mixed content is not valid for the reasons above. XML, by adopting ISO 10646, takes the line that the only way to overcome the problems that (ASCII) people have with spaces is to un-overload that damned space character. The basic principle of markup is that if a user wants something, they should unambiguosly mark it up in their data: if they want non-collapsible space, the correct answer is "Use 　" or "Use xml:space='preserve'". (However, font issues are important here: IDEOGRAPHIC SPACE may be twice as wide as " " spaces, so the xml:lang attribute may be important.) I urge deve2lopers to make sure that their products handle the 17 ISO10646 spacing/hypenation characters properly. There have been previous postings on this group, (what happen to that XML jewels website: it was there too?), or get the Unicode book, or get ISO 10646, or (best option:-) get my book (XML & SGML Cookbook, p 3-90). 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 digitome at iol.ie Sat Oct 31 09:10:11 1998 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:06:07 2004 Subject: Is XML 1.0 underspecified? (was: Re: CDATA by any other name...) In-Reply-To: <51ED3F5356D8D011A0B1006097C30734014E5B26@martinique> Message-ID: <3.0.6.32.19981031085800.00921460@gpo.iol.ie> [Greg Reynolds] >I would agree we shouldn't be too harsh on the standard as written; the >W3C intentionally does things fast, which is good on the whole, but it >means pragmatism wins out over aesthetics sometimes. But I also agree >using Z would be a very big step forward. > What he said. If the W3C had landed the XML 1.0 in Z or VDM or something we wouldn't have half as many implementations as we currently have. Sure we now need more formalism to ensure that XML goes from strength to strength but without the balance of approachability/formalism XML 1.0 uses we would not have got here. It must also be rememembered that SGML from which XML sprung has very complex interplays between parsing modes, logical and physical structures. Some of this was bound to leak over into XML. http://www.python.org The "Swiss Army Laser Beam" of programming 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 david at megginson.com Sat Oct 31 12:24:28 1998 From: david at megginson.com (david@megginson.com) Date: Mon Jun 7 17:06:07 2004 Subject: CDATA by any other name... (was The raw and the cooked) In-Reply-To: <000001be0498$180e4100$b3e887cb@NT.JELLIFFE.COM.AU> References: <000001be0498$180e4100$b3e887cb@NT.JELLIFFE.COM.AU> Message-ID: <13882.65045.258418.319288@localhost.localdomain> Rick Jelliffe writes: > If you take the view that CDATA section labels the data as > character data (i.e. not ignorable whitespace) then > is clearly invalid in Henry's example: because the " " is marked as > data and data is not allowed. But that is emphera: what does the > spec say? > I think the answer is clear from the spec: [43] content ::= > (element | CharData | Reference | CDSect | PI | Comment)* so a > CDSect is not CharData. Therefore a CDSect is only valid in mixed > content, even though it is well-formed to have it in element > content. You're pumping the spec too hard. As I've pointed out in a previous posting, elsewhere the spec says that all non-markup-characters are character data, and in the CDATA section clause, it refers to the contents of the marked section as "character data," but I would attach no more weight to these than I would to your excerpts: if the spec had meant to make a clear statement about CDATA sections in element content, I trust that Tim and the other editors would have made the statement explicitly rather than hiding it for amateur exegetes like us to dig up. > I think this is doubly clear from the discussion of "white-space" > in [XML 2.10]: white-space for xml:space considerations (in element > content) is space added for "greater readability". > does not do this!! It disrupts readability. So from the purpose of > valid whitespace in element content it is clear that > is not legitimate. The text is just as important as the > productions. This is a useful statement of intent, but again, it does not answer the fundamental question -- it also relies on a subjective interpretation of readability (though one that many of us would probably share). Note, also, that by your reading, comments might also be forbidden in element content. Consider, again, the following: ]]> Is a validating parser that reports an error conformant to the letter (if not necessarily the spirit) of the XML 1.0 REC? Yes. Is a validating parser that does *not* report an error conformant to letter (if not necessarily the spirit) of the XML 1.0 REC? Yes. Does this need to be fixed? YES! 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 papresco at technologist.com Sat Oct 31 13:11:05 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:06:07 2004 Subject: Is XML 1.0 underspecified? (was: Re: CDATA by any othername...) References: <3.0.6.32.19981031085800.00921460@gpo.iol.ie> Message-ID: <363B0A3C.A2E3F789@technologist.com> Sean Mc Grath wrote: > > What he said. If the W3C had landed the XML 1.0 in Z or VDM or > something we wouldn't have half as many implementations as we > currently have. Sure we now need more formalism to ensure that > XML goes from strength to strength but without the balance of > approachability/formalism XML 1.0 uses we would not have got > here. Given sufficient technical resources, you can have a very terse, precise specification and tutorials and "annotated specifications" that provide an introductory path to the specification. In the long run, reading a book on Z, a book on XML and a Z-based XML spec is easier than trying to reconstruct the ideas in the authors heads based on imprecise prose. It's not like making an XML parser is a weekend job anyhow! I'm not arguing in favour of Z in particular, however. I'm arguing in favour of some form of precise formalism. One approach might be to come up with a vague mental model, build non-normative formal descriptions to make sure that the ideas are sound and complete, and then transliterate into English. > It must also be rememembered that SGML from which XML sprung > has very complex interplays between parsing modes, logical and > physical structures. Some of this was bound to leak over into > XML. That is certainly true. If we could go back in time and specify SGML in terms of formalisms, it wouldn't be such a hairy language today. Even the relatively simple grove formalism has lain bare the weirdness in SGML (but also highlighted some deep and beautiful symmetries). Hind sight is 20/20. Paul Prescod - http://itrc.uwaterloo.ca/~papresco "The new revolutionaries believe the time has come for an aggressive move against our oppressors. We have established a solid beachhead on Friday. We now intend to fight vigorously for 'casual Thursdays.' -- who says America's revolutionary spirit is dead? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Sat Oct 31 13:21:54 1998 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:06:07 2004 Subject: Is XML 1.0 underspecified? (was: Re: CDATA by any othername...) Message-ID: <01BE04D9.24101280@grappa.ito.tu-darmstadt.de> Could somebody tell me what "Z" is and possibly point me to a Web site? Thanks. -- 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 ricko at allette.com.au Sat Oct 31 14:26:21 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:06:08 2004 Subject: Is XML 1.0 underspecified? (was: Re: CDATA by any othername...) In-Reply-To: <363B0A3C.A2E3F789@technologist.com> Message-ID: <000001be04da$9954dd90$a1e987cb@NT.JELLIFFE.COM.AU> > From: Paul Prescod > In the long run, reading a book on > Z, a book on XML and a Z-based XML spec is easier than trying to > reconstruct the ideas in the authors heads based on imprecise prose. It's > not like making an XML parser is a weekend job anyhow! In the end, having an available judicial body who can be asked (and can annotate the spec) is easier than all that. XML isnt so much an algebraic thing a subject of human communication. People need to know what is an error, and why. It is when they don't know why that the "what" is unpredictable. Sooner or later every specification has to be made in non-technical terms: if people are confused by XML in semi-formal terms, I don't believe they will be less mystified by XML in Z and Z specified in some other book itself in semi-formal terms. (If they already know Z, then perhaps.) In any case, if a lot of XML people freak out at DTDs, or even the draft XML productions which extended EBNF, so what on earth will they make of Z (its syntax certainly mystified me at Uni)? Perhaps things can only be well-specified formally, but people can only have things specified by going from what they know to what they do not know: initially this will be informally. A spec has to use familiar notations if it is targetted at the masses. 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 papresco at technologist.com Sat Oct 31 18:57:18 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:06:08 2004 Subject: Raw/Cooked APIs (was Re: CDATA by any other name...) References: <02b001be034c$d9b0e800$0300000a@othniel.cygnus.uwa.edu.au> <3638B491.4D5923DF@locke.ccil.org> <13880.48044.200328.880424@localhost.localdomain> <3639D5D1.B83FF8C7@locke.ccil.org> <13881.55381.777990.483844@localhost.localdomain> Message-ID: <363B5893.D0E54785@technologist.com> "Henry S. Thompson" wrote: > > The DOM made a serious mistake here in my opinion: it's > stranded in no-person's-land between raw and cooked, without being > either. It's not cooked, because it gives you EntityReference and > CDATA nodes. It's not raw, because it DOESN'T give you character > entity references. Note that grove-based APIs such as that exposed by GroveMinder and the soon-to-be-releaed PyGrove do not have this problem. They present exactly as much information as the grove user asks for or the application can supply (obviously, whichever is less!). Users and grove-providing tools can communicate what they want with "grove plans." Over a few months, I've been working on a tutorial introduction to groves. The unfinished work is at: http://www.prescod.net/groves/shorttut/ Paul Prescod - 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)