From M.H.Kay at eng.icl.co.uk Mon Mar 2 10:08:27 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:00:13 2004 Subject: Sorting out org.xml.sax.AttributeList Message-ID: <01bd45c3$49847a40$1e09e391@mhklaptop.bra01.icl.co.uk> > package org.xml.sax; > > public interface NameList { > public abstract int getLength (); > public abstract int getIndex (String name); > public abstract String getName (int index); > } > > public interface AttributeList extends NameList { > public abstract String getType (int index); > public abstract String getValue (int index); > } 1. Please could we retain the convenient public String getValue (String name); 2. I thought the consensus was that getType should return an integer, possibly a bit-significant set of flags? > >For notations... >Unparsed entities... At present this all leaves me rather cold because no-one has yet convinced me of the value of using these XML facilities versus simple application-level conventions like . I'm open to persuasion; but if we need to provide these things, we must make sure they do not add overhead for users who don't think they need to use them. 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 rodig at sdm.de Mon Mar 2 14:55:02 1998 From: rodig at sdm.de (Steffen Rodig) Date: Mon Jun 7 17:00:14 2004 Subject: Q: Using XML entities for href's Message-ID: <199803021453.PAA28485@sunfi1.fi.sdm.de> In my xml based application I want to write xml documents with some kind of indirect links, since I don't know the exact location of a link target at the time a document is created and stored into a repository. I got the idea to use the entity concept of xml for doing this, since in my understanding entities can be used as virtual identifiers for physical locations. So at the time I request a document from the repository I'd like to include some entity definitions into the internal DTD of a document. Then it would look like this: ]> ... content ... Does this idea still conform to the xml concept? Even more important: Would this work? If not, does anyone have an idea of how to solve the following problem: 1. At creation time of a xml document I only know symbolic identifiers for the link targets. The documents need to be stored into a repository without resolving the links. (however, the link target identifiers are unambiguous over the whole repository) 2. After the import of all documents into the repository, I am able to resolve the link targets. 3. At the time of exporting the documents from the repository (and displaying them in a browser), I need to exchange the symbolic identifiers with the real ones for navigation. Any help is greatly appreciated. Best regards, -- Steffen Rodig |s |d &|m | software design & management Steffen.Rodig@sdm.de | | | | GmbH & Co. KG http://www.sdm.de/ | | | | Thomas-Dehler-Str. 27 Tel/Fax +49-89-63812-395/490 | | | | 81737 Muenchen, Germany Leben ist das, was einem zustoesst, waehrend man auf die Erfuellung seiner Traeume wartet. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From szpak at well.com Mon Mar 2 16:12:19 1998 From: szpak at well.com (Mark Szpakowski) Date: Mon Jun 7 17:00:14 2004 Subject: Q: Using XML entities for href's In-Reply-To: <199803021453.PAA28485@sunfi1.fi.sdm.de> Message-ID: <199803021610.IAA28854@smtp.well.com> At 03:53 PM 3/2/98 +0100, Steffen Rodig wrote: >In my xml based application I want to write xml documents with some >kind of indirect links, since I don't know the exact location of a >link target at the time a document is created and stored into a >repository. I got the idea to use the entity concept of xml for doing >this, [...] > > >]> >... >content >... We have an almost identical challenge, with the added qualifications that a) all our pages are customized and generated on the fly, out of the repository; b) we need to generate HTML, so that pages can be viewed and navigated with today's HTML browsers. This means that at the time of serving up the documents our code needs to compose HTML content tags from the symbolic link identifiers. I.e., for outputting just HTML there seems to be no reason to generate an intermediary XML document, with entity definitions and entity refs, which then gets translated to HTML. However, the XML doc makes sense if we want to anticipate supporting both XML and HTML browsers (by switching on the browser type, and if it's HTML, generating HTML). I see no reason why your approach wouldn't work with XML browsers. - Mark ___________________________________ Mark Szpakowski WorldNav Learning Systems Inc. Halifax, Nova Scotia, Canada mark.szpakowski@learningengine.com Voice 902/422-1577 Fax 902/422-4964 ___________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rodig at sdm.de Mon Mar 2 16:33:32 1998 From: rodig at sdm.de (Steffen Rodig) Date: Mon Jun 7 17:00:14 2004 Subject: Q: Using XML entities for href's Message-ID: <199803021630.RAA01849@sunfi1.fi.sdm.de> > At 03:53 PM 3/2/98 +0100, Steffen Rodig wrote: >>In my xml based application I want to write xml documents with some >>kind of indirect links, since I don't know the exact location of a >>link target at the time a document is created and stored into a >>repository. I got the idea to use the entity concept of xml for doing >>this, > [...] >> >>> >>]> >>... >>content >>... > We have an almost identical challenge, with the added qualifications that > a) all our pages are customized and generated on the fly, out of the > repository; > b) we need to generate HTML, so that pages can be viewed and navigated > with today's HTML browsers. Does this mean, that you create HTML out of data structures that are in no way related to [X|HT]ML? We want to stick with XML in the repository 'cause we believe that XML- enabled browsers will become available soon. At the moment we plan an on-the-fly conversion to HTML as well. XML is not our intermediate format, it's going to be our basic format for the documents in the repository with elements forming objects and links forming relations among them. > ... > I see no reason why your approach wouldn't work with XML browsers. Ok, but is it valid XML, i.e. will a XML processor find the URL from the symbolic identifier? Best, -- Steffen Rodig |s |d &|m | software design & management Steffen.Rodig@sdm.de | | | | GmbH & Co. KG http://www.sdm.de/ | | | | Thomas-Dehler-Str. 27 Tel/Fax +49-89-63812-395/490 | | | | 81737 Muenchen, Germany Leben ist das, was einem zustoesst, waehrend man auf die Erfuellung seiner Traeume wartet. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 light.demon.co.uk Mon Mar 2 17:09:39 1998 From: richard at light.demon.co.uk (Richard Light) Date: Mon Jun 7 17:00:14 2004 Subject: Q: Using XML entities for href's In-Reply-To: <199803021453.PAA28485@sunfi1.fi.sdm.de> Message-ID: In message <199803021453.PAA28485@sunfi1.fi.sdm.de>, Steffen Rodig writes >In my xml based application I want to write xml documents with some >kind of indirect links, since I don't know the exact location of a >link target at the time a document is created and stored into a >repository. I got the idea to use the entity concept of xml for doing >this, since in my understanding entities can be used as virtual >identifiers for physical locations. So at the time I request a >document from the repository I'd like to include some entity >definitions into the internal DTD of a document. Then it would >look like this: > > > >]> >... >content There are two possible lines of attack suggested by XML itself (as against XLL, which uses URLs as its targets without the need for an entity declaration as in your example). The PUBLIC identifier (of which you give an example above, in the external entity declaration of your external DTD subset) is intended to be a generic name which is not bound to a physical location. Philosophically, this is exactly what you want. Unfortunately, in XML (unlike SGML) you can't just specify a PUBLIC identifier - you have to give a system identifier as well. (So, in fact, your > I've noticed some mention of XML for electronic commerce (inter@ctive week, 2/16/98) and as an alternative to EDI (XML A Primer by Simon St. Laurent, p193). I think it would be great if we could do things like XML certificates, as well. But many of these things require signing. Say, something like this: the thing signed But "the thing signed" may itself contain XML. Is this asking too much of an XML application, that it both process the contents of the signature element, while providing access to the byte array of the contents for signature verification? Thanks! Bill la Forge Sr. Research Engineer The Open Group http://www.camb.opengroup.org/~laforge/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elm at arbortext.com Mon Mar 2 17:52:36 1998 From: elm at arbortext.com (Eve L. Maler) Date: Mon Jun 7 17:00:14 2004 Subject: Q: Using XML entities for href's In-Reply-To: <98Mar2.114712est.18834@thicket.arbortext.com> Message-ID: <3.0.5.32.19980302124844.00a20590@village.doctools.com> It's legal to reference a parsed entity from an attribute value, and every XML processor should be able to handle it. To do this properly, the reference would have to look like this: content (Using an ENTITY-type attribute wouldn't automatically expand it in place, and anyway, has to be used exclusively with unparsed entities -- those with an NDATA notation.) Eve At 11:30 AM 3/2/98 -0500, Steffen Rodig wrote: >> At 03:53 PM 3/2/98 +0100, Steffen Rodig wrote: >>>In my xml based application I want to write xml documents with some >>>kind of indirect links, since I don't know the exact location of a >>>link target at the time a document is created and stored into a >>>repository. I got the idea to use the entity concept of xml for doing >>>this, >> [...] >>> >>>>> >>>]> >>>... >>>content >>>... > >> We have an almost identical challenge, with the added qualifications that > >> a) all our pages are customized and generated on the fly, out of the >> repository; >> b) we need to generate HTML, so that pages can be viewed and navigated >> with today's HTML browsers. > >Does this mean, that you create HTML out of data structures that are in >no way related to [X|HT]ML? > >We want to stick with XML in the repository 'cause we believe that XML- >enabled browsers will become available soon. At the moment we plan an >on-the-fly conversion to HTML as well. > >XML is not our intermediate format, it's going to be our basic format >for the documents in the repository with elements forming objects >and links forming relations among them. > >> ... > >> I see no reason why your approach wouldn't work with XML browsers. > >Ok, but is it valid XML, i.e. will a XML processor find the URL from >the symbolic identifier? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rodig at sdm.de Mon Mar 2 18:03:24 1998 From: rodig at sdm.de (Steffen Rodig) Date: Mon Jun 7 17:00:14 2004 Subject: Q: Using XML entities for href's Message-ID: <199803021801.TAA22881@sunfi1.fi.sdm.de> Richard, I can't even believe it: I am just reading your book "Presenting XML"! This is way cool! > In message <199803021453.PAA28485@sunfi1.fi.sdm.de>, Steffen Rodig > writes >>In my xml based application I want to write xml documents with some >>kind of indirect links, since I don't know the exact location of a >>link target at the time a document is created and stored into a >>repository. I got the idea to use the entity concept of xml for doing >>this, since in my understanding entities can be used as virtual >>identifiers for physical locations. So at the time I request a >>document from the repository I'd like to include some entity >>definitions into the internal DTD of a document. Then it would >>look like this: >> >> >>> >>]> >>... >>content > There are two possible lines of attack suggested by XML itself (as > against XLL, which uses URLs as its targets without the need for an > entity declaration as in your example). Ok, without the need, but also without the possibility? > The PUBLIC identifier (of which you give an example above, in the > external entity declaration of your external DTD subset) is intended to > be a generic name which is not bound to a physical location. > Philosophically, this is exactly what you want. > Unfortunately, in XML (unlike SGML) you can't just specify a PUBLIC > identifier - you have to give a system identifier as well. (So, in > fact, your >> is not correct.) Do I understand it correctly: Even if I use a catalog file which maps the public identifier for the dtd to its physical file name, I cannot extend the dtd with this kind of internal dtd subset (entity definitions)? When I read the formal xml spec, it seems to be possible. I am sorry, that I don't quite understand your answer. All I need is a level of indirection for the href attributes. However, the correct syntax probably would be content > Which brings us on to system identifiers, since you have to have one > anyway ;-) > The finalized XML Recommendation talks of these system identifiers being > a 'URI', as against a URL. I remember a few years ago that URIs were > going to include URNs (Uniform Resource Names) as well as the URLs we > have grown to know and love. URNs are (were?) like public identifiers > in not being closely-coupled to a physical storage location. I think > that work is being done to update the definition of URIs to provide this > kind of flexibility. So does this mean in the end, that there will be times coming that this will work? The current status of the Linking Specification, however, tells me that a LOCATOR has to be a URL only (with possible XPointer extensions). :-( In case that it doesn't work, how come that with XML one gets levels of indirection (and therefore independence from the physical location) almost everywhere (e.g. for DTDs, for extern documents), but not for links? Best, -- Steffen Rodig |s |d &|m | software design & management Steffen.Rodig@sdm.de | | | | GmbH & Co. KG http://www.sdm.de/ | | | | Thomas-Dehler-Str. 27 Tel/Fax +49-89-63812-395/490 | | | | 81737 Muenchen, Germany Leben ist das, was einem zustoesst, waehrend man auf die Erfuellung seiner Traeume wartet. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From istvanc at microsoft.com Mon Mar 2 19:06:10 1998 From: istvanc at microsoft.com (Istvan Cseri) Date: Mon Jun 7 17:00:14 2004 Subject: build breaks Message-ID: <5BF896CAFE8DD111812400805F1991F72220F7@red-msg-08.dns.microsoft.com> I'd like to ask everybody to be a little bit more careful with checkins. I know that we are in crunch mode and there doesn't seem to be enough time but believe me, we waste more time with build breaks than the time you think you save by not checking in properly. Over the weekend whenever I ssync-ed (3 times) either the normal build was broken or OMTEST didn't run or some other problem. I just ssync-ed again and now I get a memory leak in OMTEST which didn't happen at 1 am in the morning ! You should build the 'normal' version before you check in. This is without the new defines like NEWPARSER, ELEMENTNODE, SLOTNEW etc. This also includes the retail build ! You have to run the DRT tests (xml\exe\test\runtest and xml\omtest\test\runtest and xsl\drt\exe\runtest). This includes both for retail and debug. I asked this more times than I care to remember. Please let me or Phani know if you don't want to follow these procedures but otherwise I assume we agreed on this (like a couple times before !). Thanks, Istvan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From istvanc at microsoft.com Mon Mar 2 20:56:44 1998 From: istvanc at microsoft.com (Istvan Cseri) Date: Mon Jun 7 17:00:14 2004 Subject: Recall: build breaks Message-ID: <5BF896CAFE8DD111812400805F1991F72220F8@red-msg-08.dns.microsoft.com> Istvan Cseri would like to recall the message, "build breaks". xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Mar 2 22:39:15 1998 From: smith at interlog.com (Chris Smith) Date: Mon Jun 7 17:00:14 2004 Subject: Are signatures beyond the scope of XML? In-Reply-To: <3.0.32.19980302125437.00967e40@postman.osf.org> Message-ID: On Mon, 2 Mar 1998, Bill la Forge wrote: > I've noticed some mention of XML for electronic commerce (inter@ctive > week, 2/16/98) and as an alternative to EDI (XML A Primer by Simon St. > Laurent, p193). > > I think it would be great if we could do things like XML certificates, as > well. But many of these things require signing. Say, something like this: > > the thing signed > > But "the thing signed" may itself contain XML. Is this asking too much of > an XML application, that it both process the contents of the signature > element, while providing access to the byte array of the contents for > signature verification? Take a look at Open Trading Protocol at http://www.otp.org - getting something like this to work was critical to the overall protocol effort. It's too big to go into here, and we spent a good amount of time on the wording - I'd rather not try and paraphrase when the original is readily available. The details on signing (and message authentication in general) are in Part 2 of the specification. More details about OTP in general are available on the site. --------------------------------------------------------------------------- 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 SaxManJzz at aol.com Mon Mar 2 22:46:03 1998 From: SaxManJzz at aol.com (SaxManJzz) Date: Mon Jun 7 17:00:14 2004 Subject: XML Use On Web Pages Message-ID: <90e21ad5.34fb3661@aol.com> Hello all, I am new at using XML. Is the only way you can use XML through java? Or can you in some way use it directly embedded in the page? Thanks, David xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jeremie at netins.net Tue Mar 3 00:20:21 1998 From: jeremie at netins.net (Jeremie Miller) Date: Mon Jun 7 17:00:14 2004 Subject: XML Use On Web Pages In-Reply-To: <90e21ad5.34fb3661@aol.com> Message-ID: If the client is using IE4, you can utilize the built in XML parser in IE4, learn more at http://www.microsoft.com/xml/ The only other way to do it on the client side w/o using Java would be to use my JavaScript XML parser(http://www.jeremie.com/Dev/XML/ ), but the Java parsers are much more complete and I would suggest using them unless the Java startup/performance is the problem. Jeremie Miller jer@jeremie.com http://www.jeremie.com/ On Mon, 2 Mar 1998, SaxManJzz wrote: > Hello all, > > I am new at using XML. Is the only way you can use XML through java? Or can > you in some way use it directly embedded in the page? > > Thanks, > David > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Mar 3 16:21:58 1998 From: jcupp at essc.psu.edu (J. Cupp) Date: Mon Jun 7 17:00:14 2004 Subject: XML Use On Web Pages References: <90e21ad5.34fb3661@aol.com> Message-ID: <34FD3988.AA99E18C@essc.psu.edu> SaxManJzz wrote: > > Hello all, > > I am new at using XML. Is the only way you can use XML through java? Or can > you in some way use it directly embedded in the page? > You can make use of XML through CGI scripts and parsers written in C, C++, etc... I've been using LtXML (http://www.ltg.ed.ac.uk/software/xml/index.html) for a while now. It works great and any browser can read it--all sever-side. -- Jason R. Cupp (jcupp@essc.psu.edu) Deasy GeoGraphics The Pennsylvania State University xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wilfr at mail.bc.rogers.wave.ca Tue Mar 3 19:54:07 1998 From: wilfr at mail.bc.rogers.wave.ca (Wilf Reedijk) Date: Mon Jun 7 17:00:14 2004 Subject: Q: Using XML entities for href's - More questions about entities References: <3.0.5.32.19980302124844.00a20590@village.doctools.com> Message-ID: <34FC6058.45D13198@rogers.wave.ca> When I try to reference an entity within an attribute value, the parser (I am using msxml) complains. The message that I am getting is 'Invalid element in context of 'APP'. Expected [ADDURL,EDITURL] in line 3 and column 18. This message makes no sense to me. Here is my XML: ]> someurl anotherurl How do we use entities within attributes? I find the whole concept of entities to be a bit confusing (internal vs. external; general vs. parameter; parsed vs. unparsed etc.). Is there a site where one could find some good examples describing how the various types of entities are used? Eve L. Maler wrote: > It's legal to reference a parsed entity from an attribute value, and every > XML processor should be able to handle it. To do this properly, the > reference would have to look like this: > > content > > (Using an ENTITY-type attribute wouldn't automatically expand it in place, > and anyway, has to be used exclusively with unparsed entities -- those with > an NDATA notation.) > > Eve > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980303/107378ff/attachment.htm From elm at arbortext.com Tue Mar 3 21:00:05 1998 From: elm at arbortext.com (Eve L. Maler) Date: Mon Jun 7 17:00:15 2004 Subject: Q: Using XML entities for href's - More questions about entities In-Reply-To: <98Mar3.145305est.18821@thicket.arbortext.com> References: <3.0.5.32.19980302124844.00a20590@village.doctools.com> Message-ID: <3.0.5.32.19980303155637.00ac4970@village.doctools.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2211 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980303/f22f9987/attachment.bin From jft at Psychology.Nottingham.AC.UK Wed Mar 4 09:24:35 1998 From: jft at Psychology.Nottingham.AC.UK (Jeni Tennison) Date: Mon Jun 7 17:00:15 2004 Subject: Char & Java implementation Message-ID: I've been attempting Ye Olde XML-Parser-in-Java exercise, mainly to help me get to grips with Java. The last week has seen me struggling over character encodings, and I wondered if you could put my mind at rest by confirming whether I'm understanding the XML recommendation correctly. The definition of Char in the XML recommendation is: From: http://www.w3.org/TR/REC-xml#charsets - [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] ^^^^^^^^^^^^^^^^^^ Am I right in thinking that, since the indicated characters are longer than 16 bits, they can't be represented in Java with the char data type, and int must be used instead? And that this also means that you can't use normal java.lang.Strings for things like entity and attribute values? Thanks for your help in advance, Jeni Jenifer Tennison Department of Psychology, University of Nottingham University Park, Nottingham NG7 2RD, UK tel: +44 (0) 115 951 5151 x8352 fax: +44 (0) 115 951 5324 url: http://www.psychology.nottingham.ac.uk/staff/Jenifer.Tennison/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Mar 4 10:53:00 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:00:15 2004 Subject: Char & Java implementation In-Reply-To: Jeni Tennison's message of Wed, 4 Mar 1998 09:13:18 +0000 Message-ID: <25721.199803041052@cockburn.cogsci.ed.ac.uk> > [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] > | [#xE000-#xFFFD] | [#x10000-#x10FFFF] > ^^^^^^^^^^^^^^^^^^ > > Am I right in thinking that, since the indicated characters are longer than > 16 bits, they can't be represented in Java with the char data type, and int > must be used instead? The answer to this explains the otherwise mysterious missing range D800 to DFFF. These 2 * 2^10 missing characters can be used in pairs to represent the first 2^20 characters above FFFF. The character 10000 + x is represented by the pair D800 + (x >> 10), DC00 + (x & 3FF). Since none of the characters above FFFF are name characters, they are irrelevant to the syntax of XML, and you don't need to convert the pairs of "surrogates" into the characters they represent - you can just pass them through to the application. So you can treat the range of legal characters as being 9,A,D,20-FFFD. There are a few things you have to take account of: - the surrogates must appear in pairs in the input, one in the range D800-DBFF followed by one in the range DC00-DFFF - if a character entity refers to a character in the range 10000-10FFFF it should be converted to a pair of surrogates before it is passed to the application - a character entity must not expand to a character in the surrogate range D800-DFFF. I think, but I'm not certain, that this encoding only applies to UTF-16 and not UCS-2 (which would mean that the surrogate characters are an error if encountered in a UCS-2 stream). Can anyone confirm/deny 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 richard at cogsci.ed.ac.uk Wed Mar 4 13:31:21 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:00:15 2004 Subject: Q: Using XML entities for href's - More questions about entities In-Reply-To: Wilf Reedijk's message of Tue, 03 Mar 1998 11:56:08 -0800 Message-ID: <199803041330.NAA10409@stevenson.cogsci.ed.ac.uk> > When I try to reference an entity within an attribute value, the parser (I am > using msxml) complains. > The message that I am getting is 'Invalid element in context of 'APP'. Expected > [ADDURL,EDITURL] in line 3 and column 18. This message makes no sense to me. Looks OK to me (and rxp), except that <199802251724.MAA02583@unready.microstar.com> <34F6321E.8D415644@jclark.com> Message-ID: <34FD73E0.7D7144C0@edu.uni-klu.ac.at> James Clark wrote: > The following seem the reasonable combinations to me: > 1.) > - Validate and process all external entities (if you're validating > you've got to process all external entities). > 2.) > - Don't validate and process external DTD and parameter entitities > depending on the setting of standalone. > 3.) > - Don't validate and process external DTD and parameter entities > (irrespective of the setting of standalone). > 4.) > - Don't validate and don't process external DTD and parameter entities > (irrespective of the setting of standalone). What about to have two methods - setValidate(boolean validate) - setStandalone(boolean standalone) (and the corresponding getValidate, getStandalone methods as well) Where the setStandalone _overrides_ the setting in the xml-document itself, _if_ set. If _not_ set a.) standalone setting in the xml document itself -> use this setting b.) no standalone setting in the xml document itself -> defaults to the default setting of the parser (= to 'no' like 2.9 in the XML spec says). It should be possible to achieve the same combinations as above. This would give the following combinations for the examples above: [Default is for an XML processor: validate=false/standalone=no] setValidate setStandalone 1.) true setting has no effect, will always go into external DTD & PE 2.) defaults or set to false not set -> doesn't change setting of standalone in xml doc 3.) defaults or set to false set to false -> overrides to standalone 'no' 4.) defaults or set to false set to true -> overrides to standalone 'yes' Hope I got the table right :) All the best Juergen ----------------------------------------------- JUERGEN MODRE Reisdorf 6 A-9371 Brueckl Austria (Europe) Phone: ++43 4214 2320 Mobile: ++43 664 233 22 22 E-mail: jmodre@edu.uni-klu.ac.at WWW: http://www.edu.uni-klu.ac.at/~jmodre ----------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dima at paragraph.com Wed Mar 4 16:25:41 1998 From: dima at paragraph.com (Dmitri Kondratiev) Date: Mon Jun 7 17:00:15 2004 Subject: XLogo: Why Logo meta program with XML ? Message-ID: <2.2.32.19980304162602.01017210@dream.paragraph.com> The rationale for XLogo - experimental Meta OOP project - can be found at : http://www.geocities.com/SiliconValley/Lakes/3767/xlogo-index.html#why Thanks, Dima --------------------------- dima@paragraph.com 102401.2457@compuserve.com http://www.geocities.com/SiliconValley/Lakes/3767/ tel: 07-095-464-9241 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Mar 4 18:20:05 1998 From: jlapp at webmethods.com (Joe Lapp) Date: Mon Jun 7 17:00:15 2004 Subject: ANNOUNCE: Free Web Automation Toolkit for XML & HTML Message-ID: <3.0.32.19980304132318.00d4e8c0@tni.webmethods.com> webMethods, Inc. today announced that it is now distributing its XML- based Web Automation Toolkit for free. You may download the Web Automation Toolkit from . The Toolkit uses an XML-based technology called WIDL (Web Interface Definition Language) to allow developers to automate access to HTML and XML web pages and to do so without using a web browser. The developer designs interfaces consisting of functions having input and output parameters. The input parameters fill out forms on web pages, and the output parameters contain information extracted from the pages returned upon submitting the form. Applications based on WIDL do not require any understanding of HTTP, HTML, or XML and need not even know that the functions they are using perform their jobs by interacting with the web. The toolkit is written completely in Java and runs on all platforms that support JDK 1.1. The Toolkit generates code for Java, JavaScript, C, C++, Tcl/Tk, Microsoft Excel, and Visual Basic. The professional edition of the Toolkit has full RSA security built-in. The Web Automation Toolkit is a mature and fully documented product that webMethods has been shipping to its customers with the Web Automation Server. See the press release below for more information. FOR IMMEDIATE RELEASE Contact: Caren DeWitt Stella Vanderpool webMethods, Inc. Cooper/Iverson Marketing 703/352-0851 619/292-7400 caren@webMethods.com stella@coopiver.com WEBMETHODS ANNOUNCES XML-BASED WEB AUTOMATION TOOLKIT TO BE AVAILABLE FREE ON THE NET XML-RPC Enables Businesses to Connect Applications over the Web, Fosters Growth of XML for Business-to-Business E-Commerce FAIRFAX, VA, March 4, 1998 - webMethods, Inc. the leading provider of XML-based solutions for business-to-business e-commerce, today announced the free availability of its popular Web Automation Toolkit. The Toolkit is a development environment that enables companies to connect applications to existing Web sites and introduces the ability to use Web protocols to integrate business applications directly over the Web - application to application, Web site to Web site, or Web site to application. Companies can use the open standards of the Web to connect business systems with those of their customers, suppliers and partners. Although the Web Automation Toolkit uses the eXtensible Markup Language (XML) for data exchange, it works with existing HTML, and does not require corporate developer expertise in XML. The Toolkit includes an HTML/XML parser and a groundbreaking XML RPC that enables any application to exchange data with any other application using just HTTP and XML. "Much of the initial coverage about XML has focused on publishing and content management. webMethods encourages this, but we also want to foster greater understanding and use of XML particularly for business-to-business e-commerce over the Web. By freely distributing our Toolkit, we enable an even larger group of developers to begin developing XML-based applications now," said Phillip Merrick, President and CEO of webMethods. Major corporations have already developed applications with webMethods XML-based products. These applications include supply chain integration, automated procurement, and aggregation of business intelligence. "XML is a powerful enabler for Web commerce. This critical announcement gives companies an XML strategy today for creating portable business-to-business e-commerce applications with easy access to both existing HTML and legacy data. Web Automation Toolkit is definitely a world class e-commerce solution," said Natalie Shaheen, President of Netroscope. webMethods Offers Only Solution that Works With Existing HTML, and XML The Web Automation Toolkit 2.1, shipping since December 1997, is an integrated development, testing, and management environment. Using the Toolkit, developers encapsulate Web data and services through a simple and effective graphical interface. Code generators produce "Weblets" in popular programming languages and formats, including C/C++, Java, Javascript, Visual Basic, PowerBuilder, MS Excel, ActiveX and JavaBeans. Weblets are reusable Web access components that can be readily plugged into applications for direct and managed access to Web resources. Other languages and application environments, such as SAP (OTC BB:SAPHY) , Baan (Nasdaq: BAANF) and PeopleSoft (Nasdaq: PSFT), are supported via eXtensible code generation templates. The Toolkit automatically generates client code, so developers don't need to work at the level of an XML parser. The toolkit offers everything a developer needs to create a working XML application now. It can be downloaded at http://www.webMethods.com. The free Toolkit also includes a Personal Server, that supports 2 users, enabling deployment of prototype applications. To deploy to larger numbers of corporate users, webMethods' Web Automation Server is required. Deploy XML-Based Mission Critical Applications Today with Web Automation Server 1.0 The Web Automation Server, shipping since January 1998, enables corporate deployment of applications developed with the Web Automation Toolkit, and includes advanced features such as SSL and RSA (Nasdaq - SDTI) security in addition to full customer support. The Web Automation Server bridges communications between the Web and business applications. Through the use of standard Web protocols and APIs, the Web Automation Server automates the exchange of data between local or remote Web sites and corporate applications, eliminating the need for human interaction via a browser interface. Companies can now "publish" a set of Web application services, such as purchasing, shipping, and order tracking that enable them to forge stronger, more efficient, and more profitable alliances with suppliers, customers, and partners. The Web Automation Server is scalable to hundreds and thousands of corporate users, with high performance and full SSL and RSA security. The Web Automation Toolkit and Web Automation Server are available for all platforms that support Java, including Microsoft (Nasdaq: MSFT) Windows 95/NT, Sun Microsystems (Nasdaq: SUNW) Solaris, Linux, Hewlett Packard (NYSE: HWP) HPUX, Digital Equipment Corporation (NYSE: DEC) Unix, IBM (NYSE: IBM) AIX , OS/2, and Macintosh. webMethods' Web Automation Server is shipping now; pricing starts at $1,295 per concurrent user, minimum orders required with quantity discounts available. The Web Interface Definition Language - the Power of Web Automation The core technology behind webMethods' products is the Web Interface Definition Language(WIDL), an application of XML that transforms the Web from an access medium to an integration platform. WIDL provides a means of describing automated access to Web resources through well-defined interfaces. Using WIDL, XML definitions can be created over existing HTML content, enabling applications to interact with both new and existing Web-based resources. In October, 1997, the World Wide Web Consortium (W3C) acknowledged webMethods' submission of WIDL to the W3C as the first proposed standard for automated access to Web data from within business applications. webMethods Technology Roadmap webMethods' goal is to continue to be the market leader and innovator in XML-based products for business-to-business e-commerce over the Web. In Spring 1998, webMethods will announce products that offer direct integration over the Web to back-end customer databases. webMethods' products will support all popular DBMS and access protocols. Its Server products will offer powerful capabilities that support lightweight distributed computing on the Web using just XML and Java as the glue. These XML-enabled application servers will make it possible to connect any existing application directly over the Web using XML as the message format. About webMethods webMethods is the first and leading provider of XML-based Web Automation and integration technology. webMethods' suite of Web Automation products uniquely allow corporations to leverage the real value of Web data, by fully integrating it with mainstream business applications. The company is the market leader in XML-based applications for business-to-business ecommerce over the Web. webMethods' award-winning products are in use at leading companies including DHL Airways, Texas Instruments (NYSE:TXN), Ericsson (Nasdaq: ERICY), Cisco Systems (Nasdaq: CSCO), Discovery Communications, Inc., Pitney Bowes, Aramco, and the US Postal Service. As a member of the W3C, webMethods actively supports the development of XML. webMethods' XML-based Web Interface Definition Language was submitted to the W3C in October 1997 as the first proposed standard for automated access to Web data from within business applications. webMethods contributed to early volumes published on XML including, "Presenting XML", by Richard Light, and edited Tim Bray, a co-author of the XML Specification, and "XML, Tools and Techniques", published by O'Reilly's World Wide Web Journal in Oct. 1997. webMethods is a co-sponsor and a presenter of XML Xposed, a national series of roadshows designed to educate developers and executives about the business benefits of XML, beginning March 18, (http://www.xmlu.com), and XML: The Conference, to be held March 23-26 in Seattle, Washington (http://www.gca.org). Founded in 1996, venture-backed webMethods, Inc. is based in Fairfax, Virginia, with offices in San Mateo, California. -- Joe Lapp, Technology Analyst | 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 Jon.Bosak at eng.Sun.COM Thu Mar 5 01:00:18 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:00:15 2004 Subject: Seattle XML Dev Day lineup Message-ID: <199803050058.QAA03896@boethius.eng.sun.com> Speakers for the March 27 XML Developers' Day in Seattle have now been selected. See the preliminary schedule of presentations below. Abstracts describing each presentation will be available in a few days. Since Developers' Day is designed to report on the very latest in the world of XML implementations, presentations are informal, and no proceedings are published. So if you want to know what's happening, you have to be there in person. You can register for Developers' Day (and the rest of the XML Conference) at http://www.gca.org/conf/xmlcon98/ See you in Seattle! Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, Mountain View, California 94043 OASIS :: NCITS V1 :: ISO/IEC JTC1/WG4 :: W3C XML WG :: W3C XSL WG If a man look sharply and attentively, he shall see Fortune; for though she be blind, yet she is not invisible. -- Francis Bacon ---------------------------------------------------------------------- PRELIMINARY SCHEDULE -- XML DEVELOPERS' DAY SEATTLE, WASHINGTON, MARCH 27, 1998 09:00-10:30 Jon Bosak, Sun Microsystems Introduction David Megginson, Microstar SAX: The Simple API for XML Naohiko Uramoto, Hiroshi Maruyama, and Kento Tamura, IBM An XML Processor: XML for Java Steph Tryphonas, Microstar DTD Conversions: Near & Far Designer meets XML 10:30-11:00 ==================================================== BREAK 11:00-12:30 Larry Wall, O'Reilly, and Dick Hardt, ActiveState Perl XML Scott Parnell, Xerox A Java-based XML editor Henry Thompson, U. of Edinburgh Introducing XED: An XML Instance Editor 12:30-14:00 ==================================================== LUNCH 14:00-15:30 Norman Walsh, ArborText XML Styler Ray Cromwell and Shawn O'Connor, ContentWare XSL Authoring Studio Ramanathan Guha, Netscape XML in Netscape Navigator 5.0 15:30-16:00 ==================================================== BREAK 16:00-17:30 Reports Jon Bosak, W3C XML WG: Report on XML namespaces Ken Holman, OASIS: Report on XML conformance Rohit Khare, IETF: Integrating XML in WebDAV Mary Holstege, FirstFloor XML in a multi-process Java server application Ray Niemeir, REZsolutions XML in Bookingspace xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu Mar 5 12:27:34 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:00:15 2004 Subject: Char & Java implementation In-Reply-To: <25721.199803041052@cockburn.cogsci.ed.ac.uk> Message-ID: <199803051227.AA00423@murata.apsdc.ksp.fujixerox.co.jp> In message "Re: Char & Java implementation", Richard Tobin wrote... > I think, but I'm not certain, that this encoding only applies to UTF-16 > and not UCS-2 (which would mean that the surrogate characters are an > error if encountered in a UCS-2 stream). Can anyone confirm/deny this? You are right. Surrogate pairs are not available in UCS-2. In message "Re: Char & Java implementation", Richard Tobin wrote... > Since none of the characters above FFFF are name characters, they are > irrelevant to the syntax of XML, and you don't need to convert the > pairs of "surrogates" into the characters they represent - you can > just pass them through to the application. Currently, yes. But probably we will need name characters above #xFFFF in a few years. [Thu, 05 Mar 1998 21:24:20 +0900] Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bannon at objs.com Thu Mar 5 17:18:36 1998 From: bannon at objs.com (Tom Bannon) Date: Mon Jun 7 17:00:15 2004 Subject: Reliable endpoints for XML docs (and doclets) Message-ID: <34FEDE4B.F6F651FF@objs.com> Hello all, Perhaps I've missed something, but I don't see that the start and end points of XML documents are well defined, ie. something like and , akin to HTML's and . As XML is rightly obsessed with the start and end of everything else, I find this mystifying. How am I to embed XML in other data (such as HTML, but certainly not limited to it) without such markers (other than hacking my own)? An important feature of such markers is that they can be located without having to be able to interpret any of the content between them. Implicitly defining the beginning and end of an XML document as [bof] and [eof] appears shortsighted, if that is the case. Can you set me straight on this? Thanks, Tom bannon@objs.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 ora.com Thu Mar 5 17:29:04 1998 From: crism at ora.com (Chris Maden) Date: Mon Jun 7 17:00:15 2004 Subject: Reliable endpoints for XML docs (and doclets) In-Reply-To: <34FEDE4B.F6F651FF@objs.com> (message from Tom Bannon on Thu, 05 Mar 1998 11:18:03 -0600) Message-ID: <199803051733.MAA17980@geode.ora.com> [Tom Bannon] > Perhaps I've missed something, but I don't see that the start and > end points of XML documents are well defined, ie. something like > and , akin to HTML's and . As XML is > rightly obsessed with the start and end of everything else, I find > this mystifying. How am I to embed XML in other data (such as HTML, > but certainly not limited to it) without such markers (other than > hacking my own)? An important feature of such markers is that they > can be located without having to be able to interpret any of the > content between them. Implicitly defining the beginning and end of > an XML document as [bof] and [eof] appears shortsighted, if that is > the case. Can you set me straight on this? The point of XML is that you can name your own element types. A required one would defeat the entire purpose. An XML document may have exactly one root element that contains everything else. When the first element begins, the document instance begins. When that element ends, the document instance ends. See clause 2.1 in the XML specification. By the way, xml-dev is for developers of XML applications. Questions of this sort are probably more appropriate on XML-L. Send mail to listserv@listserv.hea.ie with a body of "subscribe xml-l". -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 bannon at objs.com Thu Mar 5 18:35:10 1998 From: bannon at objs.com (Tom Bannon) Date: Mon Jun 7 17:00:15 2004 Subject: Reliable endpoints for XML docs (and doclets) References: <199803051733.MAA17980@geode.ora.com> Message-ID: <34FEF0AE.91FDB447@objs.com> Chris Maden wrote: > > [Tom Bannon] > > Perhaps I've missed something, but I don't see that the start and > > end points of XML documents are well defined, ie. something like > > and , akin to HTML's and . As XML is > > rightly obsessed with the start and end of everything else, I find > > this mystifying. How am I to embed XML in other data (such as HTML, > > but certainly not limited to it) without such markers (other than > > hacking my own)? An important feature of such markers is that they > > can be located without having to be able to interpret any of the > > content between them. Implicitly defining the beginning and end of > > an XML document as [bof] and [eof] appears shortsighted, if that is > > the case. Can you set me straight on this? > > The point of XML is that you can name your own element types. A > required one would defeat the entire purpose. My take is that XML offers a method of structured description. Required pieces would not damage such a goal, aesthetically unpleasing as they might be. Besides, well defined beginnings and ends are aesthetically pleasing. > An XML document may have exactly one root element that contains > everything else. When the first element begins, the document instance > begins. When that element ends, the document instance ends. > > See clause 2.1 in the XML specification. Well, then by XML definition, XML documents are un-embeddedable, as the start of an XML document cannot be programmatically determined in the general case (as and are optional, and the name of the root element is arbitrary). Thus to embed, one would have to define their own start and end markers. This can certainly be done, but it seems a much better idea to have this be part of the XML definition so that it can be done in a standard way. > By the way, xml-dev is for developers of XML applications. Questions > of this sort are probably more appropriate on XML-L. Send mail to > listserv@listserv.hea.ie with a body of "subscribe xml-l". Sorry, I'll copy this message there (when my subscription comes through!). Tom bannon@objs.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 ora.com Thu Mar 5 18:48:27 1998 From: crism at ora.com (Chris Maden) Date: Mon Jun 7 17:00:15 2004 Subject: Reliable endpoints for XML docs (and doclets) In-Reply-To: <34FEF0AE.91FDB447@objs.com> (message from Tom Bannon on Thu, 05 Mar 1998 12:36:30 -0600) Message-ID: <199803051853.NAA20641@geode.ora.com> [Tom Bannon] > My take is that XML offers a method of structured description. > Required pieces would not damage such a goal, aesthetically > unpleasing as they might be. Besides, well defined beginnings and > ends are aesthetically pleasing. What's poorly defined about ...? The first you find starts the document. The matching ends it. > Well, then by XML definition, XML documents are un-embeddedable, as > the start of an XML document cannot be programmatically determined > in the general case (as and are > optional, and the name of the root element is arbitrary). > > Thus to embed, one would have to define their own start and end > markers. This can certainly be done, but it seems a much better > idea to have this be part of the XML definition so that it can be > done in a standard way. Having ... would *prohibit* embedding, as I'd have to strip the element tags in order to embed within another . Without predetermined tags, I can have a document whose root element is , and then write another document whose root element is , and embed those s within the with no changes. The point here is that the boundaries of the document per se aren't really interesting. The boundaries of elements are. The document element may be mildly more interesting than other elements, but not so much so as to warrant markedly different treatment. Moreover, since it's trivial to find the boundaries of the document element, why add overhead? -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 ken at bitsko.slc.ut.us Thu Mar 5 19:21:35 1998 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Mon Jun 7 17:00:15 2004 Subject: Reliable endpoints for XML docs (and doclets) In-Reply-To: Tom Bannon's message of Thu, 05 Mar 1998 11:18:03 -0600 References: <34FEDE4B.F6F651FF@objs.com> Message-ID: Tom Bannon writes: > Perhaps I've missed something, but I don't see that the start > and end points of XML documents are well defined, ie. something > like and , akin to HTML's and . Yes, you've missed something :-). HTML has and because there is an implied (if missing) at the beginning of every HTML document. In XML you will have an explicit that will say that this document's top element is .... -- Ken MacLeod ken@bitsko.slc.ut.us xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 ora.com Thu Mar 5 19:29:17 1998 From: crism at ora.com (Chris Maden) Date: Mon Jun 7 17:00:15 2004 Subject: Reliable endpoints for XML docs (and doclets) In-Reply-To: (message from Ken MacLeod on 05 Mar 1998 13:00:19 -0600) Message-ID: <199803051933.OAA23751@geode.ora.com> [Ken MacLeod on xml-dev] > In XML you will have an explicit > > > > that will say that this document's top element is .... No, you won't. Not necessarily. An XML document can be completely well-formed without a DOCTYPE declaration (where, BTW, the DOCTYPE and SYSTEM keywords would need to be upper-case). However, as there is an implied with HTML files, in XML, you can imply a DOCTYPE from the root element. The first start-tag is the start-tag of the document element; when it ends, the document is over. Any markup or data (i.e., non-"misc") after the document element's end-tag is an error. Followups to xml-l. -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 jlapp at webmethods.com Thu Mar 5 19:41:42 1998 From: jlapp at webmethods.com (Joe Lapp) Date: Mon Jun 7 17:00:15 2004 Subject: Reliable endpoints for XML docs (and doclets) Message-ID: <3.0.32.19980305144459.00d9a210@tni.webmethods.com> >Tom Bannon wrote: >> Perhaps I've missed something, but I don't see that the start >> and end points of XML documents are well defined, ie. something >> like and , akin to HTML's and . I wonder whether Tom is remarking on how DTDs and PIs aren't themselves enclosed in tags. He seems to be concerned about this because he wants to embed XML in HTML. Seems like a good question. If this is the case, I believe the answer is that DTDs and PIs will not appear embedded. The DTDs and PIs would appear elsewhere. Where? I'm not sure that this has been decided yet. Namespaces will partly resolve this issue, but the document will still have to declare the namespaces somewhere (and this doesn't help us with PIs). Are these issues really open, or am I just out of the loop? I understand that there was an "XML in HTML" W3C meeting in February. Anyone know whether any of these issues were addressed or resolved? -- Joe Lapp, Technology Analyst | 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 Boris.Moore at rivcom.com Fri Mar 6 21:19:40 1998 From: Boris.Moore at rivcom.com (Boris Moore) Date: Mon Jun 7 17:00:15 2004 Subject: Reliable endpoints for XML docs (and doclets) Message-ID: <01BD494C.FF0A9E30@ami2-82.abo.wanadoo.fr> Joe Lapp wrote: >Tom Bannon wrote: >> Perhaps I've missed something, but I don't see that the start >> and end points of XML documents are well defined, ie. something >> like and , akin to HTML's and . >I wonder whether Tom is remarking on how DTDs and PIs aren't >themselves enclosed in tags. He seems to be concerned about this >because he wants to embed XML in HTML. Seems like a good question. In our work we have a Netscape/IE plug-in which receives downloaded XML and stylesheet data, and sends a resulting HTML stream to the browser rendering engine. We have certainly found it useful on occasion to include sections of HTML data which are skipped by the XML parser and sent without modification to the browser. Our browser is set, for the moment, to accept both sections within XML, and also sections within HTML sections. It would seem to me that when browsers are able to operate in either HTML, or XML + XSL modes, then being able to switch modes within a document (being able, in effect, to embed in either direction) could indeed become quite relevant and useful. Boris Moore RivCom "Publishing Structured Information" www.rivcom.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sat Mar 7 06:16:55 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:00:15 2004 Subject: SAX: finalising org.sax.xml.Parser References: <01bd4206$6ccb6d30$a00b0ac0@pharcyde.poetsoftware.xo.com> <199802251724.MAA02583@unready.microstar.com> <34F6321E.8D415644@jclark.com> <34FD73E0.7D7144C0@edu.uni-klu.ac.at> Message-ID: <3500DEF9.249F4B14@jclark.com> Juergen Modre wrote: > Where the setStandalone _overrides_ the setting in the xml-document > itself, _if_ set. > If _not_ set > a.) standalone setting in the xml document itself > -> use this setting > b.) no standalone setting in the xml document itself > -> defaults to the default setting of > the parser (= to 'no' like 2.9 in the XML spec says). The only problem I see with that is that this would make it difficult to have a getStandalone() method. I would prefer a setStandalone(int) with values: static final int STANDALONE_DOCUMENT = -1; static final int STANDALONE_NO = 0; static final int STANDALONE_YES = 1; James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sat Mar 7 06:23:26 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:00:15 2004 Subject: XP 0.2 released Message-ID: <3500E6CA.39340726@jclark.com> XP 0.2 is now available from http://www.jclark.com/xml/xp/index.html This just fixes a couple of bugs in the previous release. 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 sblackbu at erols.com Sat Mar 7 21:10:00 1998 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:00:15 2004 Subject: Freeware MFC/C++ XML Classes Message-ID: <01bd4a0d$5ecc4ec0$8c9baccf@sammy> I've just added a little XML parser (non-validating) class to my freeware library. It is an extension library for Microsoft Foundation Classes (although porting to Unix would be easy). The classes are named CExtensibleMarkupLanguageDocument and CExtensibleMarkupLangaugeElement in the Win32 Foundation Classes (WFC). It can be downloaded at: http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm Sam Blackburn sam_blackburn@pobox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SaxManJzz at aol.com Sun Mar 8 01:48:11 1998 From: SaxManJzz at aol.com (SaxManJzz) Date: Mon Jun 7 17:00:15 2004 Subject: XML Declaration in an HTML Page Message-ID: <28860e53.3501f88f@aol.com> Hello, Once again, I am wondering how you might embed an XML file into a HTML page through Microsoft's XML Parser. If anyone knows, please e-mail me back. Thanks, David xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 8 03:42:01 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:00:15 2004 Subject: XML Declaration in an HTML Page Message-ID: <001201bd4a43$660faed0$2ee044c6@donpark> David, >Once again, I am wondering how you might embed an XML file into a HTML page >through Microsoft's XML Parser. If anyone knows, please e-mail me back. You will not be able to embed arbiturary XML data into HTML. Some filtering and transformation is required to make sure everything is digestable by HTML browsers and processors. I assume that you are planning to bracket the XML data with an HTML tag which prevents rendering and access the XML elements through DOM from a scripting language like JavaScript. I do not see any serious problem with what you are trying to do. If you are looking for some guidelines in removing HTML hostile constructs of XML, I suggest you read the HTML spec. If you are looking for some software to do this, I do not think there is anything available at this time but it should be easy to write a SAX application which reads in XML resources and writes out HTML-friendly XML. Regards, Don Park http://www.quake.net/~donpark/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sun Mar 8 09:20:58 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:00:15 2004 Subject: SP 1.3 and Jade 1.1 available Message-ID: <3502615C.39F12DD@jclark.com> SP 1.3 and Jade 1.1 are now available. See http://www.jclark.com for more information. The main change in SP 1.3 is better support for XML based on the Web SGML TC. In Jade 1.1 the main changes are the experimental extensions for XSL (documented in dsssl2.htm), and the use of XML for the FOT backend's output. 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 ak117 at freenet.carleton.ca Sun Mar 8 11:36:09 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:00:15 2004 Subject: XML Declaration in an HTML Page In-Reply-To: <28860e53.3501f88f@aol.com> References: <28860e53.3501f88f@aol.com> Message-ID: <199803081135.GAA00321@unready.microstar.com> SaxManJzz writes: > Once again, I am wondering how you might embed an XML file into a > HTML page through Microsoft's XML Parser. If anyone knows, please > e-mail me back. Here's a simple example in HTML 4.0: If you can read this, your browser does not support embedded XML documents. (You might also want to get creative by using the `classId' attribute). All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com http://home.sprynet.com/sprynet/dmeggins/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amarshal at usc.edu Sun Mar 8 17:51:12 1998 From: amarshal at usc.edu (Andrew n marshall) Date: Mon Jun 7 17:00:15 2004 Subject: More Notes on DOM Message-ID: <01BD4A78.8A95DC90.amarshal@usc.edu> Thanks to all who replied to my last batch. The following is just a need for some clarifications: * Is the NodeEnumerator of a "live" NodeList, such as getChildren, also considered "live"? * Is an empty NodeList a valid response to getChildren for a Node that has no children (instead of null)? Andrew n marshall student - artist - programmer http://www.media-electronica.com/anm-bin/anm "Everyone a mentor, Everyone a pupil" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Mon Mar 9 09:05:31 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:00:15 2004 Subject: XML Link ? Message-ID: <199803090905.KAA01791@chimay.loria.fr> Hi, I'm currently developping an XML Link implementation in Java. I'm also working on an XML query language and an XML database/indexing system for large set of XML data. So i am very interresting in the XLL spec. What about the XML Link Specification ? Is there an update planned for the XLL Specification ? I've heard that the XML Link Specification (July-31-97) would give two different spec. : - XML Links - XML XPointers Is that true ? When will they be released ? Thanks a lot. Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Projet Aquarelle : http://aqua.inria.fr * Serveur Silfide : http://www.loria.fr/Projet/Silfide ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elm at arbortext.com Mon Mar 9 14:55:15 1998 From: elm at arbortext.com (Eve L. Maler) Date: Mon Jun 7 17:00:15 2004 Subject: XML Link ? In-Reply-To: <98Mar9.040617est.18817@thicket.arbortext.com> Message-ID: <3.0.5.32.19980309095106.00a53960@village.doctools.com> Funny you should ask. :-) We hope to release fresh Working Drafts of the newly-broken-up linking specifications in the next couple of days; I just need to clean up the HTML version and work with the W3C to get the files made available. These versions reflect a few changes since the August 1997 spec, but there are still a bunch of outstanding issues that we hope to work on very soon. Eve At 04:05 AM 3/9/98 -0500, Patrice Bonhomme wrote: > >Hi, > >I'm currently developping an XML Link implementation in Java. I'm also working >on an XML query language and an XML database/indexing system for large set of >XML data. So i am very interresting in the XLL spec. > >What about the XML Link Specification ? Is there an update planned for the XLL >Specification ? I've heard that the XML Link Specification (July-31-97) would >give two different spec. : > - XML Links > - XML XPointers >Is that true ? When will they be released ? > >Thanks a lot. > >Pat. >-- > ============================================================== > bonhomme@loria.fr | Office : B.228 > http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 > -------------------------------------------------------------- > * Projet Aquarelle : http://aqua.inria.fr > * Serveur Silfide : http://www.loria.fr/Projet/Silfide > ============================================================== > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ak117 at freenet.carleton.ca Mon Mar 9 15:55:27 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:00:15 2004 Subject: Announcement: AElfred, version 1.1 Message-ID: <199803091554.KAA02202@unready.microstar.com> Microstar Software Ltd. has just released version 1.1 of its free Java-based XML parser, AElfred. You can download AElfred from the following URL: http://www.microstar.com/XML/ AElfred is a very small, very fast XML parser optimised for use with applets, where Java 1.0.2 compatibility and download time are major requirements. AElfred is forgiving with some errors, but otherwise supports the entire feature set of the XML 1.0 recommendation including Unicode, defaulted attribute values, external DTD subsets, external entities, and flagging of ignorable whitespace. The distribution also contains a native SAX (Simple API for XML) driver so that you can interchange AElfred with other SAX-supported parsers without rewriting your code. Version 1.1 introduces a smaller, cleaner interface, together with some important new functionality: - the ability to read an XML document from an input stream as well as a URI - a new, optional SAX driver - a new, optional base class for deriving event handlers - a new, optional exception class for reporting parsing errors - use of the HTTP content-encoding parameter, if available - better position-reporting for errors For more detailed information on AElfred 1.1 changes, see http://www.microstar.com/XML/news.html All the best, David Megginson, Senior Architect, Microstar Software Ltd. -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com http://home.sprynet.com/sprynet/dmeggins/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ak117 at freenet.carleton.ca Tue Mar 10 12:23:17 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:00:15 2004 Subject: AElfred Bug and Patch Message-ID: <199803101222.HAA01104@unready.microstar.com> I have received a bug report for AElfred 1.1 (and earlier versions) concerning the treatment of signed bytes in UCS-2/UTF-16 and UCS-4 encoded text. I will put out a maintenance version 1.1.1 in a few days, once other people have had time to report any additional bugs; in the mean time, since the patch is tiny (1,529 characters), I am including here for anyone who needs UCS-2/UTF-16 or UCS-4 right away. Thanks to Yoshida Masato for the bug report. ====================8<====================8<==================== *** XmlParser.java 1998/03/09 11:51:40 2.3 --- XmlParser.java 1998/03/10 12:13:53 *************** *** 3961,3968 **** encodingError("odd number of bytes in UCS-2 encoding", -1, count); } for (int i = 0; i < count; i+=2) { ! readBuffer[j++] = (char)((rawReadBuffer[i] << shift1) | ! (rawReadBuffer[i+1] << shift2)); if (readBuffer[j-1] == '\r') { sawCR = true; } --- 3961,3969 ---- encodingError("odd number of bytes in UCS-2 encoding", -1, count); } for (int i = 0; i < count; i+=2) { ! readBuffer[j++] = ! (char)(((rawReadBuffer[i] & 0xff) << shift1) | ! ((rawReadBuffer[i+1] & 0xff) << shift2)); if (readBuffer[j-1] == '\r') { sawCR = true; } *************** *** 3999,4008 **** -1, count); } for (int i = 0; i < count; i+=4) { ! value = ((rawReadBuffer[i] << shift1) | ! (rawReadBuffer[i+1] << shift2) | ! (rawReadBuffer[i+2] << shift3) | ! (rawReadBuffer[i+3] << shift4)); if (value < 0x0000ffff) { readBuffer[j++] = (char)value; if (value == (int)'\r') { --- 4000,4009 ---- -1, count); } for (int i = 0; i < count; i+=4) { ! value = (((rawReadBuffer[i] & 0xff) << shift1) | ! ((rawReadBuffer[i+1] & 0xff) << shift2) | ! ((rawReadBuffer[i+2] & 0xff) << shift3) | ! ((rawReadBuffer[i+3] & 0xff) << shift4)); if (value < 0x0000ffff) { readBuffer[j++] = (char)value; if (value == (int)'\r') { ====================8<====================8<==================== All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com http://home.sprynet.com/sprynet/dmeggins/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pazandak at OBJS.com Tue Mar 10 21:25:37 1998 From: pazandak at OBJS.com (Paul Pazandak) Date: Mon Jun 7 17:00:16 2004 Subject: XML Documents Are Objects! (or "Killing OO Softly With XML") Message-ID: <3505B0C1.FA9493BA@OBJS.com> (html and text versions included) "Wouldn't it be nice if one could simply tell an object to serialize to XML, and then deserialize back into an object?" As programmers do you long for the old days when data was data and code was code? Do you buy into the idea that the behavior associated with data should be embedded within the application so as to restrict reuse of that data? Ah, the good old days of relational databases! In its current usage XML is enabling you to revisit those days again... but don't be persuaded by the dark force! Put on your OO glasses and see the light! Sure, XML provides incredible potential, and I am all for it. But in their current form, XML documents are nothing more than mobile semi-structured non-object databases (this is pretty cool, but not OO). Why is it that programmers have suddenly forgotten all about objects just so they could write XML? Is a return to relational databases that enticing? (Bleech!) The only practical reasoning behind such an approach is that programmers want to keep their data private. They don't want other applications to have the ability to reuse that data. They accomplish this feat by embedding all of the code associated with that data (formally called "behaviors" in the OO era) in their own applications. [Who's running this show anyway? Is XML some kind of conspiracy to kill OO?] Here's a simple example. You write an application that converts unformatted poems into composite poem objects rich with behavior. You want to store these poems, and share them with other applications that want to do things with poems (whatever it is you do with poems). You define an XML structure and start generating XML documents as a means to store and share the poems. Every application (including yours) that reads in your poems using an XML parser will see the poem as something similar to: [This XML document was taken from an example accessible at the Microstar website (distributors of the AElfred XML parser). The file name is donne.xml. Below is the parse tree for this document.] root |-> Element |-> Element |-> Element | |-> Element | |-> Element |-> Element | |-> Element |-> Element |-> Element |-> Element |-> Element Pretty impressive right? It sure doesn't look like a poem object does it? Once this structure has been generated every single application will need to supply its own code to understand how to navigate and interpret this structure, and provide behavior for it. This is typical if you are a C programmer, but be clear, this isn't OO. And, while DOM takes us a bit farther, you still won't get the parser to produce a poem object and its poem-specific behaviors from the XML document (but we still want DOM!). The process of generating XML strips the behavior out of the objects; or, saying it differently, XML and related standards do not describe a mechanism by which one can attach behavior to XML documents. The parser, in turn, cannot therefore work miracles when it reads the data (which are no longer objects) back into the application. Or can it? Why can't we view XML as a serialized object representation? If we agree that this is not too far fetched, then why can't parsers deserialize or objectify the objects contained in the XML documents, rather than simply handing us data and making the applications do all of the work? What if the parsers generated real classes (with behavior!) instead of generic Element classes? The poem above would instead look like this: (perhaps if we talked about XML documents as orders (or anything else) instead of poems it might be more motivating?) root |-> poem |-> front |-> title | |-> author | |-> revision-history |-> item | |-> body |-> stanza |-> stanza |-> stanza |-> stanza Oh, but could it be that simple? (The answer is "yes.") Would having a parser output objects with type-specific behavior be useful? (Hmm...) Would programmers really want to share their objects if they could? (The answer should be "yes.") Even if they didn't want to share their objects, or if nobody wanted their objects, why violate the principles of OO and make the programmers' lives more difficult? Wouldn't it be nice if one could simply tell an object to serialize to XML, and then deserialize back into an object? With some VERY simple extensions to current parsers this can occur, and already has -- we've created an extended version of the Lark XML parser which provides this capability. Our input to this extended parser is the XML document and the type-specific classes (like poem) extended with the basic ability to deserialize themselves. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- XML Documents Are Objects! or Killing OO Softly With XML Paul Pazandak Object Services and Consulting, Inc. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Introduction XML documents are indeed objects, or at least they could be. If we simply associate behavior with the data structures defined within the XML documents we could have normal, living, breathing objects... like we're used to in the programming world. Instead of enabling the parser breathe life back into our objects, as part of the deserializing or re-objectifying the object, we are forced to do this within our applications. Simply put, parsers aren't doing enough for us. XML parsers currently support non-portable object specifications. While the XML documents themselves are portable by virtue of being written in XML, the objects represented by those documents are cannot be objectified without an accompanying document-specific application which interacts with the parser. Current XML parsers provide the ability to parse an XML document, and perhaps generate a generic object structure (parse tree) corresponding to the document. However, XML documents could potentially represent more than simple structured documents, they could describe complex objects with behavior. Common (simple) examples of XML documents include address lists. But making use of this information requires each application which desires to consume address lists to write parser-related code, as well as code to implement the behaviors of the address lists and their entries. We propose a simple extension to parsers which would all but eliminate application-parser interaction and the need for document handlers (which do not migrate with the XML document), and would facilitate objectifying XML documents into type-specific objects (like we're used to having in the programming world) having all related behaviors intact. Background Current XML parsers generate generic parse trees (most do anyway). These trees represent the structure of the data that was parsed. But what is missing is the behavior associated with this data. While there are methods associated with the generic parse tree elements, these are not data-specific but rather generic methods (see the sample code). This approach places the burden on the application to deserialize the document back into objects using the generic calls and a lot of validating code. This is true of all current XML parsers (which support parse tree generation). Once the XML document is parsed the information needs to be retrieved by the application, so it must access it from the parse tree (if one was generated -- see the note on problems with event-based parsing). In general, the consuming application may proceed in one of two ways to accomplish this: * Simple Extraction. The application will march down the structure, extracting out and consuming the data as it goes. This requires making calls using the generic parse tree methods (parser-specific -- SAX doesn't support a parse tree API). * Tree Transformation / Mapping The application copies the data out of the generic parse tree into type-specific structures (e.g. Java objects) which contain type-specific definitions. The data is then accessed by the application using the type-specific API of these new structures. In both cases, the application embeds the intelligence of how to access the data within itself. This is not unlike the approach used by relational database applications which separates the data from its behavior. If another application wishes to access this data, it must define its own behavior for that data. An Example Here's an example to illustrate this. This XML document was taken from an example accessible at the Microstar website (distributors of the AElfred XML parser). The file name is donne.xml. When an XML parser generates a parse tree for this document, the resulting (informative) tree will look like the following in Lark (and similar in the other parsers as well): root |-> Element |-> Element |-> Element | |-> Element | |-> Element |-> Element | |-> Element |-> Element |-> Element |-> Element |-> Element The Element entries are the objects created by XML parser corresponding to the Element Declarations in the XML document. To determine what each element is, the application must navigate the structure and inspect each Element object using a generic API. This requires that the knowledge of how to navigate the structure is embedded within the application. The interface of this object must be embedded within the application as well which really violates the object-oriented paradigm -- yes, the data is stored in objects, but the associated type-specific behavior is stored someplace else. While this may appear similar to how objects are serialized today (without code), the distinction is that any other application that wants to access this object will not have access to the code since it is buried in the application which created it. All other applications will have to provide their own code (this, again, is how applications for relational databases are written). There are several other problems with this approach, not the least of which is that the application should not be responsible for doing this. Furthermore, the parser-related code required to walk a complex structure is complex itself (not quite as complex as code used for event-based parsing of complex structures however), and is more difficult to maintain. Finally, the application is forced to do what the parser has already done, that is understand and navigate the structure of the document. The parser has already gone through the entire document and generated a structured instantiation of objects. The crux of the problem is that the parser generates generic objects which forces all of this additional work on the application. Worse yet, there is no reason this has to occur -- nor does the (tree-generating) parser have to be significantly modified. Event-based parsing An alternative to tree generation is simply to consume the structure on-the-fly as it is parsed. This requires writing an XML structure-specific handler (a document handler in SAX terms) which describes what should happen for each XML declaration that is encountered; no structure is automatically generated, so if objectification of the XML document is desired the handler is responsible for this. Using event-based parsing the application could adopt either of the above two approaches, the first being simple consumption and the latter which would cause the construction of some structure corresponding to the XML document. In both cases, at least for complex XML structures, there would be a lot of conditional segmented code which is more difficult to write and modify when changes in the XML structure occur. Using the extension proposed the majority of the work is done by the tree-generating parser, empowering the application to see XML documents as objects and alleviating their burden of using event-based parsing. Granted, when an application will only encounter one kind of XML structure, event-based parsing might be a reasonable approach from the standpoint that only one handler would need to be written. But it still suffers from some of the same problems as generic parse tree generation (see the summary section). XML Parsers Extended What if the output of the parser was a type-specific structure which coincided with the definition of the structure in the XML document? And, what if that resulting objects contained the type-specific behavior for the specific element type parsed? What if the resulting parse tree for the example above instead looked like: root |-> poem |-> front |-> title | |-> author | |-> revision-history |-> item | |-> body |-> stanza |-> stanza |-> stanza |-> stanza where poem, front, body, title, author, revision-history, and stanza were all classes with type-specific behavior? Instead of writing something like the following to retrieve the title of the poem: Element front = null; Vector v = root.chilren(); if (v != null) { Element front = v.elementAt(0); // v(0) "should" be the front element, we hope if (front != null) v = front.children(); for (i=0; i < front.size(); i++) { Element child = v.elementAt(i); if child.type().equals("title") return child.content(); } } } return null; one could simply write: poem.getTitle(); More importantly, all of the behaviors that should be associated with each of these object types would be defined as part of the object interfaces themselves rather than embedded within the application. Granted, an application can generate this same structure using the transformation / mapping technique above. However, this is partially a duplication of effort since it requires the application to navigate the structure generated by the parse tree, and then generate a new structure which mirrors the parse tree. The extension to Lark eliminates the need to do this because it instantiates the correct type-specific parse tree the first time. Note that this is an extension to Lark, and therefore applicable to any XML document. Details What occurs in the underlying implementation of an XML parser is rather straightforward. When it sees an XML element declaration, it instantiates a generic Element object (with Element only related methods). The extension to Lark simply extends the behavior of the parser so that instead of instantiating generic Element objects, it instantiates type-specific ones. So when the parser encounters a new element declaration, it looks for a class declaration which identifies which class to instantiate in lieu of a generic Element class object (where it looks is described below). For example, when the parser identifies the "poem" element declaration, it looks for a class declaration for poem. If it finds one, it instantiates an object of that class rather than a generic Element object. The poem class extends the interface of the Lark Element class, but in addition, adds type-specific methods relevant to a poem object. Within a type-specific parse tree class, like poem, is code which understands how to extract the parsed information. In effect, the object understands how to investigate itself. This code is provided by the object type creator. It will travel with the object as a means to facilitate re-objectifying the XML back into an object. This enables reuse of the object by any application. Of course, as stated above, the poem class will also provide a poem-specific interface. A method I have added to the Element class is process(). It can be called once an element has been parsed. In each implementation, for example within the poem class, the process() code handles extracting the data from the inherited generic structures of the Element class. Alternatively, poem methods could simply be written that do this directly. But, it is important to note that the object itself is doing this, and further, that no other parse trees or duplicate structures are being constructed. The location of the class declaration is not hard-coded. It could be within the XML file itself, in a DTD, in a stylesheet, or in a remote repository, for example. In addition, local class declarations may be used to override default class declarations. In the implementation of the Lark extension, I have simply embedded them in the DTD file along with the declaration of the structure of the XML file. In its current form the class declaration would look like the following for the poem example above, although there would be many ways to accomplish this: ... The ClassSuffix is used to avoid possible naming collisions (which may be solved otherwise using the XML namespaces proposal). So, when a new element declaration is identified by Lark it inspects this list looking for an entry matching the pattern , or in the case of the poem element declaration, "Poem-Class". Cavaet Language? Is this a language-specific extension? Not really. The class declarations could be (for example) written in Active-X I suppose, or even wrapped in CORBA, thereby enabling any language to take advantage of the idea of XML documents as objects. It would up to the parser to find the correct class declaration and objectify accordingly. Implementation Experience My experience with XML parsers began last year. As part of a DARPA-funded project I am implementing an architecture to demonstrate scalable object service architectures. I started using event-based parsing as a means to import object service specifications. These XML specifications represent real (Java and CORBA) services that are invoked by the architecture. I noticed that by adopting an event-based approach to parsing I would have to write a lot of code which would be difficult to maintain should I have changes in the future. In addition, this code would be hard for someone else to understand since each parser callback method would include conditional statements for several types of elements, and the code would be spread across several methods. I prefer a clean separation of code whenever possible, and this didn't seem very clean. I decided that tree parsing was a more practical route. The parser would automatically generate a structure for me. But, then I realized that I had to write all of the code to navigate this generic object structure, pull out the information I wanted, and then copy it into service specification objects having the behavior I wanted. Since the parser was already generating classes, why not just tell it to generate the real classes to begin with? The classes themselves would handle deserialization. Sounds like OO to me! With modest changes to Lark, when it sees an XML service specification document it will generate service specification objects right away. This extension will work for any XML document which defines specializations of the Element class and makes them available to the parser. Besides asking Lark to parse the document, my application has no other parser-related code. Furthermmore, any other application can use my XML service specification documents, and load them in as service specification objects with only a few lines of code. Summary In summary, an extension has been presented which extends the capabilities of Lark, but which could be applied to all tree-generating XML parsers. It enables type-specific composite object construction to occur within the parser which is a significant improvement over generic parse tree construction because: * We can attach behavior to XML documents. * We can therefore treat XML documents as objects. * It eliminates most of the neccessity of the application to understand SAX, or parser-specific structures, as well as reducing the amount of direct interaction between the application and the parser. To a certain extent DOM will accomplish this, but the extension proposed here augments this by enabling the generation of type-specific interfaces. * The application is then free to interact with the generated objects as "real" objects having type-specific structure and behavior. * More importantly, the XML documents can roam freely (likened to serialized objects) which can be objectified again by any application. This would not be possible with generic tree parsing or with event-based parsing (which requires specialized structure-specific parsing handlers). If we view XML as a means to serialize an object, we should view the parser as the mechanism to deserialize (or objectify) it. Once we convert an object to an XML representation, it simply doesn't make sense to throw away its behavior or the code which understands how it should be deserialized. Embedding this knowledge within an external application is just revisiting the relational DBMS experience and ignores the principal benefits of object technology. If this proposed extension were adopted it would benefit significantly from a standardization of the Element interface (something that will happen with DOM). In this way, the associated class files would not be parser-specific, and therefore any XML document could be objectified by any tree-generating parser. Status I anticipate that the extensions I have made to Lark will be incorporated into a next version of Lark (I assume this from previous dialogues I have had with Tim Bray). If not, and in the meantime, the enhanced version of Lark is freely available on request. References & Acknowledgements Related work in this area is described in Towards a Web Object Model by Frank Manola, Object Services and Consulting, Inc. Thanks to Frank Manola (OBJS, Inc.) and Tim Bray (Textuality, Inc.) for their useful feedback. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government. ? Copyright 1998 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information in this document. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pazandak at OBJS.com Tue Mar 10 21:35:42 1998 From: pazandak at OBJS.com (Paul Pazandak) Date: Mon Jun 7 17:00:16 2004 Subject: In HTML: XML Documents Are Objects! (or "Killing OO Softly With XML") References: <3505B0C1.FA9493BA@OBJS.com> Message-ID: <3505B334.8B36C0D4@OBJS.com> It looks like my last post was messed up a bit. Here's a text intro with the entire document attached in HTML. Sorry for the double post. ======================================================================= "Wouldn't it be nice if one could simply tell an object to serialize to XML, and then deserialize back into an object?" As programmers do you long for the old days when data was data and code was code? Do you buy into the idea that the behavior associated with data should be embedded within the application so as to restrict reuse of that data? Ah, the good old days of relational databases! In its current usage XML is enabling you to revisit those days again... but don't be persuaded by the dark force! Put on your OO glasses and see the light! Sure, XML provides incredible potential, and I am all for it. But in their current form, XML documents are nothing more than mobile semi-structured non-object databases (this is pretty cool, but not OO). Why is it that programmers have suddenly forgotten all about objects just so they could write XML? Is a return to relational databases that enticing? (Bleech!) The only practical reasoning behind such an approach is that programmers want to keep their data private. They don't want other applications to have the ability to reuse that data. They accomplish this feat by embedding all of the code associated with that data (formally called "behaviors" in the OO era) in their own applications. [Who's running this show anyway? Is XML some kind of conspiracy to kill OO?] Here's a simple example. You write an application that converts unformatted poems into composite poem objects rich with behavior. You want to store these poems, and share them with other applications that want to do things with poems (whatever it is you do with poems). You define an XML structure and start generating XML documents as a means to store and share the poems. Every application (including yours) that reads in your poems using an XML parser will see the poem as something similar to: [This XML document was taken from an example accessible at the Microstar website (distributors of the AElfred XML parser). The file name is donne.xml. Below is the parse tree for this document.] root |-> Element |-> Element |-> Element | |-> Element | |-> Element |-> Element | |-> Element |-> Element |-> Element |-> Element |-> Element Pretty impressive right? It sure doesn't look like a poem object does it? Once this structure has been generated every single application will need to supply its own code to understand how to navigate and interpret this structure, and provide behavior for it. This is typical if you are a C programmer, but be clear, this isn't OO. And, while DOM takes us a bit farther, you still won't get the parser to produce a poem object and its poem-specific behaviors from the XML document (but we still want DOM!). The process of generating XML strips the behavior out of the objects; or, saying it differently, XML and related standards do not describe a mechanism by which one can attach behavior to XML documents. The parser, in turn, cannot therefore work miracles when it reads the data (which are no longer objects) back into the application. Or can it? Why can't we view XML as a serialized object representation? If we agree that this is not too far fetched, then why can't parsers deserialize or objectify the objects contained in the XML documents, rather than simply handing us data and making the applications do all of the work? What if the parsers generated real classes (with behavior!) instead of generic Element classes? The poem above would instead look like this: (perhaps if we talked about XML documents as orders (or anything else) instead of poems it might be more motivating?) root |-> poem |-> front |-> title | |-> author | |-> revision-history |-> item | |-> body |-> stanza |-> stanza |-> stanza |-> stanza Oh, but could it be that simple? (The answer is "yes.") Would having a parser output objects with type-specific behavior be useful? (Hmm...) Would programmers really want to share their objects if they could? (The answer should be "yes.") Even if they didn't want to share their objects, or if nobody wanted their objects, why violate the principles of OO and make the programmers' lives more difficult? Wouldn't it be nice if one could simply tell an object to serialize to XML, and then deserialize back into an object? With some VERY simple extensions to current parsers this can occur, and already has -- we've created an extended version of the Lark XML parser which provides this capability. Our input to this extended parser is the XML document and the type-specific classes (like poem) extended with the basic ability to deserialize themselves. The details are described in the attached document. The enhanced version of Lark is freely available on request. Paul. -- ******************************************************************** Paul Pazandak pazandak@objs.com Object Services and Consulting, Inc. http://www.objs.com Minneapolis, Minnesota 55420-5409 612-881-6498 ******************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980310/5f58d8db/ExtendingLark.htm From schampeo at hesketh.com Tue Mar 10 21:48:00 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:00:16 2004 Subject: XML Documents Are Objects! (or "Killing OO Softly With XML") In-Reply-To: <3505B0C1.FA9493BA@OBJS.com> Message-ID: On Tue, 10 Mar 1998, Paul Pazandak wrote: > Who's running this show anyway? Is XML some kind of conspiracy to kill OO? Nah, I thought the whole CORBA vs. COM war was a conspiracy to kill OO... -- Steven Champeon | "Does wanting a feeling http://hesketh.com/schampeo/ | matter anymore?" http://a.jaundicedeye.com | - Husker Du xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dima at paragraph.com Tue Mar 10 22:25:46 1998 From: dima at paragraph.com (Dmitri Kondratiev) Date: Mon Jun 7 17:00:16 2004 Subject: XML Documents Are Objects! (or "Killing OO Softly With XML") Message-ID: <2.2.32.19980310222414.00733120@dream.paragraph.com> At 15:27 10.03.98 -0600, Paul Pazandak wrote: >(html and text versions included) > "Wouldn't it be nice if one could simply tell an object to serialize to XML, and then deserialize back into an object?" > You are on the right track. In fact, there is a lot of discussion going on Java2XML serialization for quite a while already. To say more, JSXML ) is a Java/XML serialization API that Bill la Forge at "The Open Group" works on. It may be also interesting for you to check XLogo - a pilot project attempting to make a next step : from Java/XML serialization to Meta OO Programming. cheers, Dima ----------------- Dmitri Kondratiev dima@paragraph.com 102401.2457@compuserve.com http://www.geocities.com/SiliconValley/Lakes/3767/ tel: 07-095-464-9241 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 opengroup.org Tue Mar 10 22:28:11 1998 From: b.laforge at opengroup.org (Bill la Forge) Date: Mon Jun 7 17:00:16 2004 Subject: XML Documents Are Objects! (or "Killing OO Softly With XML") Message-ID: <3.0.32.19980310173257.00aa2310@postman.osf.org> Paul, I've been proposing effectively the same thing on the java-xml-interest@opengroup.org list. I've been using the term COIN to express this concept--a coin has two faces, an XML element and a Java Object. Bill For information about java-xml-interest, see http://www.camb.opengroup.org/~laforge/jxml.html >>From java-xml-interest-request@opengroup.org Mon Mar 9 20:03:05 1998 >Return-Path: >Resent-Date: 10 Mar 1998 01:03:02 -0000 >Resent-Cc: recipient list not shown: ; >X-Sender: laforge@postman.osf.org >Date: Mon, 09 Mar 1998 20:09:11 -0500 >To: java-xml-interest@opengroup.org >From: Bill la Forge >Subject: State of Coins >Resent-Message-ID: <"27dFJtr0wrF.A.4bH.CFJB1"@postman.opengroup.org> >Resent-From: java-xml-interest@opengroup.org >X-Mailing-List: java-xml-interest:archive/latest/104 >X-Loop: java-xml-interest@opengroup.org >Resent-Sender: java-xml-interest-request@opengroup.org > >The tests for coins now successfully executes the following XML: > > > > > > >This is run simply with the command: > java ORG.opengroup.coins.Coins text4.xml >where test4.xml contains the above document. The output from the test is: > XYZ=123 > >The code for the coin TestFace is found at: > http://www.camb.opengroup.org/~laforge/axtp/src/ORG/opengroup/coins/tests/TestFace.java > >My contention is that coins are "better" than Java Beans, though it is difficult >to make any valid determination on the basis of such a small sample size (1!). > >My intention is to begin converting AXTP to use coins. > >I further contend that my XML processor is pretty bad. The fact that it now has >semantic support for ids and idrefs doesn't really change that. The processor >can be found at: > http://www.camb.opengroup.org/~laforge/axtp/src/ORG/opengroup/coins/Coins.java >(I've also taken care that the processor will work with signed elements, only >recomposing those elements on output which were "dirty".) > >Dmitri and Gavin find coins to be a subset of DOM. > >>>>Gavin: > >As one of the DOm WG members, I can tell you there is no conflict. You >could use DOM for some of the things in Coins, but with a probable >loss in performance. > ><<< > >I conclude from this that the api which Dmitri referenced should be, at least in part, >used where appropriate. (Why have needless variations?) > >You may enjoy the new coins package documentation at: > http://www.camb.opengroup.org/~laforge/axtp/api/Package-ORG.opengroup.coins.html > >I've also updated the AXTP zip file to include >this latest version of the coins package: > http://www.camb.opengroup.org/~laforge/axtp/#related_links > >All in all, its been a productive evening. >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 tbray at textuality.com Wed Mar 11 14:09:45 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:00:16 2004 Subject: Interesting Press Release from O'Reilly Message-ID: <3.0.32.19980311060441.00ae51ec@pop.intergate.bc.ca> FOR IMMEDIATE RELEASE For Further Information Contact Ellen Elias (707)829-0515 ext. 322 elias@oreilly.com http://www.oreilly.com/ LEADING PERL AND XML DEVELOPERS COLLABORATING Goal: To Make Perl the Top Scripting Language for XML Sebastopol, CA, March 10, 1998--Leading Perl and XML (Extensible Markup Language) developers met recently at O'Reilly & Associates to plan a way for Perl, the popular Web programming language, and XML, the hottest Web mark-up technology, to work together. Attending the Perl/XML Summit were: * Larry Wall, creator of Perl, and senior developer, O'Reilly & Associates * Tim Bray, co-editor of the XML 1.0 specification and independent consultant * Dick Hardt, developer of Perl for Win 32, and Chief Technology Officer, ActiveState Tool Corp. * Tim O'Reilly, President and CEO, O'Reilly & Associates * Dale Dougherty, CEO, Songline Studios * Gina Blaber, Director, Software Products Group, O'Reilly & Associates. One major goal resulted from the summit: to make Perl the scripting language of choice for processing XML. As Perl support for XML increases, it is expected, in turn, to make XML more accessible. "XML is currently perceived as powerful and important, but not particularly easy," explains Larry Wall. "This makes XML and Perl naturally complementary, since Perl is a language that makes easy things easy to do, and hard things possible." One of the summit group's first priorities is to get Perl working with Unicode (ISO 1046). Unicode enables code to be easily translated into other languages; XML requires Unicode. Larry Wall will lead the team working on this task. "In the design of XML, we were continuously mindful of the need to enable the fast, efficient creation of scripts and programs for processing XML," says Tim Bray. "Perl is the Web's pre-eminent text processing tool, and it's really great that the leaders of the Perl community are going to meet us halfway on this." "For many of us in the XML effort, the most important goal is to increase the proportion of the world's documents stored in open, non-proprietary formats," Bray continues. "Building slick XML processing into Perl makes the use of such formats more rewarding and helps frustrate the efforts of those who would imprison human knowledge behind the barbed-wire of proprietary file formats." A number of Perl/XML activities will take occur over the next few months, according to Gina Blaber. * The group plans to release a Perl/XML spec in Q3, 1998. * There will be a new Web site for XML, hosted by O'Reilly/Songline Studios with content from Tim Bray and Seybold Corporation. Larry Wall and Tim Bray are co-authoring an XML white paper, to be released this spring. * Larry Wall and Dick Hardt will speak on Perl and XML at XML Developer's Day, a technical conference for XML developers in Seattle on March 27, 1998. ABOUT XML A subset of Standard Generalized Markup Language (SGML), XML is similar to HTML in that it uses tags. But XML communicates information about the structure of a document, rather than the look of it, as HTML does. That structural information is the key to a wide range of applications for which XML is already being used. XML is not proprietary, meaning a document's information and structure will function in a true cross-platform manner. XML was recently approved by W3C, the consortium of Web heavyweights, and is expected to have great impact on the rapid spread of electronic commerce. ABOUT PERL Perl is currently the most popular technology for turning Web pages from a collection of static documents into dynamic information applications. Easy-to-use, efficient, flexible and strong, the cross-platform programming language can run dynamic Web sites, databases, and CGI applications, perform system management tasks, and scan, extract information from, and print reports about text files. Widely available on the Internet since 1989, Perl's active developer community regularly contributes tools and extensions to Comprehensive Perl Archive Network (CPAN), numerous online groups, and sites such as http://www.perl.com. O'Reilly & Associates' "Programming Perl," written by Larry Wall, was one of the best-selling programming books of 1997. # # # xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From anders at rcs.urz.tu-dresden.de Wed Mar 11 14:44:01 1998 From: anders at rcs.urz.tu-dresden.de (Andrea Anders) Date: Mon Jun 7 17:00:16 2004 Subject: XML-Viewer Message-ID: Hi, I want to know why I need special XML-viewers (written in java like msie), when every SGML-Viewer should be able to show XML-pages. Can anyone explain me please !? Thanx Ruben Gersdorf xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 isogen.com Wed Mar 11 15:04:07 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:00:16 2004 Subject: XML-Viewer Message-ID: <3.0.32.19980311085900.006b5078@swbell.net> At 03:42 PM 3/11/98 +0100, Andrea Anders wrote: >Hi, > >I want to know why I need special XML-viewers (written in java like msie), >when every SGML-Viewer should be able to show XML-pages. Can anyone >explain me please !? There are two problems with viewing XML documents with SGML viewers: 1. XML requires a special SGML declaration. Not all SGML viewers support alterntative SGML declarations (Panorama and all Synex Viewport-based viewers do not, for example). 2. Unless an SGML viewer supports the WebSGML TC, it may not recognize a well-formed XML document as also being an SGML document. Because PIs in XML end with "?>" instead of the default ">" of SGML, the XML declaration PI may be enough to cause some SGML viewers to reject the document entirely. Having said all this, I would be very supprised if there are any actively-developed SGML viewers that don't support XML within the next 6 to 12 months. It's not like it's hard to do. Cheers, Eliot --
W. Eliot Kimber, Senior Consulting SGML Engineer Highland Consulting, a division of ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 95202. 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 mike at yoyo.com Wed Mar 11 16:31:52 1998 From: mike at yoyo.com (Mike Rogers) Date: Mon Jun 7 17:00:16 2004 Subject: XML Documents Are Objects! (or "Killing OO Softly With XML") Message-ID: <199803111630.LAA14105@linux.oyoy.com> >> >On Tue, 10 Mar 1998, Paul Pazandak wrote: >> >> Who's running this show anyway? Is XML some kind of conspiracy to kill OO? >> > I think quite the opposite. XML now provides a uniform way for non heterogenous OO systems to communicate with each other. Mike ---- Mike Rogers * Webmaster * Yoyodyne Entertainment (914) 591-9696 * http://www.yoyobiz.com/ * mike@yoyo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 11 16:37:42 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:00:16 2004 Subject: Interesting Press Release from O'Reilly References: <3.0.32.19980311060441.00ae51ec@pop.intergate.bc.ca> Message-ID: <3506BE0A.F6D732CC@technologist.com> Let me take this opportunity to point out that Python already ships with an xmllib.py which is a non-validating XML parser module. Plans for the next version of Python are more extensive. Also Python/XML programming was featured in the February Dr. Dobbs. Python is going to give Perl a real run for its money in this niche (although it doesn't support Unicode yet either). Paul Prescod - http://itrc.uwaterloo.ca/~papresco Can we afford to feed that army, while so many children are naked and hungry? Can we afford to remain passive, while that soldier-army is growing so massive? - "Gabby" Barbadian Calpysonian in "Boots" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gmckenzi at JetForm.com Wed Mar 11 20:16:20 1998 From: gmckenzi at JetForm.com (Gavin McKenzie) Date: Mon Jun 7 17:00:16 2004 Subject: Interesting Press Release from O'Reilly Message-ID: I realize that comments on the press release aren't really on topic for this group, but... I don't want to start a 'this scripting lang is better than that scripting lang' religious argument, but I'm hoping that we can all see that ECMAScript (JavaScript) is a current and lightweight scripting language handled by a standards body. Further, you can get implementations on lots of platforms. There's a freely available engine called FESI (can't remember the URL) and an engine available on alot of platforms from a company called Nombas (www.nombas.com). Just wanted to point it out, given that XSL already seems to have ECMAScript in it, and it is more accessible to non-developer types like my customers than Perl. Gavin. >---------- >From: Paul Prescod[SMTP:papresco@technologist.com] >Sent: Wednesday, March 11, 1998 11:38 AM >To: xml-dev@ic.ac.uk >Subject: Re: Interesting Press Release from O'Reilly > >Let me take this opportunity to point out that Python already ships with >an xmllib.py which is a non-validating XML parser module. Plans for the >next version of Python are more extensive. Also Python/XML programming >was featured in the February Dr. Dobbs. Python is going to give Perl a >real run for its money in this niche (although it doesn't support >Unicode yet either). > > Paul Prescod - http://itrc.uwaterloo.ca/~papresco > >Can we afford to feed that army, > while so many children are naked and hungry? >Can we afford to remain passive, > while that soldier-army is growing so massive? > - "Gabby" Barbadian Calpysonian in "Boots" > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dima at paragraph.com Wed Mar 11 21:21:08 1998 From: dima at paragraph.com (Dmitri Kondratiev) Date: Mon Jun 7 17:00:16 2004 Subject: XML2ApplObject Framework Message-ID: <2.2.32.19980311211938.00990600@dream.paragraph.com> A few more comments I have on "XML Documents Are Objects! (or "Killing OO Softly With XML")" thread : I need __XML to problem domain object mapping API__ that will work not only in Lark, but other parsers too. To say more, I need this to work not only in parsers which work results in object _tree structure_, but in _event-based parsers_, that use SAX API, for example. In other words, I want XML2ApplObject Framework (such as Coins) *independent* from XML parser used. That was the point in my previous message about Coins vs DOM. The main point here is that my appl. may use different APIs to parse XML *at once*. So, I'd like to have a freedom to use DOM to do "regular" staff with my XML document and Coins to do *application specific* XML2ApplObject mapping. In this case, I will certainly want Coins to use object tree that DOM will produce. This will allow to avoid duplicating functionality in the code. In the other case I'd like to use SAX for "regular" work and naturally will want Coins to work with SAX. From this follows a simple conclusion: - XML2ApplObject framework should not parse XML itself. - XML2ApplObject should be configurable in run time to work with different XML parsing APIs. This can be done, in simple, case with factories, as well as other techniques that OI (Open Implementation) exploits. Dima ----------------- Dmitri Kondratiev dima@paragraph.com 102401.2457@compuserve.com http://www.geocities.com/SiliconValley/Lakes/3767/ tel: 07-095-464-9241 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Mar 12 13:05:55 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:00:16 2004 Subject: SAX: Resolving entity sysids Message-ID: I'm currently writing an SGML Open catalog parser in Python for inclusion in a set of XML parsing tools I'm building at the moment and I'm also writing a SAX EntityHandler to interact with the catalog parser. However, those SGML Open catalogs allow one to specify things like ENTITY my-entity "sysid1" ENTITY %my-entity "sysid2" Which causes me grief, since SAX does not distinguish between these two kinds of entities so there's no way to tell whether the entity name given in the call to resolveEntity belongs to a general or parameter entity. If XML does not have separate name spaces for parameter and general entities this won't be a problem, but as far as I understand the 1.0 spec, the name spaces are separate. One way to solve this might be to use a preceding "%" in the entity name to signal parameter entities. Since "%"s are not allowed to start entity names this should be sufficient. Clients that aren't interested in the difference can just disregard the leading "%". BTW: This is actually the first "problem" I've had with the SAX specification. IMHO it is very clear and includes exactly what is needed. Well done! :) -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dima at paragraph.com Thu Mar 12 13:11:47 1998 From: dima at paragraph.com (Dmitri Kondratiev) Date: Mon Jun 7 17:00:16 2004 Subject: Wish list for XMLApplication Framework Message-ID: <2.2.32.19980312131207.0096d32c@dream.paragraph.com> The following are some of the features I'd like to be able to use in XMLApplication Framework : - Support for both, event-based and tree-based parsers, to serialize XML elements to application-specific element-objects. Tree-based approach is certainly cleaner when you need to parse document as a whole, but, imagine, in my appl. I may need to stop parsing relatively big document in the middle, when I come across some element. So I don't need the whole tree! And still I may need to instantiate my appl. specific element-objects. - Runtime configuration of "element-semantic" handlers. Ideally I'd like to be able to switch element-semantic handlers in run-time. This might seem nonsense first, but if you give this idea a second thought you'll see the point. XML is very wise to **not imply element semantic**, so it may be useful for some app. (such as mine) to be able to switch one or more times when processing a document from one set of element-objects to another. In other words the ability to bind different semantic-handlers (and thus element-objects) to elements in runtime is needed. Naming handler in the XML document will allow to start parsing with some general "semantic-switch" handler, that will activate different semantic-handlers as needed. - Basic support for element-object to element markup serialization. This will allow application to modify element-object in runtime and then serialize it **in application-specific way** back in markup representation by means of XMLDataOutputStream stream connected to XML document instance. - Markup ReadElement/InsertElement from/to XMLDataInputStream/XMLDataOutputStream. With both streams connected to XML document instance. - Markup CutElement/PasteElement from/to XMLDataInputStream/XMLDataOutputStream. With both streams connected to XML document instance. Dima --------------------------- dima@paragraph.com 102401.2457@compuserve.com http://www.geocities.com/SiliconValley/Lakes/3767/ tel: 07-095-464-9241 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rakesh at watson.ibm.com Thu Mar 12 14:59:44 1998 From: rakesh at watson.ibm.com (Rakesh Mohan) Date: Mon Jun 7 17:00:16 2004 Subject: Indexing XML documents Message-ID: <013401bd4dc7$3198f3a0$10500209@turing2.watson.ibm.com> I would appreciate any pointers to work going on for indexing/querying XML documents. Thanks, Rakesh Mohan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From edz at bsn.com Thu Mar 12 15:19:18 1998 From: edz at bsn.com (Edward C. Zimmermann) Date: Mon Jun 7 17:00:16 2004 Subject: Indexing XML documents In-Reply-To: <013401bd4dc7$3198f3a0$10500209@turing2.watson.ibm.com> from "Rakesh Mohan" at Mar 12, 98 09:57:35 am Message-ID: <199803121519.QAA10015@hampton.bsn.com> > > I would appreciate any pointers to work going on for indexing/querying XML > documents. See http://www.bsn.com/Z39.50 The IB 2.0 engine supports alongside many different document formats XML-- and "on-the-fly" presentation into any of a number of document formats. S/R is available via HTTP/HTML (Webfront), Z39.50 and whois++ protocols. > > Thanks, > > Rakesh Mohan > > -- ______________________ Edward C. Zimmermann Basis Systeme netzwerk/Munich xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Mar 12 15:31:10 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:00:16 2004 Subject: SAX: Resolving entity sysids In-Reply-To: References: Message-ID: * Lars Marius Garshol | | Which causes me grief, since SAX does not distinguish between these | two kinds of entities [...] Geir Ove Grønmo has now been kind enough to clear up my confusion on this matter. SAX does not concern itself with parameter entities at all, since it's a non-DTD-aware API and PEs only occur in the DTD. Maybe I should go get some sleep or something... :) -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 12 15:41:24 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:00:16 2004 Subject: Wish list for XMLApplication Framework References: <2.2.32.19980312131207.0096d32c@dream.paragraph.com> Message-ID: <3508028C.4E253B14@infinet.com> Dmitri Kondratiev wrote: > The following are some of the features I'd like to be able to use in > XMLApplication Framework : > > - Support for both, event-based and tree-based parsers, to serialize XML > elements to application-specific element-objects. > Tree-based approach is certainly cleaner when you need to parse document as > a whole, but, imagine, in my appl. I may need to stop parsing relatively big > document in the middle, when I come across some element. So I don't need the > whole tree! And still I may need to instantiate my appl. specific > element-objects. > > - Runtime configuration of "element-semantic" handlers. > Ideally I'd like to be able to switch element-semantic handlers in run-time. > This might seem nonsense first, but if you give this idea a second thought > you'll see the point. XML is very wise to **not imply element semantic**, so > it may be useful for some app. (such as mine) to be able to switch one or > more times when processing a document from one set of element-objects to > another. In other words the ability to bind different semantic-handlers (and > thus element-objects) to elements in runtime is needed. Naming handler in > the XML document will allow to start parsing with some general > "semantic-switch" handler, that will activate different semantic-handlers as > needed. I already have a solution to this in a parser/formatter I have written for my application. The parser is non-validating and is very far from being something a third party could really use. But it works great (despite its lack of speed at the moment) for my application. There is an XMLReader and an XMLWriter. The parser of course is the reader and the formatter is of course the writer. These two classes are sublasses of java.io.Filter*Reader. > - Basic support for element-object to element markup serialization. This > will allow application to modify element-object in runtime and then > serialize it **in application-specific way** back in markup representation > by means of XMLDataOutputStream stream connected to XML document instance. I do this already be their being a root element (the document) and when the parser comes across a start element tag or an empty element tag, the the Element object (handler) is queried at run-time for a a sub-element or other object handler like a PI. This is the following interface I have now for Element. It should give you a good idea of what is going on. package com.dais.populous.util.xml; public interface Element { String getElementName(); // Attribute forAttributeName(String attributeName, int type, int index); void setElementAttributes(Attribute[] attributes); // may return null Attribute[] getElementAttributes(); // Returns a child element given an element name and content index Element forElementName(String elementName, int index); // Returns a processing instruction for this element given a target application // name and content index. ProcessingInstruction forProcessingInstructionTarget(String target, int index); void setElementCharacterData(String data, int index); // may return null Object[] getElementContent(); } Since this is an interface, you can have each of your objects implement this interface (or subclass an Adapter class) in your object graph and for objects that are final and cannot be sublassed like InetAddress, you can write an anonymous inner class to handle this type of object. Here is some code from my actual application. Note: the bounds object should probably utilize four attributes rather than 4 subelements, but in my DTD I happen to use this right now for completeness. All of these methods are from a class I call Capsule. A parent model class which acts as a Document and contains "Capsules" also implements Element so you can easily initialize/save objects with this method. public void format(OutputStream out) { try { XMLWriter writer = new XMLWriter(new OutputStreamWriter(out), " "); writer.writeDocument(this, "capsule.dtd"); writer.close(); } catch (IOException e) { e.printStackTrace(); } } public String getElementName() { return "capsule"; } public Object[] getElementContent() { byte[] data = getComponentData(); Object[] content = new Object[3 + ((data != null) ? 1 : 0)]; content[0] = capsuleEntry; content[1] = new BasicElement("component-name", componentName); content[2] = new BoundsElement(); if (data != null) content[3] = new BasicElement("component-data", DataUtil.encoder.encodeBuffer(data)); return content; } public void parse(InputStream in) { try { XMLReader reader = new XMLReader(new InputStreamReader(in)); reader.readDocument(this); in.close(); } catch (IOException e) { e.printStackTrace(); } } public Element forElementName(String elementName, int index) { if (elementName.equals("capsule-entry")) { capsuleEntry = new CapsuleEntry(); return capsuleEntry; } else if (elementName.equals("component-name")) { return new AbstractElement() { public String getElementName() { return "component-name"; } public void setElementCharacterData(String data, int index) { componentName = data.trim(); } }; } else if (elementName.equals("bounds")) { return new BoundsElement(); } else if (elementName.equals("component-data")) { return new AbstractElement() { public String getElementName() { return "component-data"; } public void setElementCharacterData(String data, int index) { try { setComponentData(DataUtil.decoder.decodeBuffer(data.trim())); } catch (IOException e) { e.printStackTrace(); } } }; } return null; } public void setElementAttributes(Attribute[] attributes) {} public Attribute[] getElementAttributes() {return null;} public ProcessingInstruction forProcessingInstructionTarget(String target, int index) {return null;} public void setElementCharacterData(String data, int index) {} class BoundsElement extends AbstractElement { public String getElementName() { return "bounds"; } public Object[] getElementContent() { Object[] content = new Object[4]; Rectangle bounds = getBounds(); content[0] = new BasicElement("x", String.valueOf(bounds.x)); content[1] = new BasicElement("y", String.valueOf(bounds.y)); content[2] = new BasicElement("width", String.valueOf(bounds.width)); content[3] = new BasicElement("height", String.valueOf(bounds.height)); return content; } public Element forElementName(String elementName, int index) { if (elementName.equals("x")) { return new AbstractElement() { public String getElementName() { return "x"; } public void setElementCharacterData(String data, int index) { Rectangle bounds = getBounds(); bounds.x = Integer.parseInt(data.trim()); setBounds(bounds); } }; } else if (elementName.equals("y")) { return new AbstractElement() { public String getElementName() { return "y"; } public void setElementCharacterData(String data, int index) { Rectangle bounds = getBounds(); bounds.y = Integer.parseInt(data.trim()); setBounds(bounds); } }; } else if (elementName.equals("width")) { return new AbstractElement() { public String getElementName() { return "width"; } public void setElementCharacterData(String data, int index) { Rectangle bounds = getBounds(); bounds.width = Integer.parseInt(data.trim()); setBounds(bounds); } }; } else if (elementName.equals("height")) { return new AbstractElement() { public String getElementName() { return "height"; } public void setElementCharacterData(String data, int index) { Rectangle bounds = getBounds(); bounds.height = Integer.parseInt(data.trim()); setBounds(bounds); } }; } return null; } } The nicest thing about this approach is that if there is an element the Element handler cannot handle, then null is returned and the parser simply ignores all subelements of that element. This is like ignoring all the stuff in between the Applet Tag if a browser cannot understand it. Also, since Element handlers are returned by reference, you don't need to instantiate special objects to wrap the XML data like you would if you built a tree based model of the XML data. Of course using this approach you could still easily build a big old tree if you wanted to. 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 Jacek.Ambroziak at East.Sun.COM Thu Mar 12 18:34:51 1998 From: Jacek.Ambroziak at East.Sun.COM (Jacek Ambroziak - Sun Microsystems Labs BOS) Date: Mon Jun 7 17:00:16 2004 Subject: Indexing XML documents In-Reply-To: "Your message with ID" <013401bd4dc7$3198f3a0$10500209@turing2.watson.ibm.com> Message-ID: Rakesh, I've done some work in this area adapting our Conceptual Indexing framework to index XML documents. I have a paper on this work almost ready. If you'll be in Seattle (XML conf) we can talk about it. The interesting fact about Conceptual Indexing is the expressive richness of its index database, which lets you store both offsets of various meaningful chunks of the indexed documents, and relations (structural and semantic) between these chunks. I use a Java XML parser and a set of small Java objects (one per element type) which know how to render each encountered element into structures appropriate for the index, consistent w/ the designed conceptualization of a given document type. This has been a cool work, and as always, more remains to be done :-) --Jacek xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcgredo at stl.nps.navy.mil Fri Mar 13 01:56:14 1998 From: mcgredo at stl.nps.navy.mil (Don McGregor) Date: Mon Jun 7 17:00:16 2004 Subject: Default attributes Message-ID: <199803130156.RAA20831@pinafore.stl.nps.navy.mil> I'm new at XML and trying to figure out how to have a default attribute assigned to an element in the DTD. What I've got now is this: I'm using the Microsoft XML parser. I always get a null value back for the attribute. However, if I explicitly add the attribute value to the marked up text, I get back a value: 1 What I want is the attribute to always be defaulted to "UnsignedByte" without having to put that in the markup text. The docs I've seen suggest that the above should work. Am I off base, or am I missing something in the MS XML parser? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Mar 13 23:18:09 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:00:16 2004 Subject: XML Dev Day not sold out Message-ID: <199803132316.PAA07661@boethius.eng.sun.com> So why is it news that the Seattle XML Developers' Day (March 27, 1998) is not sold out? Because the main conference to which it is attached *has* sold out! That's right, registration for "XML, The Conference" has hit the 500-person cutoff and is now closed. But the cognoscenti signed up for Dev Day currently number only a little over 200, so you can still get in. See http://www.gca.org/conf/xmlcon98/ Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 901 San Antonio Road, MPK17-101, Palo Alto, California 94303 OASIS :: NCITS V1 :: ISO/IEC JTC1/WG4 :: W3C XML WG :: W3C XSL WG If a man look sharply and attentively, he shall see Fortune; for though she be blind, yet she is not invisible. -- Francis Bacon ---------------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Mar 17 12:18:53 1998 From: pam.gennusa at dpsl.co.uk (Pam Gennusa) Date: Mon Jun 7 17:00:16 2004 Subject: XML product survey - V3 Message-ID: > Hello On 7 April 1998, Technology Appraisals will again be hosting a one-day seminar on XML in the UK (the first one was last April and the second one was last November when I last wrote to you about this). I have been asked to present a survey of the work to date on XML products and tools. If you responded last time, and you have new news, please do respond again. This is an excellent opportunity to let a larger community know about the vast amount of activity that is going on in this area. The presentation will not include any evaluation of the products or tools mentioned. However, I would like to be able to give the following information: Vendor or independent developer's name Contact information for vendor or developer (if desired) Name of tool or product General catelgory of tool or product Status (released, in beta, etc.) Commercial details (price, public domain, etc.) Brief description of product or tool highlighting distinguishing characteristics. If you have not got an XML offering yet, can you please let me know if your company: a) has taken a position on XML product support and if so what b) has made any announcements about XML product support and if so what (also any caveats that apply) c) is planning any XML product support that you are comfortable talking about at this time I appreciate any information you can supply. Ideally, I would like to get the information by Wednesday 1 April (earlier would be delightful and no, this isn't an April fools joke). If you intend to respond, but cannot by that date, please let me know as well. Kind regards, Pam P.S. On another topic, please note that the SGML/XML Europe '98 Advance Programme and Registration is out. It is available on the GCA website at www.gca.org or you can contact their office at +1 703 519 8167 to send a copy of the brochure. Please make sure you make your hotel reservations as early as possible as they hotel is filling up quickly ************************************************************************* Pamela L. Gennusa, Managing Director email: Pam.Gennusa@dpsl.co.uk Database Publishing Systems Ltd, 608 Delta Business Park Great Western Way, Swindon, Wiltshire SN5 7XF, UK Tel:+44 1793 512 515;fax +44 1793 512 516 URL:www.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 dgulbran at vervet.com Tue Mar 17 17:05:30 1998 From: dgulbran at vervet.com (David Gulbransen) Date: Mon Jun 7 17:00:16 2004 Subject: Announcing XML Pro! In-Reply-To: Message-ID: NEWSRELEASE CONTACT: David Gulbransen, Vervet Logic (812) 856-5270 or e-mail david@vervet.com Vervet Logic Introduces Full Featured XML Editor, XML Pro BLOOMINGTON (March 17) - Vervet Logic, a leading XML Tools development company, announced the beta release of their XML editor XML Pro. The editor allows users to create and edit documents using XML, a new Internet document standard recently ratified by the W3C. XML Pro is the first consumer oriented XML editor to reach the Internet community. "XML Pro offers users with a broad range of experience to easily create and edit XML based documents, regardless of previous experience with SGML, " said David Gulbransen, Vervet Logic CEO. "The idea behind XML Pro is to provide users with an intuitive interface, and the ability to create well-formed, validated XML documents quickly and efficiently." XML Pro features include the ability to create and edit well formed XML documents, XML Validation, and support for Document Type Definitions. The first public XML Pro beta is currently available for Windows platforms free from www.vervet.com, and will also be available in a cross-platform Java version for release. Full product release is scheduled for April 7. Related Web Sites: Vervet Logic (http://www.vervet.com) World Wide Web Consortium (http://www.w3c.org/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 ht at cogsci.ed.ac.uk Wed Mar 18 12:45:40 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:00:16 2004 Subject: Alpha release of XED: A smart XML instance editor Message-ID: <788.199803181245@naomi.cogsci.ed.ac.uk> I'm please to announce the availability of the alpha release of XED, a WYSIWYG XML instance editor. XED uses the LT XML toolset integrated with a Python-Tk user interface, to provide a free, cross-platform, well-formedness preserving editor for XML document instances. I very much welcome test users at this point, bearing in mind the alpha-status of this release. You can download XED for Windows95/NT from ftp://ftp.cogsci.ed.ac.uk/pub/ht/xed.zip A binary for Solaris will be available later today. Feedback VERY much wanted. 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 mmm at medgrid.philips.com Wed Mar 18 17:47:40 1998 From: mmm at medgrid.philips.com (Mehran) Date: Mon Jun 7 17:00:16 2004 Subject: XML Viewer for displaying XML inside a Java Application? Message-ID: <3.0.2.32.19980318124712.00926620@med10.medgrid.philips.com> I would like to display an XML document inside a Java application (as opposed to a browser). Are there any Beans or software available that can do this or come close to it? Thanks Mehran xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wilfr at mail.bc.rogers.wave.ca Wed Mar 18 18:52:36 1998 From: wilfr at mail.bc.rogers.wave.ca (Wilf Reedijk) Date: Mon Jun 7 17:00:16 2004 Subject: XML Viewer for displaying XML inside a Java Application? References: <3.0.2.32.19980318124712.00926620@med10.medgrid.philips.com> Message-ID: <35101888.C10A0609@rogers.wave.ca> Have you looked at the XML Viewer sample code that comes with the XML parser in Java from Microsoft (msxml)? It displays the document in a tree component. see http://www.microsoft.com/xml/ Wilf Mehran wrote: > I would like to display an XML document inside a Java application > (as opposed to a browser). Are there any Beans or software available > that can do this or come close to it? > > Thanks > Mehran xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From NRYBERG at email.usps.gov Wed Mar 18 19:37:33 1998 From: NRYBERG at email.usps.gov (NICHOLAS RYBERG) Date: Mon Jun 7 17:00:16 2004 Subject: XML Viewer for displaying XML inside a Java Applicati Message-ID: <0033000002203288000002L082*@MHS> FYI I believe that that particular implementation is specifically for MS Explorer 4.0. It will display it in tree format within the framework of the browser. I've been contemplating developing a XML browser (so to speak) for VB. I would hope that it is as easy to to in Java. Frankly, it's just a lot of rule based parsing. - Nick Ryberg ______________________________ Reply Separator _________________________________ Subject: Re: XML Viewer for displaying XML inside a Java Application? Author: owner-xml-dev@ic.ac.uk at INTERNET Date: 03/18/98 02:03 PM Have you looked at the XML Viewer sample code that comes with the XML parser in Java from Microsoft (msxml)? It displays the document in a tree component. see http://www.microsoft.com/xml/ Wilf Mehran wrote: > I would like to display an XML document inside a Java application > (as opposed to a browser). Are there any Beans or software available > that can do this or come close to it? > > Thanks > Mehran xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Wed Mar 18 20:04:35 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:00:17 2004 Subject: XML Viewer for displaying XML inside a Java Applicati References: <0033000002203288000002L082*@MHS> Message-ID: <35102D50.8266A9CE@finetuning.com> Here's a java-based applet viewer using John Tigue's Pax Syntactica Processor (an old one :-) http://xml.datachannel.com/XMLTreeViewer/deploy/XMLViewerAppletKit.zip and here's a tutorial i wrote fot it for web review: http://www.webreview.com/97/12/05/feature/newview.html It will work in both Netscape and IE versions 3 + and above (last i checked) enjoy! Lisa Rein NICHOLAS RYBERG wrote: > > FYI > > I believe that that particular implementation is specifically for MS > Explorer 4.0. It will display it in tree format within the framework > of the browser. > > I've been contemplating developing a XML browser (so to speak) for VB. > I would hope that it is as easy to to in Java. Frankly, it's just a > lot of rule based parsing. > > - Nick Ryberg > > ______________________________ Reply Separator _________________________________ > Subject: Re: XML Viewer for displaying XML inside a Java Application? > Author: owner-xml-dev@ic.ac.uk at INTERNET > Date: 03/18/98 02:03 PM > > Have you looked at the XML Viewer sample code that comes with the XML parser in > Java from Microsoft (msxml)? It displays the document in a tree component. > > see http://www.microsoft.com/xml/ > > Wilf > > Mehran wrote: > > > I would like to display an XML document inside a Java application > > (as opposed to a browser). Are there any Beans or software available > > that can do this or come close to it? > > > > Thanks > > Mehran > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 18 21:13:33 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:00:17 2004 Subject: XML Viewer for displaying XML inside a Java Applicati References: <0033000002203288000002L082*@MHS> Message-ID: <3510393D.9A49737C@technologist.com> NICHOLAS RYBERG wrote: > > I've been contemplating developing a XML browser (so to speak) for VB. > I would hope that it is as easy to to in Java. Frankly, it's just a > lot of rule based parsing. Creating an XML browser has two halves: parsing and displaying. Parsing is "just a lot of rule based parsing", but the rules are a little more tricky than in your average programming language. Displaying is easy if you just use a tree control, but if you want a view that is more like a "real document" view then you have to do a lot more work. After all, XML documents do not typically carry style information within them so you must get that from some other format (the stylesheet). Implementing a good stylesheet language efficiently is non-trivial. 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) From mmm at medgrid.philips.com Wed Mar 18 22:24:15 1998 From: mmm at medgrid.philips.com (Mehran) Date: Mon Jun 7 17:00:17 2004 Subject: XML Viewer for displaying XML inside a Java Applicati In-Reply-To: <3510393D.9A49737C@technologist.com> References: <0033000002203288000002L082*@MHS> Message-ID: <3.0.2.32.19980318172344.00963ad0@med10.medgrid.philips.com> I am looking for a browser Java bean to display a "real document" view (not a tree view) of an XML document inside a Java application. Does anyone know of any available software? Mehran >Creating an XML browser has two halves: parsing and displaying. Parsing >is "just a lot of rule based parsing", but the rules are a little more >tricky than in your average programming language. Displaying is easy if >you just use a tree control, but if you want a view that is more like a >"real document" view then you have to do a lot more work. After all, XML >documents do not typically carry style information within them so you >must get that from some other format (the stylesheet). Implementing a >good stylesheet language efficiently is non-trivial. > > 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) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Mar 19 00:54:48 1998 From: terje at in-progress.com (terje@in-progress.com) Date: Mon Jun 7 17:00:17 2004 Subject: RELEASE: XPublish 1.0 (XML Website Publishing) Message-ID: San Diego, CA, March 18, 1998: Media Design in*Progress today released XPublish 1.0, the first website publishing system that is based on the XML 1.0 document standard. Webmasters can use XPublish to efficiently author, publish and maintain middle sized and large websites to deploy on any platform. XPublish is first released on Macintosh, and will be available for other platforms later this year. The XPublish application can be downloaded from: http://interaction.in-progress.com/xpublish XPublish is the first commercially available professional XML authoring and publishing system. The application provides dialogs to create, inspect and modify XML markup, liberating the author from detailed knowledge of the XML specification. It provides an extendable markup editor resembling the powerful Emacs editor, but with Mac ease of use. The editing environment is dynamically tailored based on the document types and declarations of the author. XPublish generates HTML pages from XML documents at publishing time. Thus, web publishers can benefit from the efficiency and flexibility of XML when creating sites for todays browsers. All XML content is maintained in an object database for speed and concurrently as markup files for flexibility. XPublish gives web developers the advantages of one-source publishing without the overhead and complexity of full SGML. The integrated Cascading Style Sheets (CSS) editor simplifies designing and maintaining a consistent presentation style for websites. XPublish can optionally emulate CSS for older browsers that don't support style sheets. XPublish is listed at $495, but is currently available for an introductory price of $245. -- Terje | Media Design in*Progress C a s c a d e... a comprehensive Cascading Style Sheets editor for Mac XPublish - for efficient website publishing with XML Make your Web Site a Social Place with Interaction! Check out our web tools at xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From castella at CLI.DI.Unipi.IT Thu Mar 19 08:51:14 1998 From: castella at CLI.DI.Unipi.IT (Massimo Castellacci) Date: Mon Jun 7 17:00:17 2004 Subject: XML Viewer for displaying XML Message-ID: <199803190850.JAA17560@mailserver.cli.di.unipi.it> I tried to read John Bosak's Hamlet.xml with Internet Expolrer 4.00, but it doesn't display anyting else than the txt document itself. How can I do to have better result? (i.e. the tree format inside a frame?). Thanks. > FYI > > I believe that that particular implementation is specifically for MS > Explorer 4.0. It will display it in tree format within the framework > of the browser. > > I've been contemplating developing a XML browser (so to speak) for VB. > I would hope that it is as easy to to in Java. Frankly, it's just a > lot of rule based parsing. > > - Nick Ryberg > > > ______________________________ Reply Separator _________________________________ > Subject: Re: XML Viewer for displaying XML inside a Java Application? > Author: owner-xml-dev@ic.ac.uk at INTERNET > Date: 03/18/98 02:03 PM > > > Have you looked at the XML Viewer sample code that comes with the XML parser in > Java from Microsoft (msxml)? It displays the document in a tree component. > > see http://www.microsoft.com/xml/ > > Wilf > > Mehran wrote: > > > I would like to display an XML document inside a Java application > > (as opposed to a browser). Are there any Beans or software available > > that can do this or come close to it? > > > > Thanks > > Mehran > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > **************************************************** Massimo Castellacci Corso di Laurea in Scienze dell'Informazione Universita degli Studi di Pisa ---------------------------------------------------- Via Agostino di Duccio, 13 50143 - Firenze - ITALY Tel. +3955706395 +393389207607 E-mail: castella@cli.di.unipi.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 M.H.Kay at eng.icl.co.uk Thu Mar 19 15:18:33 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:00:17 2004 Subject: Alpha release of XED: A smart XML instance editor Message-ID: <01bd534a$62a1d420$1e09e391@mhklaptop.bra01.icl.co.uk> >I'm please to announce the availability of the alpha release of XED, >a WYSIWYG XML instance editor. Looks promising. Some suggestions: * on my set-up the help window is slightly off the screen, and it doesn't have a "close" button. * the notation for keystrokes (M-X) is not intuitive * it would be useful to have line number display and "goto line", as XML parsers display error messages in terms of line numbers * it would be nice to have an option to indent to show nesting (either for display on screen, or a permanent transformation of the file). Or better still an option to collapse and expand nesting levels. * Right-click on a tag would be a more standard user interface than "tab" on it. * There are many "familiar" features like double-clicking on a word and drag-and-drop missing. 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 ak117 at freenet.carleton.ca Fri Mar 20 15:42:52 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:00:17 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions Message-ID: <199803201541.KAA01043@unready.microstar.com> The draft version of the Simple API for XML (SAX) came out just over two months ago, and it has proven far more successful than I expected -- hundreds of developers have downloaded the Java interface, four of the six Java-based XML parsers now contain native SAX drivers (I have written temporary drivers for the other two), and many people are designing applications built around SAX. After two months' experience with the draft interface, however, users have discovered four serious omissions in the original design: 1) there is no standard way to read an XML document from an input stream; 2) there is no way to obtain contextual information (system id, line number, etc.) for reporting application errors; 3) there is no way to obtain external identifiers for an attribute of type NOTATIONS or ENTITIES when more than one notation or entity name is provided; and 4) there is no way to distinguish between recoverable and unrecoverable errors, as required by the XML REC. People have also rightly complained that the AttributeMap interface is too complicated. I have put together a web page containing my suggestions for revisions to fix these problems and generally to clean up the SAX interface; you will find the proposed revisions at the following URL: http://www.microstar.com/XML/SAX/proposed-changes.html If you are interested in SAX, either as a parser writer or as an application writer, please take a few minutes to read through this web page. I will look forward to receiving your comments, corrections, and suggestions. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com http://home.sprynet.com/sprynet/dmeggins/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From JLWeaver at mail.delcoelect.com Fri Mar 20 16:25:15 1998 From: JLWeaver at mail.delcoelect.com (James L Weaver) Date: Mon Jun 7 17:00:17 2004 Subject: Need good approach for XML-based presentations Message-ID: <052565CD.00560752.00@uskokg01.delcoelect.com> James L Weaver@DELCO on 03-20-98 10:56:15 AM In the past, I've developed the content of my presentations using HTML, and displayed them with a JavaScript/frames-based engine. XML seems to be the next logical step for this concept, so I would like to know if there are any tools for this. The presentations aren't complicated; usually just slide titles, bullet items, images, and links to external pages. Is this best handled by creating the content in XML and a style sheet that would be flexible enough to display the slides, or would some type of Java or JavaScript engine still be required? Thank you, James L. Weaver EDS Pager (best way to reach me): 765.454.3027 Voice mail: 765.451.4729 Email: jlweaver@mail.delcoelect.com "Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network." -Tim Berners-Lee in Technology Review, July 1996 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 20 19:06:42 1998 From: ht at cogsci.ed.ac.uk (Henry Thompson) Date: Mon Jun 7 17:00:17 2004 Subject: Need good approach for XML-based presentations In-Reply-To: "James L Weaver"'s message of Fri, 20 Mar 1998 10:56:15 -0500 References: <052565CD.00560752.00@uskokg01.delcoelect.com> Message-ID: James Weaver asks about XML for presentation and re-use: I have been doing exactly what you describe for about six months. I use a simple XML dtd, plus 2+1/2 style sheets. One XSL (translated into DSSSL using XSLJ (shameless plug :-)) goes from my XML to RTF in a form which Powerpoint is happy with. One+one-half (DSSSL with a switch for RTF/HTML) outputs to RTF or HTML as you prefer, for print or web delivery. It saves me HUGE amounts of time, I use it for everything now. And now with XED (another plug :-) I virtually never have XML errors in the documents I produce. See my home page for pointers to the tools, I'll package up the stylesheets and dtd in ftp://ftp.cogsci.ed.ac.uk/pub/ht/xmldoc.zip in just a minute. 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 dgd at cs.bu.edu Fri Mar 20 19:40:05 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:00:17 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions Message-ID: I read the revisions, and they're very sensible. But I have one deletion request, and one addition request. I don't believe the arguments about the uselessness of Doctype. Until this proposal, I didn't see any reason to argue about it, however. Leave Doctype in. Those who find it useless won't use it. It's sure not so hard to implement that requiring it is a hardship on parser writers, so I fail to see why it shouldn't be kept. Please, please, please, allow me a way to find out if an element was "empty". (i.e. written ). I use this information when I write DTDs, and intend to continue doing so. I also know, from the long discussions in the XML-SIG that I am not alone in using this syntax to represent a distinction that I want preserved and detectable by applications. Probably the best way to handle this might be to have an extra flag argument on the element end event (to indicate this element end was not present in the document). This lets people who care about whether an element was empty find out, without greatly inconveniencing people who want to follow the simpler "every element is a container" model. -- David ------------------------------------------+---------------------------- David Durand dgd@cs.bu.edu| david@dynamicDiagrams.com Boston University Computer Science | Dynamic Diagrams http://www.cs.bu.edu/students/grads/dgd/ | http://dynamicDiagrams.com/ | MAPA: mapping for the WWW xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Fri Mar 20 20:23:15 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:00:17 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions References: Message-ID: <3512D4BA.D43FAD56@finetuning.com> just a polite second about DOCTYPE. Leave it in please. Please, oh please, leave it in. :-) thank you (oh thank you) lisa David G. Durand wrote: > > I read the revisions, and they're very sensible. But I have one deletion > request, and one addition request. > > I don't believe the arguments about the uselessness of Doctype. Until this > proposal, I didn't see any reason to argue about it, however. Leave > Doctype in. Those who find it useless won't use it. It's sure not so > hard to implement that requiring it is a hardship on parser writers, so I > fail to see why it shouldn't be kept. > > Please, please, please, allow me a way to find out if an element was > "empty". (i.e. written ). I use this information when I write DTDs, and > intend to continue doing so. I also know, from the long discussions in the > XML-SIG that I am not alone in using this syntax to represent a distinction > that I want preserved and detectable by applications. > > Probably the best way to handle this might be to have an extra flag argument > on the element end event (to indicate this element end was not present in > the document). This lets people who care about whether an element was empty > find out, without greatly inconveniencing people who want to follow the > simpler "every element is a container" model. > > -- David > ------------------------------------------+---------------------------- > David Durand dgd@cs.bu.edu| david@dynamicDiagrams.com > Boston University Computer Science | Dynamic Diagrams > http://www.cs.bu.edu/students/grads/dgd/ | http://dynamicDiagrams.com/ > | MAPA: mapping for the WWW > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 20 21:37:24 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:00:17 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions In-Reply-To: <199803201541.KAA01043@unready.microstar.com> References: <199803201541.KAA01043@unready.microstar.com> Message-ID: * David Megginson | | If you are interested in SAX, either as a parser writer or as an | application writer, please take a few minutes to read through this | web page. I will look forward to receiving your comments, | corrections, and suggestions. Before my comments I should perhaps add some background: A Python special interest group for XML processing has recently been established and as a part of that effort there are now several budding XML parsers in Python (plus one C module), a SAX library, a prototypical DOM implementation etc. See for more details. My part in all this has so far been an XML parser as well as the Python SAX translation and drivers. (This is available from the link above. A parser version with full well-formedness checking will probably be released later this weekend.) Apart from the comments below this I agree with all the changes and mostly with the rationales for the changes as well. However, I don't like adding the Location argument to every *Handler method. IMHO, that clutters the interfaces too much. I'd much prefer this alternative: Make a new interface BaseHandler, which only has two methods: getLocator and setLocator, which can be used to give the handler a Location object[1] it can ask about the current location. This interface can then be implemented by DTDHandler, EntityHandler, DocumentHandler and ErrorHandler. It would simplify those four interfaces (by removing an attribute from every method in each interface) and probably both simplify implementation and transition to the new SAX version. (SAX version numbers might perhaps be an idea?) The specification should perhaps also specify exactly where the Location object should point to. The most obvious choice is the first character of the reported construct, but IMHO that should be spelled out. The last issue is that of AttributeList. In Python (and many other languages) lists, hash tables and tuples are "native" types and this is basically what AttributeList is. Also, Java is now going to have a standardized Collections API with Java 1.2. I think AttributeList should be in a form that makes it implementable with the "native" types where that is natural and still make it conform with the Collections API of Java 1.2. One way to do that might be to have an Attribute object with Name, Type and Value attributes and just make AttributeList a hash table that maps attribute names to those objects. In Python/Common Lisp/Perl this might be implemented with hash tables and lists/tuples. Alternatively, one could throw out the type information and just use a plain hash table/associative array. Below this point I have two ideas that may clash with what people want with/from SAX. If they are out of the question that's OK, I just want to hear the reactions to them. One thing that would be very nice would be to make it possible for SAX clients to do validation themselves in case the underlying parser does not support it. This would make it possible to build a validating XML parser in languages like Python/tcl/Scheme from three components: a C module for fast document scanning, a Python/tcl/Scheme module for the same in case the C one hasn't been compiled in and finally the validation itself, written in Python/tcl/Scheme. What's necessary for this is basically the doctype method, access to the internal subset somehow and access to the XML declaration.[2] These things should perhaps be in a separate interface, since they are pretty different from most of the other things SAX is concerned with. (DTDHandler is probably the wrong place for them, since that would probably only be implemented if the parser already does validation.) This is of course not a matter of life and death, since it's possible to do this without SAX, but IMHO it would be nice as it would provide a clean decoupling of XML scanning and XML validation. Finally, one thought that struck me when I read this API was that SAX seemed to be biased towards parsers that read the DTD, while I'm biased the other way. This is probably due to the differences between the situation Python is in (and Perl/... probably will be in) and the currents state of affairs in Java. This makes me think that it might perhaps be an idea to add a second level to SAX: one that provides logical information about elements, entities, attributes and notations as they are declared in the DTD. The existing SAX can then be simplified to only provide logical information about the document itself. The second level will of course only be supported by the parsers that actually parse the DTD and if my suggestions above are taken in the second level can be built on the first. Doing this would also solve the AttributeList and DTDHandler "problems", since AttributeList would then become a plain hash table in most languages[3] while DTDHandler would become part of the DTD interfaces. One advantage of this is that there would no longer be several methods in SAX level 1 that many simple parsers will not support. Just an idea. The problem is of course how to provide access to the complex stuff: element content models. (Possibly by avoiding the issue entirely and instead having methods that ask the DTD "is this element allowed here?") [1] With this change it would probably be best to rename Location to Locator, since that's really what happens. Locator might also perhaps be merged with Parser. [2] It would be nice if the SAX spec could specify whether or not the XML declaration should be reported as an ordinary processing instruction. Reporting it would solve the problem with access to it, but would add complexity for the users. [3] Probably an assoc list in R5RS Scheme and object/record arrays in VB/Delphi/C/.... -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 21 12:10:20 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:17 2004 Subject: Relational Tables and structured documents Message-ID: <3.0.1.16.19980319121115.346f2d3c@pop3.demon.co.uk> I have been spending the last two weeks working on a molecular application which essentially consists of relational tables. The application is largely hierarchical (a protein molecule) so that it benefits from being recast into structured document form. I have therefore found it useful to create routines which generate nodes in a tree as a result of joining tables. I expect this is a common operation (e.g. creation of orgCharts from relational tables). XML would seem to provide a useful approach, especially client-side (most humans don't read relational tables very well). Excuse my ignorance, but is this a sufficiently generic application that there are well-understood rules for it and is there scope for a generic XML approach? 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 Mar 21 12:17:31 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:17 2004 Subject: XML-tools Message-ID: <3.0.1.16.19980319120306.229f7b18@pop3.demon.co.uk> A common question is 'where can I get an XML browser?' - which normally means 'I have received an XML document composed mainly of human-readable text. Where can I get something to process it so that I, as a human, can make sense of it'. The common approach - rightly - is that most cases are well served by combining: - an XML parser - a stylesheet - appropriate software for processing and rendering XML documents accompanied by stylesheets (e.g. Jade, XSLJ, etc.) At present this is not always combined into a monolithic application, but we can expect many of these in both the commercial and public arenas. However, XML is also, for many of us, a wonderful opportunity to do non-textual operations. Many people will want to work closely with the 'raw' XML, mainly - but not always - in tree-structured form. XML can be used for transporting generic things such as: - relational tables - call graphs and semantic networks - graphics primitives - declarative programs I believe there is a role for a set of interoperable tools or APIs to avoid us all reinventing the wheel. (They might also lead to some de facto 'standards' for some of these.) >From my experience with JUMBO (essentially a prototype tool for XML applications) I have felt a need for the following (and implemented many of them): - tree display/editing, with/out DTD/schema information - attribute display/editing, with/out DTD/schema information - addition of semantics through hyperlinking - e.g to glossaries. - addition of behaviour through linking to code (e.g. Java classes) - a generic entity/element/attribute/content navigation system for a document - a search mechanism based on Xptrs but extended (e.g. case insensitivity, regexp, FOREIGN methods, etc.) - sorting, filtering, etc. - implementation of XLL (yes, it's still in draft but it will fly :-) - DTD/schema-specific customisation of the environment (e.g. menus) - addition of interactive objects (e.g. buttons) - graphical display/editing of hyperlinks and perhaps more domain-specific: - an element-based spreadsheet/table - display/entry widgets for 'data', possibly with validation - 2D graphics primitives (where is CGM at?) The great success of SAX suggests that it may possible to approach *some* of these in modular form - either through APIs or implementation of components. As I have already stated, I'd be happy to make JUMBO available for dissection by anyone who shares this sort of vision and I'm not proud - I'd be delighted if it were essentially built from components created by others. (That would leave me free to actually build the applications which is what my real motivation is :-) 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 Mar 21 12:19:11 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:17 2004 Subject: LISTRIVIA In-Reply-To: <3512D4BA.D43FAD56@finetuning.com> References: Message-ID: <3.0.1.16.19980319104015.229fdaf6@pop3.demon.co.uk> At 12:42 20/03/98 -0800 (and during the last 2 weeks) , [some new, and some veteran, members] wrote: followed by, or including, a . and some sent multiple copies to list members. We welcome the new members to the list :-). We adopt an XML-like discipline in posting and try to follow simple guidelines: - reply only to the list (xml-dev) and not to the poster. Easy to avoid - just delete the poster's name from the To: or CC: fields - only include quoted material if it helps the reader. The list is archived as HTML and this is a very convenient way to browse postings. Many people (including me) have to pay for mail traffic and so we try to keep the volume to a minimum. It's also good XML-discipline - if you use the same text in more than one place, your should think about entities of XLL rather than cut-and-paste. Anyone is welcome on XML-DEV but in general it isn't the right place for (appropriate place in parentheses): - "what is this XML thing anyway?" (www.ucc.ie/xml and www.sil.org/sgml/xml.html) - "I don't like feature X in XML - let's change it". (specially appointed groups of the W3C) - stylesheets (xsl-list@mulberrytech.com) - general discussion of xml issues (xml-l@LISTSERV.HEA.IE) 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 Mar 21 12:54:13 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:17 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions Message-ID: <3.0.1.16.19980319125427.346febd8@pop3.demon.co.uk> David G. Durand wrote: > > Please, please, please, allow me a way to find out if an element was > "empty". (i.e. written ). I use this information when I write DTDs, and > intend to continue doing so. I also know, from the long discussions in the > XML-SIG that I am not alone in using this syntax to represent a distinction > that I want preserved and detectable by applications. > Whatever the desirability of this - and I'm neutral - my understanding is that currently the spec makes no distinction between and . IOW documents differ only in the byte stream and not in the result of parsing. An analogy is that Lord's and Lord's are completely equivalent. I therefore think it would be incorrect and misleading for SAX to implement this - sorry. 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 tyler at infinet.com Sat Mar 21 15:29:08 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:00:17 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions References: <199803201541.KAA01043@unready.microstar.com> Message-ID: <3513DA3F.3CD58BAC@infinet.com> David Megginson wrote: > The draft version of the Simple API for XML (SAX) came out just over > two months ago, and it has proven far more successful than I expected > -- hundreds of developers have downloaded the Java interface, four of > the six Java-based XML parsers now contain native SAX drivers (I have > written temporary drivers for the other two), and many people are > designing applications built around SAX. > > After two months' experience with the draft interface, however, users > have discovered four serious omissions in the original design: > > 1) there is no standard way to read an XML document from an input > stream; > > 2) there is no way to obtain contextual information (system id, line > number, etc.) for reporting application errors; > > 3) there is no way to obtain external identifiers for an attribute of > type NOTATIONS or ENTITIES when more than one notation or entity > name is provided; and > > 4) there is no way to distinguish between recoverable and > unrecoverable errors, as required by the XML REC. > > People have also rightly complained that the AttributeMap interface is > too complicated. I have put together a web page containing my > suggestions for revisions to fix these problems and generally to clean > up the SAX interface; you will find the proposed revisions at the > following URL: > > http://www.microstar.com/XML/SAX/proposed-changes.html One thing which would be invaluable to may people from a performance perspective is to change: void startElement(String name, AttributeList attributes, Location loc) to: boolean startElement(String name, AttributeList attributes, Location loc). The boolean return value would indicate to the parser whether or not all sub elements and sub content should be ignored which would let the parser arbitrarily skip to the end element tag (if the element is not an empty element). For documents which only represent some sort of data storage mechanism where if one element is unknown then all its child elements should be unknown, this would be something very nice to have. Also another change I would propose would be: void endElement(String name, Location loc) to: Also, it would be nice if Parser had some sort of pause/resume feature so you could explicitly stop and start parsing at any point. In this case you might have every method return a boolean instead of void so that you could return true to continue parsing or false to pause. When dealing with multiple threads, this idea would be very nice as a control mechanism since the InputStream that is passed as an argument might be being filled up as you parse the document. You don't want to stop parsing until you know that the stream is closed. 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 jjc at jclark.com Sun Mar 22 02:27:47 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:00:17 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions References: <199803201541.KAA01043@unready.microstar.com> Message-ID: <3513A0CA.C5C5B13@jclark.com> David Megginson wrote: > 2) there is no way to obtain contextual information (system id, line > number, etc.) for reporting application errors; I have mixed feelings about this. I think this is useful information for some applications. On other hand, I don't think XML parsers are under any obligation to provide this information; it has a cost in terms of performance and complexity and parser writers may decide that, for their target market, it's not worth this cost. I don't think SAX should be impossible to implement on top of such parsers. Also SAX is supposed to be simple. Adding a Location argument to every single callback is a very significant increase in complexity. Moreover it complicates the use of SAX for all applications, even those (I guess the majority) that are aren't interested in this location information. Unless a better way can be found to do this, I don't think this functionality should be added. 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 jonathan at texcel.no Sun Mar 22 03:52:18 1998 From: jonathan at texcel.no (Jonathan Robie) Date: Mon Jun 7 17:00:17 2004 Subject: Relational Tables and structured documents In-Reply-To: <3.0.1.16.19980319121115.346f2d3c@pop3.demon.co.uk> Message-ID: <3.0.3.32.19980321223731.02d74670@pop.mindspring.com> At 12:11 PM 3/19/98, Peter Murray-Rust wrote: >I have been spending the last two weeks working on a molecular application >which essentially consists of relational tables. The application is >largely hierarchical (a protein molecule) so that it benefits from being >recast into structured document form. I have therefore found it useful to >create routines which generate nodes in a tree as a result of joining tables. > >I expect this is a common operation (e.g. creation of orgCharts from >relational tables). XML would seem to provide a useful approach, >especially client-side (most humans don't read relational tables very >well). Excuse my ignorance, but is this a sufficiently generic application >that there are well-understood rules for it and is there scope for a >generic XML approach? This is rather analogous to the object-to-relational mapping problem. If you define schemas in XML and define a mapping onto the relational database, there is a solution. Or you can have someone define how the joins should be made to create the XML elements. There is not, of course, a general solution for looking at a relational database and making a sensible set of "objects" out of it. There's been some research into inferring structure from relational tables, but nothing that has been that good in the general case. Jonathan jonathan@texcel.no Texcel Research http://www.texcel.no xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 22 12:27:30 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:17 2004 Subject: Relational Tables and structured documents In-Reply-To: <3.0.3.32.19980321223731.02d74670@pop.mindspring.com> References: <3.0.1.16.19980319121115.346f2d3c@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980320105511.0d279d38@pop3.demon.co.uk> At 22:37 21/03/98 -0500, Jonathan Robie wrote: [... PeterMR...] > >This is rather analogous to the object-to-relational mapping problem. If >you define schemas in XML and define a mapping onto the relational >database, there is a solution. Or you can have someone define how the joins >should be made to create the XML elements. There is not, of course, a Thanks. This is indeed the solution I have been pursuing. My intention is to control the joins through a set of declarations (in XML :-) - this means that they can be reconfigured by different people/clients. I wondered if there was already a standard 'language' for this or whether I just hack my own and hope. 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 jeroen at tcf.nl Sun Mar 22 13:50:53 1998 From: jeroen at tcf.nl (Jeroen van Rotterdam) Date: Mon Jun 7 17:00:17 2004 Subject: ANNOUNCE: MusicML a sheetmusic DTD/Browser Message-ID: <351516FF.AFCF6C0F@tcf.nl> We wrote MusicML, a DTD for sheetmusic. We included a Java Browser for displaying sheetmusic written with MusicML. check it out: http://www.tcf.nl/trends/trends6-en.html jeroen -- ________________________________________________________ name : Jeroen van Rotterdam organisation : The Connection Factory b.v. Grotekerkplein 38 3011 GE Rotterdam, the Netherlands url : http://www.tcf.nl email : jeroen@tcf.nl tel : +31 10 4046870 fax : +31 10 4046498 ________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 22 14:03:21 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:17 2004 Subject: IDREF Message-ID: <3.0.1.16.19980320125934.346f475e@pop3.demon.co.uk> I am trying to create tools for looking at hyperlink structure within XML documents and would like comment on the role of IDREF (I have never used it myself). The XML spec says very little about IDREF/ID. (In essence: An IDREF must match an ID attribute somewhere in the document; no two IDs can have identical values). Since IDREF has potentially a strong overlap with XLL, I would like to know if they are two ways of doing the same things or whether they have distinct roles (so that it would be conceivable to have a document using both constructs). (Although XLL is not finalised I am assuming that it will be widely deployed within the nearish future :-). Or is ID/IDREF primarily to ensure SGML compatibility until XLL gains ground? Are there any examples of XML documents that use IDREF? The XML-REC (in XML) would appear to do so as there are a number of attributes ending in *REF, but since I have not yet found the DTD this is guesswork. The following is how I see the differences between the constructs - I'd be grateful for additional pointers: IDREF is formally part of XML and can be used now. Parsers have to honour it. XLL is not yet here and requires additional software. IDREF has no semantics in the Spec. XLL has quite a lot (including attaching ROLEs and BEHAVIOR to the link). IDREF requires link integrity to be checked by the parser (validity failure is Draconian). XLL has (at present) no requirement for integrity checking. IDREF requires DTD information for its identification (though a consistent naming scheme might be valuable). XLL relies on hardcoded attribute names (though a DTD can be useful in supplying them). IDREFs are concise and simple to implement(?). XLL is normally more verbose and if fully implemented requires a non-trivial investment. IDREFS (sic) can have several targets. An HREF can have only one. This might make IDREFS considerably more concise. ------ At present I neglect IDREFs because of the substantial additional effort in implementing what I see as a parallel system that may not be widely used. I'd be grateful to know if this is realistic. 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 tbray at textuality.com Sun Mar 22 14:46:30 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:00:17 2004 Subject: IDREF Message-ID: <3.0.32.19980322063902.00adb888@pop.intergate.bc.ca> At 12:59 PM 20/03/98, Peter Murray-Rust wrote: >IDREF requires link integrity to be checked by the parser (validity failure >is Draconian). Yes and no. Yes, they're checked by the parser, no, validity errors are not fatal. >IDREF requires DTD information for its identification (though a consistent >naming scheme might be valuable). XLL relies on hardcoded attribute names >(though a DTD can be useful in supplying them). That's the big problem. We need a way for automatically spotting ID attributes. -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 larsga at ifi.uio.no Sun Mar 22 15:18:12 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:00:17 2004 Subject: IDREF In-Reply-To: <3.0.1.16.19980320125934.346f475e@pop3.demon.co.uk> References: <3.0.1.16.19980320125934.346f475e@pop3.demon.co.uk> Message-ID: * Peter Murray-Rust | | Are there any examples of XML documents that use IDREF? I've got one at | The XML-REC (in XML) would appear to do so as there are a number of | attributes ending in *REF, but since I have not yet found the DTD | this is guesswork. Actually, that's one DTD it would be very nice to have for testing purposes. Is it available anywhere? (Please?) In my experience ID/IDREF is very nice for simple cross-references inside a document, since they're so simple to use. (The error handling need not be Draconian. nsgmls-like behaviour where the reporting can be turned off is IMHO sensible for this, since there may be invalid references while the document is being written.) | IDREFs are concise and simple to implement(?). Compared to XLL, yes, but they do require a parser that reads the DTD. I've not added them to my own parser yet, but they won't require much work (unless there are hidden surprises, of course). -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jonathan at texcel.no Sun Mar 22 16:36:58 1998 From: jonathan at texcel.no (Jonathan Robie) Date: Mon Jun 7 17:00:17 2004 Subject: Relational Tables and structured documents In-Reply-To: <3.0.1.16.19980320105511.0d279d38@pop3.demon.co.uk> References: <3.0.3.32.19980321223731.02d74670@pop.mindspring.com> <3.0.1.16.19980319121115.346f2d3c@pop3.demon.co.uk> Message-ID: <3.0.3.32.19980322105711.02ead650@pop.mindspring.com> At 10:55 AM 3/20/98, Peter Murray-Rust wrote: >At 22:37 21/03/98 -0500, Jonathan Robie wrote: >[... PeterMR...] >> >>This is rather analogous to the object-to-relational mapping problem. If >>you define schemas in XML and define a mapping onto the relational >>database, there is a solution. Or you can have someone define how the joins >>should be made to create the XML elements. There is not, of course, a > >Thanks. This is indeed the solution I have been pursuing. My intention is >to control the joins through a set of declarations (in XML :-) - this means >that they can be reconfigured by different people/clients. I wondered if >there was already a standard 'language' for this or whether I just hack my >own and hope. This is something I've been thinking about, but my thoughts are currently a bunch of notes on pieces of scrap paper. I would love to discuss this with anybody who is interested. I think that this is an extremely promising area; ideally, I would like to see a solution more general than just relational databases, but not as complicated as RDF. Jonathan jonathan@texcel.no Texcel Research http://www.texcel.no xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 22 16:43:50 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:00:17 2004 Subject: IDREF Message-ID: <001a01bd55b1$5f1e1020$950b4ccb@NT.JELLIFFE.COM.AU> From: Tim Bray > We need a way for automatically spotting ID attributes. Many people recommend that an attribute should only be called "ID" if it is an ID attribute. So in the following, x1 is good and x2 is naughty: I think it is good practice anyway: dont name an attribute using an XML keyword if that is not the type you want. 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 deke at tallent.com Sun Mar 22 17:34:45 1998 From: deke at tallent.com (Deke Smith) Date: Mon Jun 7 17:00:17 2004 Subject: Relational Tables and structured documents Message-ID: <1321556034-20216275@tallent.com> Peter Murray-Rust, peter@ursus.demon.co.uk said on 3/20/98 10:55 AM: >>Or you can have someone define how the joins >>should be made to create the XML elements. There is not, of course, a > >Thanks. This is indeed the solution I have been pursuing. My intention is >to control the joins through a set of declarations (in XML :-) - this means >that they can be reconfigured by different people/clients. I wondered if >there was already a standard 'language' for this or whether I just hack my >own and hope. Arijit Sengupta, asengupt@cs.indiana.edu, has done some research in expressing SQL queries in SGML. He has a rather complete SGML DTD for SQL: http://www.cs.indiana.edu/hyplan/asengupt/sgml96/dtd/ http://www.cs.indiana.edu/hyplan/asengupt.html ----------------------------------------------------------------- Deke Smith Tallent Communications Group, Brentwood TN deke@tallent.com, 615-661-9878 ----------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Sun Mar 22 22:27:20 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:00:17 2004 Subject: IDREF References: <001a01bd55b1$5f1e1020$950b4ccb@NT.JELLIFFE.COM.AU> Message-ID: <3515901C.74535583@allette.com.au> Rick Jelliffe wrote: > Many people recommend that an attribute should only be called > "ID" if it is an ID attribute. So in the following, x1 is good and > x2 is naughty: > > > > > I think it is good practice anyway: dont name an attribute > using an XML keyword if that is not the type you want. True, but the requirements of the attribute may not be known until processing time. You may use a parameter entity in the declaration subset and assign the value based on whether the parser will have access to the rest of the dataset or whether this is a subset that would result on the generation of useless and unwanted errors, ie: in the DTD, and then, depending on the doctype element, generate either: ]> or: ]> at the head of the instance. -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From info at riposte.com Mon Mar 23 08:42:37 1998 From: info at riposte.com (MW) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured documents Message-ID: <01bd5634$73d74da0$72d0c3c2@clueless.riposte.com> Jonathan: I was pondering about related problems the other day. What I came up with - in the absence of any other solution out there - was some kind of stylesheet language for mapping relational data to XML/HTML. It takes database information (e.g. ODBC DSN, table names) as input and then defines the output in terms of group/detail elements. A very rough example could be (XVSL: XML View Styleshett Language; "View" stands for views on relational data): Lower case tags are supposed to be XVSL tags, upper case ones define the output. The following could be an example of output genereated by the XVSL stylesheet: Ralf Westphal 981212 1234.12 982555 989.23 2223.35 John Doe 971233 4443.23 4443.23 (Maybe this way of converting "simple" relations to XML is overkill, but it can be defined outside any database, does not necessarily require any coding in some programming language and uses a well known paradigm (group-detail).) If you (or anyone) should find this way of expressing relation to XML mappings of interest, let´s get together on it. Ralf Westphal Mey & Westphal RIPOSTE Software >At 10:55 AM 3/20/98, Peter Murray-Rust wrote: >>At 22:37 21/03/98 -0500, Jonathan Robie wrote: >>[... PeterMR...] >>> >>>This is rather analogous to the object-to-relational mapping problem. If >>>you define schemas in XML and define a mapping onto the relational >>>database, there is a solution. Or you can have someone define how the joins >>>should be made to create the XML elements. There is not, of course, a >> >>Thanks. This is indeed the solution I have been pursuing. My intention is >>to control the joins through a set of declarations (in XML :-) - this means >>that they can be reconfigured by different people/clients. I wondered if >>there was already a standard 'language' for this or whether I just hack my >>own and hope. > >This is something I've been thinking about, but my thoughts are currently a >bunch of notes on pieces of scrap paper. I would love to discuss this with >anybody who is interested. I think that this is an extremely promising >area; ideally, I would like to see a solution more general than just >relational databases, but not as complicated as RDF. > >Jonathan > >jonathan@texcel.no >Texcel Research >http://www.texcel.no > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matthew at praxis.cz Mon Mar 23 08:51:10 1998 From: matthew at praxis.cz (Matthew - Praxis) Date: Mon Jun 7 17:00:18 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions Message-ID: <01bd5638$802752e0$020b0ac0@xerius> How about defining a standard UnknownLocation class derived from Location (and using is as the default value in the interface)? -----Original Message----- From: James Clark To: xml-dev Mailing List Date: Sunday, March 22, 1998 3:46 AM Subject: Re: ANNOUNCEMENT: Proposed SAX Revisions >David Megginson wrote: > >> 2) there is no way to obtain contextual information (system id, line >> number, etc.) for reporting application errors; > >I have mixed feelings about this. I think this is useful information >for some applications. On other hand, I don't think XML parsers are >under any obligation to provide this information; it has a cost in terms >of performance and complexity and parser writers may decide that, for >their target market, it's not worth this cost. I don't think SAX should >be impossible to implement on top of such parsers. Also SAX is supposed >to be simple. Adding a Location argument to every single callback is a >very significant increase in complexity. Moreover it complicates the >use of SAX for all applications, even those (I guess the majority) that >are aren't interested in this location information. Unless a better way >can be found to do this, I don't think this functionality should be >added. > >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 M.H.Kay at eng.icl.co.uk Mon Mar 23 10:00:58 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:00:18 2004 Subject: IDREF Message-ID: <01bd5642$d5d3cde0$1e09e391@mhklaptop.bra01.icl.co.uk> Peter Murray-Rust wrote: >I am trying to create tools for looking at hyperlink structure within XML >documents and would like comment on the role of IDREF... I have been using IDREF to represent relationships within a genealogical data set, but with considerable reservations because I would prefer something that extends naturally to cross-file links using XLL. If I use IDREF I get the benefit of not having to do the validation myself; if I prefix my IDREF's with a "#" they become forwards compatible to XLL but I lose the benefit of validation. I would be more enthusiastic about the XLL approach if it wasn't so full of hyperlink behaviour. I want to model a relationship between two objects that happen to be in different datasets. All the XLL stuff about the manner in which links are followed is to me entirely presentation-oriented and I don't want it in my data thankyou very much. From that point of view I prefer the IDREF style of specification which says nothing about the behavioural characteristics of the link. What I really need is a "distributed IDREF". 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 Mar 23 10:07:57 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:00:18 2004 Subject: IDREF Message-ID: <01bd5643$cc04b4e0$1e09e391@mhklaptop.bra01.icl.co.uk> Peter Murray-Rust: >IDREF requires DTD information for its identification (though a consistent >naming scheme might be valuable). XLL relies on hardcoded attribute names >(though a DTD can be useful in supplying them). Which has the possibly unintended consequence that you can have as many IDREF attributes on an element as you like, but you can only have one XLL linking attribute. (For data modellers like me, the notion of an object that can only have one relationship is a strange one indeed!) 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 Mar 23 10:28:18 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured documents Message-ID: <01bd5646$a5fa84c0$1e09e391@mhklaptop.bra01.icl.co.uk> Peter Murray-Rust: >I have been spending the last two weeks working on a molecular application >which essentially consists of relational tables. The application is >largely hierarchical (a protein molecule) so that it benefits from being >recast into structured document form. I have therefore found it useful to >create routines which generate nodes in a tree as a result of joining tables. I think there are several things that one could usefully do. (1) define a recommended way of representing a relational table in XML. (There are a number of ways of doing this, the biggest decision is whether to use a standard DTD for all tables or a DTD that reflects the specific table definition.) (2) extend this to a richer data model, e.g. the nested relational model, that allows you to represent hierarchic structures, or the ODMG model which allows to to represent arbitrary graphs. (Note that the problem then becomes analogous to the one of using XML as a serialisation format for CORBA objects) (3) provide a toolkit that allows you to perform transformations on these XML documents that reflect the operators of the relevant data model, e.g. relational selection, projection, and join; sorting and grouping; flattening of nested relations. Of course one way to implement such operations would be to load the data into a database, but many of the operations can be implemented directly without too much effort. I think the key thing is to keep the set of structures and operations very clean: base it on a data model with an established formal basis rather than inventing something new. 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 mtbryan at sgml.u-net.com Mon Mar 23 11:54:46 1998 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:00:18 2004 Subject: IDREF Message-ID: <01bd5635$9fae5620$LocalHost@sgml.u-net.com> Peter Murray-Rust wrote: >Since IDREF has potentially a strong overlap with XLL, I would like to know >if they are two ways of doing the same things or whether they have distinct >roles (so that it would be conceivable to have a document using both >constructs). (Although XLL is not finalised I am assuming that it will be >widely deployed within the nearish future :-). Or is ID/IDREF primarily to >ensure SGML compatibility until XLL gains ground? They have distinct, if possibly overlapping, roles. ID/IDREF was designed to handle internal links within a document: XLL is primarily designed to handle links between one document and another. It so happens that you can use XLL is a way that implies internal links, but this requires the use of the same mechanisms that are used to handle external links. There are fundamental differences, not least in terms of validation and embedding. ID/IDREF comes with some inbuilt validation that you cannot get with XLL. XLL comes with some inbuilt behaviours, which are not necessarily appropriate for handling internal links. (For example, you would not normally associate embedding with internal links.) >IDREFS (sic) can have several targets. An HREF can have only one. This >might make IDREFS considerably more concise. XLL allows multiple locators in an extended link, but requires a separate element rather than a separate attribute value token for each one. >At present I neglect IDREFs because of the substantial additional effort in >implementing what I see as a parallel system that may not be widely used. >I'd be grateful to know if this is realistic. You could decide that your application only supports XLL links, using Xptrs without a source to specify them. Your application would not, though, be a full XML application as it would not be able to create internal links from any element with an IDREF attribute back to the element with the associated ID attribute. (In general you only need to provide behaviour for IDREF->ID traversal. Not many applciations allow you to find all the points where an ID has been referenced.) Is it really all that difficult to handle IDREF->ID links as simple links (from the element with the attribute) which have the SHOW attribute set to REPLACE and each IDREF token treated as if it were #token in XLL? 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 jonathan at texcel.no Mon Mar 23 12:21:46 1998 From: jonathan at texcel.no (Jonathan Robie) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured documents In-Reply-To: <1321556034-20216275@tallent.com> Message-ID: <3.0.3.32.19980323072036.030fd100@pop.mindspring.com> At 11:34 AM 3/22/98 -0600, Deke Smith wrote: >Arijit Sengupta, asengupt@cs.indiana.edu, has done some research in >expressing SQL queries in SGML. He has a rather complete SGML DTD for SQL: > >http://www.cs.indiana.edu/hyplan/asengupt/sgml96/dtd/ >http://www.cs.indiana.edu/hyplan/asengupt.html I saw this in 1976, but I didn't grasp why it is useful to express an SQL query in SGML, instead of just storing the SQL string. Can you give me some scenarios that would clarify this? Jonathan jonathan@texcel.no Texcel Research http://www.texcel.no xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 at jmaca.com Mon Mar 23 15:22:43 1998 From: mike at jmaca.com (Michael Emmel) Date: Mon Jun 7 17:00:18 2004 Subject: XML-tools References: <3.0.1.16.19980319120306.229f7b18@pop3.demon.co.uk> Message-ID: <351681DB.47AD2A0@jmaca.com> It would be nice if a web site could be added that allowed people to register there tools both commercial and non-commercial. I would make it much easier for people to see what is available. Along the lines of gamelan or other web/ftp sites. Along with a FAQ. Mike mike@jmaca.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 23 15:37:12 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:00:18 2004 Subject: IDREF Message-ID: <01bd5671$ad728a60$1e09e391@mhklaptop.bra01.icl.co.uk> Gavin Nicol: >Extended links allow n-ary links. Yes, but only one n-ary link from each element. 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 dgd at cs.bu.edu Mon Mar 23 16:38:33 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:00:18 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions Message-ID: From: Peter Murray-Rust David G. Durand wrote: > > Please, please, please, allow me a way to find out if an element was > "empty". (i.e. written ). I use this information when I write DTDs, and > intend to continue doing so. I also know, from the long discussions in the > XML-SIG that I am not alone in using this syntax to represent a distinction > that I want preserved and detectable by applications. > Whatever the desirability of this - and I'm neutral - my understanding is that currently the spec makes no distinction between and . IOW documents differ only in the byte stream and not in the result of parsing. An analogy is that Lord's and Lord's are completely equivalent. I therefore think it would be incorrect and misleading for SAX to implement this - sorry. Since the spec. explicitly allows this (though under the IMO misleading name of a "for compatibility" feature) it can't be "incorrect and misleading" for SAX to implement it. It also means that SAX is not _required_ to implement it, but then, my plea wasn't phrased in those terms. The fact that this is an implementor option does not remove my need to have the information available. Since this is instance-only information, I see no reason that SAX can't easily provide it. In fact, I proposed a simple way to support it that doesn't prevent other applications from ignoring the distinction. -- David ------------------------------------------+---------------------------- David Durand dgd@cs.bu.edu| david@dynamicDiagrams.com Boston University Computer Science | Dynamic Diagrams http://www.cs.bu.edu/students/grads/dgd/ | http://dynamicDiagrams.com/ | MAPA: mapping for the WWW xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 23 17:30:49 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:00:18 2004 Subject: ANNOUNCEMENT: Proposed SAX Revisions Message-ID: <01bd5681$ab0f04a0$1e09e391@mhklaptop.bra01.icl.co.uk> > David G. Durand wrote: > > > > Please, please, please, allow me a way to find out if an element was > > "empty". (i.e. written ). ... > >The fact that this is an implementor option does not remove my need to >have the information available. When I write in a document, I want confidence that the application will treat it as equivalent to , just as I want confidence that it will ignore white space in contexts where it is insignificant. I won't have that confidence if SAX client applications are enabled to make a distinction. Perhaps you could explain more clearly why you need to know? 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 eliot at isogen.com Mon Mar 23 17:57:07 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:00:18 2004 Subject: IDREF Message-ID: <3.0.32.19980323115634.006e7928@swbell.net> At 10:02 AM 3/23/98 -0000, Michael Kay wrote: >I would be more enthusiastic about the XLL approach if it >wasn't so full of hyperlink behaviour. I want to model a >relationship between two objects that happen to be in different >datasets. All the XLL stuff about the manner in which links are >followed is to me entirely presentation-oriented and I don't >want it in my data thankyou very much. From that point of >view I prefer the IDREF style of specification which says >nothing about the behavioural characteristics of the link. >What I really need is a "distributed IDREF". It sounds like what you want is what HyTime provides: more general and robust link representation and addressing methods that don't imply any specific behaviors (which HyTime considers to be presentation/behavior style beyond its ken). Note that Xpointers can be used witin a HyTime context because HyTime allows you to use any addressing method you want with hyperlinks (or any other use of addressing). Xpointers can be formally defined in terms of operations on groves, which is all you need to do to make it make sense in a HyTime processing context (not counting implementation of support for the query notation in your system). Note also that both the simple and extended link elements can be formally defined as specializations of the HyTime hylink (simple) and varlink (extended) forms, which means that you can view XLink as a specialized application of HyTime, one that adds specific behavior and description semantics to HyTime's basic structures. Here's a tip: if you've implemented support for simple and extended, implementing support for the rest of HyTime's hyperlink forms is an almost trivial exercise (doing full HyTime semantic validation would require a bit more effort). If you've implemented Xpointers, implementing HyTime's built-in addressing elements is mostly an application of the code that implements the Xpointer fundamentals (it's a bit more complicated because you have to deal with indirection and such, but it's not rocket science). For more information about HyTime, see the following Web sites: - www.hytime.org, the HyTime user's group Web site. - www.techno.com, TechnoTeachers' web site, where you'll find lots of good information, as well as the HyBrowse demonstration HyTime browser (it's out of date in that it doesn't support HyTime 2nd Edition, but it's still a useful demonstration and learning tool) - www.isogen.com/demos/tools, the ISOGEN demo area, where you'll find some sample HyTime implementations of various sorts - www.ornl.gov/sgml/wg4, the ISO/IEC JTC1/WG4 web site, where you can find information about HyTime and its related standards. Cheers, Eliot --
W. Eliot Kimber, Senior Consulting SGML Engineer Highland Consulting, a division of ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 95202. 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 dkuhlman at netcom.com Tue Mar 24 02:45:31 1998 From: dkuhlman at netcom.com (G. David Kuhlman) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured document Message-ID: <199803240245.SAA28002@netcom.com> I've been following the comments about using XML as a database, and I have a question -- The discussion of ODMG and using XML as a database suggests that you will be able to update the database. But, if you have a large XML file, how do you update fields within that file without copying or re-writting the whole file? That sounds very awkward. Or am I missing a step in this process? Are we assuming that the XML file has been sucked into an OODBMS such as one for which there are ODMG language bindings? I think this would be very powerful. However, it is no longer XML, is it? Or is the goal to store the data in a RDBMS or OODBMS and then export it to XML so we can send it across the wire and around the Web? I guess I am asking whether there is a model this kind of use of XML as a database. Dave > Peter Murray-Rust: > > >I have been spending the last two weeks working on a molecular application > >which essentially consists of relational tables. The application is > >largely hierarchical (a protein molecule) so that it benefits from being > >recast into structured document form. I have therefore found it useful to > >create routines which generate nodes in a tree as a result of joining > tables. > > > I think there are several things that one could usefully do. > > (1) define a recommended way of representing a relational table in XML. > (There > are a number of ways of doing this, the biggest decision is whether to use a > standard DTD for all tables or a DTD that reflects the specific table > definition.) > > (2) extend this to a richer data model, e.g. the nested relational model, > that > allows you to represent hierarchic structures, or the ODMG model which > allows > to to represent arbitrary graphs. (Note that the problem then becomes > analogous to the one of using XML as a serialisation format for CORBA > objects) > > (3) provide a toolkit that allows you to perform transformations on these > XML > documents that reflect the operators of the relevant data model, e.g. > relational > selection, projection, and join; sorting and grouping; flattening of nested > relations. > Of course one way to implement such operations would be to load the data > into > a database, but many of the operations can be implemented directly without > too > much effort. > > I think the key thing is to keep the set of structures and operations very > clean: > base it on a data model with an established formal basis rather than > inventing > something new. > > 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) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From parikr at pointcast.com Tue Mar 24 04:12:09 1998 From: parikr at pointcast.com (Parik Rao) Date: Mon Jun 7 17:00:18 2004 Subject: How to specify validation properties in DTDs? Message-ID: <93DA154E07D3D0119C7E006097743AA001154A1C@hq-exs1.pointcast.com> Hi, I'm trying to figure out how do I do parameter validation in my DTD. For example, I have an element which specifies a SIZE as an attribute. I'd like to enforce certain rules : the charaacter data in size is digits and the size is always less than 1,000,000 (for example). As far as I can figure out, there is no way to do this! E.g. Well, how do I set validation parameters for size? I tried to play around with entity but really couldn't come up with anything: Anyone done this sort of thing? Is this sort of validation beyond the scope of DTDs? -- Parik Rao parikr@pointcast.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sudar at pspl.co.in Tue Mar 24 04:21:12 1998 From: sudar at pspl.co.in (Sudarshan Purohit) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured document References: <199803240245.SAA28002@netcom.com> Message-ID: <3517359A.255EF1A5@pspl.co.in> G. David Kuhlman wrote: >Or am I missing a step in this process? Are we assuming that the > XML file has been sucked into an OODBMS such as one for which there > are ODMG language bindings? I think this would be very powerful. > However, it is no longer XML, is it? Or is the goal to store the > data in a RDBMS or OODBMS and then export it to XML so we can send > it across the wire and around the Web? > > I guess I am asking whether there is a model this kind of use of > XML as a database. > I've been working on something like this. My project involves translation of RDBMS data into an XML file (with database info stored as an XML-Data schema) and vice-versa. XML-Data, I feel, does a reasonable job of storing key, referential, etc. info. What I'd like to add to David's query is : How close does this sort of usage come to the basis of a standard for his interface? Is anyone out there doing something similar? What I need right now is a standardised model for translating the entity-level data concepts expressible through XML-Data into ground realities of tables/etc. in RDBMS terms. I could hack it, but if there is some such work being done already, that would help. Thanks in advance, Sudarshan 24th mar 98 PSPL,Pune 0950hrs. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Mar 24 04:56:20 1998 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured documents Message-ID: This is a fine application for XML. As several people have pointed out, schema extensions would be rather helpful for defining how to express relational-style joins. Sudarshan Purohit [sudar@pspl.co.in], rightfully pointed out that XML-Data has facilities for this. Look at http://www.microsoft.com/standards/xml/xmldata.htm#References. -----Original Message----- From: Peter Murray-Rust [SMTP:peter@ursus.demon.co.uk] Sent: Thursday, March 19, 1998 4:11 AM To: xml-dev@ic.ac.uk Subject: Relational Tables and structured documents I have been spending the last two weeks working on a molecular application which essentially consists of relational tables. The application is largely hierarchical (a protein molecule) so that it benefits from being recast into structured document form. I have therefore found it useful to create routines which generate nodes in a tree as a result of joining tables. I expect this is a common operation (e.g. creation of orgCharts from relational tables). XML would seem to provide a useful approach, especially client-side (most humans don't read relational tables very well). Excuse my ignorance, but is this a sufficiently generic application that there are well-understood rules for it and is there scope for a generic XML approach? 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) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Tue Mar 24 05:53:51 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured documents References: Message-ID: <35174F1F.2D110EA2@finetuning.com> I've been exploring this area of making complex queries on a meta-data-filled object-relational database through an ODBC interface (multidimensional database, containing complex data types a la XML-Data) for a few weeks now...and, although I haven't tried to implement anything yet....it seemed like the resources might prove useful in the context of this discussion. -- Lisa http://www.cs.toronto.edu/~bonner/papers.html Anthony Bonner's Papers http://www.cs.brown.edu/research/oodb/papers/icde-format-dist.ps The AQUA Approach to Querying Lists and Trees in Object-Oriented Databases, Bharathi Subramanian, Theodore W. Leung, Scott L. Vandenberg and Stanley B. Zdonik, Proceedings of the International Conference on Data Engineering, Taipei, Taiwan, 1995 http://www.cs.brown.edu/research/oodb/papers/dbpl-93-algebra.ps The AQUA Data Model and Algebra, Theodore W. Leung, Gail Mitchell, Bharathi Subramanian, Bennet Vance, Scott L. Vandenberg and Stanley B. Zdonik, Proceedings of the Fourth International Workshop on Database Programming Languages, New York, 1993 http://www.cs.brown.edu/research/oodb/papers/dbpl-93-ordered.ps Ordered Types in the AQUA Data Model, Bharathi Subramanian, Stanley B. Zdonik, Theodore W. Leung and Scott L. Vandenberg, Proceedings of the Fourth International Workshop on Database Programming Languages, New York, 1993 http://www.cs.brown.edu/courses/cs227/papers/b0/equiv.ps Object-Oriented Queries: Equivalence and Optimization, Gail M. Shaw and Stanley B. Zdonik, Proceedings of the First Conference of Deductive and Object-Oriented Databases, Tokyo, Japan, 1989. ftp://wilma.cs.brown.edu/u/mfc/mutability.ps.Z ftp://wilma.cs.brown.edu/u/mfc/pos96.ps.Z The Effects of Mutability on Querying (~90K) Mitch Cherniack and Eui-Suk Chung, February, 1996. (Compressed Postscript) The ability of an object to mutate is one of the definingcharacteristics of Object-Oriented Databases (OODBs). But the impact of object mutability on querying is typically ignored. Presumably, this is because queries are usually assumed free of side-effects, and therefore objects are effectively immutable while they are queried. But mutability affects other object behaviors aside from how they change, such as how they are compared for equality, and if it is possible to detect that they are shared. In this paper, we show how these behaviors impact querying in general and query optimization and mutable set construction in particular. Charles Frankston wrote: > > This is a fine application for XML. As several people have pointed out, > schema extensions would be rather helpful for defining how to express > relational-style joins. Sudarshan Purohit [sudar@pspl.co.in], rightfully > pointed out that XML-Data has facilities for this. Look at > http://www.microsoft.com/standards/xml/xmldata.htm#References. > > -----Original Message----- > From: Peter Murray-Rust [SMTP:peter@ursus.demon.co.uk] > Sent: Thursday, March 19, 1998 4:11 AM > To: xml-dev@ic.ac.uk > Subject: Relational Tables and structured documents > > I have been spending the last two weeks working on a molecular > application > which essentially consists of relational tables. The application is > largely hierarchical (a protein molecule) so that it benefits from > being > recast into structured document form. I have therefore found it > useful to > create routines which generate nodes in a tree as a result of > joining tables. > > I expect this is a common operation (e.g. creation of orgCharts from > relational tables). XML would seem to provide a useful approach, > especially client-side (most humans don't read relational tables > very > well). Excuse my ignorance, but is this a sufficiently generic > application > that there are well-understood rules for it and is there scope for a > generic XML approach? > > 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) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 24 06:12:31 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:00:18 2004 Subject: An example of database query result in XML Message-ID: <002d01bd56ea$fe3b5840$2ee044c6@donpark> Recently, there has been some discussion on the topic of accessing relational database in XML. One of my pet project called "XDO -XML Data Object" accepts SQL and emits the result as XML. At this point, I see that there is no magic at all to retrieving XML from databases. The hard part is in submitting XML data into database. Anyway, I thought some of you might find what I did interesting so here is a fragment of XML returned by XDO. The database is the AdvWorks Access database that comes with Active Server Page package. BTW, following XML was generated with IncludeMetadata option set to true and PrimaryDimension set to 'row'. ]> 1 1 5 1995-02-02 00:00:00 52 Jaime Yorres Let's Stop N Shop 87 Polk St. Suite 5 San Francisco CA 94117 USA (415) 555-5938 1995-02-03 00:00:00 1 2.0000 0.0 2 1 5 1995-03-14 00:00:00 32 Jaime Yorres Let's Stop N Shop 87 Polk St. Suite 5 San Francisco CA 94117 USA (415) 555-5938 1995-03-15 00:00:00 4 3.0000 0.0 Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smith at interlog.com Tue Mar 24 07:09:16 1998 From: smith at interlog.com (Chris Smith) Date: Mon Jun 7 17:00:18 2004 Subject: IDREF In-Reply-To: <01bd5642$d5d3cde0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: On Mon, 23 Mar 1998, Michael Kay wrote: > I have been using IDREF to represent relationships within a > genealogical data set, but with considerable reservations ... > wasn't so full of hyperlink behaviour. I want to model a > relationship between two objects that happen to be in different > datasets. All the XLL stuff about the manner in which links are > followed is to me entirely presentation-oriented and I don't > want it in my data thankyou very much. From that point of > view I prefer the IDREF style of specification which says > nothing about the behavioural characteristics of the link. > What I really need is a "distributed IDREF". On OpenTradingProtocol, we are using ID/IDREF in much this manner, with the additional riders - IDs, once attached to an element, are permanent because the entity may be authenticated (including attributes) - and (the tough one) elements may be picked up from several previous documents ("messages") and assembled in a new document with a guarantee that the unchanged IDs will not conflict! We only achieved this by clearly specifying the generation process for the *content* of the IDs. I think it was worth the effort, because it allows all the pieces of the transaction to be readily accessible. It should even be possible (although not required) to store all the components of an OTP transaction (many messages) in a single document for receipt purposes without the IDs conflicting. --------------------------------------------------------------------------- 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 M.H.Kay at eng.icl.co.uk Tue Mar 24 10:52:00 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:00:18 2004 Subject: An example of database query result in XML Message-ID: <01bd5713$218e2200$1e09e391@mhklaptop.bra01.icl.co.uk> >Anyway, I thought some of you might find what I did interesting so here is a >fragment of XML returned by XDO. It's certainly interesting and instructive: I would never have thought of doing the metadata in quite that way. Is it really practical to have quite so much tagging? I know it will compress beautifully for transmission over a network, but compressing a gigabyte file is not something one does just for fun. Using shorter tags (e.g. , for the cells would be a simple fix, but it's still much bigger than a CSV file. I would be interested to know why you chose the representation AB rather than One other minor comment, are you doing anything to preserve white space in the data content? 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 donpark at quake.net Tue Mar 24 12:53:22 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:00:18 2004 Subject: An example of database query result in XML Message-ID: <003701bd5722$eb1e54a0$2ee044c6@donpark> >It's certainly interesting and instructive: I would never have thought of >doing the metadata in quite that way. Frankly, it looks pretty sick from certain perspective but thankfully the feeling goes away after reading a stack of XML specs ;-) >Is it really practical to have quite so much tagging? I know it will >compress beautifully for transmission over a network, but compressing a gigabyte >file is not something one does just for fun. Using shorter tags (e.g. , > for the cells would be a simple fix, but it's still much bigger than a CSV file. Using shorthand tags is nice but losing clarity to save a few characters is quite worth it especially if the loss will be propagated down the line (i.e XSL rules will start to look funky). I am perfectly willing to trust the compression to do its magic at this point. >I would be interested to know why you chose the representation >AB >rather than 1. I wanted to treat column and rows on equal footing so that you could have columns on the outside as well as inside. 2. I do not like using attributes to hold contents. 3. Using #FIXED attribute values for field metadata will certainly not work since there is no attributes for attributes. My XDO example's main attraction is the way the metadata is described as internal DTD subset. The result can now be carried to any database and inserted with very little ambiguity. >One other minor comment, are you doing anything to preserve white space >in the data content? Yes. Whitespaces in Field element content are significant. For example, the element content can have linefeed. As I mentioned before, my XDO example is something anyone can write over a weekend because extracting XML-based information from legacy systems is a no-brainer. Going the other direction is much harder and should be fertile ground for quite a few startups. XML is very flexible and it is easy to convert practically any data into XML without significant loss of information. But because XML is so powerful, the problem of converting XML to other data formats is much greater than before and is bound to cause information loss. So I guess I am leading toward using XML more as a data communication format and less as a data storage format. Just whining cuz I am not going to the XML Conference, Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamsden at us.ibm.com Tue Mar 24 14:24:03 1998 From: jamsden at us.ibm.com (Jim Amsden) Date: Mon Jun 7 17:00:18 2004 Subject: An example of database query result in XML Message-ID: <5040100016492318000002L082*@MHS> Interesting and informative example, but there may be better ways to structure the XML for the result. First, rows generally aren't that interesting, its the meaning of the data in the row that's important. Taking a more object (or entity relationship) oriented view, the columns represent attributes of an object and/or associative links to other objects. XML attributes are best here because they have additional semantics over content: minimal typing, defaults, required, etc. Using attributes takes up less space in the document too as there is no end tag. Foreign keys in the tables represent value-based links to other entities. These can be captured using ID and IDREF attribute types with the foreign keys providing the attribute values. Finally, the columns taken together represent some object that has semantic meaning derived from the state variables and associations in its attributes. The tag name provides a convenient way to name this element and to provide a hint about what that semantic meaning is. Using row elements completely looses this valuable encapsulation of knowledge. In the example given, it looks like the rows are instances of an Order, but I'm not sure without looking at the query. Finally, using fixed attributes to capture the schema meta-data, and elements for the data is an interesting idea, but a better solution is to do what SQL does. Treat the schema as just another database providing data about data. If you need that data, go get it. If you don't, then don't bother. The DTD in the example is attempting to describe two different, but related subject areas in the same internal DTD. One is the structure of the data, and another is the structure of its meta-data. Although mixing these subject areas may be convenient for some applications, it's generally better to keep separate concerns separate. Note that the DTD for the example would allow empty rows, and rows that only contained 15 ShipPhoneNumbers! Rows have ID attributes that are likely redundant with the ID of the order in them. So the result might be something like: OrderID="1" CustomerID="1" EmployeeID="5" OrderDate="1995-02-02 00:00:00" PurchaseOrderNumber="52"> ContactFirstName="Jaime" ContactLastName="Yorres" ShipName="Let's Stop N Shop" ShipAddress="87 Polk St. Siite 5" ShipCity="San Francisco" ShipStateOrProvince="CA" ShipPostalCode"94117" ShipCountry="USA" ShipPhoneNumber="(415) 555-5938" ShipDate="1995-02-03 00:00:00" ShippingMethodID="1" FreightCharge="2.0000" SalesTaxRate="0.0" ... It might be possible to shortened some of the names because since they're attributes, its less likely they'll get confused with similar names in other elements. So ShipCity could just be City. You'd need to know more about the problem domain to make this decision though. Now a CustomerOrder could be an XML element whose contents is many orders. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From NRYBERG at email.usps.gov Tue Mar 24 14:34:19 1998 From: NRYBERG at email.usps.gov (NICHOLAS RYBERG) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured document Message-ID: <0033000002284959000002L092*@MHS> Hmmmm.... I would think, from a Windows perspective at least, that it would be possible to update an XML "database" at the field and row level. It would possibly be a question of search and replace functions, and there I could see problems. If, however, you used unique keys for all of your XML "tables", that shouldn't be too much of an issue. I would think it's feasible - whether it's as easy to use as a regular relational or object oriented DB, is another thing. I would want to test the speed of access also. Without any data, I'd have to say that a binary level database would probably perform faster, perhaps much faster, than a human readable ASCII document combined with a XML database app. ______________________________ Reply Separator _________________________________ Subject: Re: Relational Tables and structured document Author: owner-xml-dev@ic.ac.uk at INTERNET Date: 03/23/98 09:59 PM I've been following the comments about using XML as a database, and I have a question -- The discussion of ODMG and using XML as a database suggests that you will be able to update the database. But, if you have a large XML file, how do you update fields within that file without copying or re-writting the whole file? That sounds very awkward. Or am I missing a step in this process? Are we assuming that the XML file has been sucked into an OODBMS such as one for which there are ODMG language bindings? I think this would be very powerful. However, it is no longer XML, is it? Or is the goal to store the data in a RDBMS or OODBMS and then export it to XML so we can send it across the wire and around the Web? I guess I am asking whether there is a model this kind of use of XML as a database. Dave > Peter Murray-Rust: > > >I have been spending the last two weeks working on a molecular application > >which essentially consists of relational tables. The application is > >largely hierarchical (a protein molecule) so that it benefits from being > >recast into structured document form. I have therefore found it useful to > >create routines which generate nodes in a tree as a result of joining > tables. > > > I think there are several things that one could usefully do. > > (1) define a recommended way of representing a relational table in XML. > (There > are a number of ways of doing this, the biggest decision is whether to use a > standard DTD for all tables or a DTD that reflects the specific table > definition.) > > (2) extend this to a richer data model, e.g. the nested relational model, > that > allows you to represent hierarchic structures, or the ODMG model which > allows > to to represent arbitrary graphs. (Note that the problem then becomes > analogous to the one of using XML as a serialisation format for CORBA > objects) > > (3) provide a toolkit that allows you to perform transformations on these > XML > documents that reflect the operators of the relevant data model, e.g. > relational > selection, projection, and join; sorting and grouping; flattening of nested > relations. > Of course one way to implement such operations would be to load the data > into > a database, but many of the operations can be implemented directly without > too > much effort. > > I think the key thing is to keep the set of structures and operations very > clean: > base it on a data model with an established formal basis rather than > inventing > something new. > > 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) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 ora.com Tue Mar 24 15:14:17 1998 From: crism at ora.com (Chris Maden) Date: Mon Jun 7 17:00:18 2004 Subject: How to specify validation properties in DTDs? In-Reply-To: <93DA154E07D3D0119C7E006097743AA001154A1C@hq-exs1.pointcast.com> (message from Parik Rao on Mon, 23 Mar 1998 20:11:10 -0800) Message-ID: <199803241518.KAA01501@geode.ora.com> [Parik Rao] > Hi, I'm trying to figure out how do I do parameter validation in my > DTD. For example, I have an element which specifies a SIZE as an > attribute. I'd like to enforce certain rules : the charaacter data > in size is digits and the size is always less than 1,000,000 (for > example). As far as I can figure out, there is no way to do this! > E.g. > > SIZE CDATA #REQUIRED > > > > Well, how do I set validation parameters for size? I tried to play > around with entity but really couldn't come up with anything: > > > > > Anyone done this sort of thing? Is this sort of validation beyond > the scope of DTDs? On the nose: this is beyond the scope of DTDs. This kind of restriction must be specified as an application restriction, and enforced by means outside the current scope of XML. A stylesheet might be able to check the attribute value, and throw an error if it doesn't conform (if the XSL WG decides to have error handling); an XML application could check this information after the parser parses the data. There's also work ongoing about XML-Data, which would permit you to specify restrictions like this. However, it's not done (or close, I think). -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 deke at tallent.com Tue Mar 24 19:07:27 1998 From: deke at tallent.com (Deke Smith) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured document Message-ID: <1321377664-30944515@tallent.com> G. David Kuhlman, dkuhlman@netcom.com said on 3/23/98 8:45 PM: >But, if you have a large XML file, how do you update fields within >that file without copying or re-writting the whole file? That >sounds very awkward. You're right, you would have to parse the file to some sort of tree structure and edit the nodes of the tree. Then it can be parsed back to XML. ----------------------------------------------------------------- Deke Smith Tallent Communications Group, Brentwood TN deke@tallent.com, 615-661-9878 ----------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 24 20:01:16 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:00:18 2004 Subject: Relational Tables and structured document In-Reply-To: <1321377664-30944515@tallent.com> References: <1321377664-30944515@tallent.com> Message-ID: * G. David Kuhlman | | But, if you have a large XML file, how do you update fields within | that file without copying or re-writting the whole file? That | sounds very awkward. * Deke Smith | | You're right, you would have to parse the file to some sort of tree | structure and edit the nodes of the tree. Then it can be parsed back | to XML. A DOM server might solve that problem. My dream is to have a DOM implementation that's CORBA-aware and has some sort of locking mechanism for concurrent access.[1] The ideal implementation would have some language for expressing operations on the DOM tree (or at least for locating the node where you want to start editing (XLL?)) so that repetitive operations could be simplified. It would also be nice to have some sort of caching in that documents could be kept in one of three forms: as objects in memory, as serialized objects in some form of permanent storage (disk, database, whatever) or as an XML document. Whether this would actually have any advantages over an ODBMS is not clear to me, but I intend to find out. I certainly see a lot of possible advantages, but also some pitfalls. [1] The CORBA hype claims that the CORBA services can provide security, transactions and locking transparently. If it's true it would certainly be a major help. CORBA might not be a viable alternative for all kinds of web applications yet (although Netscape 4 (maybe also 3) comes with an ORB), so an HTTP2CORBA gateway might have to be installed as well. -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From NRYBERG at email.usps.gov Tue Mar 24 21:42:55 1998 From: NRYBERG at email.usps.gov (NICHOLAS RYBERG) Date: Mon Jun 7 17:00:19 2004 Subject: Relational Tables and structured document Message-ID: <0033000002295453000002L032*@MHS> While I agree that concurrent access would be painful to implement, I don't feel that editing particular records, per se, in a XML doc would be all that difficult. If not this, what else is a random access file for? From a purely procedural point of view, I would guess that you'd have to: 1) Make the changes to the text of the particular record you're working on 2) Go back to the source XML doc and find that particular line 3) Replace the text in that one particular line 4) Badda-bing! Save it, and you're done. Am I being hopelessly naive about this? - Nick Ryberg ______________________________ Reply Separator _________________________________ Subject: Re: Relational Tables and structured document Author: owner-xml-dev@ic.ac.uk at INTERNET Date: 03/24/98 04:13 PM G. David Kuhlman, dkuhlman@netcom.com said on 3/23/98 8:45 PM: >But, if you have a large XML file, how do you update fields within >that file without copying or re-writting the whole file? That >sounds very awkward. You're right, you would have to parse the file to some sort of tree structure and edit the nodes of the tree. Then it can be parsed back to XML. ----------------------------------------------------------------- Deke Smith Tallent Communications Group, Brentwood TN deke@tallent.com, 615-661-9878 ----------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Tue Mar 24 22:14:35 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:00:19 2004 Subject: An example of database query result in XML References: <003701bd5722$eb1e54a0$2ee044c6@donpark> Message-ID: <35183020.7534257@allette.com.au> Don Park wrote: > XML is very flexible and it is easy to convert practically any data into XML > without significant loss of information. The trick I think, is to convert information taken for granted by humans into something more formal. Formatting such as indents need to be interpreted as nested objects. Humans don't have a problem with this because they primarily digest the information linearly - finding the ends of objects programatically isn't always as easy. I think the conversion to XML is much more likely to result in lost information than the conversion out. > But because XML is so powerful, > the problem of converting XML to other data formats is much greater than > before and is bound to cause information loss. If your XML is adequately designed, it should contain all of the information - getting it out with something like OmniMark is trivial. It might be difficult to render neatly in your output, but that's not an XML issue. > So I guess I am leading > toward using XML more as a data communication format and less as a data > storage format. I don't see that being any more true for XML than it has ever been for SGML. > Just whining cuz I am not going to the XML Conference, By the sounds of it, we're the minority group... -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Mar 25 00:28:19 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:00:19 2004 Subject: An example of database query result in XML Message-ID: <00ab01bd5784$1463b420$2ee044c6@donpark> Jim wrote >the XML for the result. First, rows generally aren't that interesting, its the >meaning of the data in the row that's important. Taking a more object (or Rows are not interesting because they are anonymous elements designed to fire rules. >example given, it looks like the rows are instances of an Order, but I'm not >sure without looking at the query. Rows are result of a query which just happens to involve Order only. It could just as well involved many other tables as well as databases. >Finally, using fixed attributes to capture the schema meta-data, and elements >for the data is an interesting idea, but a better solution is to do what SQL >does. Treat the schema as just another database providing data about data. If >you need that data, go get it. If you don't, then don't bother. The DTD in the >example is attempting to describe two different, but related subject areas in >the same internal DTD. One is the structure of the data, and another is the >structure of its meta-data. Although mixing these subject areas may be >convenient for some applications, it's generally better to keep separate >concerns separate. You are right if the example was meant to be stored somewhere. However, if XML is used for communication only and not for storage, you have a problem. Where do you store the DTD file if XML file itself is temporary? In XDO, I had to store the metadata within the XML because it had to be standalone. >Note that the DTD for the example would allow empty rows, and rows that only >contained 15 ShipPhoneNumbers! Rows have ID attributes that are likely >redundant with the ID of the order in them. You are right there. >It might be possible to shortened some of the names because since they're >attributes, its less likely they'll get confused with similar names in other >elements. So ShipCity could just be City. You'd need to know more about the >problem domain to make this decision though. Ah. Now we are back to TagNet. Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Wed Mar 25 04:44:49 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:00:19 2004 Subject: An example of database query result in XML References: <5040100016492318000002L082*@MHS> Message-ID: <35188B68.23@hiwaay.net> Jim Amsden wrote: > > So the result might be something like: > > > OrderID ID #REQUIRED > CustomerID IDREF #REQUIRED > EmployeeID IDREF #REQUIRED > OrderDate CDATA #REQUIRED > PurchaseOrderNumber CDATA #REQUIRED > ContactFirstName CDATA #IMPLIED > ContactLastName CDATA #REQUIRED > ShipName CDATA #REQUIRED > ShipAddress CDATA #REQUIRED > ShipCity CDATA #REQUIRED > ShipStateOrProvince CDATA #REQUIRED > ShipPostalCode CDATA #REQUIRED > ShipCountry CDATA #REQUIRED > ShipPhoneNumber CDATA #REQUIRED > ShipDate CDATA #REQUIRED > ShippingMethodID CDATA #REQUIRED > FreightCharge CDATA "2.0000" > SalesTaxRate CDATA "0.0 > > > > > OrderID="1" > CustomerID="1" > EmployeeID="5" > OrderDate="1995-02-02 00:00:00" > PurchaseOrderNumber="52"> > ContactFirstName="Jaime" > ContactLastName="Yorres" > ShipName="Let's Stop N Shop" > ShipAddress="87 Polk St. > Siite 5" > ShipCity="San Francisco" > ShipStateOrProvince="CA" > ShipPostalCode"94117" > ShipCountry="USA" > ShipPhoneNumber="(415) 555-5938" > ShipDate="1995-02-03 00:00:00" > ShippingMethodID="1" > FreightCharge="2.0000" > SalesTaxRate="0.0" > There is a long history of debate on the issue of usings attibutes vs elements for describing data in SGML. The DTD models frequency and occurrence. In a representation where there are not duplicates there is no benefit to modeling frequency and occurrence. In that case, the better representation is the simpler one if the query is simplified by this. 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 mtbryan at sgml.u-net.com Wed Mar 25 08:13:55 1998 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:00:19 2004 Subject: Relational Tables and structured document Message-ID: <01bd57c4$98ee4300$068577c2@sgml.u-net.com> For your information, ISO JTC1/WG4, the body responsible for SGML, DSSSL and HyTime, is organizing a by-invitation Workshop on accessing and exchanging metadata represented in SGML from databases, knowledge bases and search tools, which will be held on the day after SGML/XML Europe in Paris. One of the questions this workshop has to consider is that of standardized methods of exchanging queries related to SGML and XML documents. Among those attending the workshop will be the editors of the SQL and SQL/MM standards. Hopefully OMG/CORBA and W3C experts will also be present. I hope that this workshop will lead to the development of a standardized mechanism for exchanging database queries and updates between XML systems. 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 peter at ursus.demon.co.uk Wed Mar 25 09:53:50 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:19 2004 Subject: Relational Tables and structured document In-Reply-To: <0033000002284959000002L092*@MHS> Message-ID: <3.0.1.16.19980323095543.361f2f48@pop3.demon.co.uk> At 09:18 24/03/98 -0500, [A number of people who don't read my messages] wrote: [...large amounts of quoted material...] ending in THREE XML-DEV signature quotes Normally I would title this message LISTRIVIA, but some posters ***including some well known names*** have been inconsiderate in their postings lately. ***Having returned from 2 weeks absence, I posted about 3 mails to XML-DEV. MOST OF MY MAIL THEN CONSISTED OF ***MULTIPLE POSTINGS OF UNNECESSARILY QUOTED MATERIAL***. What saddens me is that I posted (gently) to the list only a week ago, and the inconsiderate behaviour started immediately afterwards. It's very simple: Decide what you want to say (the standard is very good - keep it up). Say it, clearly and concisely (again good) Don't say what ***other people have said*** unless it's critical Reply ***only to the list*** READ YOUR MESSAGE BEFORE POSTING. Cut out any unnecessary quotes. If you think this is fussy, be aware than many people have to ***pay for what mail they receive***. An XML-DEV'er may be proud of what they have posted to this list, but they don't want to have to pay to read ***SIX*** copies of it as I have had to this week. 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 kumar at OpenMarket.com Wed Mar 25 18:26:02 1998 From: kumar at OpenMarket.com (Selva Kumar) Date: Mon Jun 7 17:00:19 2004 Subject: attibutes vs elements for describing data Message-ID: <3.0.32.19980325132503.00906740@mail-60.openmarket.com> At 10:43 PM 3/24/98 -0600, len bullard wrote: > >There is a long history of debate on the issue of usings >attibutes vs elements for describing data in SGML. Len Could you give me some URL references ? I am trying to create DTD for an XML-based message. This is one of the issues I face. So, I am interested in knowing what kinda factors one should consider to make this decision. Thanks in advance. Selva xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ser at javalab.uoregon.edu Wed Mar 25 21:06:02 1998 From: ser at javalab.uoregon.edu (ser@javalab.uoregon.edu) Date: Mon Jun 7 17:00:19 2004 Subject: unsbscribe xml-dev Message-ID: <19980325210551.4176.qmail@javalab.uoregon.edu> 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 mcgredo at stl.nps.navy.mil Wed Mar 25 22:10:21 1998 From: mcgredo at stl.nps.navy.mil (Don McGregor) Date: Mon Jun 7 17:00:19 2004 Subject: XML-Data examples? Message-ID: <199803252210.OAA03118@pinafore.stl.nps.navy.mil> Does anyone have some example XML-Data schema examples that I can look at? I've attempted to cook up some simple examples based on the W3C web site notes, but it keeps on failing when I try to parse it with the MS parser, probably for unknown syntax reasons. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From safro at CS.bgu.ac.il Thu Mar 26 04:03:57 1998 From: safro at CS.bgu.ac.il (Safro Ilya) Date: Mon Jun 7 17:00:19 2004 Subject: How to translate tags? Message-ID: Hello, I want to translate tag into in XML, how can i do it. I have a document hello and i want to build DTD of my_tag, such as a XML processor will translate it to hello Thank you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Mar 26 12:29:46 1998 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:00:19 2004 Subject: WFC Release 33 is out Message-ID: <013f01bd58b2$e08dbc10$e280accf@sammy> If you're a Win32 C++ programmer... I just posted release 33 of Win32 Foundation Classes to http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm This release beefs up the XML classes. It is now a lot easier to create XML documents. There is a CXMLArchive class that let's you serialize objects to/from an XML document. You can now stop the parsing of a document from a callback (callbacks are registered for particular elements, when an element element of that type has been parsed, the callback is executed which can abort the parsing process if it so chooses). WFC is freeware distributed in source code form. If you're not a Win32 programmer, you could port the XML classes over without much difficulty (you'd need a string class and a byte-array class). HTH, 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 amitr at abinfosys.com Thu Mar 26 17:50:53 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:00:19 2004 Subject: ANY MAIL LISTS FOR XSL ???? Message-ID: <3.0.5.32.19970326204036.008fd900@192.168.1.1> ANY GOOD MAIL LISTS FOR XSL QUERIES???? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 26 17:50:53 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:00:19 2004 Subject: MSXSL DOES NOT VALIDATE XML AGAINST DTD Message-ID: <3.0.5.32.19970326203649.008fd510@192.168.1.1> I have run a few test applications using the MSXSL processor. But unfortunately,the MSXSL processor is not validating the XML file I give it as input, against its corresponding DTD. How to enable the MSXSL processor to validate the XML against its 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 amitr at abinfosys.com Thu Mar 26 17:50:57 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:00:19 2004 Subject: ANY GOOD XML AND XSL DEBUGGERS!!! Message-ID: <3.0.5.32.19970326203913.008ff790@192.168.1.1> Are they any GOOD XML and XSL debuggers which trace thru XML and it's corresponding pattern in XSL???? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 ora.com Thu Mar 26 18:03:11 1998 From: crism at ora.com (Chris Maden) Date: Mon Jun 7 17:00:19 2004 Subject: ANY MAIL LISTS FOR XSL ???? In-Reply-To: <3.0.5.32.19970326204036.008fd900@192.168.1.1> (message from Amit Rekhi on Wed, 26 Mar 1997 20:40:36) Message-ID: <199803261807.NAA05436@geode.ora.com> [Amit Rekhi] > ANY GOOD MAIL LISTS FOR XSL QUERIES???? THE XSL-LIST AT MULBERRY!!!!... sorry - my caps lock was stuck. And my punctuation - darndest thing. Try . -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 fiid at westlake.com Thu Mar 26 18:05:15 1998 From: fiid at westlake.com (David Williams) Date: Mon Jun 7 17:00:19 2004 Subject: ANY GOOD XML AND XSL DEBUGGERS!!! In-Reply-To: <3.0.5.32.19970326203913.008ff790@192.168.1.1> Message-ID: Yes... I know of a product in development that is an editor / debugger / development tool with syntactic hilighting and the like. Talk to shawn@westlake.com (Shawn O'Conner) for more info. Fiid. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 26 20:42:49 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:00:19 2004 Subject: MSXSL DOES NOT VALIDATE XML AGAINST DTD Message-ID: <01bd590a$f7e0ece0$e8acdccf@uspppBckman> >>But unfortunately,the MSXSL processor is not validating the XML file I give it as input, against its corresponding DTD.<< It is not required for XML processors to validate against the DTD, they only have to see that they are well formed. "5. Conformance Conforming XML processors fall into two classes: validating and non-validating. Validating and non-validating systems alike must report violations of the well-formedness constraints given in this specification. Validating processors must report violations of the constraints expressed by the declarations in the DTD. They must also report all failures to fulfill the validity constraints given in this specification. " Frank -----Original Message----- From: Amit Rekhi To: xml-dev@ic.ac.uk Date: Thursday, March 26, 1998 9:58 AM Subject: MSXSL DOES NOT VALIDATE XML AGAINST DTD > I have run a few test applications using the MSXSL processor. > But unfortunately,the MSXSL processor is not validating the XML file I >give it as input, against its corresponding DTD. > How to enable the MSXSL processor to validate the XML against its 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) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 26 22:04:48 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:00:19 2004 Subject: Check out xml.com Message-ID: <3.0.32.19980326140251.00af6bb4@pop.intergate.bc.ca> Hi - I've been working with Seybold and O'Reilly, and there is a preview version available of the xml.com web-site, which opens officially on May 1. It has a usefully-annotated XML spec and some other material and (any minute now) a cgi-based XML well-formedness checker. Check it out at http://www.xml.com Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 27 01:23:26 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:00:19 2004 Subject: Check out xml.com Message-ID: <004e01bd591e$20909880$2ee044c6@donpark> Tim, >Hi - I've been working with Seybold and O'Reilly, and there is a >preview version available of the xml.com web-site, which opens >officially on May 1. It has a usefully-annotated XML spec and some >other material and (any minute now) a cgi-based XML well-formedness >checker. I just visited it and it looks just great. Your annotated XML spec is just awesome (gosh, its been years since I used that word). If there a downloadable version available, it would be outrageous! BTW, I think there is some overlap between xml.com and the great work Robin is doing. It would be even more awesome if you and Robin could somehow work together. Keep up the good work and thanks for the annotated XML spec, Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Mar 27 04:08:22 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:00:19 2004 Subject: Architecture description Message-ID: I don't know if the XML-DEV community is interested in the possibilities of an XML/HTTP-centered client-server architectures, but I've posted one possibility to http://members.aol.com/simonstl/xml/. It's a brief first draft, built of pieces leftover from XML: A Primer and the echoings that have been tearing through my head since I first encountered this technology. It's not fully baked yet by any means. I'm quite aware that it probably won't be to everyone's tastes, but all suggestions and comments are welcome. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Mar 27 04:12:28 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:00:19 2004 Subject: Check out xml.com In-Reply-To: <3.0.32.19980326140251.00af6bb4@pop.intergate.bc.ca> Message-ID: <3.0.3.32.19980326230820.0085ddd0@nexus.polaris.net> >It has a usefully-annotated XML spec I like the annotation a *lot*, both for its style (a human face on an inscrutable object) and for the substance -- the mechanism. Thanks so much for posting it, Tim. You didn't cross-post the announcement in XML-L, but I think folks there might appreciate it as well. John E. Simpson (Just XML: Coming [if I'm lucky] from Prentice-Hall, Fall '98) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From trevort at za.ibm.com Fri Mar 27 08:06:06 1998 From: trevort at za.ibm.com (Trevor Turton) Date: Mon Jun 7 17:00:19 2004 Subject: Check out xml.com Message-ID: <5060200013506424000002L042*@MHS> The annotated XML is brilliant - a labour of love, diligence and wit. This will do much to make XML accessible to us mere mortals. Trevor Turton xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 27 15:01:19 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:00:19 2004 Subject: Is DSSSL-O dead? Message-ID: <01bd59aa$ea4450e0$31addccf@uspppBckman> In part XSL was proposed because of DSSSL's fearsome reputation for difficulty, a reputation that in part has been fostered by the proponents of DSSSL themselves. It seems that when 'disselites' speak only the elite 'disselites' can understand.(I will make a disclaimer right now that there are exceptions, for example Paul Prescods tutorial is a model of clarity). Having just finished teaching a course on style-sheets, I wonder if that fearsome reputation is not a little over-rated. I identified the following four areas that I thought the students would have difficulty with. 1. The concept of flow objects. 2. The concept of pre-fix operands 3. The lack of suitable tools for experimentation 4. The lack of suitable documentation for teaching at an entry level. (And even experienced programmers learning a new language benefit from entry level materials) Much to my surprise 1. presented absolutely no difficulty at all provided the concept was presented right up front. 2. presented much less difficulty than I thought, the students treated the pre-fix operands as rather a game, competing with one another to create the most outlandish and non-readable expression. 3. I wrote a very simple little teaching application that enabled the students to play with the rules and output HTML. This more than anything else conquers the "boredom" factor and turns an abstract discussion into a concrete one. XSL may have taken off because a parser was provided right from the beginning. 4. This remains a problem Paul Prescod and David Germain's tutorials are excellent, but they are not aimed at the lite version, and Jade requires a DTD to operate, and is non exactly user-friendly. A tool for XS should operate without a DTD. DSSSL is an incredibly powerful language, in fact all the other languages evince a "I want to be like Mike" attitude (for non US readers this refers to a Nike Ad starring Michael Jordan), and I for one would hate to see it relegated again to the marginalia of document authoring. It strikes me that all the perceived problems are eminently "fixable" Frank Boumphrey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 27 15:01:21 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:00:19 2004 Subject: RFC2318 Message-ID: <01bd59a6$09e52fa0$31addccf@uspppBckman> I notice that the media type text/xml is not registered, or wll one just stick with text/sgml ? Frank -----Original Message----- From: Hakon Lie To: www-style@w3.org Date: Friday, March 27, 1998 2:37 AM Subject: RFC2318 >The media type "text/css" is now registered in IANA [1] by way of >RCF2318 [2]. Thanks to everyone who reminded us to do so :) > >[1] http://www.isi.edu/in-notes/iana/assignments/media-types/media-types >[2] ftp://ftp.isi.edu/in-notes/rfc2318.txt > >-h&kon > >H ? k o n W i u m L i e >howcome@w3.org http://www.w3.org/people/howcome >World W i d e Web Consortium > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Hans-Guenter.Stein at fast.de Fri Mar 27 15:31:14 1998 From: Hans-Guenter.Stein at fast.de (Hans-Guenter Stein) Date: Mon Jun 7 17:00:19 2004 Subject: XML-to-legacy-DBs gateway needed Message-ID: <351BB7EB.6AD9525E@fast.de> Hi all, I have to implement a gateway between XML and standard databases like MS SQL or Informix. Scenerio: A Java program (agent) wants to perform a DB query. The query parameters are specified in form of an XML-document. The agent passes a handle to this XML-query to the gateway. The gateway parses the XML and translates it (according to application specific rulesets) into an SQL-statement. The SQL-statement is send to the DB (e.g. via JDBC driver). The answer to the query is transalted back to XML (according to another ruleset) and passed to the agent. Has anybody done something like that before? Is there a standard way to implement it (besides the apllication specific translation rules)? If so please let me know - I just don't want to re-invent the wheel... Hans-Guenter -- Hans-G?nter Stein, FAST e.V. Arabellastr. 17 | Tel +49-89-920047-55 | mailto:hgs@fast.de D-81925 Muenchen | Fax +49-89-920047-18 | http://www.fast.de/~hgs xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Sat Mar 28 04:31:25 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:00:19 2004 Subject: XML.com mistake Message-ID: <351C81CC.E36C7E83@finetuning.com> Dear Dale: This letter is in regards to the URL: http://www.xml.com/resource/xml-w3c.html, an article published on XML.com entitled: "XML and the W3C" that was mistakenly published without my knowledge. In light of the altered title and implied content of the piece, the material has been inappropriately placed completely out of context. I realize it was merely the onslaught of events this week that allowed this kind of thing to happen, but I hope you understand the seriousness of the situation and act accordingly. In order to do justice to my professional reputation, and the reputation of XML.com, I must insist that you replace the current version with an amended version of the article, and publish an appropriate retraction somewhere prominently on the site. I am concerned that huge portion of the XML community may have already seen the piece, and that it would appear to be an incomplete and haphazard presentation of what should be a very straightforward topic, placing the issue of my technical understanding of XML and RDF, my understanding of the W3C's architectural design goals for the WWW, and even my conscientious and respectful participation in the W3C's standards process into serious question. Considering the high profile of the site, the level of expertise of the other contributors, and the attention the site has been receiving by the expert developer community, I am concerned that the quality of this hastily-published subset of another article will cause harm to my professional reputation. Although you informed me yesterday, in person, that the content of the piece had been used on a different publication than originally intended, you had not informed me of the new unrelated title and seriously altered implied-focus of the published result (from "XML Resources for Web Review" to "XML and the W3C" for xml.com). When the piece was submitted it was appropriately inclusive, descriptive, and timely, considering my assignment only required a baseline collection of technnical resources. Instead, an incomplete version was published in an entirely different context than intended. As an "article" about "XML and the W3C", the brief and general explanations appear as an outdated, incomplete, and sloppy attempt to explain a much larger and detailed subject. I have been working harder than ever in order to preserve my personal and professional integrity as a writer, consultant, and serious XML developer. The future of my career, the respect of my fellow W3C RDF Schema Working Group members, my continued interaction with the members of the W3C XML Working Group, and the success of my upcoming book are all depending on it, and as the situation grows more complex and detailed over time, I hope to earn a reputation of paying MORE attention to detail, not less. No hard feelings, but fix it fast please. Respectfully, Lisa Rein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 28 05:44:23 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:00:19 2004 Subject: XML news Message-ID: <3.0.32.19980327214300.00b2a650@pop.intergate.bc.ca> Although a remarkable proportion of the world's XML cognoscenti were in the big room in Seattle today, those who were not may be interested to hear that Larry Wall demonstrated perl reading XML in about 8 different ways (he used it to generate his HTML slides), and R.V. Guha of Netscape demonstrated Nav5 showing an ordinary-looking Web page with a form and a couple of pictures, and when he did "View Source", it was XML with CSS styles, plus HTML forms and images transcluded via XLink. Neither are finished/shipping; but source code for everything will be on the web before too long. Both the Perl and Navigator projects are basing their work on James Clark's C-language processor. And it still would have been an interesting technology day without either of those. Too many other details to go into now, but maybe the most amusing thing was that while Henry Thomson was demo-ing his lightweight XML wf-instance editor, Larry Wall (on the same panel, hence on-stage) quietly downloaded and installed it via his cellphone. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-708-9592 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 28 16:04:08 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:19 2004 Subject: XML.com mistake In-Reply-To: <351C81CC.E36C7E83@finetuning.com> Message-ID: <3.0.1.16.19980328155804.2c17deae@pop3.demon.co.uk> At 20:51 27/03/98 -0800, Lisa Rein wrote: >Dear Dale: > >This letter is in regards to the URL: >http://www.xml.com/resource/xml-w3c.html, an article published on >XML.com entitled: "XML and the W3C" that was mistakenly published >without my knowledge. In light of the altered title and implied content [... concerns about XML.COM and related material deleted ...] I have deliberately not visited the URL above, nor do I know any of the participants and the history, but the posting to which I have replied seems quite inappropriate for XML-DEV. [I posted a few days ago about the purpose of XML-DEV.] The posting refers to matters which are nothing to do with XML-DEV (a list for XML-developers). The material quoted refers to a site completely unconnected with XML-DEV and (unless the material on that site makes mention) has no relevance to this site. XML-DEV has been going for over a year and we have avoided any 'flame-wars' completely. I do not feel it is appropriate for person-to-person postings to be sent to XML-DEV. While it was appropriate for xml.com to be announced (since there was an announcement of an annotated spec and other developer material), the present controversy should be taken elsewhere. IMO the traffic on XML-DEV over the last year has been of very high quality and I thank posters, readers, and developers alike. 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 Mar 28 16:18:26 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:19 2004 Subject: XSL-List in xml-dev LISTRIVIA In-Reply-To: <199803262054.PAA25623@camel8.mindspring.com> Message-ID: <3.0.1.16.19980328154526.2c6fe698@pop3.demon.co.uk> My message about he address of the XSL LIST was poorly phrased and I apologise for slipping from the heights of precision that all XML devotees strive for. Here is Tony Graham's correction. P. At 15:54 26/03/98 -0500, XSL-List Owner wrote: >Peter, > >Your LISTRIVIA message to the xml-dev mailing list contains correct >but misleading information on the XSL-List. I have already had one >person attempt to subscribe by sending a subscription request to the >posting address of the XSL-List. > >Should you send out your LISTRIVIA message again, please either direct >people to http://www.mulberrytech.com/xsl/xsl-list or direct them to >send mail to majordomo@mulberrytech.com with "subscribe xsl-list" as >the body of their message. > >Regards, > > >Tony Graham >======================================================================= >Tony Graham >Mulberry Technologies, Inc. Phone: 301-315-9632 >17 West Jefferson Street, Suite 207 Fax: 301-315-8285 >Rockville, MD USA 20850 email: tgraham@mulberrytech.com >======================================================================= 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 SimonStL at classic.msn.com Sat Mar 28 17:17:38 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:00:19 2004 Subject: XML as middle ware between CORBA and COM Message-ID: Sorry for the cross-post, but this seems appropriate to both XML-Dev and a discussion about XML's (un)suitability for object communications that's been on XML-L. The key quote is: > Microsoft is expected to announce next month plans to use XML as a link for > communication between the Component Object Model (COM) and CORBA. The full story is at: http://www.infoworld.com/cgi-bin/displayStory.pl?980328.ehxml.htm Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Mar 28 20:16:17 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:00:20 2004 Subject: Important XML announcements Message-ID: <199803282014.MAA11152@boethius.eng.sun.com> In the bustle of XML-related conference and work group activities over the last few weeks, it's possible that the world at large has received insufficient notice of a couple of significant developments in the realm of XML specifications in progress. In order to make sure that no one with an interest misses the news, therefore, please be aware of the following: 1. Revisions of the working drafts relating to XML linking are available to the public from the W3C web site at http://www.w3.org/TR/WD-xlink http://www.w3.org/TR/WD-xptr http://www.w3.org/TR/NOTE-xlink-principles These are the first publicly available updates to the work in progress on XML linking in many months. Note that the previous single working draft has now been split up into two separate working drafts covering linking mechanisms and addressing mechanisms and a note covering design principles. 2. The first working draft of "Namespaces in XML" has just been made available at http://www.w3.org/TR/WD-xml-names In order to meet urgent requirements from other W3C working groups, the W3C XML WG intends to move the Namespace WD to the status of a Proposed Recommendation as soon as possible. The document is open to public comment in the forums to which this message has been posted, but please note the following points: A. Implementation at this point is at your own risk. As stated at the beginning of the draft itself: This draft specification is a work in progress representing the current consensus of the W3C XML Working Group. This is a W3C Working Draft for review by W3C members and other interested parties. Publication as a working draft does not imply endorsement by the W3C membership. While we do not anticipate substantial changes, we still caution that further changes are possible and therefore we recommend that only experimental software or software that can be easily field-upgraded be implemented to this specification at this time. The XML Working Group will not allow early implementation to constrain their ability to make changes to this specification prior to final release. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite W3C Working Drafts as other than "work in progress". B. The provisional status of the draft notwithstanding, it should be noted that the urgent need for this specification on the part of working groups in both the W3C and the IETF makes it extremely unlikely that any changes to the draft beyond the repair of outright errors will be made for the Proposed Recommendation of Version 1.0 of the specification. C. It is the current intention of the XML WG to attempt the promotion of the Namespaces WD to Proposed Recommendation by the beginning of May. This allows just one month for public comment. D. It will save a great deal of unnecessary bandwidth to understand the circumstances under which Version 1.0 of the Namespaces draft has been developed. Given the extraordinary depth of the problem that the specification begins to address, the importance of solving that problem correctly, the lack of implementation experience in this area, and the need for a quick first cut for use by activities depending on the specification, the XML WG has taken it as a guiding principle to specify just the absolute minimum needed to meet the immediate requirements. This means that a number of fairly obvious aspects of naming that one would expect to be addressed in the specification have quite deliberately been left unspecified for Version 1.0. Thus, comments pointing out the failure of Version 1.0 to address particular features are in general unnecessary and will likely be ignored. Persons wishing to make useful contributions to the public review of the draft should confine their comments to pointing out broken places in those mechanisms that the draft provides rather than suggesting additional ones. Jon Bosak Chairman, W3C XML WG P.S. Never send comments about XML specifications to me personally. I won't read them. ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 901 San Antonio Road, MPK17-101 | Best is he that inuents, Palo Alto, California 94303 | the next he that followes ISO/IEC JTC1/WG4::NCITS V1::OASIS | forth and eekes out a good Davenport::W3C XML WG::W3C XSL WG | inuention. ---------------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From john at datachannel.com Sun Mar 29 09:22:28 1998 From: john at datachannel.com (John Tigue) Date: Mon Jun 7 17:00:20 2004 Subject: XML as middle ware between CORBA and COM Message-ID: <009301bd5ae3$fbd8b000$720a1bac@gigue.datachannel.com> -----Original Message----- From: Simon St.Laurent Subject: XML as middle ware between CORBA and COM >Sorry for the cross-post, but this seems appropriate to both XML-Dev and a >discussion about XML's (un)suitability for object communications that's been >on XML-L. > I've been writing a lot of code which proves that XML works just fine for software component object inter-communication and in some ways is even superior to current systems (even if it weren't better, how else would you do such things in a Web-native fashion if not in XML). As a result of my research I have published a few DTDs related to such matters. They can be found at: http://xml.datachannel.com/WebBroker/DTDs.html I presented my findings at the XML Conference in Seattle last week. A presentation slide show is at http://xml.datachannel.com/public/presentation/XMLSeattle/ I am currently reving the proof of concept code to match the DTDs (at this point the code does things wellformedly, but not in a way that is validatable to the DTDs plus the code is just plain ugly to look at and ugly to use). I'll announce when the code is ready for public display shortly but I believe the DTDs speak for themselves (WebBroker is an implementation and the DTDs are the 'API'; they are seperate issues). I welcome any feedback on the DTDs. The WebBroker is a specific application of XML and I don't really know if discussing it belongs on this list but I had to respond to the above posting. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Mar 29 19:39:10 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:20 2004 Subject: XML data typing (Re: XML as middle ware between CORBA and COM) In-Reply-To: <009301bd5ae3$fbd8b000$720a1bac@gigue.datachannel.com> Message-ID: <3.0.1.16.19980329172859.2c8f78ce@pop3.demon.co.uk> At 23:26 28/03/98 -0800, John Tigue wrote: [...] > >I've been writing a lot of code which proves that XML works just fine for >software component object inter-communication and in some ways is even >superior to current systems (even if it weren't better, how else would you >do such things in a Web-native fashion if not in XML). As a result of my >research I have published a few DTDs related to such matters. They can be >found at: http://xml.datachannel.com/WebBroker/DTDs.html I presented my >findings at the XML Conference in Seattle last week. A presentation slide >show is at http://xml.datachannel.com/public/presentation/XMLSeattle/ > In the slides, John hinted that there was progress in dataTyping XML. I am particularly interested in this and would like to know if this is likely to result in a re-usable protocol (or if not, whether we could pursue this on XML-DEV a la SAX). Historically this first surfaced from a proposal (I think) by Tim Bray - XML-TYPE (listed in XML-DEV), but became subsumed in XML-DATA. I would be pleased to see progress made along those lines, but don't want to have to implement the whole of the current draft for my purposes (numeric values in technical documents). In the same way as XLL has split into xptr and xlink, it could make sense to split XML-data into the primitive types and the structural part. IMO the primitive types would be very heavily re-used in XML applications and would prevent a fragmentation where everyone ends up defining FLOAT and so on in very slightly different incompatible ways. Now that we have (or will have) namespaces to separate these from everything else there should be nothing to stop this. It would be the most widely used re-usable set of XML information objects. [If this is already part of a formal W3C activity with milestones, please forgive my ignorance and lead me to it.] 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 James.Anderson at mecom.mixx.de Sun Mar 29 23:08:28 1998 From: James.Anderson at mecom.mixx.de (james anderson) Date: Mon Jun 7 17:00:20 2004 Subject: wd-namespaces (was Re: Important XML announcements Message-ID: <351EC68F.6E6A71DA@mecom.mixx.de> greetings, it is nice to see that the discussion on namespaces has reached wd status. i have four remarks on the document: I: the discussion regarding ambiguous names is too brief. in particular, it is not clear (given the restriction on "no fragments" in the namespace pi uri, how the multiple names spaces would be defined with reference to a single, integral schema. as i followed the document, '.'-qualified names appear for the first time at that point; i couln't figure out how they are expressed or interpreted. II: the discussion of the scope of the invocation of a namespace should be more thorough. i recall this issue being discussed at greater length in other documents on xml namespaces and miss it here. in particular, that the scope extends over the content of an opening tag, but not over the dependant elements, requires better treatment. the interpretation of unqualified attribute names is, for example, specified, but that for unqualified tag names was not to be found at the analogous location in the discussion. this distinction is unfortunate from the point of view of applying the standard, as is that between names for tags and those for entities. more discussion is required here. a more consistent semantic is no harder to implement, easier to understand, and more compact in expression. together with the restriction that entity names are always unqualified, it leads me to the belief that i won't be able to make cross-schema references to entity definitions. is that true? is that intended? III: w.r.t item D. > D. ... Given the extraordinary depth of the problem that the > specification begins to address, the importance of solving that > problem correctly, the lack of implementation experience in this area, > ... i note that this proposal (as did an earlier one) describes much the same mechanism as the package mechanism in common lisp (minus export/import/inter-package-inheritance). there is much useful experience to be drawn on there. > Persons wishing to make useful contributions to the public review of > the draft should confine their comments to pointing out broken places > in those mechanisms that the draft provides rather than suggesting > additional ones. the implementation of namespaces on the basis of packages in a cl-based implementation of an xml processor was quite straightforward. it suggests that the proposed namespace mechanism (though not "broken") could be made more complete, if it were kept simpler and uniform: 1. all unqualified tokens are interned into the package bound to the variable *package*. qualified tokens are interned into the package named by the qualification. this package must exist. 2. *package* is rebound at the start of each element entity to the package into which the element tag name has been interned. after the close tag for an element entity, *package* is returned to its previous binding. the qualification of the close tag could be optional, but i have found it to be a useful constraint. 3. external entities are read, with the exceptions of dtd entities, according to the current *package* binding. dtd entites are read as follows: a. a namespace pi creates a package with the specified name (the 'prefix' attribute from the spec) and rebinds *package* to that value while reading the dtd. b a doctype entity creates a package with the same name as the document type, and sets *package* to that value. the value thereby becomes the default package for the external dtd, for an internal dtd if one is present, and for the root document element. when reading a dtd, i've restricted all entity definition names to be unqualified, but that doesn't need to be. 4. any defined package inherits from the "XML" package, in which all standard tokens interned and from which they are exported. this mechanism makes references to all elements (including entities) of a given dtd very simple. it permits cross-dtd references. it is easy to implement and to understand because it is uniform. i have yet to see a naming example from the various documents on namespaces which could not be expressed given these semantics. no, it doesn't address the architectural examples, but then it's orthogonal to them. IV: the section on universal names is too brief. i understand, that such information would be a necessary in order to identify the origin of a name. what i don't understand is why one would need to do this. when i specify that tokens belong in different packages, it's because i want them to be different. the overhead of managing a directly available universal namespace seems at first reflection to be high for something i'd "never" do, but, i admit, i may well be shortsighted here. in my present implementation, the information is available indirectly through the package, to the dtd, to the dtd's uri, but i wouldn't call that a universal namespace. an example of the intended purpose would be very useful here - and necessary in order to judge how to best implement it. bye for now, james 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 peter at ursus.demon.co.uk Sun Mar 29 23:12:35 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:00:20 2004 Subject: Important XML announcements [from James Anderson] Message-ID: <3.0.1.16.19980329210600.38af900c@pop3.demon.co.uk> >Return-Path: > >greetings, >it is nice to see that the discussion on namespaces has reached wd status. > >i have four remarks on the document: > >I: the discussion regarding ambiguous names is too brief. > >in particular, it is not clear (given the restriction on "no fragments" in the >namespace pi uri, how the multiple names spaces would be defined with reference >to a single, integral schema. as i followed the document, '.'-qualified names >appear for the first time at that point; i couln't figure out how they are >expressed or interpreted. > >II: the discussion of the scope of the invocation of a namespace should be more >thorough. > >i recall this issue being discussed at greater length in other documents on xml >namespaces and miss it here. in particular, that the scope extends over the >content of an opening tag, but not over the dependant elements, requires better >treatment. the interpretation of unqualified attribute names is, for example, >specified, but that for unqualified tag names was not to be found at the >analogous location in the discussion. > >this distinction is unfortunate from the point of view of applying the standard, >as is that between names for tags and those for entities. more discussion is >required here. a more consistent semantic is no harder to implement, easier to >understand, and more compact in expression. > >together with the restriction that entity names are always unqualified, it leads >me to the belief that i won't be able to make cross-schema references to entity >definitions. is that true? is that intended? > >III: w.r.t item D. > >> D. ... Given the extraordinary depth of the problem that the >> specification begins to address, the importance of solving that >> problem correctly, the lack of implementation experience in this area, >> ... > >i note that this proposal (as did an earlier one) describes much the same >mechanism as the package mechanism in common lisp (minus >export/import/inter-package-inheritance). there is much useful experience to be >drawn on there. > >> Persons wishing to make useful contributions to the public review of >> the draft should confine their comments to pointing out broken places >> in those mechanisms that the draft provides rather than suggesting >> additional ones. > >the implementation of namespaces on the basis of packages in a cl-based >implementation of an xml processor was quite straightforward. it suggests that >the proposed namespace mechanism (though not "broken") could be made more >complete, if it were kept simpler and uniform: > >1. all unqualified tokens are interned into the package bound to the variable >*package*. qualified tokens are interned into the package named by the >qualification. this package must exist. >2. *package* is rebound at the start of each element entity to the package into >which the element tag name has been interned. after the close tag for an element >entity, *package* is returned to its previous binding. the qualification of the >close tag could be optional, but i have found it to be a useful constraint. >3. external entities are read, with the exceptions of dtd entities, according to >the current *package* binding. dtd entites are read as follows: > a. a namespace pi creates a package with the specified name (the 'prefix' >attribute from the spec) and rebinds *package* to that value while reading the >dtd. > b a doctype entity creates a package with the same name as the document type, >and sets *package* to that value. the value thereby becomes the default package >for the external dtd, for an internal dtd if one is present, and for the root >document element. when reading a dtd, i've restricted all entity definition >names to be unqualified, but that doesn't need to be. >4. any defined package inherits from the "XML" package, in which all standard >tokens interned and from which they are exported. > >this mechanism makes references to all elements (including entities) of a given >dtd very simple. >it permits cross-dtd references. >it is easy to implement and to understand because it is uniform. >i have yet to see a naming example from the various documents on >namespaces which could not be expressed given these semantics. no, it doesn't >address the architectural examples, but then it's orthogonal to them. > > >IV: the section on universal names is too brief. > >i understand, that such information would be a necessary in order to identify >the origin of a name. what i don't understand is why one would need to do this. >when i specify that tokens belong in different packages, it's because i want >them to be different. the overhead of managing a directly available universal >namespace seems at first reflection to be high for something i'd "never" do, >but, i admit, i may well be shortsighted here. in my present implementation, >the information is available indirectly through the package, to the dtd, to the >dtd's uri, but i wouldn't call that a universal namespace. >an example of the intended purpose would be very useful here - and necessary in >order to judge how to best implement it. > >bye for now, >james anderson > > > 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 Jon.Bosak at eng.Sun.COM Mon Mar 30 05:59:58 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:00:20 2004 Subject: RFC2318 In-Reply-To: <01bd59a6$09e52fa0$31addccf@uspppBckman> Message-ID: <199803300357.TAA11976@boethius.eng.sun.com> | I notice that the media type text/xml is not registered, or wll one just | stick with text/sgml ? The process of registering text/xml and application/xml is already underway. 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 alex.webb at staempfli.com Mon Mar 30 12:00:29 1998 From: alex.webb at staempfli.com (Webb Alex) Date: Mon Jun 7 17:00:20 2004 Subject: SX: Beginners question Message-ID: Hi, I have a (probably self-inflicted) problem with sx converting German/French sgml documents. All the 8-bit characters: ? (ä), ?(ö), and ?(ü), and the capital versions are all being converted to the same output string: "???". If I convert the 8-bit characters to the entity equivalents they are ignored and are not outputted to my target document. I have set the system variables as per the documentation, but no luck. Any help would be appreciated. Many thanks - Alex Webb Technical Consultant St?mpfli AG Grafisches Unternehmen xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk">mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Mar 30 18:41:00 1998 From: smith at interlog.com (Chris Smith) Date: Mon Jun 7 17:00:20 2004 Subject: Experimenting with Namespaces - DTDs? In-Reply-To: Message-ID: For those who either are experimenting or considering experimenting with namespaces - I'm curious how the related DTDs should look. The following fragment comes from ex.3 of the XML-Namespace WD, a work-in-progress. 80183589575795589189518915 My question is simply: what is the definition for "Order" ? I can see one easy possibility: However, this doesn't 'allow' the 'dsig:dsig' entry to appear. If you have a validating parser, this should (?) show up as an error. An alternative is: The problem here is that this is carte blanche to put ... well, ANYthing in there - even another . What could you reasonably see a validating parser expecting in order to allow namespaces (as above) without throwing your entire DTD structure out the window? Basically, I want to tell the parser 'here there can be other stuff, but none of mine'. Occasionally, I may want something more sophisticated, along the lines of 'here there can be anything that isn't from my DTD, and in addition these few items from my DTD'. This would provide for controlled inclusion of 'Manifest' (above) inside 'Order'. And, ideally, I can provide this info in my DTD **before** I know what other DTDs are to be namespaced into mine. This means I can't explicitly include it via Any ideas? --------------------------------------------------------------------------- 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 ak117 at freenet.carleton.ca Mon Mar 30 19:10:55 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:00:20 2004 Subject: Experimenting with Namespaces - DTDs? In-Reply-To: References: Message-ID: <199803301710.MAA01121@unready.microstar.com> Chris Smith writes: > For those who either are experimenting or considering experimenting > with namespaces - I'm curious how the related DTDs should look. > > The following fragment comes from ex.3 of the XML-Namespace WD, a > work-in-progress. > > > > 80183589575795589189518915 > > My question is simply: what is the definition for "Order" ? You would have to do something like this: The Namespace WD does not propose any DTD changes, and the only existing spec for XML is the 1.0 REC -- making any changes to that would require a whole new process. It is entirely possible that a standardised, higher-level schema language will emerge in the future; however, when you convert your schema to an XML 1.0 DTD for exchange, the DTD will have to have all of the relevant element type names and attribute names prefixed. The DTD syntax could, of course, change in future versions of XML, depending on what the XML WG and the W3C decide. All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com http://home.sprynet.com/sprynet/dmeggins/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Mar 30 19:46:02 1998 From: paul.foster at bt-sys.bt.co.uk (Paul Foster) Date: Mon Jun 7 17:00:20 2004 Subject: XML DTD Syntax - A burning question Message-ID: Hi, Like most people when they first subscribe to a new mailing list it is because they have a burning question they cant answer themselves. I am no exception. My question regards the DTD syntax for Element Content as defined in Section 3.2.1 of the XML V1.0 specification. The '*' character following an element name implies that the element can occur zero or more times, '+' indicates it can occur one or more times. But, what happens in the unlikely event that I want to specify that the element occurs exactly 50 times, or upto 50 times. Is there a short cut way of doing it or do I have to write the element name out 50 times. I suppose the same question applies to the XML-Data spec wrt the 'OCCURS=' property. Kind 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 eliot at isogen.com Mon Mar 30 20:00:57 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:00:20 2004 Subject: XML DTD Syntax - A burning question Message-ID: <3.0.32.19980330115616.006a2720@swbell.net> At 06:45 PM 3/30/98 +0100, Paul Foster wrote: >The '*' character following an element name implies that the element >can occur zero or more times, '+' indicates it can occur one or more >times. But, what happens in the unlikely event that I want to specify >that the element occurs exactly 50 times, or upto 50 times. Is there a >short cut way of doing it or do I have to write the element name out 50 >times. Yes, you have to write it out 50 times. The ability to specify a numeric occurrence indicator has long been discussed as something to add as part of the SGML revision. Of course, it's easy to write a validation program that simply counts the number of occurrences to see if they exceed 50. When thinking about these issues, it's important to keep in mind that no matter how much DTD syntax is extended, or how much funtionality you put into some other schema language, for non-trivial uses of XML, there will almost always be things that need to be validated that can only be validated by specialized processors. Thus, you can expect to always have to write some form of "validation application" to do whatever validation you don't get for free from your parser or schema-specific processor. Given that, the cost of adding frills like numeric occurrence to SGML or XML may outweigh the general benefit. Revising standards has a very high cost, both in terms of the time of the people who do it and the potential for breakage. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer Highland Consulting, a division of ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 95202. 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 amarshal at usc.edu Mon Mar 30 20:07:00 1998 From: amarshal at usc.edu (Andrew n marshall) Date: Mon Jun 7 17:00:20 2004 Subject: FW: Comments on Section 2.6 of XML-Namespaces Message-ID: <01BD5BC4.79E7BD70.amarshal@usc.edu> Andrew n marshall student - artist - programmer http://www.media-electronica.com/anm-bin/anm "Everyone a mentor, Everyone a pupil" -----Original Message----- From: Andrew n marshall [SMTP:amarshal@usc.edu] Sent: Sunday, March 29, 1998 8:32 AM To: 'tbray@textuality.com'; 'dmh@corp.hp.com'; 'andrewl@microsoft.com' Cc: 'XML-L@LISTSERV.HEA.IE' Subject: Comments on Section 2.6 of XML-Namespaces In section 2.6 of your initial draft of XML Namespaces you comment on the possible ambiguity of specifying a namespace for an element's attribute, where more than one element may hold that attribute. I find this notation to be problematic and not useful. Beginning with your first example: Sudden death may ensue. While you point out that this there is no grammatical or conceptual errors here since all HTML elements define the class attribute, there is no guarantee from the DTD that they mean the same thing in use. While it happens that they do mean the same thing in HTML, allowing this namespace syntax fails to resolve the ambiguity on mean in other possible XML applications. Even in your attempt to rectify this situation with the syntax used in your last example: You still provide no guarantee that there is a meaning for the attribute 'Temp' without possible sibling attributes. Take for example: Does the use of href have any meaning without the 'target' attribute which may be implicitly be defined with the default value of '_self'? Probably not. Therefore does it make sense to pull an attribute out of its normal context? Probably not. For these reason, I suggest that namespaces specification limit itself to the namespaces of elements, which have well defined meanings and can be validated against their appropriate DTDs. The attempts to solve the above problems should left up to the next version of XML which will hopefully define a way to describe attribute inheritance between element types and abstract element definitions. Such a scheme will allow the reuse attributes without the above ambiguities in meaning. Andrew n marshall student - artist - programmer http://www.media-electronica.com/anm-bin/anm "Everyone a mentor, Everyone a pupil" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amarshal at usc.edu Mon Mar 30 20:07:07 1998 From: amarshal at usc.edu (Andrew n marshall) Date: Mon Jun 7 17:00:20 2004 Subject: Experimenting with Namespaces - DTDs? Message-ID: <01BD5BC4.7B82CFD0.amarshal@usc.edu> On Monday, March 30, 1998 8:40 AM, Chris Smith [SMTP:smith@interlog.com] wrote: . . . SNIP . . . > However, this doesn't 'allow' the 'dsig:dsig' entry to appear. If you > have a validating parser, this should (?) show up as an error. I've been looking at the namespace spec and have come to beleive that it cannot be wholly useful until mean for element inheritance is developed. If that was the case, then it should be possible to create a new element that inherits the syntax AND the use of elements from other namespaces. In addition, I think the namespace issue has problems when an application attempts to pull attributes out from their original context, a particular element in another namepsace, and use them somewhere else. I will repost my letter I wrote to the authors of the namespace spec to the xml-dev listserv. Andrew n marshall student - artist - programmer http://www.media-electronica.com/anm-bin/anm "Everyone a mentor, Everyone a pupil" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mar 31 01:05:33 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:00:20 2004 Subject: Proposed extensions to SAX Message-ID: I'm thinking of adding some methods to the Python version of SAX and feedback from the Python list indicates that I should propose that it be added to the main SAX interface, so here goes: Proposed changes: Creating a SAX interface in the SAX module with these methods: - sax_version, returns the version number of the SAX version implemented - saxlib_version, returns the version number of the SAX implementation - create_parser, returns a parser (see below for how the method decides which parser to return) - get_parser_list, returns a list of the parsers in the order they will be tried by create_parser. The first parser on the list that is present will be returned. (Any SAX implementation must have a predetermined default list.) - set_parser_list, lets the user decide parser priority - get_present_parsers, returns a list of the parsers that are actually present. (May be difficult to implement in Java (and other languages), but should be pretty straightforward in Python. This method should therefor be allowed to return None/null/nil if it isn't supported.) Adding two methods to the parser interface: - parser_name, returns the name of the parser used (to allow users to check which parser they are using) - parser_version, returns the parser version number Rationale: I think these extensions give users a simple and standardized way to control which parser is used and also to detect this, in order to handle differing versions and their differences in XML support and bugs. The package methods should only be implemented once for each language and should be fairly simple to implement. They can also be kept apart in the documentation, so as to not clutter the API for those who don't need/want these features. The parser methods should be trivial to implement and shouldn't clutter the interface too much. If this goes through a naming scheme should be decided for parsers. I think the class name (with full package name) should be used, in order to avoid confusion and also for backward compatibility. It would also give a simple way of distinguishing between the validating and non-validating versions of parsers that have different classes for this. (Any that don't?) (And, yes, the method names should perhaps be changed to something a bit more Java-like. :) -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Mar 31 08:05:29 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:00:20 2004 Subject: Comments on Section 2.6 of XML-Namespaces Message-ID: <002f01bd5c6b$2bbc2ad0$7e0b4ccb@NT.JELLIFFE.COM.AU> -----Original Message----- From: Andrew n marshall > While you point out that this there is no grammatical or conceptual errors > here since all HTML elements define the class attribute, there is no > guarantee from the DTD that they mean the same thing in use. While it > happens that they do mean the same thing in HTML, allowing this namespace > syntax fails to resolve the ambiguity on mean in other possible XML > applications. I think it is important to know that the namespace mechanism does not attempt to solve all problems with sticking names into schemas. All it does is bundle names with a comon prefix into a bag with a name (the "ns" attribute") and then point to some other resource which may contain some interesting information about the schema. Most elements and attributes belong to multiple schemas. This is both because no one schema language is good enough to define all the requirements that any single type has, and because of the symphonic, interrelated nature of the use of elements in documents. So the namespace mechanism does not attempt to provide a general solution to all these problems. If you are interested in such a thing, then the HyTime architectural forms mechanism may be of interest to you. (See http://www.ornl.gov/sgml/wg8/docs/n1920/html/toc.html ) It is a far more general solution to a fairly similar problem. The namespace mechanism as proposed is a minimal and modest thing, just enough to allow RDF and some other applications to progress, and to allow debate and exploration of the particular issues. As for as your particular example goes, there is "no guarantee from the DTD that they mean the same thing" because there is no mechanisms built into raw XML DTDs to provide such a guarantee: in fact this is why namespaces are needed--to make it clear that an attribute in one element type is kin to another. And in any case, in your particular case of hrefs, the XLink draft provides an attribute remapping feature. So an href element * is attached to its element type in the Instance (& DTD) * is bound to a namespace by its prefix and the namespace PI * may be remapped to a different name by the Xlink xml:attribute attribute * may have additional schemas and semantics added using the Architectural Forms Deinition Rquirements AFDR mechanism (See http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html ) which uses fixed attributes on the DTD in particular. (Architecture = schema) In this example (dashed off, apologies if there is an error) the my:href attribute will have some syntax or semantics determined by its element type "x", some from its namespace "my", some from its role as a simple XLink, and some from it being an alias to ""your:href" in the schema "your-schema". This should not be confusing--it shows that XML offers a great degree of richness, and that there are several ways of skinning the same cat. In the usual case, the connection with the namespace of the element type is enough. In some general cases, like XLink, there will need to be both a general mechanism for specifying the semantics of an attribute (.e.g xml:attribute) and a way to specialize this in an element-type independent way (e.g. namespaces). And finally, some particularly rich kinds of data may need to have multiple schemas specified...the HyTime AFDR mechanism is there for this. This gives a nice hierarchy of techniques to use from simplest to most complex. 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 smith at interlog.com Tue Mar 31 23:05:06 1998 From: smith at interlog.com (Chris Smith) Date: Mon Jun 7 17:00:20 2004 Subject: Experimenting with Namespaces - DTDs? In-Reply-To: <199803301710.MAA01121@unready.microstar.com> Message-ID: On Mon, 30 Mar 1998, David Megginson wrote: > Chris Smith writes: > > > > > > > 80183589575795589189518915 > > > > My question is simply: what is the definition for "Order" ? > > You would have to do something like this: > > > > I must admit I had considered this, but had rejected it since it seemed to require that each DTD exist before the other DTD. In addition, it hardly seemed reasonable for something as general as dsig: to know - in the DTD - about all its uses. (This is why I thought that the use of ANY or #PCDATA might be a way to facilitate the experiments.) > The Namespace WD does not propose any DTD changes, and the only > existing spec for XML is the 1.0 REC -- making any changes to that > would require a whole new process. As a developer I don't want them to make lots of changes - I prefer a stable standard. But also as a developer, this seems to make this almost impossible to even experiment with namespaces. As far as I can tell, DTDs are what give you the ability to eXtend XML - without a comparable tool involving namespaces, I can't specify what the eXtension is. The notes suggest that changes to Namespaces are unlikely (not impossible, just...). But changes to XML 1.0 also appear to be unlikely in the near future. The only option available seems to be to ignore Namespaces, since I can't find a way to use them that will give me any benefits that XML hasn't already given me - unless I start to abandon XML 1.0 in favour of a non-existent-non-standard XML 1.1 that has a namespace aware DTD notation. Possibly I have an unreasonable expectation? Namely, that I can provide a DTD that makes use of 'plugged-in' DTDs from other domains - but without requiring that I know this or rewrite the DTD? If I rewrite the DTD every time I extend it, I don't see that much more than the most basic of XML browsing tools will be able to handle the resulting document. --------------------------------------------------------------------------- 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 ak117 at freenet.carleton.ca Tue Mar 31 23:27:51 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:00:20 2004 Subject: Experimenting with Namespaces - DTDs? In-Reply-To: References: <199803301710.MAA01121@unready.microstar.com> Message-ID: <199803312127.QAA00299@unready.microstar.com> Chris Smith writes: > But also as a developer, this seems to make this almost impossible to > even experiment with namespaces. As far as I can tell, DTDs are what > give you the ability to eXtend XML - without a comparable tool > involving namespaces, I can't specify what the eXtension is. The notes > suggest that changes to Namespaces are unlikely (not impossible, > just...). But changes to XML 1.0 also appear to be unlikely in the > near future. The only option available seems to be to ignore > Namespaces, since I can't find a way to use them that will give me any > benefits that XML hasn't already given me - unless I start to abandon > XML 1.0 in favour of a non-existent-non-standard XML 1.1 that has a > namespace aware DTD notation. There is another (somewhat unattractive) option: you can use your own schema notation internally, then export it as an XML 1.0 DTD for exchange. As Jon Bosak explained in his announcement, the namespace spec was brought out very quickly because other efforts like RDF had a dependency on it -- ideally, it would have waited six months or a year until there was time to deal with schemas, etc., but that wasn't possible. Personally, I'd recommend architectural forms over namespaces if you're concerned with DTDs, since architectural forms have several major advantages: 1. they work very well with XML 1.0 DTD syntax 2. they allow multiple inheritance 3. they allow you to hide the namespaces from the author (unless the author cares to poke around in #FIXED attribute values) 4. they are allowed to be declared in the external DTD subset 5. they are a more mature technology 6. they are part of an International Standard Namespaces may or may not become more useful in the future, depending on what the XML WG decides about schemas -- for now, they make a very awkward fit with XML 1.0 DTDs (they work, but as you say, they don't give you much). All the best, David -- David Megginson ak117@freenet.carleton.ca Microstar Software Ltd. dmeggins@microstar.com http://home.sprynet.com/sprynet/dmeggins/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)