From mrc at allette.com.au Tue Sep 1 02:32:23 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:04:17 2004 Subject: Validating IDREFS... References: <01BDD40A.50BDF630@wingate> Message-ID: <35EB406E.1D9BA771@allette.com.au> Attila Torcsvari wrote: > Recently I wanted to make more checkable my SGML/XML source, > and I have similar troubles mentioned on this thread. > What should I do if my IDs and IDREFs contain non-name characters? Why is it so?! > (My pages should be reachable for external databases, which use identifiers with the same syntax, so I can not just convert the values to something else.) With SGML it's easy - you just need to extend the SGML declaration to allow the characters to be valid name characters. With XML, the only thing I can think of off hand is to define the attributes as CDATA rather than ID/IDREF and write something to check that the values match up, possibly as a post process. ID/IDREF processing can't be resolved until the end of the document has been reached anyway, so this might not be a huge disadvantage. -- 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 stevew at access.com.au Tue Sep 1 09:52:02 1998 From: stevew at access.com.au (Steve Withall) Date: Mon Jun 7 17:04:17 2004 Subject: ANNOUNCEMENT: XML Testbed software Message-ID: <3.0.5.32.19980901174220.007f69e0@mail.access.com.au> I am pleased to announce the release of an XML application environment written in Java which I have been developing over the last eleven months or so - as presented at the recent Montreal XML Developers' Conference. For historical reasons it's called 'XML Testbed', but there's now more to it that that. The software uses an XML configuration file to define the (Swing-based) user interface. It includes its own non-validating XML parser (though it can use any SAX parser instead), a nascent XSL engine (to the old standard - just in time to be out of date), and a few other odds and ends. The key feature of the infrastructure is that it is intended to be easily expandable, to allow application-specific functionality to be slotted in dynamically. This is achieved by registering the classes to be instantiated for given named elements, and invoking special behaviour in a generic way by invoking a method called verify() on each element as soon as it has been parsed. The software is freely available for non-commercial use and can be downloaded, with all source code, from the following sites: http://www.xml.com http://www.w3.org/XML/#9808withall http://www.gca.org/conf/xmldev98 (soon!) Please don't hesitate to send me any comments you may have - criticisms, suggestions, anything. I'd like to thank xml.com, W3C and GCA for being so kind as to host this software. Thanks also to my employer, Access Systems, for being so tolerant in allowing me to pursue this activity, which is an independent, personal endeavour. Enjoy! Steve Withall. ________________________________________________________________________ Steve Withall Systems Architect Tel: 61 2 9957 1036 Access Systems Research Pty. Limited Fax: 61 2 9959 5111 Level 10, 20 Berry Street North Sydney NSW 2060 Email: stevew@access.com.au Australia http://www.access.com.au xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 10:39:37 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:04:17 2004 Subject: Validating IDREFS... Message-ID: <005401bdd584$93b73a20$1e09e391@mhklaptop.bra01.icl.co.uk> >The whole point of ID and IDREF is to have a simple intra-document >link, so that documents that have non-hierarchical natural structures >can be fitted into SGML/XML hierarchies Indeed so. And the real difficulty with them is not the inconvenience to parser writers, but the fact that they are incompatible with XPointer. 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 Tue Sep 1 11:06:24 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:04:17 2004 Subject: ANN: New SAXON Release (3.03) Message-ID: <00da01bdd588$4d500400$1e09e391@mhklaptop.bra01.icl.co.uk> A new version of SAXON (3.03) is available for download at http://home.iclweb.com/icl2/mhkay/saxon.html SAXON is a java class library that sits on top of a SAX-compliant XML parser, providing additional services to aid document manipulation and transformation. In general it is designed to help you write applications that need to process a *specific* document type, rather than for general-purpose XML tools. The distribution includes as a sample application DTDGenerator, a tool that takes an XML document as input and produces as output a DTD to which it conforms. Principal changes in this version: * Improved mechanisms for performing multiple document passes when using the DOM * Improved ParserManager for controlling which SAX parser to use (now uses a Java properties file and incorporates a starter list of known parsers) * Updated to work (optionally) with Docuverse DOM-SDK. (The previous unannounced version 3.01 worked with Free-DOM 3 and was on the web for fully three hours before Don Park announced the replacement of Free-DOM by DOM-SDK. Is this a record for software obsolescence?) There are two classes included in SAXON which are free-standing and which can probably add value to any SAX application: - ParserManager, which allows you to maintain a list of installed parsers and to control which one should be instantiated - ExtendedInputSource, which subclasses the SAX InputSource class to allow a java File to be supplied as the XML source Terms of use have not changed: essentially free to use but not to include in a commercial product. Source is included. If you find SAXON useful, please let me know, it tells me my time was not wasted! Thanks to the correspondents, whose names I have forgotten, who suggested the improvements in this version. Michael Kay M.H.Kay@eng.icl.co.uk ICL Electronic Business Services xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From David.Rosenborg at xsse.se Tue Sep 1 11:08:14 1998 From: David.Rosenborg at xsse.se (David Rosenborg) Date: Mon Jun 7 17:04:17 2004 Subject: XML ATTRIBUTES : Are they attribute Names or Type Names? References: <199808311925.OAA21202@foyt.indyrad.iupui.edu> Message-ID: <35EBB8FB.B159989@xsse.se> Hi, Yes, this is exactly what I'm aiming at. Mark Tucker wrote: > > Hi David, > > I'm not sure what you said about typenames and attribute > names, but I wonder if it is this problem. XML ELEMENT names are > confused about whether they are acting as programming language "type > names", or as programming language "field names". [snip] > -- type > -- field > -- type > 3 -- field > 4 > > ... > In a strongly typed system you could also write it like this 34 ... And the fact that lower-left is of type point would be expressed in the schema. I guess that architectural forms provide the basic machinery to express these relations at the XML level (that is structurally), but I would also like to formally express the relations of types and names in the application level with some schema. Cheers, ___________________________________________________________________ David.Rosenborg@xsse.se OM Exchange Technology xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 12:15:37 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:04:17 2004 Subject: XML-QL Message-ID: <00e501bdd591$faef4180$1e09e391@mhklaptop.bra01.icl.co.uk> >I just discovered the XML Query Language proposal at >http://www.w3.org/TR/NOTE-xml-ql/, and find it very interesting. It looks >a lot like SQL, which could be handy, but also somewhat limiting. What do >you'all think about it? Thanks for drawing this to my attention. My immediate reaction is to compare this not with SQL, but with the new XSL "tree construction" facilities which essentially provide an XML transformation language. I don't have time to do a detailed point-by-point comparison but it would certainly be a useful exercise. Conceptually they have many similarities but there are many points of detail where one is stronger than the other. I would think it is entirely possible to devise a language that combines the power of both without a significant loss of usability. Generally XSL seems more oriented to the "document" paradigm (an XML stream consists of sequential content interspersed with markup) while XML-QL is more oriented to the "data" paradigm (an XML stream is a serialisation of a database). So XML-QL has much better facilities for operations such as sort, join, aggregation, and IDREF dereferencing, while XSL is stronger on detecting patterns based on ordering of input elements (e.g. the first-of-type() predicate). Both proposals seem to concentrate primarily on transforming the structure of the tree, with little emphasis on transforming the character strings in its leaf nodes; neither seems to be capable of doing something as elementary as converting an attribute value to upper case. Also, neither has matching operators oriented to free text searching, e.g. linguistic word matching. 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 Sep 1 12:21:56 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:17 2004 Subject: New SAXON Release (3.03) Message-ID: <001001bdd590$f52b3b60$2ee044c6@arcot-main> >A new version of SAXON (3.03) is available for download at >http://home.iclweb.com/icl2/mhkay/saxon.html Great. >(The previous unannounced version 3.01 worked with Free-DOM >3 and was on the web for fully three hours before Don Park >announced the replacement of Free-DOM by DOM-SDK. Is this a >record for software obsolescence?) Well, you did it to me this time because I was about to release the PR2 version of the DOM SDK when I saw your announcement. I am going to delay the release to make sure it works with SAXON 3.03. For your information, PR2 includes the HTML layer support (lots of typing folks). Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ruchig at iitk.ac.in Tue Sep 1 15:22:33 1998 From: ruchig at iitk.ac.in (ruchig) Date: Mon Jun 7 17:04:18 2004 Subject: New SAXON Release (3.03) In-Reply-To: <001001bdd590$f52b3b60$2ee044c6@arcot-main> Message-ID: Really Great. Thanks Don. Regards Ruchig On Tue, 1 Sep 1998, Don Park wrote: > >A new version of SAXON (3.03) is available for download at > >http://home.iclweb.com/icl2/mhkay/saxon.html > > > Great. > > >(The previous unannounced version 3.01 worked with Free-DOM > >3 and was on the web for fully three hours before Don Park > >announced the replacement of Free-DOM by DOM-SDK. Is this a > >record for software obsolescence?) > > > Well, you did it to me this time because I was about to release the PR2 > version of the DOM SDK when I saw your announcement. I am going to delay > the release to make sure it works with SAXON 3.03. For your information, > PR2 includes the HTML layer support (lots of typing folks). > > Best, > > Don Park > Docuverse > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amitr at abinfosys.com Tue Sep 1 15:26:04 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:04:18 2004 Subject: Is there a size limitation on XML file given to MSXSL as input? Message-ID: <011601bdd5ac$a4a79820$0101a8c0@server.abinfosys.com> Hello, ENVIRONMENT :- Web Browser :- IE 4.01 XSL Processor :- MSXSL ActiveX Control Is there a restriction on the size of the XML file I give as input to the MSXSL ActiveX control? I am using the MSXSL ActiveX control to display a XML file using the following :- . . . (***) . . . PROBLEM Now when I give the documentURL property of the MSXSL (see *** above) an XML file (say test.xml) which contains a large amount of data (say about 100-150 instances each element) , MSXSL does not render the XML file (test.xml). Infact IE 4.01 hangs! QUESTIONS 1) Is there a limitation on the amount of XML elements that can be present in a XML file given as input to the MSXSL processor? 2) If so what is it? 3) If there exists a length limitation then ,how to send XML files containing large amounts of data to MSXSL ActiveX control? Any help would be appreciated, Thanks in advance, AMIT REKHI Software Engineer, A.B. Infosys. P. Ltd, New Delhi, INDIA. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Sep 1 15:38:04 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:04:18 2004 Subject: XML-QL References: <00e501bdd591$faef4180$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <35EBF5E5.1BB74120@technologist.com> Michael Kay wrote: > > My immediate reaction is to compare this not with SQL, but > with the new XSL "tree construction" facilities which > essentially provide an XML transformation language. I don't > have time to do a detailed point-by-point comparison but it > would certainly be a useful exercise. It would also be useful to compare XPointer, which is a sort of query that returns a single node. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Everything I touch turns into Python. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Tue Sep 1 16:45:28 1998 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:04:18 2004 Subject: Is there a size limitation on XML file given to MSXSL as input? In-Reply-To: <011601bdd5ac$a4a79820$0101a8c0@server.abinfosys.com> Message-ID: <199809011442.QAA29400@sonne.darmstadt.gmd.de> Amit Rekhi wrote at 1 Sep 98, 18:26: > Is there a restriction on the size of the XML file I give as input > to the MSXSL ActiveX control? > I am using the MSXSL ActiveX control to display a XML file using the > following :- I used systematically tested free XML tools and found many of them choking on large input. Especially IE5b1 seems to have a crash- guarantee when dealing with > 25.000 elements. The most common death is exponential time consumption while garbage collecting string fragments. Many Java-based tools suffer from that. My afterall impression is that most available tools do well with toy examples, but any input being in the MB range easily blasts them. At least that's true for what came from MS so far. > 1) Is there a limitation on the amount of XML elements that can be present > in a XML file given as input to the MSXSL processor? There is a way in SGML, namely SGML declarations. Maybe that wasn't an all-so-bad idea. Vendors should publish formal declarations for the capacity of their products. ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Tue Sep 1 17:20:26 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:04:18 2004 Subject: Validating IDREFS... In-Reply-To: <005401bdd584$93b73a20$1e09e391@mhklaptop.bra01.icl.co.uk> (M.H.Kay@eng.icl.co.uk) Message-ID: <199809011518.LAA19289@ruby.ora.com> [Michael Kay] > >The whole point of ID and IDREF is to have a simple intra-document > >link, so that documents that have non-hierarchical natural > >structures can be fitted into SGML/XML hierarchies > > Indeed so. And the real difficulty with them is not the > inconvenience to parser writers, but the fact that they are > incompatible with XPointer. That's not true. XPointer doesn't explicitly provide support for IDREFs, but it doesn't need to, since they are built in to XML itself. And it's not clear what you meant by "they", but IDs are at the heart of robust use of XPointer. The first XSL draft provides a way, using the link and link-end-locator formatting objects, to turn IDREFs into links using XPointers. -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 papresco at technologist.com Tue Sep 1 17:27:47 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:04:18 2004 Subject: Validating IDREFS... In-Reply-To: <199809011518.LAA19289@ruby.ora.com> Message-ID: On Tue, 1 Sep 1998, Chris Maden wrote: > The first XSL draft provides a way, using the link and > link-end-locator formatting objects, to turn IDREFs into links using > XPointers. Terminological nit: A particular element either is or is not a link. Link-ness is as inherent as paragraph-ness or title-ness. XSL provides a way to format links (and other elements) as clickable hotspots. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Sep 1 17:36:37 1998 From: jonathan at texcel.no (Jonathan Robie) Date: Mon Jun 7 17:04:18 2004 Subject: XML-QL In-Reply-To: <00e501bdd591$faef4180$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <3.0.3.32.19981031113623.00c537c0@pop.mindspring.com> At 11:19 AM 9/1/98 +0100, Michael Kay wrote: >My immediate reaction is to compare this not with SQL, but >with the new XSL "tree construction" facilities which >essentially provide an XML transformation language. I don't >have time to do a detailed point-by-point comparison but it >would certainly be a useful exercise. Conceptually they have >many similarities but there are many points of detail where >one is stronger than the other. I would think it is entirely >possible to devise a language that combines the power of >both without a significant loss of usability. In fact, at Metastructures 98 I presented a language called XQL that uses a syntax very similar to XSL Patterns. This language was developed primarily by Joe Lapp of webMethods and me. Like XML-QL, XQL is declarative. One of the significant differences between XML-QL and XQL is that XQL can do both hierarchy and sequence. The fundamental structural relationships in XQL are: o hierarchy o parent/child o ancestor/descendant o sequence o precedes o immediately precedes o position o subscripts o ranges I think sequence is pretty important in documents, though it is not important in many data-oriented systems. XML-QL's heritage in relational theory has caused it to ignore sequence. 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 lisarein at finetuning.com Tue Sep 1 18:02:48 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:18 2004 Subject: XML-QL References: <3.0.3.32.19981031113623.00c537c0@pop.mindspring.com> Message-ID: <35EC23CB.9C589B4D@finetuning.com> Jonathan: We can sink our teeth into this elusive spec so we can compare them head to head? Is there a URL available? I'm doing a query language round up for xml.com So far I've got: SQL (of course) XPointer XML-QL XQL? Appel... more? thanks everybody, lisa Jonathan Robie wrote: > > At 11:19 AM 9/1/98 +0100, Michael Kay wrote: > > >My immediate reaction is to compare this not with SQL, but > >with the new XSL "tree construction" facilities which > >essentially provide an XML transformation language. I don't > >have time to do a detailed point-by-point comparison but it > >would certainly be a useful exercise. Conceptually they have > >many similarities but there are many points of detail where > >one is stronger than the other. I would think it is entirely > >possible to devise a language that combines the power of > >both without a significant loss of usability. > > In fact, at Metastructures 98 I presented a language called XQL that uses a > syntax very similar to XSL Patterns. This language was developed primarily > by Joe Lapp of webMethods and me. Like XML-QL, XQL is declarative. > > One of the significant differences between XML-QL and XQL is that XQL can > do both hierarchy and sequence. The fundamental structural relationships in > XQL are: > > o hierarchy > > o parent/child > o ancestor/descendant > > o sequence > > o precedes > o immediately precedes > > o position > > o subscripts > o ranges > > I think sequence is pretty important in documents, though it is not > important in many data-oriented systems. XML-QL's heritage in relational > theory has caused it to ignore sequence. > > 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 lisarein at finetuning.com Tue Sep 1 18:13:16 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:18 2004 Subject: XML-QL References: <3.0.3.32.19981031113623.00c537c0@pop.mindspring.com> <35EC23CB.9C589B4D@finetuning.com> Message-ID: <35EC2633.5531F7C6@finetuning.com> Henry I am a little confused about perceiving XSL as a query language. It was my understanding that it aims to be a transformation language, like DSSSL, that works with a query or scripting language to transform/process and format data. Am I confused again :-)? thanks, lisa Henry S. Thompson wrote: > > I'd hope you will include the XSL query language > (http://www.w3.org/TR/1998/WD-xsl-19980818#AEN310) and the LT-query, > the query language from LT XML, our toolkit: > http://www.ltg.ed.ac.uk/corpora/xmldoc/release/c335.htm > > Cheers > > 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 lisarein at finetuning.com Tue Sep 1 18:15:36 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:18 2004 Subject: xsl query or transformation language Message-ID: <35EC2682.EB9C9E38@finetuning.com> hey sorry about that I should have started a new thread. Henry Thompson suggested XSL for my query language roundup, and, well you know the rest... lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Sep 1 18:27:51 1998 From: jlapp at webMethods.com (Joe Lapp) Date: Mon Jun 7 17:04:18 2004 Subject: xsl query or transformation language Message-ID: <3.0.32.19980901122818.006cc2d4@gw1.webmethods.com> At 09:53 AM 9/1/98 -0700, Lisa Rein wrote: >hey sorry about that I should have started a new thread. > >Henry Thompson suggested XSL for my query language roundup, and, well >you know the rest... I suspect that he was referring to the pattern language portion of XSL -- the match and selection strings. XSL patterns is an excellent query language; be sure to cover it. -- Joe Lapp, Senior Engineer | jlapp@webMethods.com webMethods, Inc. | Voice: 703-267-1726 http://www.webMethods.com | Fax: 703-352-0370 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Tue Sep 1 18:30:11 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:04:18 2004 Subject: xsl query or transformation language In-Reply-To: Lisa Rein's message of Tue, 01 Sep 1998 09:53:22 -0700 References: <35EC2682.EB9C9E38@finetuning.com> Message-ID: Lisa Rein writes: > Henry I am a little confused about perceiving XSL as a query language. > It was my understanding that it aims to be a transformation language, > like DSSSL, that works with a query or scripting language to > transform/process and format data. Well, XSL defines its own query syntax for walking the input document tree, a) for the purposes of deciding which style rules to apply to which input document components (in which case you should think of a query as returning a 'yes this matches' or a 'no this doesn't match' result when applied to a node in the tree; b) for the purposes of finding one or more bits of the tree to process next, given a starting point (the node we're processing now), in which case you should think of a query as returning a set of nodes in the tree given a starting point. A variant of type (b) where you just want the first element of the set occurs as well. Sounds like what I mean by a query language, how about you? 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 david at megginson.com Tue Sep 1 19:07:11 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:18 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) In-Reply-To: <199809011442.QAA29400@sonne.darmstadt.gmd.de> References: <011601bdd5ac$a4a79820$0101a8c0@server.abinfosys.com> <199809011442.QAA29400@sonne.darmstadt.gmd.de> Message-ID: <199809011655.MAA00993@unready.megginson.com> Ingo Macherius writes: > My afterall impression is that most available tools do well with > toy examples, but any input being in the MB range easily blasts > them. At least that's true for what came from MS so far. I don't think that that's true in general. Most of the Java-based XML parsers I've tried seem to be able to handle Jon Bosak's XML Old Testament (nearly 4MB) just fine, if somewhat slowly -- I used ot.xml for routine testing and profiling while developing AElfred, and AElfred barely kicked up a sweat. The problem comes if the parser tries to build a tree rather than simply reporting an event stream. Depending on the implementation, document trees tend to be very large. With a naive tree implementation, a 10MB document might use 100MB or more of virtual memory for the document tree -- that'll bring most current desktop systems to a screeching halt. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Tue Sep 1 19:22:27 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:04:18 2004 Subject: Validating IDREFS... Message-ID: <013601bdd5cd$9e1c2ae0$1e09e391@mhklaptop.bra01.icl.co.uk> MK>> ... the real difficulty with [IDREFs] is ... the fact that they are MK>> incompatible with XPointer. > Chris Maden>That's not true. I can use either an IDREF or an XPointer (within an XLink, or otherwise) to define a reference by ID to another element in the same XML document, but there are differences: * The syntax is different ["idval" versus "ID(idval)" or "#idval"] * I can have several IDREF attributes in an element, but only one XLink attribute * A dangling IDREF is an error; a dangling XPointer is not That is what I mean by saying the two facilities are incompatible. Or to put it another way, once I have made a design choice to use IDREF or to use XPointer for the links in my documents, I am stuck with my choice. This is one of several situations in the XML family of standards where there is more than one way of doing the same thing, and no obvious way to choose between them. As the frequency of questions about the element-vs-attribute choice shows, this confuses users no end; it also complicates software tools. MK xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 19:46:48 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:18 2004 Subject: Validating IDREFS... References: <013601bdd5cd$9e1c2ae0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <35EC3C2F.3C5FC7FC@finetuning.com> Aren't these the kinds of inconsistencies that need to be "normalized" (for lack of a better word) so that you could interoperate more easily with disparate systems irregardless of which technique they chose? In a perfect world, let's say, you can run a script and convert IDREF attributes to their XPointer equivalents, yes? Otherwise I sense danger! Danger will robinson! lisa Michael Kay wrote: > > MK>> ... the real difficulty with [IDREFs] is ... the fact > that they are > MK>> incompatible with XPointer. > > > Chris Maden>That's not true. > > I can use either an IDREF or an XPointer (within an XLink, > or otherwise) to define a reference by ID to another element > in the same XML document, but there are differences: > > * The syntax is different ["idval" versus "ID(idval)" or > "#idval"] > * I can have several IDREF attributes in an element, but > only one XLink attribute > * A dangling IDREF is an error; a dangling XPointer is not > > That is what I mean by saying the two facilities are > incompatible. Or to put it another way, once I have made a > design choice to use IDREF or to use XPointer for the links > in my documents, I am stuck with my choice. > > This is one of several situations in the XML family of > standards where there is more than one way of doing the same > thing, and no obvious way to choose between them. As the > frequency of questions about the element-vs-attribute choice > shows, this confuses users no end; it also complicates > software tools. > > MK > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at arbortext.com Tue Sep 1 20:05:30 1998 From: paul at arbortext.com (Paul Grosso) Date: Mon Jun 7 17:04:19 2004 Subject: xsl query or transformation language Message-ID: <3.0.32.19980901125907.00f3f68c@pophost.arbortext.com> At 17:28 1998 09 01 +0100, Henry S. Thompson wrote: >Lisa Rein writes: > >> Henry I am a little confused about perceiving XSL as a query language. > >> It was my understanding that it aims to be a transformation language, >> like DSSSL, that works with a query or scripting language to >> transform/process and format data. > >Well, XSL defines its own query syntax for walking the input document >tree, > >a) for the purposes of deciding which style rules to apply to >which input document components (in which case you should think of a >query as returning a 'yes this matches' or a 'no this doesn't match' >result when applied to a node in the tree; Since what gets said here might get copied elsewhere, we should be careful about wording. XSL currently has no style rules and may never. Henry is referring to construction rules here. I would disagree with Henry that pattern matching is querying in any useful, usual sense of the word. If there is a "query" (in the non-technical sense of the word) at all here, it's "given a node in the source document tree, what construction rule's pattern best matches the given node's context?" I don't see this as "returning" anything in the usual sense, and I don't think it's helpful to confuse this with what most people think of as queries even if the syntax of match patterns is similar to (or even the same as) the syntax of select patterns (which is what Henry discusses below). I also disagree that XSL "walks the tree" as Henry mentions above. I agree that the syntax of XSL patterns (both match patterns and select patterns, since they use almost the same syntax) is a potentially useful syntax for an XML-aware query language. > >b) for the purposes of finding one or more bits of the tree to process >next, given a starting point (the node we're processing now), in which >case you should think of a query as returning a set of nodes in the >tree given a starting point. > >A variant of type (b) where you just want the first element of the set >occurs as well. > >Sounds like what I mean by a query language, how about 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 andrew at epiphanysoftware.com Tue Sep 1 20:28:06 1998 From: andrew at epiphanysoftware.com (Andrew Cogan) Date: Mon Jun 7 17:04:19 2004 Subject: Tools to convert Word to XML? Message-ID: <35EC2EA8.E65CF9C1@epiphanysoftware.com> Can anyone recommend good tools that can convert Word files to XML? I don't need tools that claim XML compatibility per se; any utility that gives me control over what tag to insert at the beginning of a style and at the end of a style would probably suffice. The ability to work with Word footnotes is a big plus. -- Andrew Cogan, Epiphany Software xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Tue Sep 1 20:33:58 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:04:19 2004 Subject: A DTD for DCD Message-ID: <5030300024689352000002L022*@MHS> Here is a DTD I've been working on for DCD. It supports only the "strict" (i.e. attribute'y) version of the syntax, and there are some ordering limitations that are not implied by the spec, just because of I don't want to do 10 different content versions in some places in order to support all of the possibilities. I'd appreciate any feedback on why it fits or does not fit, or what sucks or does not suck about it. Be forwarned that many of the examples in the spec won't make it through this DTD. In some cases its because of simple ordering, but mostly its just because the examples were not compliant with the spec. I've passed these failures back to Ashok who I assume will update the next version. If anyone wants fixed versions of all of the examples that will also go through this DTD, let me know and I'll send them to you. Anyway, any comments on this DTD or the readability of the DCD spec or on DCD in general would be appreciated. I'll make sure that they get to Ashok. Also, any comments on the RDF aspects of DCD would be appreciated. Here is the DTD: ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Sep 1 20:38:03 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:04:19 2004 Subject: xsl query or transformation language In-Reply-To: <3.0.32.19980901125907.00f3f68c@pophost.arbortext.com> Message-ID: On Tue, 1 Sep 1998, Paul Grosso wrote: > > I would disagree with Henry that pattern matching is querying in any > useful, usual sense of the word. Querying is about asking "what elements in the grove match this pattern?" XSL matching is about asking "what patterns does this element match?" They are opposite, but they both have the "match" at their heart. The syntax of matching, at least, should be the same. Perhaps a generalized query language should also have extra stuff for transforming the matches. > I agree that the syntax of XSL patterns (both match patterns and > select patterns, since they use almost the same syntax) is a potentially > useful syntax for an XML-aware query language. I think almost everybody agrees that we should at least attempt this. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Tue Sep 1 20:41:21 1998 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:04:19 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) In-Reply-To: <199809011655.MAA00993@unready.megginson.com> References: <199809011442.QAA29400@sonne.darmstadt.gmd.de> Message-ID: <199809011837.UAA08308@sonne.darmstadt.gmd.de> David Megginson wrote at 1 Sep 98, 12:55: > Ingo Macherius writes: > > > My afterall impression is that most available tools do well with > > toy examples, but any input being in the MB range easily blasts > > them. At least that's true for what came from MS so far. > > I don't think that that's true in general. Most of the Java-based XML > parsers I've tried seem to be able to handle Jon Bosak's XML Old > Testament (nearly 4MB) just fine That's right, but as discussed in some xml list few weeks ago that's "just" middleware. With few exceptions (e.g. Techno2000) parsers were fine. > The problem comes if the parser tries to build a tree rather than > simply reporting an event stream. How many real world applications will be happy with just the event stream ? XSL-visualization always needs two trees, the parser tree and the resulting Formatting Object Tree (FOT). Double impact ! XML- querys/DOM need to build a transformed versions. Triple impact ! Each processing stage seems to duplicate data over and over. A possible way out is a shared pool which trees may only point to. IBM's xml4j goes in that direction with "subtree hashes". And (surprise, surprise) DOM-processing with xml4j was feasible. > Depending on the implementation, > document trees tend to be very large. With a naive tree > implementation, a 10MB document might use 100MB or more of virtual > memory for the document tree -- that'll bring most current desktop > systems to a screeching halt. IE5b1 needs 28MB for the parse tree of an 0.6 MB document and the resulting (very simple) JScript generated FOT. "Game Over" happens if I increase the source document size from 0.6MB to 0.8 MB. Little change, great effect. I won't even mention the one minute screen freeze while JavaScript/CSS processing. OK, my scripts are straight forward, but I wouldn't call them plain dumb. I hope MS does uses a "naive" implementation in the beta ... Cruel reality ... XML rules viewed from theoretical point. But I was beamed from campus right to heavy-duty database research. I'm the XML- geek, and I'm given database community tasks. Solving them with today's XML-tools turned out harder than expected. ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Sep 1 21:31:00 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:19 2004 Subject: xsl query or transformation language References: <3.0.32.19980901125907.00f3f68c@pophost.arbortext.com> Message-ID: <35EC4D58.E9008CDC@mecomnet.de> Paul Grosso wrote: > > At 17:28 1998 09 01 +0100, Henry S. Thompson wrote: > ... > > > >Well, XSL defines its own query syntax for walking the input document > >tree, > > > ... > > I also disagree that XSL "walks the tree" as Henry mentions above. > While the following is not specified to be the only implementation, it, in itself, sounds very much like a pre-order, depth-first tree walk: 2.3 Processing Model Ed. Note: This needs expanding and polishing. A node is processed to create a result tree fragment. The result tree is constructed by processing the root node. A node is processed by finding all the template rules with patterns that match the node, and choosing the best amongst them. The chosen rule's template is then instantiated for the node. During the instantiation of a template, the node for which the template is being instantiated is called the current node. A template typically contains instructions that select an additional sequence of source nodes for processing. A sequence of source nodes is processed by appending the result tree structure created by processing each of the members of the sequence in order. The process of matching, instantiation and selection is continued recursively until no new source nodes are selected for processing. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Tue Sep 1 22:00:17 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:04:19 2004 Subject: xsl query or transformation language In-Reply-To: james anderson's message of Tue, 01 Sep 1998 21:39:05 +0200 References: <3.0.32.19980901125907.00f3f68c@pophost.arbortext.com> <35EC4D58.E9008CDC@mecomnet.de> Message-ID: Thanks to Paul G. for correcting my sloppy terminology in referring to construction rules by the wrong name, my mistake. And Paul G. and Paul P. are both right that my (a) is better described as asking of a set of construction rules which one should be used for a given node, a process in which pattern matching plays a part, but not the only part. As for walking the tree, we're ALL right (all right!) on this one. The 90% case for construction rules in simple stylesheets is for them to contain templates with xsl:process-children in their midst. If ALL construction rules in a stylesheet are like that, then the nodes in the source tree will indeed yield results which are assembled as if by pre-order. But note the next line of the draft: "Implementations are free to process the source document in any way that produces the same result as if it were processed using this processing model." It's important to remember this: there is no guarantee of sequential processing even in the simple case. Because construction rules are independent of one-another, it doesn't matter what order bits of the result tree are constructed in. However there is one case in which a preorder sequencing is implied, in which case things look pretty much like querying: will process ALL the descendants of the current element whose element type is 'target' in preorder [this isn't said explicitly in the draft, but should be: it is implied in the description of xsl:process] 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 david at megginson.com Tue Sep 1 23:03:51 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:19 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) In-Reply-To: <199809011837.UAA08308@sonne.darmstadt.gmd.de> References: <199809011442.QAA29400@sonne.darmstadt.gmd.de> <199809011655.MAA00993@unready.megginson.com> <199809011837.UAA08308@sonne.darmstadt.gmd.de> Message-ID: <199809012057.QAA01820@unready.megginson.com> Ingo Macherius writes: > > The problem comes if the parser tries to build a tree rather than > > simply reporting an event stream. > > How many real world applications will be happy with just the event > stream ? XSL-visualization always needs two trees, the parser tree > and the resulting Formatting Object Tree (FOT). Double impact ! XML- > querys/DOM need to build a transformed versions. Triple impact ! Yes, but often the trees can be built and discarded at a fairly low level. For example, if I have a serialised database table like David Megginson david@megginson.com Ingo Macherius macherius@darmstadt.gmd.de
I do not need to build a tree for the whole document; instead, I can cache the information for each entry (or each n entries, for efficiency), dump it into my SQL database (or whatever), then move on to the next set. The second situation is where you are using XML to serialise a data model that is already well-defined (as for vector graphics). In this case, it makes more sense to build the specialised object tree directly from the event stream rather than building a DOM tree only to tear it down. Specialised object trees can be considerably smaller than a corresponding DOM tree, depending on the format. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Wed Sep 2 03:12:53 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:19 2004 Subject: xsl query or transformation language Message-ID: <009f01bdd60f$72e166f0$2c6167cb@ntwork.harvestroad.com.au> While we are correcting terminology, is it _Formatting_ or _Flow_ Objects? 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 tyler at infinet.com Wed Sep 2 03:38:34 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:19 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) References: <011601bdd5ac$a4a79820$0101a8c0@server.abinfosys.com> <199809011442.QAA29400@sonne.darmstadt.gmd.de> <199809011655.MAA00993@unready.megginson.com> Message-ID: <35ECA1CC.FEF3EF57@infinet.com> David Megginson wrote: > Ingo Macherius writes: > > > My afterall impression is that most available tools do well with > > toy examples, but any input being in the MB range easily blasts > > them. At least that's true for what came from MS so far. > > I don't think that that's true in general. Most of the Java-based XML > parsers I've tried seem to be able to handle Jon Bosak's XML Old > Testament (nearly 4MB) just fine, if somewhat slowly -- I used ot.xml > for routine testing and profiling while developing AElfred, and > AElfred barely kicked up a sweat. > > The problem comes if the parser tries to build a tree rather than > simply reporting an event stream. Depending on the implementation, > document trees tend to be very large. With a naive tree > implementation, a 10MB document might use 100MB or more of virtual > memory for the document tree -- that'll bring most current desktop > systems to a screeching halt. This is especially true for Java which is very memory hungry. Most of the memory problems with objects can be significantly reduced if your nodes only allocate memory for sub-arrays as needed (most implementations I would assume would use an array rather than a Vector to store children). Also, if there is only one child, do not create an array just to store that one child. In other words, you have something like this: class Node { Node child; Node[] children; int nodeLength } if child is null, then there are no elements if the size ever goes above 1, set child to null and copy the contents of child into children[0] and the parameter node into children[1]. Then when you look up a child by index of name you first test to see if child is null. If it is not then return the child if the index requested is 0, otherwise the index is out of bounds. If child is null, test to see if children is null. If children is not null, then just look up the node by index. If children is null then there are no elements (nothing has been added or deleted). For a lot of trees where it is somewhat common for nodes to only have one child, this can save you a lot of memory. It can also speed up your tree traversals a bit since you do not have to look up the children nodes by index in the case where there is only one child. Also, for building the tree, you will likely speed your app up a lot since you will now only have to create a new array object if the child index is greater than 1. Otherwise it is just a reference assignment which is about as fast as an integer assignment. I have not had a lot of problems building trees. For the DOM implementation, in conjunction with the parser I have, I build a DOM tree off of Jon Bosak's ot.xml in about 12 seconds running a JIT with JDK 1.2 b4, on an old P-120 with 64 megs of RAM running Windows NT 4.0. I have not been able to do any reliable memory benchmarks because the GC seems to be invoked much frequently with SUN's JDK 1.2 VM. I would suspect that the DOM package provided by Don Park has similiar performance and memory consumption. Your best bet would probably be to look at an XSL package which takes a DOM tree of your XML data, and a DOM tree of an XSL stylesheet and spits out the content. That way you are not stuck with an MS, IBM, Oracle, or whatever implementation that you are not happy with. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Sep 2 04:38:00 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:20 2004 Subject: Cement Shoes for XML? Message-ID: <199809020237.WAA12934@hesketh.com> Some of you may be interested in my latest essay, "Cement Shoes for XML?", which explores some reasons why client-side XML support, at least in the dominant browsers, may be slow in coming or perhaps worse. Hopefully, I haven't said anything too rude, but it's the result of several weeks of frustration brought on by reading articles about how slow and/or broken the XML development efforts in the current browsers appear to be. Developers planning on using server-side tools to send XML to browser clients will probably find it most alarming. (Myself included.) The essay is posted at: http://www.simonstl.com/articles/cement.htm Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Sep 2 07:34:53 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:04:20 2004 Subject: xsl query or transformation language References: <3.0.32.19980901125907.00f3f68c@pophost.arbortext.com> Message-ID: <35ECC1AA.23C04E7A@jclark.com> Paul Grosso wrote: > I would disagree with Henry that pattern matching is querying in any > useful, usual sense of the word. If there is a "query" (in the > non-technical sense of the word) at all here, it's "given a node in > the source document tree, what construction rule's pattern best matches > the given node's context?" I don't see this as "returning" anything > in the usual sense, and I don't think it's helpful to confuse this > with what most people think of as queries even if the syntax of > match patterns is similar to (or even the same as) the syntax of > select patterns (which is what Henry discusses below). I think it's possible and desirable to think of match patterns as queries, because select patterns are definitely queries and it's highly desirable to have a unified semantic model for both uses of patterns. If you say that a node matches a match pattern if the node is in the set returned by evaluating the match pattern as a query with the input set as all the nodes in the document, everything works out fine. For example, "foo" as a query returns the nodes that are children of nodes in the input set and that are of type "foo". When used as a select pattern, the input node set is the current node, so it returns the children of the current node of type foo. When used as a match patterm, the input nodes set is all the nodes in the document, so it matches the all nodes of types "foo" (this works for the document element since that is a child of the root). 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 john at totten.com Wed Sep 2 08:30:34 1998 From: john at totten.com (John Totten) Date: Mon Jun 7 17:04:20 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) References: <011601bdd5ac$a4a79820$0101a8c0@server.abinfosys.com> <199809011442.QAA29400@sonne.darmstadt.gmd.de> <199809011655.MAA00993@unready.megginson.com> <35EC43B6.C25052AB@totten.com> <199809012042.QAA01773@unready.megginson.com> Message-ID: <35ECF542.850D47EB@totten.com> Take some time to review this little item. http://www.equi4.com/metakit/index.html I have been playing around with this and would like to link it to a DOM parser so that the tree was built in a persistence store rather than memory. Being dynamically configurable makes this an ideal vehicle for doing this. You could thereafter deal directly with the object store or even just the view (indexed into the store) and not repeatedly reparse the document. It also removes any limits on the size of the document that you could parse in a single pass. If anyone succeeds in doing this then I let me know please. John Totten David Megginson wrote: > > John Totten writes: > > > > With a naive tree implementation, a 10MB document might use 100MB > > > or more of virtual memory for the document tree -- that'll bring > > > most current desktop systems to a screeching halt. > > > > Do you mean 100MB for the stack of parsed treeview objects as > > opposed to the GUI toolkit. And if so then why does it take so much > > space when all it takes is the addition of the parent ID to the > > serialised data item? > > I don't recognise some of your terminology -- perhaps it is > MS-specific. In general, the GUI should not add significantly to the > storage requirements (especially with an MVC architecture, like the > one used by the Java Swing components) -- what takes up the room is > the tree of nodes representing elements, attributes, character data, > etc. > > All the best, > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Wed Sep 2 09:20:43 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:20 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) References: <011601bdd5ac$a4a79820$0101a8c0@server.abinfosys.com> <199809011442.QAA29400@sonne.darmstadt.gmd.de> <199809011655.MAA00993@unready.megginson.com> <35EC43B6.C25052AB@totten.com> <199809012042.QAA01773@unready.megginson.com> <35ECF542.850D47EB@totten.com> Message-ID: <35ECF201.E3EA1392@infinet.com> John Totten wrote: > Take some time to review this little item. > > http://www.equi4.com/metakit/index.html > > I have been playing around with this and would like to link it to a DOM > parser so that the tree was built in a persistence store rather than > memory. Being dynamically configurable makes this an ideal vehicle for > doing this. You could thereafter deal directly with the object store or > even just the view (indexed into the store) and not repeatedly reparse > the document. It also removes any limits on the size of the document > that you could parse in a single pass. > If anyone succeeds in doing this then I let me know please. > > John Totten This is an interesting idea that could probably not be too hard to implement in Java using a read only random access file. Basically, a stream based parser would dump the contents of a very large document directly into some DOM format for a random access file. You would then have a special DOM implementation that is an interface to this file. Nevertheless, this sort of stuff would probably best be handled by some comprehensive database which presents a DOM interface to the DOM data. I think this is probably what companies like Oracle and IBM may be up to, but who really knows. If you wanted to go to the extreme you could even represent an entire directory service like NDS this way. 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 bmhughes at ozemail.com.au Wed Sep 2 10:11:57 1998 From: bmhughes at ozemail.com.au (Baden Hughes) Date: Mon Jun 7 17:04:20 2004 Subject: Tools to convert Word to XML? In-Reply-To: <35EC2EA8.E65CF9C1@epiphanysoftware.com> Message-ID: <001101bdd649$1f4871c0$dd3570c2@bmhmobile> > Andrew Cogan, Epiphany Software > Can anyone recommend good tools that can convert Word files > to XML? I don't need tools that claim XML compatibility per se; any > utility that gives me control over what tag to insert at the beginning > of a style and at the end of a style would probably suffice. The ability > to work with Word footnotes is a big plus. We've worked on this using Word styles and a heap of macros which allow us to "export" remapping the styles to markup. Basically you figure out what markup you'd like applied and then what WYSIWYG style you would like the user to apply (ie work in) then on export the styles are all remapped to XML tagging. The beauty of this is that you can tag as much as you want - the tagging is all done behind 'formatting' which from the user point of view is just fine. They don't have to know about XML, just about which styles to apply where in a Word document. And you can also export/hack the stylesheet to be CSS if you are really going for it then you have the markup and the formatting instructions separately. If you want to know more specifics, mail me privately. Baden xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 10:19:18 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:20 2004 Subject: State of browsers/JUMBO (was Re: Cement Shoes for XML?) In-Reply-To: <199809020237.WAA12934@hesketh.com> Message-ID: <3.0.1.16.19980901091011.223f28e8@pop3.demon.co.uk> At 22:39 01/09/98 -0400, Simon St.Laurent wrote: >Some of you may be interested in my latest essay, "Cement Shoes for XML?", >which explores some reasons why client-side XML support, at least in the >dominant browsers, may be slow in coming or perhaps worse. Hopefully, I >haven't said anything too rude, but it's the result of several weeks of >frustration brought on by reading articles about how slow and/or broken the >XML >development efforts in the current browsers appear to be. > >Developers planning on using server-side tools to send XML to browser clients >will probably find it most alarming. (Myself included.) Minor correction: the essay suggests that JUMBO is a specialist browser for chemistry - in fact it is a general element-oriented browser which can address any domain where functionality can be provided by adding code on a per-element basis. For example I have added a simple vector graphics module which can be expended to support VML/PGML/FOO when those firm up (and when I feel confident enough to start using JDK1.2/Java2D for the additional primitives). I was surprised not to see more browsers at Montreal developers' day - my current assessment is that the main authors are: - Steve Withall (XXX) - Scott Parnell (Raven) - PeterMR (JUMBO) All of these use Swing (Java) for their rendering and all suffer from the bugginess of Swing. [This bugginess was confirmed by several conversations.]. For example we have found it difficult to provide proper formatting using the Style/AttributeSet and received wisdom is that the author has to rewrite parts of Swing to get it to work. As a result of the lack of browsers I have spent time investigating how JUMBO2 might be expanded to meet 'most' needs. It seems that the following may be valuable: - support for simple styles. I am developing an approach where readers can select per-element behavior for stylesheets [i.e. bold, leading CR, display start-tag, colour could be selected from a menu of elements.] It would probably be relatively simple to make it into a subset of CSS. I don't intend to do this myself because I don't have the time or passion to worry about rendering on screen at least till Swing is better. - simple searching (similar to XPointer). - HTML-like forms/CDC/XML-data. I demo'ed this briefly at Montreal - the forms are created by the XML input and can be written out with edited values. This seems to me a simple, valuable thing that a browser can do to enhance the value of XML over HTML. Thus JUMBO can apply algorithms very easily to client-side data entry to validate before upload. I don't imagine I'm the only person who thinks this could be a useful function. - vector graphics. JUMBO will have the ability to read or edit simple vector graphics. Not completely finished, but I've done this before. This would allow simple - if not instantaneous - collaborative graphical working. Doesn't this excite other people?? - structural and per-element editing. The only thing I am not going to do is write a text editor. Editing other elements is easier, both individually and for structure. I have repeatedly suggested that we develop these tools communally and have offered JUMBO on this basis. I've had a few replies, but not as many as I would have hoped. Is everyone paralysed by waiting for others to do it??? It seems inconceivable that we couldn't write a useful simple browser starting from where we are. I have written a manifesto about this on http://www.xml.com (xml:geek) if you want further motivation. P. The next snapshot of JUMBO should be out this in day or two. It's not polished - and some of the things and only part implemented - but most of the bits are there somewhere. 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 peterj at wrox.com Wed Sep 2 11:03:10 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:20 2004 Subject: DOCTYPE decl Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C036020@WROX3> Can I just check the following with folks on the list: I have what I would like to be a well-formed, but not valid, document: ]> &entityname; Question: If I have to include a !DOCTYPE declaration in order to declare entities, am I also forced to declare the root element with an !ELEMENT decl. too? Thanks, Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Wed Sep 2 11:16:04 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:20 2004 Subject: DOCTYPE decl Message-ID: <001b01bdd652$ec4d1960$2c6167cb@ntwork.harvestroad.com.au> -----Original Message----- From: Peter Jones >Can I just check the following with folks on the list > >I have what I would like to be a well-formed, but not valid, document: > > >]> > >&entityname; > >Question: >If I have to include a !DOCTYPE declaration in order to declare >entities, am I also forced to declare the root element with an !ELEMENT >decl. too? No, not at all. What you have above is well-formed, but not valid, just as you want. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Wed Sep 2 11:27:59 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:04:20 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) Message-ID: <002901bdd654$7e92f8c0$1e09e391@mhklaptop.bra01.icl.co.uk> >... You could thereafter deal directly with the object store or >even just the view (indexed into the store) and not repeatedly reparse >the document. The sirens have lured you! I have a lot of experience with storing parsed document trees in an object database and I have experimented with storing the Java serialization of DOM-like models on disk, and for what it's worth, in both cases retrieving the document takes a lot longer than reparsing original XML. The main reason is simply that there are more bytes to read. The only technique that I find really effective for handling large documents is to split them up into lots of small ones. That way you only parse the bits the user actually wants to see. MK xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Wed Sep 2 12:44:15 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:20 2004 Subject: PARAMETER entities & WFness Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C036025@WROX3> Since for well-formed but not valid docs I can't rely on external parameter entities to be read and included, is it true that parameter entities really only have one use for us in our well-formed-but-not-valid documents: to alter the order in which entity declarations are parsed? If so, can anyone think of a situation where this would need to be resorted to? Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Wed Sep 2 13:20:02 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:04:20 2004 Subject: State of browsers/JUMBO Message-ID: <005501bdd664$28bb9e60$1e09e391@mhklaptop.bra01.icl.co.uk> > As a result of the lack of browsers I have spent time investigating how >JUMBO2 might be expanded to meet 'most' needs... > I have repeatedly suggested that we develop these tools communally and >have offered JUMBO on this basis. I've had a few replies, but not as many >as I would have hoped. Some observations: - I tried (more than once) downloading Jumbo and exploring what it could do for me. I didn't make much progress. There's clearly an enormous amount of functionality there, but I found it very hard to know where to start. I've had the same experience with downloads of other XML software (most recently XML Toolkit), and I dare say others have had the same experience with my own SAXON library. - I suspect that as a community the thing we are desperately lacking is a commonly understood architecture. We're all writing bits of code that do useful things with XML, but we don't have a clear vision as to what the total set of capabilities should look like or how its components should relate to each other. I think this is why it's hard to take something like Jumbo and discover quickly what pieces of the jigsaw it supplies. - Having all these people produce free software is great, but the downside is that most of it was written to satisfy the intellectual creativity and/or parochial application requirements of the individual author, which means that the boring parts of software development, like working out who the users are and writing good task-oriented documentation to meet their needs, have been sadly neglected. Perhaps this is why real product developers like Microsoft seem to be slow. Fred Brooks, I recall, said that writing a one-off program is one-tenth the effort of producing a software product that does the same thing. Regarding Simon's essay, I don't share his pessimism. I don't personally regard client-side browser support for XML as particularly urgent, I'm quite happy to do rendition server-side either on demand, or in many cases at site generation time. One reason is that the client-side model (along with XLink and XSL) seems to assume that the web of XML documents has the same topology as the web presented to the user, which I think grossly underexploits the ability of XML to separate the information structure from the user view. I think a much more valuable development would be the integration of XML with database technology. (And in practice, I'm actually using XML mainly for "EDI" style applications. ) 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 Wed Sep 2 15:04:57 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:21 2004 Subject: xsl query or transformation language Message-ID: <009d01bdd670$e8707fd0$2ee044c6@arcot-main> >I think it's possible and desirable to think of match patterns as >queries, because select patterns are definitely queries and it's highly >desirable to have a unified semantic model for both uses of patterns. Thinking of match patterns as queries would certainly appeal to database and IR folks but I like to like of match patterns as 'criteria'. As far as XSL processing model goes, I think of it as a sort of an inference engine. What I would have liked to see in XSL is the nested template feature which is wonderfully interesting and confusing at the same time because it is like a clever expression looking for a deep meaning. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Sep 2 15:05:16 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:21 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) Message-ID: <009e01bdd670$e935a490$2ee044c6@arcot-main> >I would suspect that the DOM package provided by Don Park has similiar >performance and memory consumption. Your best bet would probably be to look at >an XSL package which takes a DOM tree of your XML data, and a DOM tree of an XSL >stylesheet and spits out the content. That way you are not stuck with an MS, >IBM, Oracle, or whatever implementation that you are not happy with. About 10 seconds and 10 meg of memory to convert each meg of XML into DOM with JIT enabled. My solution to the problem of DOM building speed is based on that famous doctor joke about a guy telling his doctor "Doctor, it hurts when I do this!". The trick lies in reducing the need to build DOM everytime the XML document changes. Unless you are into pain, that is. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Sep 2 15:05:54 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:21 2004 Subject: XML-QL Message-ID: <009f01bdd670$ea00e3d0$2ee044c6@arcot-main> >Henry I am a little confused about perceiving XSL as a query language. > >It was my understanding that it aims to be a transformation language, >like DSSSL, that works with a query or scripting language to >transform/process and format data. > >Am I confused again :-)? No. XSL is definitely not a query language although it uses ideas which could be useful for querying. What I am concerned about is the obsession with thinking about XML as a 'thing'. I think it is much more interesting to think of XML as a language of communication. When we are talking about XML query language, are we talking about expressing a query in XML or are we talking about an expression, not necessarily in XML, that will return information from data sources, not necessarily XML document repositories, in XML format? What we have is a multitude of needs and I think we need to sort out which of them address before we unintentionally drop XQL into Wired Hot/Cold list. BTW, there is another topic related to XML-QL which is XBE or XML-[query]-By-Example. I am not sure if anyone is working on it because I just thought of it . You just write an example of the XML document you want by specifying the tags as you want it and fill in the values to match. XBE engine uses it to return the data the way you want exactly, rejecting mismatches and weeding out unwanted information. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlapp at webMethods.com Wed Sep 2 15:28:41 1998 From: jlapp at webMethods.com (Joe Lapp) Date: Mon Jun 7 17:04:21 2004 Subject: XML-QL Message-ID: <3.0.32.19980902092901.00a7b3c4@gw1.webmethods.com> At 05:53 AM 9/2/98 -0700, Don Park wrote: >No. XSL is definitely not a query language although it uses ideas which >could be useful for querying. I would argue that XSL patterns is definitely a query language, but that the template language portion of XSL (the big picture) probably is not. >[...] >When we are talking about XML query language, are we talking about >expressing a query in XML or are we talking about an expression, not >necessarily in XML, that will return information from data sources, not >necessarily XML document repositories, in XML format? I can represent SQL in XML, OQL in XML, even XPointers in XML. XML is a way to represent data structures. I can represent C, C++, Java, and Pascal all in XML if I want to. I can chose an XML representation that provides exactly the information found in the non-XML representation. This suggests to me that the more interesting challenge is to create a language that queries data structures that are represented in XML, not to just create a query language that is expressed in XML. I don't mean to make any statement about whether this language for querying XML should itself be expressed in XML -- that's an orthogonal issue. >[...] >BTW, there is another topic related to XML-QL which is XBE or >XML-[query]-By-Example. I am not sure if anyone is working on it because I >just thought of it . You just write an example of the XML document you >want by specifying the tags as you want it and fill in the values to match. >XBE engine uses it to return the data the way you want exactly, rejecting >mismatches and weeding out unwanted information. Interesting approach -- sort of the inverse of XSL -- but I suspect that in order to be useful it won't be so simple. In its simplest form, you'd only return the elements that you provided, serving only as an existence test, returning no other information. QBE at a minimum requires wildcards, and it would be interesting to find an appropriate set of wildcards. -- Joe Lapp, Senior Engineer | jlapp@webMethods.com webMethods, Inc. | Voice: 703-267-1726 http://www.webMethods.com | Fax: 703-352-0370 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlapp at webMethods.com Wed Sep 2 15:46:55 1998 From: jlapp at webMethods.com (Joe Lapp) Date: Mon Jun 7 17:04:21 2004 Subject: Another XML query language (was Re: XML-QL) Message-ID: <3.0.32.19980902094723.00ab57a0@gw1.webmethods.com> Here's another markup query language that is actually quite mature. It is called the webMethods Object Model (WOM), which is not to be confused with APIs such as DOM (WOM is a string-based query language). We've been using it in our products for for than a year and a half now. WIDL depends on it. You can think of WIDL as an application of a query language. WOM was originally developed for HTML, but has proven more valuable with XML. We use our latest incarnation of WIDL with XML all the time; WIDL is a language for crossing the tree/data-structure barrier that exists between flow object representations and programming languages. (I'll be giving a speech on WIDL for XML at the XML 98 conference.) I've put some pages up on our site. These pages are from our product documentation. They probably aren't as accessible in this form, since I went through and removed the product tutorial pieces. Hopefully I didn't leave to many links dangling. The URL: http://www.webMethods.com/technology/wom.html At 09:41 AM 9/1/98 -0700, Lisa Rein wrote: > >So far I've got: > >SQL (of course) >XPointer >XML-QL >XQL? >Appel... > >more? > >thanks everybody, > >lisa > >Jonathan Robie wrote: >> >> At 11:19 AM 9/1/98 +0100, Michael Kay wrote: >> >> >My immediate reaction is to compare this not with SQL, but >> >with the new XSL "tree construction" facilities which >> >essentially provide an XML transformation language. I don't >> >have time to do a detailed point-by-point comparison but it >> >would certainly be a useful exercise. Conceptually they have >> >many similarities but there are many points of detail where >> >one is stronger than the other. I would think it is entirely >> >possible to devise a language that combines the power of >> >both without a significant loss of usability. >> >> In fact, at Metastructures 98 I presented a language called XQL that uses a >> syntax very similar to XSL Patterns. This language was developed primarily >> by Joe Lapp of webMethods and me. Like XML-QL, XQL is declarative. >> >> One of the significant differences between XML-QL and XQL is that XQL can >> do both hierarchy and sequence. The fundamental structural relationships in >> XQL are: >> >> o hierarchy >> >> o parent/child >> o ancestor/descendant >> >> o sequence >> >> o precedes >> o immediately precedes >> >> o position >> >> o subscripts >> o ranges >> >> I think sequence is pretty important in documents, though it is not >> important in many data-oriented systems. XML-QL's heritage in relational >> theory has caused it to ignore sequence. >> >> 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) > -- Joe Lapp, Senior Engineer | jlapp@webMethods.com webMethods, Inc. | Voice: 703-267-1726 http://www.webMethods.com | Fax: 703-352-0370 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Sep 2 15:49:58 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:21 2004 Subject: XBE (was Re: XML-QL) Message-ID: <000c01bdd677$2e712060$2ee044c6@arcot-main> >Interesting approach -- sort of the inverse of XSL -- but I suspect that in >order to be useful it won't be so simple. In its simplest form, you'd only >return the elements that you provided, serving only as an existence test, >returning no other information. QBE at a minimum requires wildcards, and >it would be interesting to find an appropriate set of wildcards. At the simple level, fuzzy match of attribute values and text contents should work pretty well. Any missing attribute or elements can be treated as wildcards. At the complex level, scripting language for matching should work pretty well. Here is an example: CD-ROM quantity > 10 Above XBE should return all order records for sales made at the electronics department by Bob where product description 'contains' the string "CD-ROM" and quantity exceeds 10. The scripting language refers to context elements and attributes by name (order.department for attribute). There are obvious rough spots but I think it has promises. Whether or not I will invest time and effort into XBE is another question of course. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlapp at webMethods.com Wed Sep 2 16:06:40 1998 From: jlapp at webMethods.com (Joe Lapp) Date: Mon Jun 7 17:04:21 2004 Subject: Another XML query language (was Re: XML-QL) Message-ID: <3.0.32.19980902100707.00ab9c84@gw1.webmethods.com> Oops, here are some corrections. Sorry about that. Working too much: At 09:47 AM 9/2/98 -0400, Joe Lapp wrote: >[...] >We've been using it in our products for for than a year and a half now. ^^^ more >[...]WIDL is a language for crossing the tree/data-structure barrier that >exists between flow object representations and programming languages. ^^^^^^^^^^^ grove -- Joe Lapp, Senior Engineer | jlapp@webMethods.com webMethods, Inc. | Voice: 703-267-1726 http://www.webMethods.com | Fax: 703-352-0370 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jgarrett at navix.net Wed Sep 2 16:13:34 1998 From: jgarrett at navix.net (Jim Garrett (NAVIX)) Date: Mon Jun 7 17:04:21 2004 Subject: Cement Shoes for XML Message-ID: <000401bdd679$757264e0$14c8c8c8@jgnt40> Simon: So what do we(the XML users) do now...? And how do we keep XML from the getting a new pair of these shoes...?? This is most alarming....!!! I had "Hiiiiiigh hopes" for Ubiquitous XML..!!! JDGarrett >Some of you may be interested in my latest essay, "Cement Shoes for XML?", >which explores some reasons why client-side XML support, at least in the >dominant browsers, may be slow in coming or perhaps worse. Hopefully, I >haven't said anything too rude, but it's the result of several weeks of >frustration brought on by reading articles about how slow and/or broken the >XML >development efforts in the current browsers appear to be. > >Developers planning on using server-side tools to send XML to browser clients >will probably find it most alarming. (Myself included.) > >The essay is posted at: >http://www.simonstl.com/articles/cement.htm > > > >Simon St.Laurent >Dynamic HTML: A Primer / XML: A Primer >Cookies / Sharing Bandwidth (November) > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 16:27:34 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:04:21 2004 Subject: PARAMETER entities & WFness Message-ID: <3.0.32.19980902072809.00f6828c@207.34.179.21> At 11:38 AM 9/2/98 +0100, Peter Jones wrote: >parameter entities really only have one use for us in our >well-formed-but-not-valid documents: to alter the order in which entity >declarations are parsed? I don't think parameter entities have any use whatsoever in any circumstances unless you're validating. Reason: a non-validating processor doesn't have to read them. -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 gcsfred at magma.ca Wed Sep 2 16:53:14 1998 From: gcsfred at magma.ca (Gustavo Frederico) Date: Mon Jun 7 17:04:21 2004 Subject: Java IDEs and XML Message-ID: <199809021305.JAA01216@mag1.magmacom.com> I am prototyping a new application, and it will be using WebObjects. WebObjects has a development environment, a JVM and does a bridge between Java objects and the database. I was thinking about using XML for handling the contents of news, event announcements and for storing metadata about documents. Would that be better than having the application to talk directly to the database, updating directly database entries? I think the general answer is: depends on the application. In this case, I like the idea of using XML because it would easyly handle documents metadata, and I would easyly handle news stuff with something like CDF. On the other hand, the whole development environment is driven to model objects, map them to the database and generate Java code. And if I don't use any database at all for those sections of the project, how am I going to handle concurrent updates, data (or document, in this case) consistency on blablablaML documents? Is this responsability over my Java code now and not on the database? Do you think XML is a good alternative to this application? I think that would be a problem that aplies to other Java tools also, although I don't know deeply other Java IDE. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gcsfred at magma.ca Wed Sep 2 16:53:16 1998 From: gcsfred at magma.ca (Gustavo Frederico) Date: Mon Jun 7 17:04:21 2004 Subject: Java IDEs and XML Message-ID: <199809021351.JAA16290@mag1.magmacom.com> I am prototyping a new application, and it will be using WebObjects. WebObjects has a development environment, a JVM and does a bridge between Java objects and the database. I was thinking about using XML for handling the contents of news, event announcements and for storing metadata about documents. Would that be better than having the application to talk directly to the database, updating directly database entries? I think the general answer is: depends on the application. In this case, I like the idea of using XML because it would easyly handle documents metadata, and I would easyly handle news stuff with something like CDF. On the other hand, the whole development environment is driven to model objects, map them to the database and generate Java code. And if I don't use any database at all for those sections of the project, how am I going to handle concurrent updates, data (or document, in this case) consistency on blablablaML documents? Is this responsability over my Java code now and not on the database? Do you think XML is a good alternative to this application? I think that would be a problem that aplies to other Java tools also, although I don't know deeply other Java IDE. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gustavo.frederico at ott.montage.ca Wed Sep 2 16:56:45 1998 From: gustavo.frederico at ott.montage.ca (Gustavo Frederico) Date: Mon Jun 7 17:04:21 2004 Subject: Java IDEs and XML (again) Message-ID: (sorry if you are reading twice. I got a problem with my SMTP server) I am prototyping a new application, and it will be using WebObjects. WebObjects has a development environment, a JVM and does a bridge between Java objects and the database. I was thinking about using XML for handling the contents of news, event announcements and for storing metadata about documents. Would that be better than having the application to talk directly to the database, updating directly database entries? I think the general answer is: depends on the application. In this case, I like the idea of using XML because it would easyly handle documents metadata, and I would easyly handle news stuff with something like CDF. On the other hand, the whole development environment is driven to model objects, map them to the database and generate Java code. And if I don't use any database at all for those sections of the project, how am I going to handle concurrent updates, data (or document, in this case) consistency on blablablaML documents? Is this responsability over my Java code now and not on the database? Do you think XML is a good alternative to this application? I think that would be a problem that aplies to other Java tools also, although I don't know deeply other Java IDE. ---------------------- Gustavo Frederico gustavo.frederico@ott.montage.ca xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Sep 2 19:16:41 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:21 2004 Subject: State of browsers/JUMBO In-Reply-To: <005501bdd664$28bb9e60$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <3.0.1.16.19980901181721.289f6b3e@pop3.demon.co.uk> At 12:23 02/09/98 +0100, Michael Kay wrote: > >Some observations: > >- I tried (more than once) downloading Jumbo and exploring >what it could do for me. I didn't make much progress. >There's clearly an enormous amount of functionality there, >but I found it very hard to know where to start. I've had Fully accepted. This is true of most enthusiast software. I had expected JUMBO to be overtaken. I need it for my own purposes and offer it to others. [A new version should be out tonight - but it's still 'alpha']. >the same experience with downloads of other XML software >(most recently XML Toolkit), and I dare say others have had >the same experience with my own SAXON library. > >- I suspect that as a community the thing we are desperately >lacking is a commonly understood architecture. We're all Certainly. The architecture that JUMBO needs is the ability to render/process/validate on a per-object basis. This is also what XXX does. Steve Withal uses verify() [I think] while I use what I think is a similar function processXML(). Something that runs code on an endElement event to: - customise/transform the internals - verify (possibly includes DTD-like validation) - render in interactive form. For chemistry I have to have processing for data types (a la DCD) and specials such as >writing bits of code that do useful things with XML, but we >don't have a clear vision as to what the total set of >capabilities should look like or how its components should >relate to each other. I think this is why it's hard to take >something like Jumbo and discover quickly what pieces of the >jigsaw it supplies. I'd be delighted if there were others who have this need and we can work out an API. This is the most obvious area for me - and I would assume many others. Or is everyone quite happy to wait for stylesheets - in which case I am in a minority as stylesheets and ECMAScript won't do much useful for chemistry. > >- Having all these people produce free software is great, >but the downside is that most of it was written to satisfy >the intellectual creativity and/or parochial application >requirements of the individual author, which means that the >boring parts of software development, like working out who >the users are and writing good task-oriented documentation >to meet their needs, have been sadly neglected. Perhaps this >is why real product developers like Microsoft seem to be >slow. Fred Brooks, I recall, said that writing a one-off >program is one-tenth the effort of producing a software >product that does the same thing. No question. But the enthusiast community has - on occasion - shown it can be done. I don't see why it couldn't be attempted here. > >Regarding Simon's essay, I don't share his pessimism. I >don't personally regard client-side browser support for XML >as particularly urgent, I'm quite happy to do rendition >server-side either on demand, or in many cases at site If 'rendition' means rendering for humans to read then we can use PDF. The points of client side functionality for me are that: - we can carry out operations without troubling the server. Examples are interactive graphics (my background is molecular graphics). Holding the displayTree in the server for processing is untenable for many operations. And my graphics have to be intelligent enough to be coupled to a data model - we may not even *have* a server (some people will interact with XML documents disconnected from a remote server) - we may wish to interact with the local resources I still feel that XML is suited to many operations other than sending human-readable non-interactive text over the WWW. For example I could see it as a way of building a MOO (or - more ambitiously - interactive games) in a platform-independent manner. You can't do this well in HTML. >generation time. One reason is that the client-side model >(along with XLink and XSL) seems to assume that the web of >XML documents has the same topology as the web presented to >the user, which I think grossly underexploits the ability of >XML to separate the information structure from the user >view. I think a much more valuable development would be the >integration of XML with database technology. (And in >practice, I'm actually using XML mainly for "EDI" style >applications. ) Surely one thing we need is form-like data entry implemented on the client side. [Using XML to generate HTML forms surely misses the point.] So I have been experimenting with client-side data authoring tools. XML has great potential as an authoring tool for specialist or complex domains - again I see little evidence that people are addressing this. I shall keep appealing for enthusiasts and we'll see what turns up. Doesn't need many. Maybe they don't yet come to XML-DEV... P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Sep 2 21:01:31 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:21 2004 Subject: PARAMETER entities & WFness In-Reply-To: <29AA5A0E3A0CD21196F300A0C9D8575C036025@WROX3> from "Peter Jones" at Sep 2, 98 11:38:47 am Message-ID: <199809021904.PAA15517@locke.ccil.org> Peter Jones scripsit: > Since for well-formed but not valid docs I can't rely on external > parameter entities to be read and included, is it true that > parameter entities really only have one use for us in our > well-formed-but-not-valid documents: to alter the order in which entity > declarations are parsed? Actually, that won't work either. Parameter entities have no use at all in documents that must be processed by minimally conformant parsers. The good news is that almost all parsers actually do process external entity references, both general and parameter. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dent at highway1.com.au Wed Sep 2 22:00:44 1998 From: dent at highway1.com.au (Andy Dent) Date: Mon Jun 7 17:04:22 2004 Subject: auto table mapping Message-ID: The context is our storing a report-writer output into a standalone document so the same engine can later reparse the document, and allow user editing. We have a tree of report-writer objects, almost all of which link to one or more database views. An obvious shortcut is to put a lot of specialist attributes into our DTD so that our structures are easily rebuilt. I'm playing with the idea of having our parser able to recreate such a tree in a fairly generic manner (ie: handle other people's XML :-). The essential issue is the flattening of the bottom level. Instead of a general tree, with leaves containing PCDATA (or b64-encoded images) we want to recognise the situation where a number of sibling leaves are actually fields in a single record. Thus, two levels of the tree map to an internal 'table' object. Nested elements which contain other PCDATA leaves would be modelled as related tables (as an OORDBMS OOFILE models relationships as well as tables). The key assumptions here are 1) we will auto-generate some internal ID to track the relationships (I haven't time for the complexities of XML-Data, and join keys may not be in the exported data) 2) some portion of the DTD will fall into a pattern of 'tables' with possible nested tables 3) inside this pattern, we may require you to explicitly bracket multiple occurrences of an element inside another element so we can recognise a nested table (ie: can't contain multiple elements directly, but needs ) Is there interest in discussing this further or should I just carry on and implement something merely good enough for our immediate load/save operation? Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.highway1.com.au/adsoftware/crossplatform.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fabien at girardin.org Wed Sep 2 23:27:32 1998 From: fabien at girardin.org (Fabien Girardin) Date: Mon Jun 7 17:04:22 2004 Subject: XML and servlets Message-ID: <35EDB7FD.8E26C7D4@girardin.org> Hi all, I have done some experiments where XML documents are processed on the client side. But I think, for my project, it would be more interesting to parse these files on the server side using a servlet. I am using MSXML, but I can't load the XML file in the servlet (while a had no problems doing it on my prior experiments in applets and applications). Has anybody have tried the same kind of experiment or could point me to some valuable documentation or code to help me solve this problem. -- Fabien xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Wed Sep 2 23:52:09 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:22 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) References: <009e01bdd670$e935a490$2ee044c6@arcot-main> Message-ID: <35EDBE44.1DA8781B@infinet.com> Don Park wrote: > >I would suspect that the DOM package provided by Don Park has similiar > >performance and memory consumption. Your best bet would probably be to > look at > >an XSL package which takes a DOM tree of your XML data, and a DOM tree of > an XSL > >stylesheet and spits out the content. That way you are not stuck with an > MS, > >IBM, Oracle, or whatever implementation that you are not happy with. > > About 10 seconds and 10 meg of memory to convert each meg of XML into DOM > with JIT enabled. For my implementation, for ot.xml (a 4 meg document) only about 1-2 megs of RAM is used to store the 4 meg file in RAM due to all Names being cached at the parser level. It also takes only 10-12 seconds with a P-120 running Symantec's JIT for JDK 1.2 b4 to build the entire DOM tree. For spitting out the DOM tree (and normalizing all the Text nodes) it takes about 15-20 seconds of which 5 seconds is spent normalizing text nodes and most of the rest of this time is actually spent in a brute force search and replace method that scans all character data and attribute values and replaces any occurrences of entity values with entity names. This can be very expensive but I know no other way around it. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From kent at trl.ibm.co.jp Thu Sep 3 02:37:09 1998 From: kent at trl.ibm.co.jp (TAMURA Kent) Date: Mon Jun 7 17:04:22 2004 Subject: Update: IBM XML for Java version 1.0.9 Message-ID: <199809030035.JAA38798@ns.trl.ibm.com> http://www.alphaworks.ibm.com/formula/xml XML for Java, an XML processor written in Java, has been updated. It runs on Java 1.1.x and some samples require Swing 1.0.x. CHANGES: o DOM-19980818 Proposed Recommendation support o An experimental implementation of attribute-based namespace (WD-xml-names-19980802) PI-based namespace was removed. o All sample programs were moved to "samples." package and stored in xml4jSamples_1_0_9.jar. o etc. I'm sorry that a fatal bug is already found: o A parser crashes by PIs with empty data like . -- TAMURA, Kent @ Tokyo Research Laboratory, IBM Japan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Thu Sep 3 02:45:41 1998 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:04:22 2004 Subject: XML tools and big documents In-Reply-To: <199809012057.QAA01820@unready.megginson.com> References: <199809011837.UAA08308@sonne.darmstadt.gmd.de> Message-ID: <199809030044.CAA05059@sonne.darmstadt.gmd.de> David Megginson wrote at 1 Sep 98, 16:57: > I do not need to build a tree for the whole document; instead [...] > dump it into my SQL database [...]. => Put it into an RDBMS > [...] it makes more sense to build the specialised object tree > directly from the event stream rather than building a DOM tree => Put it into an OODBMS "Michael Kay" wrote at Wed, 2 Sep 1998 10:31:41 +0100: > [...] storing the Java serialization of DOM-like models on disk [...] > takes a lot longer than reparsing original XML => Put it in a file and reparse So when it gets big, use a database ? Did I get this wrong and XML was never ment to be a storage paradigm ? Anyway, I can affirm Michael's results. We implemented an experimental database storage for SGML with jjc's SP and Informix's IUS. It generalizes something similar to David's second suggestion. Object-aggregation is done by marking the content of specified element types (e.g. in a Shakespeare play) to be stored unparsed. When it comes to queries it is reparsed on the fly. Kind of automatic object generation. Queries turned out to become slow when granularity gets less coarse. Most navigations trigger child/sibling lookups, which trigger object ID table lookups. That's at least one SQL statement firing for every DOM navigation call. Caching helps, but doesn't really the problem. Trees in RDBM are no fun. Michael writes they are no fun in OODB, too. IMHO the good timings in in-memory DOM implementations result from the fact that looking up children is a cheap operation. In current DB systems it's not cheap at all. Is anybody aware of literature for efficient addressing in trees ? This should help both in-memory DOMs and DBs. A bit disillusioned, ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Sep 3 02:48:13 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:22 2004 Subject: XML tools and big documents Message-ID: <005c01bdd6d3$04ed3560$2ee044c6@arcot-main> >For my implementation, for ot.xml (a 4 meg document) only about 1-2 megs of RAM >is used to store the 4 meg file in RAM due to all Names being cached at the >parser level. It also takes only 10-12 seconds with a P-120 running Symantec's My test results were from running on Atari 800 (just kidding ). My test machine is Pentium-133 with JDK 1.1.6 with JIT enabled. Building DOM is a slow process but there are intermediate forms I am investigating which cuts down DOM loading drastically. >JIT for JDK 1.2 b4 to build the entire DOM tree. For spitting out the DOM tree >(and normalizing all the Text nodes) it takes about 15-20 seconds of which 5 >seconds is spent normalizing text nodes and most of the rest of this time is >actually spent in a brute force search and replace method that scans all >character data and attribute values and replaces any occurrences of entity values >with entity names. This can be very expensive but I know no other way around it. Why are you normalizing text nodes before writing them out? Also, blindly replacing entity values with entity names is error prone. Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Sep 3 03:01:24 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:22 2004 Subject: XML tools and big documents In-Reply-To: <199809030044.CAA05059@sonne.darmstadt.gmd.de> References: <199809011837.UAA08308@sonne.darmstadt.gmd.de> <199809012057.QAA01820@unready.megginson.com> <199809030044.CAA05059@sonne.darmstadt.gmd.de> Message-ID: <199809030053.UAA04222@unready.megginson.com> Ingo Macherius writes: > > [...] it makes more sense to build the specialised object tree > > directly from the event stream rather than building a DOM tree > => Put it into an OODBMS No, not exactly -- I'm suggesting building an application-specific object tree, not a generic XML one, and am not particularly concerned with where it is stored. > So when it gets big, use a database ? Did I get this wrong and XML > was never ment to be a storage paradigm ? XML is for interchange -- for simple applications you can use it for storage (as I do on my notebook), but for larger, multi-user applications, you probably want to put it into some kind of specialised storage, if only for the sake of revision and access control. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eric at hellman.net Thu Sep 3 05:34:16 1998 From: eric at hellman.net (Eric Hellman) Date: Mon Jun 7 17:04:22 2004 Subject: Tools to convert Word to XML? Message-ID: Sounds like what you want is RTF2HTML http://www.sunpack.com/RTF/ (Brand new version out this week!) It runs on any platform, and with custom configurations you can do precisely what you ask for. (You need Word to save as RTF, though.) Previous version have been very solid. Eric >From: Andrew Cogan >Date: Tue, 01 Sep 1998 10:28:09 -0700 >Subject: Tools to convert Word to XML? > >Can anyone recommend good tools that can convert Word files to XML? I >don't need tools that claim XML compatibility per se; any utility that >gives me control over what tag to insert at the beginning of a style and >at the end of a style would probably suffice. The ability to work with >Word footnotes is a big plus. >- -- > Andrew Cogan, Epiphany Software Eric Hellman Openly Informatics, Inc. http://www.openly.com/ Tools for 21st Century Scholarly Publishing xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From yikim at savage.comeng.chungnam.ac.kr Thu Sep 3 06:17:36 1998 From: yikim at savage.comeng.chungnam.ac.kr (=?euc-kr?B?sei/tcDPKEtpbSBZb3VuZyBJbCk=?=) Date: Mon Jun 7 17:04:23 2004 Subject: About xml Style tag Message-ID: <00db01bdd6f0$232a1ee0$bd2cbca8@hero.comeng.chungnam.ac.kr> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5665 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980903/bee56526/attachment.gif From tyler at infinet.com Thu Sep 3 15:15:46 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:23 2004 Subject: XML tools and big documents References: <005c01bdd6d3$04ed3560$2ee044c6@arcot-main> Message-ID: <35EE96CC.B0115079@infinet.com> Don Park wrote: > >For my implementation, for ot.xml (a 4 meg document) only about 1-2 megs of > RAM > >is used to store the 4 meg file in RAM due to all Names being cached at the > >parser level. It also takes only 10-12 seconds with a P-120 running > Symantec's > > My test results were from running on Atari 800 (just kidding ). My test > machine is Pentium-133 with JDK 1.1.6 with JIT enabled. Building DOM is a > slow process but there are intermediate forms I am investigating which cuts > down DOM loading drastically. Most of all of the hard work of building the DOM tree is already done by the parser. Right now with the current state of Java, the single most important thing I have found that you can do to speed up building the DOM tree is to only allocate memory for container structures like Arrays, Vectors, or other utility Collection classes as needed. In other words, an leaf-node should not have any memory allocated for storing children. As for the memory issue, I have thought about some sort of LZW compression of all of the text in a document tree. This would save a lot of memory, but may slow down building the DOM tree a bit. Any ideas on this? > >JIT for JDK 1.2 b4 to build the entire DOM tree. For spitting out the DOM > tree > >(and normalizing all the Text nodes) it takes about 15-20 seconds of which > 5 > >seconds is spent normalizing text nodes and most of the rest of this time > is > >actually spent in a brute force search and replace method that scans all > >character data and attribute values and replaces any occurrences of entity > values > >with entity names. This can be very expensive but I know no other way > around it. > > Why are you normalizing text nodes before writing them out? Also, blindly > replacing entity values with entity names is error prone. In general I agree with this, and this sort of stuff should be done at the application level. Nevertheless, the programmer I feel should have a choice whether to manually do this or let the formatter do all of the hard work. As for the text nodes, they do not have to be normalized, just that in my tests I accounted for this since many people will want to normalize the document tree to make the output look pretty. 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 donpark at quake.net Thu Sep 3 15:45:25 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:23 2004 Subject: XML tools and big documents Message-ID: <003601bdd73f$b66b51c0$2ee044c6@arcot-main> >As for the memory issue, I have thought about some sort of LZW compression of all >of the text in a document tree. This would save a lot of memory, but may slow >down building the DOM tree a bit. Any ideas on this? Your performance will suffer and memory problem still remains. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Sep 3 16:07:30 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:23 2004 Subject: XML tools and big documents In-Reply-To: <003601bdd73f$b66b51c0$2ee044c6@arcot-main> References: <003601bdd73f$b66b51c0$2ee044c6@arcot-main> Message-ID: <199809031400.KAA06725@unready.megginson.com> Don Park writes: > > As for the memory issue, I have thought about some sort of LZW > > compression of all of the text in a document tree. This would > > save a lot of memory, but may slow down building the DOM tree a > > bit. Any ideas on this? > > > Your performance will suffer and memory problem still remains. Agreed. The overhead comes from the node objects, not from the text. The biggest hogs can be attributes, especially in the standard SGML DTDs which often include dozens of defaulted attributes for each document type. If you can optimise those (allocating nodes only on demand and then freeing them as soon as they're not needed), you're half-way there. The second biggest hogs are leaf elements which contain only text. If you can treat those as special cases and allocate only one object for each one instead of three (element node, node list, text node), then you're another quarter of the way there. PIs , doctype declarations, notations, etc. are rare enough that you don't gain much by optimising them. Your mileage on comments, entity references and CDATA sections may vary, but you're probably best skipping them or replacing them with their contents when you build the tree, unless your application has very specialised requirements. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nigelk at umich.edu Thu Sep 3 17:01:08 1998 From: nigelk at umich.edu (Nigel Kerr) Date: Mon Jun 7 17:04:23 2004 Subject: XML tools and big documents In-Reply-To: David Megginson's message of "Wed, 2 Sep 1998 20:53:57 -0400" References: <199809011837.UAA08308@sonne.darmstadt.gmd.de> <199809012057.QAA01820@unready.megginson.com> <199809030044.CAA05059@sonne.darmstadt.gmd.de> <199809030053.UAA04222@unready.megginson.com> Message-ID: Quoth David Megginson : > XML is for interchange -- for simple applications you can use it for > storage (as I do on my notebook), but for larger, multi-user > applications, you probably want to put it into some kind of > specialised storage, if only for the sake of revision and access > control. My interest in descriptive markup in general is in describing large, relatively static (meaning they don't get revised, usually), text collections: the many fine TEI or EAD encoding projects, for instance, the various literature collections one can get from Chadwyck-Healey, and the like (our shop here takes such things and indexes them with some version or other of OpenText for searching and structured retrieval). These are all described by SGML DTD's. I've seen discussion and work on making an XML DTD to correspond as closely as possible to the TEI, similarly with EAD. The kinds of documents these two DTD's can describe can be arbitrarily large (the average EAD finding aid is relatively small, but we have a couple pushing several megabytes). Are there then folks interested in XML for things other than interchange? Authoring, certainly, but also storage and retrieval of large text collections? To this end, I have been (in such spare time as i have) tinkering about with Mr. Clark's XP API (com.jclark.xml.tok, mostly) to write an application that will allow me to attach the logical element structure to offsets in the storage entity, so that I can consider the logical structure's relationship to points in the text without reparsing the document. I want to be able to ask questions like: "what's the most immediate containing element of offset X in file Y?" "traverse up the logical structure from offset X until a DIV element with a HEAD is found, and return me the offsets of that HEAD" Exact expression language is, uh, gee. These are the kinds of questions we could ask with "some XML query language", but if i have a gigabyte or so of variously-structured English text marked up this way, i really don't want to have to parse the document entity just to answer these kinds of simple questions. This is a weak specification of what I'm trying to do, i realize. (this all largely because i am disatisfied with the limited information of the logical tree that OpenText's sgmlrgnXX gives... ). Anyone else here interested in these kinds of problems, and using XML tools on them? Nigel Kerr nigelk@umich.edu Digital Library Production Services http://www.umdl.umich.edu/ University of Michigan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 3 17:14:12 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:23 2004 Subject: XML tools and big documents References: <003601bdd73f$b66b51c0$2ee044c6@arcot-main> Message-ID: <35EEB289.ADF0AEC8@infinet.com> Don Park wrote: > >As for the memory issue, I have thought about some sort of LZW compression > of all > >of the text in a document tree. This would save a lot of memory, but may > slow > >down building the DOM tree a bit. Any ideas on this? > > Your performance will suffer and memory problem still remains. > > Don Well the memory problem will remain but it could be reduced significantly for large redundant documents. Some people have claimed they get 97% compression of some XML documents when using popular compression utilities like Winzip. Reducing memory overhead with Names can be done at the parser level and actually is implemented in some fashion for every major parser I know of. As for character content, the idea centers largely around each text node only allocating a new String if the application requests it. The String however is created by looking up all of the character fragments stored in some sort of symbol table and then parsing the String. Then the String would be cached. Nevertheless if the text node is mutated in any way, the String reference is then set to null. On second thought this may not degrade performance too much as you will be getting the added benefit of only needing to allocate memory to store an integer array (the sequence of symbols used to parse the string from the symbol table) instead of a using a String which allocates two objects, the String object itself, and the character array contained within it. Of course this optimization is Java specific and in languages like C++ or Eiffel where heap based objects are not as expensive to deal with, this may be counter-productive. Who knows it might be counter-productive in Java. I guess there is only one way to find out unless someone has already tried this and has some insight they can lend. Most parsers and parser interfaces like SAX present the character data as characters and not as Strings. So building the DOM tree without ever needing to create any new String objects initially is very much doable. I guess the real question is: should the DOM even be used for multi-megabyte documents in the first place. Initially I thought of XML as something that would be used for two main purposes: EDI like web transactions and as a replacement for HTML. It seems like people now are using it for so many other things, many of which may not be suitable for XML's abilities. I guess the responsibility of XML tools developers is to provide the most abstract functionality possible so people can do many more things with XML than what it was intended for. Nevertheless, I think it is also a responsibility not to sell XML as the do-all solution of every computing problem known to man. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Sep 3 17:24:56 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:23 2004 Subject: XML tools and big documents References: <003601bdd73f$b66b51c0$2ee044c6@arcot-main> <199809031400.KAA06725@unready.megginson.com> Message-ID: <35EEB507.1FE6FF1E@infinet.com> David Megginson wrote: > Don Park writes: > > > > As for the memory issue, I have thought about some sort of LZW > > > compression of all of the text in a document tree. This would > > > save a lot of memory, but may slow down building the DOM tree a > > > bit. Any ideas on this? > > > > > > Your performance will suffer and memory problem still remains. > > Agreed. The overhead comes from the node objects, not from the text. > The biggest hogs can be attributes, especially in the standard SGML > DTDs which often include dozens of defaulted attributes for each > document type. If you can optimise those (allocating nodes only on > demand and then freeing them as soon as they're not needed), you're > half-way there. > > The second biggest hogs are leaf elements which contain only text. If > you can treat those as special cases and allocate only one object for > each one instead of three (element node, node list, text node), then > you're another quarter of the way there. Very true. However, in Java at least you can get around allocating a new object for the node list by having your Node implementation also implement the NodeList implementation as well. Only allocate a buffer to store the children as needed. You can do the same thing with the Element Node with regard to attributes. This saves a lot of memory and heap-based object allocation that you would have to do otherwise. Nevertheless, in Java allocating raw Objects is a memory hog to begin with. > PIs , doctype declarations, notations, etc. are rare enough that you > don't gain much by optimising them. Your mileage on comments, entity > references and CDATA sections may vary, but you're probably best > skipping them or replacing them with their contents when you build the > tree, unless your application has very specialised requirements. This is very true. For large documents both heavily document oriented or transaction oriented I still think that compressing all of the text in the document tree may have some promise. I guess before spending any more time talking about it, I should spend the necessary hours to just do it. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at ACADCOMP.SIL.ORG Thu Sep 3 17:47:35 1998 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 17:04:23 2004 Subject: XML Website - new URL Message-ID: <199809031555.KAA25626@ACADCOMP.SIL.ORG> The SGML/XML Web Page now has a new URL: http://www.oasis-open.org/cover/ Readers are asked to change links and bookmarks to the new URL - especially those links on prominent Web pages. The Web site hierarchy remains substantially unchanged, so a simple string replacement of 'http://www.oasis-open.org/cover' for 'http://www.sil.org/sgml' should suffice in most cases. The surface text in links should be edited to remove reference to the previous host site. Formerly sponsored by SIL and SoftQuad Inc., this online database for SGML/XML and related standards is now hosted by OASIS (Organization for the Advancement of Structured Information Standards). OASIS is a non-profit international consortium dedicated to the promotion of structured information processing standards, especially the SGML/XML family of languages, including XLL, XSL, DSSSL, HyTime, HTML, CGM, STEP, and others. Under OASIS sponsorship, Robin Cover's SGML/XML Web Page will remain an industry-neutral resource. It aims to provide a comprehensive and cumulative online database containing reference information and software pertaining to SGML/XML and related standards. Sincere gratitude is hereby expressed to the readers of the SGML/XML Web Page for their support over the years - providing information about updates and new resources. Your continued participation will be greatly appreciated. ------------------------------------------------------------------------- Robin Cover Email: robin@acadcomp.sil.org 6634 Sarah Drive Dallas, TX 75236 USA >>> The SGML/XML Web Page <<< Tel: +1 (972) 296-1783 (h) http://www.oasis-open.org/cover/ Tel: +1 (972) 708-7346 (w) FAX: +1 (972) 708-7380 ========================================================================= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Thu Sep 3 18:08:17 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:04:23 2004 Subject: XML tools and big documents In-Reply-To: Nigel Kerr's message of 03 Sep 1998 11:00:45 -0400 References: <199809011837.UAA08308@sonne.darmstadt.gmd.de> <199809012057.QAA01820@unready.megginson.com> <199809030044.CAA05059@sonne.darmstadt.gmd.de> <199809030053.UAA04222@unready.megginson.com> Message-ID: Nigel Kerr writes: > "what's the most immediate containing element of offset X in > file Y?" > > "traverse up the logical structure from offset X until a DIV > element with a HEAD is found, and return me the offsets of > that HEAD" > > Exact expression language is, uh, gee. These are the kinds of > questions we could ask with "some XML query language", but if i have a > gigabyte or so of variously-structured English text marked up this > way, i really don't want to have to parse the document entity just to > answer these kinds of simple questions. This is a weak specification > of what I'm trying to do, i realize. (this all largely because i am Our LT XML tool set and API were designed for precisely this sort of application (we regularly work with >1GB language SGML-encoded corpora such as the BNC). We get good performance because 1) Our parser is written in C, our search and retrieval tools use it directly via a stream-based API, only custom UI tends to get written in a scripting language which looks at whole trees; 2) We only produce tree fragments when we get to the interesting bits: our query processor is optimised to avoid building large amounts of tree unnecessarily; 3) For REALLY big datasets, we do produce and use offset-based indices. For more information, see http://www.ltg.ed.ac.uk/software/xml/. 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 peterj at wrox.com Thu Sep 3 18:22:32 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:23 2004 Subject: Browser support practicalities Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C036046@WROX3> Can anyone tell me where I can get the best info on just what Microsoft or Netscape's v.4+ web browsers are capable of (or not) w.r.t. XML? Thanks, Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Thu Sep 3 18:33:11 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:04:23 2004 Subject: Browser support practicalities In-Reply-To: <29AA5A0E3A0CD21196F300A0C9D8575C036046@WROX3> Message-ID: On Thu, 3 Sep 1998, Peter Jones wrote: > Can anyone tell me where I can get the best info on just what Microsoft > or Netscape's v.4+ web browsers are capable of (or not) w.r.t. XML? There's an overview of Netscape's v.5 plans on their Mozilla site, http://www.mozilla.org/rdf/doc/xml.html (you can probably find marketing PR blurb on their netscape.com site too...) I don't think v4.5 has much except the rdf-based smartbrowsing 'related links' system. Dan -- Daniel.Brickley@bristol.ac.uk Institute for Learning and Research Technology http://www.ilrt.bris.ac.uk/ University of Bristol, Bristol BS8 1TN, UK. tel: +44(0)117 9288478 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Thu Sep 3 18:40:08 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:23 2004 Subject: Browser support practicalities Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C036047@WROX3> Thanks, but I've seen that already. I should have been more specific. I'm after information about just how closely the browser makers have followed the DOM (now Proposed recommendation) or not. > -----Original Message----- > From: Dan Brickley [SMTP:Daniel.Brickley@bristol.ac.uk] > Sent: Thursday, September 03, 1998 5:33 PM > To: 'XML-DEV' > Subject: Re: Browser support practicalities > > > On Thu, 3 Sep 1998, Peter Jones wrote: > > > Can anyone tell me where I can get the best info on just what > Microsoft > > or Netscape's v.4+ web browsers are capable of (or not) w.r.t. XML? > > There's an overview of Netscape's v.5 plans on their Mozilla site, > http://www.mozilla.org/rdf/doc/xml.html > (you can probably find marketing PR blurb on their netscape.com site > too...) I don't think v4.5 has much except the rdf-based smartbrowsing > 'related links' system. > > Dan > > > > > -- > Daniel.Brickley@bristol.ac.uk > Institute for Learning and Research Technology > http://www.ilrt.bris.ac.uk/ > University of Bristol, Bristol BS8 1TN, UK. tel: +44(0)117 > 9288478 > > > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bunner at massquantities.com Thu Sep 3 19:44:00 1998 From: bunner at massquantities.com (Andrew Bunner) Date: Mon Jun 7 17:04:23 2004 Subject: How to put msxml to immediate use Message-ID: <199809031743.KAA00453@mail-gw.pacbell.net> If you're a web author, you've probably already played with msxsl and seen some neat possibilities. One thing that prevents msxsl from being a being a valuable tool is the fact that it doesn't expand ENTITY references. It's my belief that anyone with a Java development environment could fix this in an hour (or less). Wouldn't it be handy to do something like this... jview msxml -d lots_of_entities.xml > temp.xml msxls -i temp.xml -s style.xsl -o final_output.html If anyone with VJ++ (or something like it) wants to do the web authoring community a favor, change the way msxml behaves to print the entity itself rather than the reference when it's run with the -d option. Very brief example... -ExternalDTD.xml- This is a &foo; &bar; -EternalDTD.dtd- -bar.xml- Hello World! Would anyone be willing to modify msxml to output... This is a bar Hello World! ...instead of... This is a &foo; &bar; ...which it does now? I've done my reading and researched this and I haven't found any set of tools that will take map (.xml, .xsl) -> .html Any help, thoughts or .class files would be greatly appreciated ;) -- Andrew Andrew Bunner President, Founder Mass Quantities, Inc. Professional Supplements for the Perfect Physique http://www.massquantities.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eriblair at mediom.qc.ca Thu Sep 3 20:00:14 1998 From: eriblair at mediom.qc.ca (Eric Riblair) Date: Mon Jun 7 17:04:23 2004 Subject: Where can I found Internet Explorer 4.71... Message-ID: <199809031759.NAA17915@netra.mediom.qc.ca> Please ... can somebody help me ... Where can I found Internet Explorer 4.71... Thanks for any help ?ric Riblair, Agronome e-mail: eriblair@mediom.qc.ca xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wxie at gmswireless.com Thu Sep 3 20:06:10 1998 From: wxie at gmswireless.com (Weihong Xie) Date: Mon Jun 7 17:04:23 2004 Subject: parsing XML within HTML files Message-ID: <002701bdd764$f58dbc10$89fcd8d0@lastexit.gmswireless.com> hi, I am developing some servlet application and am looking at XML to see if I can use it to present dynamic information. AlL I want to do is in normal HTML files, there will be some customized XML tags to mark the places where dynamic values will be inserted, so when the servlet serves those pages, it will provide those values but leave the HTML text alone. The question is how I can do this, do I need a DTD that defines HTML and my customized tags or is there any XML parsers understand HTML? I am new to XML, so any advice is welcome. Thanks. Weihong. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wxie at gmswireless.com Thu Sep 3 23:22:25 1998 From: wxie at gmswireless.com (Weihong Xie) Date: Mon Jun 7 17:04:23 2004 Subject: parsing XML within HTML files Message-ID: <002e01bdd780$62e5b950$89fcd8d0@lastexit.gmswireless.com> I posted this before and was returned by mail failure. Sorry if duplicated. ---------------------------------------------------------------------------- -- hi, I am developing some servlet application and am looking at XML to see if I can use it to present dynamic information. AlL I want to do is in normal HTML files, there will be some customized XML tags to mark the places where dynamic values will be inserted, so when the servlet serves those pages, it will provide those values but leave the HTML text alone. The question is how I can do this, do I need a DTD that defines HTML and my customized tags or is there any XML parsers understand HTML? I am new to XML, so any advice is welcome. Thanks. Weihong. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Curt.Arnold at hyprotech.com Fri Sep 4 01:37:09 1998 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:04:24 2004 Subject: parsing XML within HTML files Message-ID: "Presenting XML" by Light discusses how to write HTML so that it is also valid XML. Basically you have to do things like explicitly close your paragraphs, i.e.

This is a paragraph. The following close paragraph tag is legal HTML (and required for it to be legal XML) but no HTML authoring tool would ever add it.

If that is tolerable, you could insert you special tags within the document that you replace.

This is a replace this

You wouldn't need to have a HTML DTD (but you could if you wanted). However, given all that, if you aren't interested in extracting any meaning from the XML (like the URL in the same), It would seem easier to take the approach Microsoft did with VB 6 and just use a DIV tag within your normal HTML stream and have your servlet scan and replace the "
" blocks it recognizes.

This is a

-----Original Message----- From: Weihong Xie [mailto:wxie@gmswireless.com] Sent: Thursday, September 03, 1998 4:18 PM To: Xml-Dev Subject: parsing XML within HTML files I posted this before and was returned by mail failure. Sorry if duplicated. ------------------------------------------------------------------------ ---- -- hi, I am developing some servlet application and am looking at XML to see if I can use it to present dynamic information. AlL I want to do is in normal HTML files, there will be some customized XML tags to mark the places where dynamic values will be inserted, so when the servlet serves those pages, it will provide those values but leave the HTML text alone. The question is how I can do this, do I need a DTD that defines HTML and my customized tags or is there any XML parsers understand HTML? I am new to XML, so any advice is welcome. Thanks. Weihong. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Sep 4 02:36:43 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:24 2004 Subject: ANNOUNCE: JUMBO2a2 and xml-cml.org Message-ID: <3.0.1.16.19980903013822.45f7e46c@pop3.demon.co.uk> This is to announce the release of the latest snapshot of JUMBO2 (alpha2) and also the page it's located at: xml-cml.org. xml-cml.org is the home page of the nascent Chemical Markup Forum, metamorphosing from the Open Molecular Foundation. Henry Rzepa, Steve Zara and I are involved in getting this going - hopefully more info later. JUMBO2 is an element-oriented XML-browser, in Java/Swing. Its source is freely available with the normal sort of copyright. The architecture tries to follow the specs and anticipate the possible XML-related APIs. The tension between time available and achievement is evident; there are many bits not fully finished, but I felt there was a sufficient shortage of 'browsers' that you will forgive the buglets. JUMBO2 is offered to the community as a catalyst to spawn the creation of high-quality client-side tools ('browsers'). Ideally we converge towards a set of core APIs and all that remains of my code will be the elephant-specific stuff. I have already started to get some offers of help. At present JUMBO2: - uses SAX and a range of parsers - uses Swing (tree, table, text, and various windows/widgets). Of these the text is the worst to make work - not just my opinion. - has a namespace kludge ( to provide per-element functionality. This allows a variety of client-side processes: - validation (e.g. for data values) - transformation of complex objects (e.g. molecules) - creation of element-specific rendering (forms, etc.) - vector graphics (embryonic, but so is Java until we get Java2D - I'm told JDK1.2beta4 is rather buggy) - other authoring/editing functionality - has a per-element stylesheet table editable by the reader, and a number of default styles - can analyse the elements/attributes/values in the tree and navigate to them - is not well documented The latest *.jar is mounted and the *.java should be posted soon. Follow the WWW site for incremental announcements. I haven't distributed much in the way of ex maples - there are some simple data files including graphics. Jon Bosak's Shakespeare works very well. I hope to develop the styletable approach to support things like rec.xml - you are welcome to play. **Since this is an alpha release I'd be very grateful for bug-reports, but not beginners' questions.** [I had expected that JUMBO would have been overtaken by commercial client-side browsers by now, but get the sad impression that client-side XML is not being addressed as excitingly as it could. (The idea of using XML server-side to generate PDF is underwhelming as a global revolution). There are so many really exciting things we can do with client-side tools - I would be very grateful to have more offers of help. JUMBO is critical for some of the things I need to do and I haven't yet seen much alternative. At the least I hope we can come up with some useful APIs.] 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 mikeb at amgen.com Fri Sep 4 02:54:39 1998 From: mikeb at amgen.com (Michael Brennan) Date: Mon Jun 7 17:04:24 2004 Subject: Tools to convert Word to XML? References: <35EC2EA8.E65CF9C1@epiphanysoftware.com> Message-ID: <35EF3A23.D9B460E5@amgen.com> Andrew Cogan wrote: > > Can anyone recommend good tools that can convert Word files to XML? I > don't need tools that claim XML compatibility per se; any utility that > gives me control over what tag to insert at the beginning of a style and > at the end of a style would probably suffice. The ability to work with > Word footnotes is a big plus. Inso Corporation, I believe, has a tool to convert Word documents to SGML files. I know nothing of the tool, though. I've simply seen it mentioned on their web site. ---- Michael Brennan Sr. Systems Analyst Amgen Inc. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Fri Sep 4 06:03:15 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:04:24 2004 Subject: Please..... Message-ID: <00bd01bdd7b9$8009f620$31aedccf@ix.netcom.com> >Can any one help he from where I can get >introduction of xml and other stuff. Try my tutorial at the URL below. Follow the XML link. I also list other tutorials. regards, Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com -----Original Message----- From: ruchig To: Date: Sunday, August 30, 1998 8:05 AM Subject: Please..... > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dent at highway1.com.au Fri Sep 4 07:42:15 1998 From: dent at highway1.com.au (Andy Dent) Date: Mon Jun 7 17:04:24 2004 Subject: WP conversion issues Message-ID: Possibly not immediately, but within the next few months, our XML output from the report writer is going to have to do some conversion of embedded WP formats. (We are currently planning to use the Led cross-platform WP toolkit). I've got a fairly good understanding now of how we can make XSL and XML work from our overall report layout, but I'm unsure of the idioms in converting the straight WP formatted notes. BTW something I'd like to see a lot more of are examples of markup decision making and the reasoning behind them, like the Design Patterns movement in programming. Anyway, given a lump of styled text with font changes, bolding etc, there seem to be several possible ways to map this. 1) the obvious "HTML-style" of defining tags for etc. and applying them inline, then adding the XSL definitions to match. This has a huge benefit of giving us HTML conversion in the same hit. 2) some attempt to infer a document model, and defining the stylesheet on the basis of location (eg: the word "school" within paragraph 1). This feels very awkward but delivers cleaner text with separate styles. 3) conversion to RTF and encoding as same, on the basis that this will be parsable by other tools as an embedded format in future. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Fri Sep 4 08:17:28 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:04:24 2004 Subject: WP conversion issues References: Message-ID: <35EF78CD.8BB4A586@allette.com.au> Andy Dent wrote: > BTW something I'd like to see a lot more of are examples of markup decision > making and the reasoning behind them, like the Design Patterns movement in > programming. Since you asked, my book "The XML & SGML Cookbook: Recipes for Structured Information", Charles F. Goldfarb Series on Structured Information Management, Prentice Hall, 1998, 650 pages + CD-ROM, ISBN 0-13-614-223, is the only attempt I know of to look at markup from the Design Patterns movement viewpoint. Part 2 of the book is called "Document Patterns". It has patterns for most basic structures, with discussions of when one is more appropriate than another and tips and warnings. I am not aware of any material on the internet, though there may be some general discussions, e.g. relating to design of particular structures in HTML, i.e. tables. Another possible source, targetted at explaining particular DTDs, is Dave Megginsons' "Structuring XML Documents", which you may also find useful. 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 jtauber at jtauber.com Fri Sep 4 08:20:19 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:24 2004 Subject: WP conversion issues Message-ID: <012301bdd7cc$122d49a0$bc6118cb@caleb> >BTW something I'd like to see a lot more of are examples of markup decision >making and the reasoning behind them, like the Design Patterns movement in >programming. See Rick Jelliffe's SGML/XML Cookbook or David Megginson's Structuring XML Documents ( http://www.xmlinfo.com/books/ ) >Anyway, given a lump of styled text with font changes, bolding etc, there >seem to be several possible ways to map this. > >1) the obvious "HTML-style" of defining tags for etc. and applying them >inline, then adding the XSL definitions to match. This has a huge benefit >of giving us HTML conversion in the same hit. Just look at Word97's Save as HTML to see why this isn't trivial. >2) some attempt to infer a document model, and defining the stylesheet on >the basis of location (eg: the word "school" within paragraph 1). This >feels very awkward but delivers cleaner text with separate styles. Hard to do generically. >3) conversion to RTF and encoding as same, on the basis that this will be >parsable by other tools as an embedded format in future. If you are happy to transport a presentational format around. 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 mrc at allette.com.au Fri Sep 4 10:15:55 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:04:24 2004 Subject: Tools to convert Word to XML? References: <35EC2EA8.E65CF9C1@epiphanysoftware.com> <35EF3A23.D9B460E5@amgen.com> Message-ID: <35EFA185.BB4554E1@allette.com.au> Michael Brennan wrote: > Andrew Cogan wrote: > > > Can anyone recommend good tools that can convert Word files to XML? I > > don't need tools that claim XML compatibility per se; any utility that > > gives me control over what tag to insert at the beginning of a style and > > at the end of a style would probably suffice. The ability to work with > > Word footnotes is a big plus. > > Inso Corporation, I believe, has a tool to convert Word documents to > SGML files. I know nothing of the tool, though. I've simply seen it > mentioned on their web site. I think that's DynaTag - used to get documents into DynaText quickly. I believe it works OK, though I've never used it. My pick is Rick Geimer's beerware - it can be found at http://www.sesha.com/omlette/#rtf2xml. I've tested it in the past and found it to be very good. It leaves you with valid XML ripe for the inevitable next stage of manipulation - trying to infer the nesting. It's a great way out of RTF and into something valid. Rick kindly released this under the GNU General Public License and only requests payment if you roll it into a paying project, I think. -- 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 M.H.Kay at eng.icl.co.uk Fri Sep 4 12:37:52 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:04:24 2004 Subject: XML and servlets Message-ID: <005c01bdd7f0$7cc43c00$1e09e391@mhklaptop.bra01.icl.co.uk> >[I would like] to parse these files on the server side using a servlet. >Has anybody have tried the same kind of experiment or could point me to >some valuable documentation or code to help me solve this problem. I have a couple of servlet demo applications in the SAXON package available from http://home.iclweb.com/icl2/mhkay/saxon.html They produce an HTML rendition of the Shakespeare XML documents, which must first be split into separate scenes using another sample app. I have run these servlets under Microsoft IIS using the Live Software JRUN servlet environment. I don't recall whether or not MSXML was one of the parsers I tested in this environment but any SAX parser should work. (MSXSL is a different matter, it doesn't seem to be supported server-side and is generally rather fussy about its environment). 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 Fri Sep 4 12:56:05 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:04:24 2004 Subject: XML tools and big documents Message-ID: <009701bdd7f3$24de11c0$1e09e391@mhklaptop.bra01.icl.co.uk> >To this end, I have been (in such spare time as i have) tinkering >about with Mr. Clark's XP API (com.jclark.xml.tok, mostly) to write an >application that will allow me to attach the logical element structure >to offsets in the storage entity, so that I can consider the logical >structure's relationship to points in the text without reparsing the >document I think we're all looking for a solution to the problem that a >1Mb document is too big, we don't want to parse it every time we want to look at it, but storing the fine-grained DOM representation has the opposite problem, it takes too much space and takes too long to reassemble a reasonable unit like a page. Indexing the original serial XML (say at "chapter" level) is one solution; it's essentially equivalent to my approach, which has been to split the original XML (say at "chapter" level) and store the "chapters" as separate linked XML documents. What I mean by "chapter" is typically 1-10Kb, or alternatively, a chunk of text such that the user doesn't mind pressing "Next" when he's got to the end of it. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elm at arbortext.com Fri Sep 4 16:35:22 1998 From: elm at arbortext.com (Eve L. Maler) Date: Mon Jun 7 17:04:25 2004 Subject: WP conversion issues In-Reply-To: <35EF78CD.8BB4A586@allette.com.au> References: Message-ID: <199809041435.KAA21285@doctools.com> I'm not familiar with the Design Patterns movement, but my book Developing SGML DTDs: From Text to Model to Markup (Prentice-Hall PTR, ISBN 0-13-309881-8) has a whole chapter on markup design considerations. Most of the information applies directly to XML, although the book is obviously written to full SGML. It also presents an entire methodology for markup design, again based on full SGML but equally applicable to XML. In the course of demonstrating the methodology, it covers a lot of typical design decisions and their rationales. Eve At 04:21 PM 9/4/98 +1100, Rick Jelliffe wrote: > > >Andy Dent wrote: > >> BTW something I'd like to see a lot more of are examples of markup decision >> making and the reasoning behind them, like the Design Patterns movement in >> programming. > >Since you asked, my book "The XML & SGML Cookbook: Recipes for Structured >Information", Charles F. Goldfarb Series on Structured Information Management, >Prentice Hall, 1998, 650 pages + CD-ROM, ISBN 0-13-614-223, is the only attempt >I know of to look at markup from the Design Patterns movement viewpoint. Part 2 >of the book is called "Document Patterns". It has patterns for most basic >structures, with discussions of when one is more appropriate than another and >tips and warnings. > >I am not aware of any material on the internet, though there may be some general >discussions, e.g. relating to design of particular structures in HTML, i.e. >tables. > > Another possible source, targetted at explaining particular DTDs, is Dave >Megginsons' "Structuring XML Documents", which you may also find useful. > >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 MSCALIA at kti.com Fri Sep 4 17:02:35 1998 From: MSCALIA at kti.com (Michael Scalia) Date: Mon Jun 7 17:04:25 2004 Subject: Tools to convert Word to XML? Message-ID: >From: Andrew Cogan >Date: Tue, 01 Sep 1998 10:28:09 -0700 >Subject: Tools to convert Word to XML? > >Can anyone recommend good tools that can convert Word files to XML? I >don't need tools that claim XML compatibility per se; any utility that >gives me control over what tag to insert at the beginning of a style and >at the end of a style would probably suffice. The ability to work with >Word footnotes is a big plus. >- -- > Andrew Cogan, Epiphany Software Andrew, Check out "Ace" from RMIT in Melbourne, Australia. Freely downloadable at http://ace.mds.rmit.edu.au/adl. Ace can convert RTF and does a lot more. To convert RTF to SGML in Ace: String bufRTF := readFile(rtfFile); String bufSGML := bufRTF.rtfToSgml(); Then you can stream through the SGML, to modify and insert tags as you wish. Can also create an in-memory parse tree. You can choose to parse as SGML or XML. Michael xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Sep 4 18:02:59 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:25 2004 Subject: Notation Declarations? Message-ID: <35F00F7D.2F6CF07A@infinet.com> Unlike the specification for Element Declarations, Entity Declarations, and Attribute List declarations, there is nothing that I can find on Notations which says what you are supposed to do if a Notation with a particular Name is declared more than once. Basically I am just wondering if you should: (1) Replace the old NotationDecl with the new NotationDecl (2) Ignore all new NotationDecls after the first encountered NotationDecl has been declared (3) Throw an error One other thing I have been wondering about is how best to present validity errors to the application. Many validity errors cannot be found in a stream-based parser until the end of the document has been reached, so in a lot of ways it would make sense to batch all validation errors in a list and present them to the application at the end of the document. >From what I have already been told, the spec says nothing about how a validating processor is supposed to present validity errors, just that they are to be presented as recoverable errors in some fashion. Thanx in advance, 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 larsga at ifi.uio.no Fri Sep 4 23:06:20 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:25 2004 Subject: parsing XML within HTML files In-Reply-To: <002701bdd764$f58dbc10$89fcd8d0@lastexit.gmswireless.com> Message-ID: <3.0.5.32.19980904230525.007bfd00@ifi.uio.no> * Weihong Xie > >AlL I want to do is in normal HTML files, there will be some customized XML >tags to mark the places where dynamic values will be inserted, so when the >servlet serves those pages, it will provide those values but leave the HTML >text alone. In that case you could probably use cpp or just write your own tool that does the substitution. Mark the places with something like $place$ and that's it. It sounds like overkill to use XML for this. >The question is how I can do this, do I need a DTD that defines >HTML and my customized tags or is there any XML parsers understand HTML? HEX does. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bunner at massquantities.com Fri Sep 4 23:39:00 1998 From: bunner at massquantities.com (Andrew Bunner) Date: Mon Jun 7 17:04:25 2004 Subject: A utility to make msxsl more useful Message-ID: <199809042138.OAA25850@mail-gw.pacbell.net> I wrote a small Perl script that can be used to preprocess XML files before sending them to msxsl. Why might you want to do this? So you can expand ENTITY references and do something like It's very basic and very small so I just attached it to this message for anyone who's interested. Here's the syntax for using it from the DOS command prompt... C:\\Perl.exe expand.pl myfile.xml > temp.xml msxsl -i myfile.xml -s myfile.xsl -o output.html myfile.xml can define entities in its internal and external DTD by saying or You can use single or double quotes. I also made it so you can include a file by saying Basically, I'm trying to find ways to make msxsl usable now. I was sort of hoping some Java programmers would leap to the rescue and turn msxml (or some equivalent parser) into type of preprocessor for msxsl but, failing that, I worked up a quick and dirty way to do what I want. Hopefully some one else will find it useful. -------------- next part -------------- main(); sub main { $xml = (&readFile($ARGV[0])); %externalEntities = &parseExternalDTD($xml); %internalEntities = &parseInternalDTD($xml); my($moreToGo) = (1); while ($moreToGo) { $moreToGo = &expandEntities(%externalEntities, %internalEntities) | &expandLinks(%externalEntities, %internalEntities); } print $xml; } # $_[0] = file name or path # returns full text of file sub readFile { my($contents); my(@fileInfo) = stat($_[0]); open(F, $_[0]) or die "Couldn't open $_[0]\n"; read F, $contents, $fileInfo[7]; close(F); return $contents; } # $_[0] full text of an XML document # returns hash of external entities and what they reference sub parseExternalDTD { # Looking for... unless ($_[0] =~ / declarations # returns entity has of names and values sub extractEntities { my($text) = $_[0]; my(%entities); my($entityName, $entityPath); # Looking for or while ($text =~ ///s) { $entities{$1} = $2; } elsif ($text =~ s///s) { ($entityName, $entityPath) = ($1, $2); $entities{$entityName} = &readFile($entityPath); } } return %entities; } # @_ is a hash of entities and what they expand to # works on global variable $xml searching for &foo; references # returns true if it was able to make any replacements sub expandEntities { my(%entities) = @_; my($gotOne) = (0); while ($xml =~ s/\&(\w+);/$entities{$1}/) { $gotOne = 1; } return $gotOne; } sub expandLinks { my($gotOne) = (0); # We're looking for... # This is not a complete implementation! A real XML processor would # look for any type of link that's defined to have SHOW="EMBED" and ACTUATE="AUTO" # ...but that's too much work for what I'm after while ($xml =~ s//&readFile($1)/se) { $gotOne = 1; } return $gotOne; } -------------- next part -------------- -- Andrew Andrew Bunner President, Founder Mass Quantities, Inc. Professional Supplements for the Perfect Physique http://www.massquantities.com From larsga at ifi.uio.no Sat Sep 5 09:21:28 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:25 2004 Subject: A utility to make msxsl more useful In-Reply-To: <199809042138.OAA25850@mail-gw.pacbell.net> Message-ID: <3.0.5.32.19980905092036.007a62c0@ifi.uio.no> * Andrew Bunner > >Basically, I'm trying to find ways to make msxsl usable now. I was sort >of hoping some Java programmers would leap to the rescue and turn msxml (or >some equivalent parser) into type of preprocessor for msxsl but, failing >that, I worked up a quick and dirty way to do what I want. Hopefully some >one else will find it useful. Andrew, there are a couple of things you should know: - MSXSL implements the old XSL proposal, which was obsoleted by the new XSL Working Draft that was released on 19980818. This means that developing new tools for MSXSL is rather pointless. - There are several other XSL tools, some of which implement the 19980818 Working Draft: --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Sat Sep 5 13:13:15 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:25 2004 Subject: Validating IDREFS... Message-ID: <3.0.5.32.19980905131219.007be900@ifi.uio.no> * Michael Kay | | * A dangling IDREF is an error; a dangling XPointer is not They are both errors, but at different levels, which IMHO makes perfect sense. To check your XPointers you have to run an XPointer checker, since XPointer is not part of XML (and IMHO shouldn't be). | That is what I mean by saying the two facilities are | incompatible. Or to put it another way, once I have made a design | choice to use IDREF or to use XPointer for the links in my | documents, I am stuck with my choice. Definitely not. As Lisa Rein points out it's easy to convert from IDREFs to XPointers. Going the other way may not be possible, since XPointer can do much that IDREFs cannot, in which case I guess that's not what you want anyway. :) | This is one of several situations in the XML family of standards | where there is more than one way of doing the same thing, and no | obvious way to choose between them. I've never felt that this was a difficult choice. For links inside the document where you can count on IDs to be present, use IDREF, for external links, links to arbitrary elements (or with even finer granularity if required) use XPointer. -- "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 larsga at ifi.uio.no Sat Sep 5 13:15:45 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:25 2004 Subject: XML-QL Message-ID: <3.0.5.32.19980905131429.007a5130@ifi.uio.no> To: Subject: References: <00e501bdd591$faef4180$1e09e391@mhklaptop.bra01.icl.co.uk> <35EBF5E5.1BB74120@technologist.com> Gcc: nnml+archive:Sendt --text follows this line-- * Paul Prescod | | It would also be useful to compare XPointer, which is a sort of | query that returns a single node. XPointer can return sets of nodes, parts of nodes and a span of nodes. Whether they can operate on a set of nodes is not stated in the current WD (it's on the list of things to be clarified), but I would assume not. But it's still useful to compare XPointer. The CSS2 selectors are also a sort of query language, and seem rather similar to XSL patterns. (I have just briefly skimmed the XSL WD so far.) In fact I think it would make very good sense for XSL patterns to extend the CSS2 selectors instead of starting again from scratch with XML query language number 3. -- "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 ruchig at iitk.ac.in Sat Sep 5 17:17:56 1998 From: ruchig at iitk.ac.in (Prashant) Date: Mon Jun 7 17:04:25 2004 Subject: This is Java question .. Message-ID: Hello Everybody: Can anybody tell me what is the Algorithm used by the Java VM Garbage-Collector ?. I am sorry to post this question in xml discussion group. Thanks Rg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Sat Sep 5 23:50:30 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:25 2004 Subject: This is Java question .. Message-ID: <002401bdd915$d68ff0a0$2ee044c6@arcot-main> >Can anybody tell me what is the Algorithm used by the Java VM >Garbage-Collector ?. I am sorry to post this question in xml >discussion group. Every Wednesday morning although they won't guarantee pickup. I would like to suggest that you search the JavaSoft site at http://www.javasoft.com or subscribe to one of the Java related mailing lists at http://www.xcf.berkeley.edu/lists.html Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 6 04:46:51 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:25 2004 Subject: ANN: Docuverse DOM SDK PR2 Released Message-ID: <003501bdd93f$3a2ac350$2ee044c6@arcot-main> Docuverse DOM SDK Preview Release 2 is now available at: http://www.docuverse.com/domsdk/index.html PR2 includes W3C DOM HTML API support and minor bug fixes. Also, as of PR2, DOM SDK can be used for commercial purpose for free. This change in licensing policy was made in response to numerous pleas, complaints, and comparisons to IBM's free commercial license for XML4J. Although comparing Docuverse to IBM is like comparing Tweety Bird to Dolly Parton IMHO, we thought the change was necessary to encourage development of DOM-based XML software. In another word, we made a mistake when we restricted commercial use before. Our appologies. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bmhughes at ozemail.com.au Sun Sep 6 09:50:42 1998 From: bmhughes at ozemail.com.au (Baden Hughes) Date: Mon Jun 7 17:04:25 2004 Subject: Word to XML : how to's are on their way Message-ID: <000001bdd96a$bed9fdc0$e83670c2@bmhmobile> Since I replied about how to take Word documents and export them with markup, there have been a lot of requests for how to do this (specifics). I'm going to put up a page or two about it in a couple of weeks, after I've managed to justify my budget for next year in the next week in the UK. Baden xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Sep 6 22:06:30 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:04:25 2004 Subject: [ANN] Silfide XML Parser in Java - 0.8 Message-ID: <199809061952.VAA06633@chimay.loria.fr> The Silfide Working Group is happy to announce the availability of the Silfide XML Parser (SXP, v0.8 - Sun Sep 6 1998 ), a release of our validating XML Parser writing in Java. The SXP entirely implements the XML 1.0 recommendation and most of its satellite recommendations: - XML Namespaces (WD 18-05-1998, the old draft) - Document Object Model Level 1 (DOM Core and XML, PR 08-08-1998) - XPointer (WD 03-03-1998) - XLink (WD 03-03-1998) SXP provides also a driver for the SAX interface (fr.loria.xml.sax.SAXDriver). Both of the XML and XPointer parsers are developed with the tool JavaCC. Changes from last revision: - Implements the DOM Proposed Recommendation 18 August, 1998 - DTD parsing has been improved (with PE inclusion) - A new NodeFilter interface (to use with, for example, an XMLTreeIterator) - some bugs has been fixed (thanks for your bug reports) - some new bugs may have been introduced (!) Java source files, java classes, some samples and documentation are freely available here: http://www.loria.fr/projets/XSilfide/EN/sxp/ SILFIDE is a project of CNRS and AUPELF-UREF. Server SILFIDE, as an interactive server, wants to offer to the whole of the French-speaking university community working starting from the language (linguists, teachers, data processing specialists...) a tool user-friendly and reasoned for the handling of electronic resources. A more detailed description of the Silfide project is available here: http://www.loria.fr/projets/XSilfide/ We are waiting for all of your comments, questions and suggestions. Pat. silfide-dev: the Silfide development mailing list, maintained/organized by Patrice Bonhomme (bonhomme@loria.fr) To subscribe, send email to listserv@loria.fr with the single message line 'SUBscribe silfide-dev Your Name'. To unsubscribe, send email to listserv@loria.fr with the single message line 'SIGnoff silfide-dev'. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Mon Sep 7 02:49:06 1998 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:04:25 2004 Subject: Tools to convert Word to XML? In-Reply-To: <35EC2EA8.E65CF9C1@epiphanysoftware.com> Message-ID: <199809070048.KAA12555@fep2.mail.ozemail.net> At 03:28 2/09/1998 , you wrote: | Can anyone recommend good tools that can convert Word files to XML? I | don't need tools that claim XML compatibility per se; any utility that | gives me control over what tag to insert at the beginning of a style and | at the end of a style would probably suffice. The ability to work with | Word footnotes is a big plus. Andrew, This may be a good candidate for a custom-written conversion. Converting RTF to SGML/XML is not too hard, particularly using a tool such as Omnimark. Cheers, James ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Mon Sep 7 09:54:39 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:04:25 2004 Subject: Fwd: Re: Announcing PrismEd (a configurable metadata editor) Message-ID: Apologies for cross posting, but this seems a useful tool! >To: Andrew Waugh >cc: meta2@mrrl.lboro.ac.uk, Andrew.Waugh@cmis.CSIRO.AU >Subject: Re: Announcing PrismEd (a configurable metadata editor) >Date: Mon, 07 Sep 1998 10:10:27 +1000 >From: Andrew Waugh >Sender: owner-meta2@net.lut.ac.uk >Precedence: bulk > >Dear all, > >On Saturday I wrote... >> Some of you may be interested in trying PrismEd. PrismEd is a >> configurable metadata editor which will cope with structured metadata >> values. Schema files are provided for Dublin Core (in French and >> English), and ANZLIC. It produces RDF, and will read the RDF it produces >> (but I don't claim that it can read arbitrary RDF!). >> >> You can view the documentation for PrismEd at >> http://www.mel.dit.csiro.au:8080/~ajw/prismEd/prismEd/help.html >> >> If you have a reasonably modern web browser (with Java 1.1), you can >> try PrismEd as an applet at >> http://www.mel.dit.csiro.au:8080/~ajw/prismEd/prismEd.html >> >> If you prefer, you can download the PrismEd class files and run it >> locally using anonymous ftp: >> ftp://weever.vic.cmis.csiro.au/staff/ajw/prismEd.jar >> >> I'd be very interested in bug reports, additional features that people >> might be interested in, etc. > >Our system administrators just turned off anonymous ftp (account >hackers :-(. To download the class files try the following URLs: > >with INTERNET EXPLORER (250K) > http://www.mel.dit.csiro.au:8080/~ajw/prismEd/prismEd.jar > >with NETSCAPE (590K) > http://www.mel.dit.csiro.au:8080/~ajw/prismEd/prismEd.tar >(Due to unfortunate interactions between our http server and Netscape, >the jar file doesn't download correctly. The TAR file can be extracted >using WinZip). > >Sorry for the confusion! > >andrew waugh > Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From byrnes at prl.research.philips.com Mon Sep 7 19:40:24 1998 From: byrnes at prl.research.philips.com (Nigel Byrnes) Date: Mon Jun 7 17:04:26 2004 Subject: Newbie Question Message-ID: <35F41AD8.7F530CD1@prl.research.philips.com> Hi I'm just getting started in the XML world and I'm working through Simon St. Laurent's book "XML: A Primer". The start of chapter 5 looks at the parsing of a simple xml document. So I type it into a text editor and parse it with MSXML only to receive the following error message: C:\msxml>jview msxml -d1 me\simple.xml Root element name must match the DOCTYPE name Location: file:/C:/msxml/me/simple.xml(10,2) Context: (Attached as an appendix to this mail is the listing of simple.xml.) From what i can gather, the error occurs at the second character in the element. The error message is telling me that the root element name must match the DOCTYPE name ["simple"]. However, i haven't being able to solve this error. I haven't got many more hairs to pull out, so can someone point in the the right direction. Many thanks, Nigel -=-=-=-=- Listing of simple.xml -=-=-=-=-=-=-=-= ]> This is an entity inside an element: &Description; -- Nigel Byrnes, Software Engineering Applications Group Philips Research Laboratories, Redhill. Tel: +44 (0)1293 815578 Surrey, Fax: +44 (0)1293 815024 RH1 5HA. UK Email: byrnes@prl.research.philips.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Mon Sep 7 20:09:29 1998 From: digitome at iol.ie (Sean Mc grath) Date: Mon Jun 7 17:04:26 2004 Subject: Newbie Question Message-ID: <1.5.4.32.19980907175356.0094c8cc@gpo.iol.ie> [Nigel Byrnes] >C:\msxml>jview msxml -d1 me\simple.xml >Root element name must match the DOCTYPE name A validating XML parser enforces the constraint that the root element of the document matches the element type name specified in the doctype. So this snippet is ok: (foo matches foo) but this is not: (foo does not match baz) Non-validating parsers, on the other hand, don't care. Sean Mc Grath http://www.digitome.com/sean.htm +353 96 47391 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Sep 7 20:16:39 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:04:26 2004 Subject: Newbie Question In-Reply-To: <35F41AD8.7F530CD1@prl.research.philips.com> Message-ID: <3.0.3.32.19980907141557.00ba07e0@nexus.polaris.net> Hi Nigel. Don't be worried about being a newbie -- nearly everyone is yet, at some level. :) At 06:41 PM 9/7/98 +0100, Nigel Byrnes wrote: >... I type it into a text editor and parse it with MSXML only to >receive the following error message: > >C:\msxml>jview msxml -d1 me\simple.xml >Root element name must match the DOCTYPE name >Location: file:/C:/msxml/me/simple.xml(10,2) >Context: >... the error occurs at the >second character in the element. The error message is >telling me that the root element name must match the DOCTYPE >name ["simple"]. However, i haven't being able to solve this >error. > > > trackNum CDATA #REQUIRED > secLevel (unclassified|classified) >"unclassified"> > >]> >This is an entity inside an element: >&Description; This should be pretty, er, simple. Your DOCTYPE declaration says that the root element of your document is the element. However, the actual document (which follows the close of the internal DTD, that is, the line containing the ]> characters) contains as its root an element called . Either change the DTD so that the root element is DOCUMENT (. Remember to keep the capitalization consistent, as (for example) an element called is *not* the same as one called . Then you should be all set. ================================================= John E. Simpson simpson@flixml.org http://www.flixml.org Just XML - coming in September from Prentice-Hall xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Mon Sep 7 22:20:33 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:26 2004 Subject: Validating IDREFS... In-Reply-To: <3.0.5.32.19980905131219.007be900@ifi.uio.no> Message-ID: <3.0.1.16.19980907185746.2a0768f6@pop3.demon.co.uk> At 13:12 05/09/98 +0200, Lars Marius Garshol wrote: > >I've never felt that this was a difficult choice. For links inside the >document where you can count on IDs to be present, use IDREF, for >external links, links to arbitrary elements (or with even finer >granularity if required) use XPointer. I have also struggled gently with this and - at present - tend not to use IDREF at all. The only - but valuable - benefit of IDREF is that it requires the parser to check presence of IDs. However I believe that the XLink approach is not to use IDREF for href so that IDREF cannot be used with XLink. Since XLink is a cornerstone of much of what I do, I can't see that I should use IDREF. Is this reasonable? 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 Mon Sep 7 22:20:39 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:26 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 Released) In-Reply-To: <003501bdd93f$3a2ac350$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980907190338.2a070b12@pop3.demon.co.uk> At 19:36 05/09/98 -0700, Don Park wrote: >Also, as of PR2, DOM SDK can be used for commercial purpose for free. This >change in licensing policy was made in response to numerous pleas, >complaints, and comparisons to IBM's free commercial license for XML4J. >Although comparing Docuverse to IBM is like comparing Tweety Bird to Dolly >Parton IMHO, we thought the change was necessary to encourage development of >DOM-based XML software. In another word, we made a mistake when we >restricted commercial use before. Our appologies. My sincere thanks for this change of policy. It can and will make an enormous difference to many of us - otherwise we end up rewriting each other's software. It is a courageous decision - as was IBM's - and should be applauded. I also think it will be a fruitful decision. I have been through the same thoughts when people have asked whether they could distribute JUMBO in their book/CDROM or whatever. I now have no problem with this, and am looking at the GPL for this purpose [comments would be much appreciated.] I think the quid-pro-quo would be to ask people to register their use with you and you may well benefit from this. P. > >Best, > >Don Park >Docuverse > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Sep 8 05:36:13 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:26 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 In-Reply-To: <3.0.1.16.19980907190338.2a070b12@pop3.demon.co.uk> from "Peter Murray-Rust" at Sep 7, 98 07:03:38 pm Message-ID: <199809080341.XAA12969@locke.ccil.org> Peter Murray-Rust scripsit: > My sincere thanks for this change of policy. It can and will make an > enormous difference to many of us - otherwise we end up rewriting each > other's software. It is a courageous decision - as was IBM's - and should > be applauded. Indeed! Unfortunately, the license is still very restrictive, disallowing modification of the DOM SDK. > I now have no problem with this, and am > looking at the GPL for this purpose [comments would be much appreciated.] I > think the quid-pro-quo would be to ask people to register their use with > you and you may well benefit from this. I would urge Don and you to look at http://www.opensource.org/intro/free, which has information on why loosening restrictions can be beneficial for everyone. The Artistic License is a good substitute for the GPL and allows you to keep control of the named product while allowing others to create differently named variations. See http://language.perl.com/misc/Artistic.html . -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Usha_R2 at verifone.com Tue Sep 8 05:44:15 1998 From: Usha_R2 at verifone.com (Usha_R2@verifone.com) Date: Mon Jun 7 17:04:26 2004 Subject: Newbie Question Message-ID: <7BA6E16CF180D111944700A0C9979DE51D4F77@blr-nt-mail2.verifone.com> Just make the Document type to be of "DOCUMENT". It will work. ------------------------------------------------------------------------ -------- ]> This is an entity inside an element: &Description; ------------------------------------------------------------------------ -------- One more clarification. When the above XML file is compiled using MSXML, in the output the parser does not substitute the contents of the Entity &Description;. Why it so? Is it a bug in MSXML parser or is there any error in ENTITIY declaration Thank you K. Usha Rani > ---------- > From: Nigel Byrnes > Reply To: Nigel Byrnes > Sent: Monday, September 07, 1998 11:11 PM > To: xml-dev@ic.ac.uk > Subject: Newbie Question > > > > Hi > > I'm just getting started in the XML world and I'm working > through Simon St. Laurent's book "XML: A Primer". The start of > chapter 5 looks at the parsing of a simple xml document. So I > type it into a text editor and parse it with MSXML only to > receive the following error message: > > C:\msxml>jview msxml -d1 me\simple.xml > Root element name must match the DOCTYPE name > Location: file:/C:/msxml/me/simple.xml(10,2) > Context: > > (Attached as an appendix to this mail is the listing of > simple.xml.) From what i can gather, the error occurs at the > second character in the element. The error message is > telling me that the root element name must match the DOCTYPE > name ["simple"]. However, i haven't being able to solve this > error. > > I haven't got many more hairs to pull out, so can someone point > in the the right direction. Many thanks, > > Nigel > > -=-=-=-=- Listing of simple.xml -=-=-=-=-=-=-=-= > > > > trackNum CDATA #REQUIRED > secLevel (unclassified|classified) > "unclassified"> > > ]> > This is an entity inside an element: > &Description; > > -- > > Nigel Byrnes, Software Engineering > Applications Group > Philips Research Laboratories, > Redhill. Tel: +44 (0)1293 815578 > Surrey, Fax: +44 (0)1293 815024 > RH1 5HA. UK Email: > byrnes@prl.research.philips.com > > > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bunner at massquantities.com Tue Sep 8 05:59:38 1998 From: bunner at massquantities.com (Andrew Bunner) Date: Mon Jun 7 17:04:26 2004 Subject: Java Script, and it's conflicts with 2.4.4 Message-ID: <199809080359.UAA11275@mail-gw.pacbell.net> The XSL Working Draft seems to make it impossible to generate an HTML file with embedded Java Script. "Impossible" might be too strong a word, but I can't find any method to get the literal character '<' into my generated file. So, if you're interested in doing Java Script comparisons, you seem to be limited to equality and inequality. I can only see three reasons for this... 1) I've missed something and there is a way to do it, but it's not obvious 2) The XSL Working Group made a gross oversight 3) There's some extremely good reason for this design decision, but it's not obvious If we're looking at case two, then I'd like to suggest a revision to section 2.4.4. Since we already have a way to generate < I think we ought to make put the literal character '<' in the generated file. If we're looking at case three, then I'd like say that, IMHO, the well-formedness of the generated document is not so important that we should prohibit the author from putting in characters that need to be there. -- Andrew Andrew Bunner President, Founder Mass Quantities, Inc. Professional Supplements for the Perfect Physique http://www.massquantities.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jeremy at omsys.com Tue Sep 8 06:18:03 1998 From: jeremy at omsys.com (Jeremy H. Griffith) Date: Mon Jun 7 17:04:26 2004 Subject: Java Script, and it's conflicts with 2.4.4 In-Reply-To: <199809080359.UAA11275@mail-gw.pacbell.net> References: <199809080359.UAA11275@mail-gw.pacbell.net> Message-ID: <3652af44.622192074@mail.together.net> On Mon, 07 Sep 1998 21:05:17 -0700, Andrew Bunner wrote: > "Impossible" might be too strong a word, but I can't find any method to >get the literal character '<' into my generated file. So, if you're >interested in doing Java Script comparisons, you seem to be limited to >equality and inequality. There's always the hack used for older browsers that suffered from the same problem... reverse the terms in the comparison and use '>'. Or is that prohibited too? -- Jeremy H. Griffith, at Omni Systems Inc. (jeremy@omsys.com) http://www.omsys.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Sep 8 06:46:22 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:26 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 Message-ID: <001f01bddae2$3caee1c0$2ee044c6@arcot-main> >Indeed! Unfortunately, the license is still very restrictive, disallowing >modification of the DOM SDK. John, Docuverse is not a non-profit organization nor is it a purely consulting-based business. We build development tools and high performance servers. It is our intention to offer free commercial quality DOM implementation to promote popularity of DOM-based software which will turn increase the need for high performance DOM implementation which we intend to introduce soon as a commercial product. To this end, it is important that we promote our API and minimize proliferation of variations so that users can simply 'plugin' the high performance version. Furthermore, we believe that extensions are better than variations and we will make sure that our API is easily extensible. Best, Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Tue Sep 8 07:01:37 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:26 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 References: <199809080341.XAA12969@locke.ccil.org> Message-ID: <35F4BA73.EA707E0C@infinet.com> John Cowan wrote: > Peter Murray-Rust scripsit: > > > My sincere thanks for this change of policy. It can and will make an > > enormous difference to many of us - otherwise we end up rewriting each > > other's software. It is a courageous decision - as was IBM's - and should > > be applauded. > > Indeed! Unfortunately, the license is still very restrictive, disallowing > modification of the DOM SDK. > > > I now have no problem with this, and am > > looking at the GPL for this purpose [comments would be much appreciated.] I > > think the quid-pro-quo would be to ask people to register their use with > > you and you may well benefit from this. > > I would urge Don and you to look at http://www.opensource.org/intro/free, which > has information on why loosening restrictions can be beneficial for > everyone. > > The Artistic License is a good substitute for the GPL and allows you > to keep control of the named product while allowing others to create > differently named variations. See http://language.perl.com/misc/Artistic.html . If you ever plan on making any money off of a product, never give it away for free. If you are not planning on ever making money on a product, then it is of the most benefit to essentially publish the source-code as is and let anyone do what they want with it. The only reasons I see for creating free software is either idealism, enhancing your personal or company reputation in the developer community, or to kill your up and coming competitors. Not charging for a product initially, and then later on (when the competition has subsided) charging for a product is about the same as marking down airline fares below cost to kill of competition and then raising them later on to insane levels. The worst way to lose face with other developers is to not be clear about your long-term plans for a product. Developers (at least the intelligent ones) will pay for a superior product that cuts down the development time of their current project so long as the licensing is clear and consistent over time. Anything less is pulling a fast one in my book... The DOM SDK license is as restrictive as Docuverse wants to make it. In the real world there is no such thing as a free lunch so you should not expect Docuverse or any other small ISV to be the angels of free software. Even though I don't plan on using the DOM SDK myself anytime soon, I think it would do the developer community more benefit in the long run if Docuverse were to charge a fair price for a commercial license so there is incentive in the future for Docuverse to do bug-fixes and updates and maybe even provide some level of support. If you look at Netscape, they have basically capitulated on improving the web browser (no incentive to improve it or add new features) and their future as a profitable company is suspect. They were a company that gave everything away for free to kill off browser competition early on and then tried to charge for it when the competition died off. Then of course, Microsoft jumped in and did to Netscape what Netscape did to everyone else. In the end, the customers lose because from this point on web browsers will likely have little innovation applied to them from this point out. In other words they will just plain suck. For those people using the DOM SDK now and who enjoy the product, I would seriously encourage these people to plea for Docuverse to charge something for a commercial license, even if it is as low as $99 so that they can have some solace in the fact that there will be future quality versions of the DOM SDK. 99$ is basically the same cost as 3 development hours for the average engineer. If 99$ is too much money to spend on any commercial product, then your whole business plan for your product needs some serious reevaluation. Small ISV's like Docuverse should not feel pressured to capitulate to the large ISV's like IBM or Microsoft who can afford to give all their tools away for free in their efforts to squelch the up and coming. If you look at the best XML tools to date you will find that they are not from the big names that we know of, rather small guys who are dedicated to quality. If we all want quality tools to work with we will all need to put our money where our mouth is one way or another. My 2 cents... 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 bunner at massquantities.com Tue Sep 8 07:50:01 1998 From: bunner at massquantities.com (Andrew Bunner) Date: Mon Jun 7 17:04:26 2004 Subject: Java Script, and it's conflicts with 2.4.4 In-Reply-To: <3652af44.622192074@mail.together.net> References: <199809080359.UAA11275@mail-gw.pacbell.net> <199809080359.UAA11275@mail-gw.pacbell.net> Message-ID: <199809080549.WAA11710@mail-gw.pacbell.net> >There's always the hack used for older browsers that suffered from >the same problem... reverse the terms in the comparison and use '>'. >Or is that prohibited too? The problem runs deeper than that. Any occurence of &,',",< or > in the style sheet or in the element content of the XML document will be escaped to &xxx; -- Andrew Andrew Bunner President, Founder Mass Quantities, Inc. Professional Supplements for the Perfect Physique http://www.massquantities.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Sep 8 07:53:04 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:26 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 In-Reply-To: <199809080341.XAA12969@locke.ccil.org> References: <3.0.1.16.19980907190338.2a070b12@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980908065237.2dbfb0d8@pop3.demon.co.uk> At 23:41 07/09/98 -0400, John Cowan wrote: > >The Artistic License is a good substitute for the GPL and allows you >to keep control of the named product while allowing others to create >differently named variations. See http://language.perl.com/misc/Artistic.html I've had a similar [private] suggestion for the AL. I saw it a few years ago and liked it but hadn't seen it since. Since I believe this is a key issue for XML it could be very useful to have somewhere that people thinking of releasing XML code could go for help. Is this an OASIS area? i.e. to provide some guidance or material of the sort 'this is what people have already done...'. IOW my motivation is something like: ' I want a simple license that allows anyone to use my source code but: to respect authors' moral rights not to include legal liability not to imply author support or responsibility for distributed versions (i.e. if someone else distributes my code, *I* don't suffer if it something goes wrong). I'd probably be quite happy to use and amend James' Clark's license but there might be small things I want to add. To be able to pick a license off the shelf would be very useful and also leads to a greater degree of community support and feeling. P. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Sep 8 08:01:32 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:26 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 Message-ID: <000c01bddaec$a82c3b50$2ee044c6@arcot-main> Tyler, >For those people using the DOM SDK now and who enjoy the product, I would seriously >encourage these people to plea for Docuverse to charge something for a commercial >license, even if it is as low as $99 so that they can have some solace in the fact >that there will be future quality versions of the DOM SDK. 99$ is basically the >same cost as 3 development hours for the average engineer. If 99$ is too much money >to spend on any commercial product, then your whole business plan for your product >needs some serious reevaluation. Small ISV's like Docuverse should not feel >pressured to capitulate to the large ISV's like IBM or Microsoft who can afford to >give all their tools away for free in their efforts to squelch the up and coming. Thanks for the thought but even if all of the hundred or so DOM SDK users I am aware of sent me a check for $99, it will not even begin to cover the cost of developing and maintaining the DOM SDK. It is also unfair to tax early developers with financial burden. They are mostly individual developers with pioneering spirits working in explorative projects which are not usually funded well. I think it makes more sense to 'invest' in encouraging these pioneers so that XML-based technologies will be widely accepted in corporations around the world. At this time, far less than 1% of data in corporations are in XML format. When the figure exceeds 10%, we will begin to see the fruits of our combined efforts. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Tue Sep 8 09:03:40 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:27 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 References: <000c01bddaec$a82c3b50$2ee044c6@arcot-main> Message-ID: <35F4D71E.C88CDDD0@infinet.com> Don Park wrote: > Tyler, > > >For those people using the DOM SDK now and who enjoy the product, I would > seriously > >encourage these people to plea for Docuverse to charge something for a > commercial > >license, even if it is as low as $99 so that they can have some solace in > the fact > >that there will be future quality versions of the DOM SDK. 99$ is > basically the > >same cost as 3 development hours for the average engineer. If 99$ is too > much money > >to spend on any commercial product, then your whole business plan for your > product > >needs some serious reevaluation. Small ISV's like Docuverse should not > feel > >pressured to capitulate to the large ISV's like IBM or Microsoft who can > afford to > >give all their tools away for free in their efforts to squelch the up and > coming. > > Thanks for the thought but even if all of the hundred or so DOM SDK users I > am aware of sent me a check for $99, it will not even begin to cover the > cost of developing and maintaining the DOM SDK. It is also unfair to tax > early developers with financial burden. They are mostly individual > developers with pioneering spirits working in explorative projects which are > not usually funded well. I think it makes more sense to 'invest' in > encouraging these pioneers so that XML-based technologies will be widely > accepted in corporations around the world. At this time, far less than 1% > of data in corporations are in XML format. When the figure exceeds 10%, we > will begin to see the fruits of our combined efforts. I agree totally here, but I think this misses the point. Large ISV's are rarely innovators, but adapters. They let all the small guys like Docuverse do all the hard work to grow the market and come up with useful implementations and marketing plans and then clone both the implementations and marketing plans and use anti-competitive business practices like giving away free software to own the market that the little guys worked so hard to create. Yes the early adopters should not be punished for developing with your product, but they should be charged something if they ever use it in a real application. Whatever you charge can then be discounted at your discretion based upon things like how active they were in beta-testing, but only give away your software for free if you never intend upon charging for it. Likewise, developers who use free-tools should accept them as is and not expect any kind of support whatsoever, nor should they expect any degree of product quality. Though this may bring about a lot of flames, for-profit organizations should not be allowed to give out free-software. What once was a great libertarian idea I feel now has become a tool of large software monopolies to protect their own turf and promote an anti-competive software market in general. Large ISV's make most of their money selling support for their own tools, not on the actual software itself. The crappier the software, the more support they sell. You would think most IT organizations would catch on, but to date they have not. They continue to buy overpriced databases (and support), overpriced computing systems and spend billions on fly-by night consultants that would be unnecessary if the software was robust in the first place. When a large ISV gives away free software, it is a simple bait and trap. You should be able to take a company to court and sue for damages if you can prove that they are willing to lose money on a software product solely to win market-share. These sort of practices are bad for the software industry and discourage entrepreneurial endeavours in general. Anyways this is an XML-DEV list so I will try and end this thread here as the politics of the software industry have little to with promoting and developing XML in the first place... Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Tue Sep 8 10:29:10 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:04:27 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 Message-ID: <002701bddb02$85580e40$5255fea9@laforge> I think it is important to distinguish between enabling software and product. The W3C DOM is a technology enabler. A high-speed implementation is a product. The Docuverse SDK is something in between. Call it an expedient? I have been wrestling with these concepts for a while myself. I'd like to see the Coins api widly adopted. So I've tried to make use of common api (SAX and DOM), rather than provide a propriatary one. But I am driven by a need to make a profit. I hope to do this by charging a reasonable price for related development tools. The bet that I am making is that Coins will become widespread and that I can make a reasonable profit selling those tools for $99. Bill la Forge http://www.jxml.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Tue Sep 8 10:32:07 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:04:27 2004 Subject: Coins 1 release Message-ID: <002d01bddb02$e34e02c0$5255fea9@laforge> Just a quick note to say that version 1 of Coins has been completed and released: http://www.jxml.com/coins/index.html Coins is an XML-based alternative to Java Beans. Coins version 1 is available for commercial use without charge to all registered developers--see the download page for details: http://www.jxml.com/coins/download.html Coins uses both SAX and the Docuverse SDK 1.0 pr 2. Bill la Forge xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Tue Sep 8 10:53:27 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:27 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 References: <002701bddb02$85580e40$5255fea9@laforge> Message-ID: <35F4F0D9.EB9B6991@infinet.com> Bill la Forge wrote: > I think it is important to distinguish between enabling software and > product. > > The W3C DOM is a technology enabler. A high-speed implementation is a > product. The Docuverse SDK is something in between. Call it an expedient? > > I have been wrestling with these concepts for a while myself. I'd like to > see the Coins api widly adopted. So I've tried to make use of common api > (SAX and DOM), rather than provide a propriatary one. But I am driven by a > need to make a profit. I hope to do this by charging a reasonable price for > related development tools. > > The bet that I am making is that Coins will become widespread and that I can > make a reasonable profit selling those tools for $99. I haven't looked at coins too much in the last 5 months myself, but it seems like a useful tool for building parameter-driven applications that if put behind a big name software label could easily sell for $999 a seat. The biggest failure of a lot of software companies is being indecisive with pricing. Either you go for high-volume, low-margins in a general market, or else you go for low-value, high-margins in a niche market. Low-level tools like parsers generally sell in the high-volume market, while high-level software like Coins I would think is more of a niche application that some organizations would pay top-dollar for. On the other end of the spectrum, if you could prove to people that parameter-driven application development is far superior to traditional application development, then Coins may become much more pervasive allowing you to lower-the price of coins and go for volume. On a sidenote to coins, an individual developer named Jack Harich who hangs out on the Advanced-Java mailing list (I am sure you are familiar with it) has done a lot of personal research on stuff that is right up the alley of what I perceive coins to be. Maybe you two should correspond. I remember someone referring Jack to your work before, so maybe you two have already corresponded. 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 lisarein at finetuning.com Tue Sep 8 12:23:52 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:27 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 References: <199809080341.XAA12969@locke.ccil.org> <35F4BA73.EA707E0C@infinet.com> Message-ID: <35F50BAC.DA69F331@finetuning.com> I think it is very important that we all get used to the idea of giving everything away for now. As a writer and developer that has chosen the path of working harder more often for less money, this last year of working more for less has to have been the most fulfilling year of my life. I would literally not be able to even consider trying affording something like a $99 license for something like DOM SDK. That would be enough of a financial imposition to knock me right out of the game. Now, of course, being out of the game is not an option. So that means I would have to (gasp) use it without a license, pirate it, steal it, never pay my little reg fee, whatever. So be it, if necessary, to be honest. But I much prefer an open, honest, atmosphere of open source-based generosity: where everybody does the best that they can with whatever community-based tools are available -- which in our case are the best available anyway (as far as tools that "let" you think for yourself go -- don't get me started on the black box again :-) So what am I (admittedly) taking so long to say? I'm saying: don't sweat the small shit man! There are bigger fish to fry in the long run if we all stick together now and just relish in sharing knowledge for the sake of itself -- mmmmm, mmmmm, mmmmm, look at all that free knowledge and understanding -- it has a snowball effect once it gets going -- it's raising the bar in people's minds of what are acceptable software practices -- and you know as well as I do that THAT was a bar that REALLY needed to be raised -- and I for one am willing to eat a little more top ramen now if that means that we have a superior foundation for universal data interchange in the future. And the other thing to consider, for those of you who (understandably) have maybe already been biting the bullet financially for a lot longer than I've even known what an abstract data model was, is that when this stuff takes off, and it will ;-)...there are really only going to be a couple hundred people (max) that are going to really understand it well enough to implement it on the grand scale that is going to be required. And THAT is then when the capitalistic principles of supply and demand will be in our favor in a big way -- plus we'll be able to offer more practically-feasible, intellectually-fulfilling solutions, to the world and each other, precisely because we did not sacrifice quality and integrity for a quick buck early on. By taking this kind of idealistic pride in our work, we are all making a very serious investment in each others' future that is valuable in the long run. We also provide a good example to the rest of the world that it does pay to "give it away". We must foster and cherish these kinds of community-based, open development environments that may be only written about in the future -- we have been fortunate enough to have been here when much of this was "just beginning", and now it is our responsibility to do everything in our power to see that it never ends. So anyway, I'm just taking a long time to say that this is not time to get pessimistic about anything being "all for nothing," but rather it's more important than ever to continue to lead by example, and seize the day! If unlimited informational exchange is the free-love of the 90's -- I say "love is all you need". lisa Tyler Baker wrote: > > John Cowan wrote: > > > Peter Murray-Rust scripsit: > > > > > My sincere thanks for this change of policy. It can and will make an > > > enormous difference to many of us - otherwise we end up rewriting each > > > other's software. It is a courageous decision - as was IBM's - and should > > > be applauded. > > > > Indeed! Unfortunately, the license is still very restrictive, disallowing > > modification of the DOM SDK. > > > > > I now have no problem with this, and am > > > looking at the GPL for this purpose [comments would be much appreciated.] I > > > think the quid-pro-quo would be to ask people to register their use with > > > you and you may well benefit from this. > > > > I would urge Don and you to look at http://www.opensource.org/intro/free, which > > has information on why loosening restrictions can be beneficial for > > everyone. > > > > The Artistic License is a good substitute for the GPL and allows you > > to keep control of the named product while allowing others to create > > differently named variations. See http://language.perl.com/misc/Artistic.html . > > If you ever plan on making any money off of a product, never give it away for free. > If you are not planning on ever making money on a product, then it is of the most > benefit to essentially publish the source-code as is and let anyone do what they > want with it. The only reasons I see for creating free software is either idealism, > enhancing your personal or company reputation in the developer community, or to kill > your up and coming competitors. > > Not charging for a product initially, and then later on (when the competition has > subsided) charging for a product is about the same as marking down airline fares > below cost to kill of competition and then raising them later on to insane levels. > > The worst way to lose face with other developers is to not be clear about your > long-term plans for a product. Developers (at least the intelligent ones) will pay > for a superior product that cuts down the development time of their current project > so long as the licensing is clear and consistent over time. Anything less is > pulling a fast one in my book... > > The DOM SDK license is as restrictive as Docuverse wants to make it. In the real > world there is no such thing as a free lunch so you should not expect Docuverse or > any other small ISV to be the angels of free software. > > Even though I don't plan on using the DOM SDK myself anytime soon, I think it would > do the developer community more benefit in the long run if Docuverse were to charge > a fair price for a commercial license so there is incentive in the future for > Docuverse to do bug-fixes and updates and maybe even provide some level of support. > > If you look at Netscape, they have basically capitulated on improving the web > browser (no incentive to improve it or add new features) and their future as a > profitable company is suspect. They were a company that gave everything away for > free to kill off browser competition early on and then tried to charge for it when > the competition died off. Then of course, Microsoft jumped in and did to Netscape > what Netscape did to everyone else. In the end, the customers lose because from > this point on web browsers will likely have little innovation applied to them from > this point out. In other words they will just plain suck. > > For those people using the DOM SDK now and who enjoy the product, I would seriously > encourage these people to plea for Docuverse to charge something for a commercial > license, even if it is as low as $99 so that they can have some solace in the fact > that there will be future quality versions of the DOM SDK. 99$ is basically the > same cost as 3 development hours for the average engineer. If 99$ is too much money > to spend on any commercial product, then your whole business plan for your product > needs some serious reevaluation. Small ISV's like Docuverse should not feel > pressured to capitulate to the large ISV's like IBM or Microsoft who can afford to > give all their tools away for free in their efforts to squelch the up and coming. > > If you look at the best XML tools to date you will find that they are not from the > big names that we know of, rather small guys who are dedicated to quality. If we > all want quality tools to work with we will all need to put our money where our > mouth is one way or another. > > My 2 cents... > > Tyler > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Tue Sep 8 12:28:53 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:27 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 References: <000c01bddaec$a82c3b50$2ee044c6@arcot-main> <35F4D71E.C88CDDD0@infinet.com> Message-ID: <35F51037.2753FF72@finetuning.com> Tyler wrote: > Anyways this is an XML-DEV list so I will try and end this thread here as the > politics of the software industry have little to with promoting and developing > XML in the first place... exactly.....we can not let the fear-inspired patterns of the past infiltrate the purity of our vision of the future. lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arcdev at mail.matav.hu Tue Sep 8 13:02:15 1998 From: arcdev at mail.matav.hu (Attila Torcsvari) Date: Mon Jun 7 17:04:27 2004 Subject: XML tools and big documents (was: Re: Is there a size limitation on XML file given to MSXSL as input?) Message-ID: <01BDDB28.D9EAF230@p2> Fellow DOMers, have anybody tested/compared (consequently) the mem. requirements and speed of different DOM implementations? Attila Torcsvari Arcanum Development xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 14:01:24 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:27 2004 Subject: ANN: Docuverse HTML SDK 0.1 Message-ID: <001a01bddb1e$eeae3ce0$2ee044c6@arcot-main> Docuverse HTML SDK 0.1 is available at: http://www.docuverse.com/htmlsdk/index.html It is currently very small right now (about 10K ZIP file) but it contains something I am quite sure all the SAX users will want: a HTML parser with SAX driver. Actually, it does not contain a HTML parser, instead the HTML parser in the latest Swing release (1.1 Beta 2) is used. Docuverse's own HTML parser is being written but it is a painful process so this will have to do for now. A DOMReader implementation is also included. Note that with HTML SDK and DOM SDK together, you can now create DOM out of any HTML files. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Sep 8 14:01:25 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:27 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 Message-ID: <001901bddb1e$ee01a930$2ee044c6@arcot-main> Lisa, I agree with everything you said except for two things: 1. Not all of us can adopt open-source policy. 2. Top Ramen sucks. You should try Shin Ramen (available in Korean grocery stores) which is sinfully spicy and cheaper. Best, Don Park Docuverse PS: I think you just earned yourself one of those LISTRIVIA from Peter . xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Tue Sep 8 16:42:14 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:04:27 2004 Subject: Fwd: Proposal to XML-DEV: Collaborative XML Message-ID: >X-Sender: pazpmr@unix.ccc.nottingham.ac.uk >Date: Tue, 08 Sep 1998 14:40:11 +0100 >To: h.rzepa@ic.ac.uk >From: Peter Murray-Rust >Subject: Proposal to XML-DEV: Collaborative XML >Mime-Version: 1.0 > >Henry, > Please could you forward this to XML-DEV - ta. >------------------------------------------------------ > >I am continuing to miss 'real' applications of XML that I can enthuse about >to people - and I suspect others share this feeling (cf. SimonStL's posting >on cement shoes). In this message I propose that XML-DEV - a Bazaar as Eric >Raymond calls it [1] - develop a small rapid communal application to >demonstrate that XML can do new things. If you are excited by this, read on. > >IMO many killer apps will come from using XML client-side. The following >proposal requires an almost completely dumb server capable only of >re-routing XML documents. > >I propose that we develop an XML-based system for games. > >Chess is chosen as somewhere to start. It is not a killer app but the >methodology is easy to extend. It would be as easy to do it for go. Henry >and I will use it for molecular whiteboards - discussing molecules over the >WWW - for example. If you have better ideas than 2-player games, suggest >them (but be prepared to make some contribution...) > >We assume a simple XML representation of the state of a chess game (a >simple 8x8 table with characters would suffice.) A player makes a (legal) >alteration to this state and sends it as an XML document to the other >player, either through the dumb server or possibly through e-mail (I am >ignorant of whether this is a good idea). The updated state is then >recreated for the receiving player and so on. > >It is straightforward to display this with a per-element browser such as >JUMBO or (I assume) XXX from Steve Withall. The programmer has to be able to: > - display the state > - allow moves to be made (mouse, typed text, etc.) > - verify their legality (the main point of client-side code) > - send the new state to the other player. > >In JUMBO there are only about 3 modules that need to be written for such a >component: > - constructor // resets the board > - processXML() // having reached endElement() in SAX, process the subtree > - getDisplayComponent() // provide a JComponent for embedding in the browser >The rest of the code is unrelated to XML and might include verifying the >legality of moves. > >This should be fairly easy to do - it should also provide a simple >demonstrator which can be used anywhere. The palyer would have to: > > - download a browser > - download the chess.jar file > - know how to play chess. > >It would be really fun to do it with more than one browser, showing that >XML was not browser-dependent. i.e. player 1 could have JUMBO2 and player2 >could have XXX. [Of course until we get a consistent per-element API there >would be different chess classes for each browser - or each class might >have to to have multiple hooks.] > >There are several reasons why this is a useful thing to do: > - could bring in new people > - gives an easily understandable demo of XML that does something that HTML >can't do (yes, I know that you can do *anything* server-side and send the >results to an HTML form, but that misses the point of XML) > - gives us experience in per-element programming > - gives us experience of developing collaborative environments using XML. >Obviously for games with >2 players the server may have to make some >decisions but this should be a valuable area to explore. > > P. > >[1]http://sagan.earthspace.net/~esr/writings/cathedral-bazaar/ - well worth >reading as are some of the links. >----------------------------------------------------- > Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gcsfred at magma.ca Tue Sep 8 16:54:44 1998 From: gcsfred at magma.ca (Gustavo Frederico) Date: Mon Jun 7 17:04:27 2004 Subject: Fwd: Proposal to XML-DEV: Collaborative XML Message-ID: <199809081453.KAA25180@mag1.magmacom.com> I have some other questions: If you want to build this chess game for 2 players ove the net, is XML a good way to do it? Is it the best way? Why? What about a java servlet? I would like to hear more about that from you list members. On Tue, 8 Sep 1998 15:44:44 +0100, "Rzepa, Henry" wrote: > >X-Sender: pazpmr@unix.ccc.nottingham.ac.uk > >Date: Tue, 08 Sep 1998 14:40:11 +0100 > >To: h.rzepa@ic.ac.uk > >From: Peter Murray-Rust > >Subject: Proposal to XML-DEV: Collaborative XML > >Mime-Version: 1.0 > > > >Henry, > > Please could you forward this to XML-DEV - ta. > >------------------------------------------------------ > > > >I am continuing to miss 'real' applications of XML that I can enthuse about > >to people - and I suspect others share this feeling (cf. SimonStL's posting > >on cement shoes). In this message I propose that XML-DEV - a Bazaar as Eric > >Raymond calls it [1] - develop a small rapid communal application to > >demonstrate that XML can do new things. If you are excited by this, read on. > > > >IMO many killer apps will come from using XML client-side. The following > >proposal requires an almost completely dumb server capable only of > >re-routing XML documents. > > > >I propose that we develop an XML-based system for games. > > > >Chess is chosen as somewhere to start. It is not a killer app but the > >methodology is easy to extend. It would be as easy to do it for go. Henry > >and I will use it for molecular whiteboards - discussing molecules over the > >WWW - for example. If you have better ideas than 2-player games, suggest > >them (but be prepared to make some contribution...) > > [snip] > > > >There are several reasons why this is a useful thing to do: > > - could bring in new people > > - gives an easily understandable demo of XML that does something that HTML > >can't do (yes, I know that you can do *anything* server-side and send the > >results to an HTML form, but that misses the point of XML) > > - gives us experience in per-element programming > > - gives us experience of developing collaborative environments using XML. > >Obviously for games with >2 players the server may have to make some > >decisions but this should be a valuable area to explore. > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Tue Sep 8 17:16:32 1998 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:04:27 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 Message-ID: <001a01bddb3b$69663020$1a10fea9@laforge> >And the other thing to consider, for those of you who (understandably) >have maybe already been biting the bullet financially for a lot longer >than I've even known what an abstract data model was, is that when this >stuff takes off, and it will ;-)...there are really only going to be a >couple hundred people (max) that are going to really understand it well >enough to implement it on the grand scale that is going to be required. >And THAT is then when the capitalistic principles of supply and demand >will be in our favor in a big way -- plus we'll be able to offer more >practically-feasible, intellectually-fulfilling solutions, to the world >and each other, precisely because we did not sacrifice quality and >integrity for a quick buck early on. Lisa, Any product in the $99 class has got to be looking at a broad base of sales--which is what I want to do with some of the Coins add-on's like a revised mint capability. What seems to make sense to me is to price it at $99.00 for the final commercial version, but to keep it in "free beta" mode until the market is ready. (Not to mislead, JXML is also looking at other development tools that would be at a much higher price and consequently require a much smaller market.) Frankly, I'd rather be working on this stuff (only) full time and get my life back. I think it is important to set up a reasonable business model, while taking care to develop that market. There will always be a place for enabling technology. I believe in open source, too--makes for better software. And coming from The Open Group, I've seen how commercial constraints on software lead to all kinds of complications for researchers. So lets admit that it is complicated, and be sensitive in our policies. But to realize our dreams, we need the commercial side too. I for one would like to see a market develop which encouraged independent developers and small independent companies. There's got to be a better business model than trying to be bought up by Microsoft. XML is a simplifier. That makes it both pro-freeware and pro-small business. We don't need the large products to have something useable. Can we see our way as a community to a business model that truely serves all our needs? 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 lisarein at finetuning.com Tue Sep 8 17:36:13 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:27 2004 Subject: Fwd: Proposal to XML-DEV: Collaborative XML References: <199809081453.KAA25180@mag1.magmacom.com> Message-ID: <35F5583C.BD9070D4@finetuning.com> yes an xml-enabled javaservlet is the way to go! (in general :-) lisa Gustavo Frederico wrote: > > I have some other questions: > If you want to build this chess game for 2 players ove the net, is > XML a good way to do it? Is it the best way? Why? What about a java servlet? > I would like to hear more about that from you list members. > > On Tue, 8 Sep 1998 15:44:44 +0100, "Rzepa, Henry" wrote: > > >X-Sender: pazpmr@unix.ccc.nottingham.ac.uk > > >Date: Tue, 08 Sep 1998 14:40:11 +0100 > > >To: h.rzepa@ic.ac.uk > > >From: Peter Murray-Rust > > >Subject: Proposal to XML-DEV: Collaborative XML > > >Mime-Version: 1.0 > > > > > >Henry, > > > Please could you forward this to XML-DEV - ta. > > >------------------------------------------------------ > > > > > >I am continuing to miss 'real' applications of XML that I can enthuse about > > >to people - and I suspect others share this feeling (cf. SimonStL's posting > > >on cement shoes). In this message I propose that XML-DEV - a Bazaar as Eric > > >Raymond calls it [1] - develop a small rapid communal application to > > >demonstrate that XML can do new things. If you are excited by this, read on. > > > > > >IMO many killer apps will come from using XML client-side. The following > > >proposal requires an almost completely dumb server capable only of > > >re-routing XML documents. > > > > > >I propose that we develop an XML-based system for games. > > > > > >Chess is chosen as somewhere to start. It is not a killer app but the > > >methodology is easy to extend. It would be as easy to do it for go. Henry > > >and I will use it for molecular whiteboards - discussing molecules over the > > >WWW - for example. If you have better ideas than 2-player games, suggest > > >them (but be prepared to make some contribution...) > > > > [snip] > > > > > >There are several reasons why this is a useful thing to do: > > > - could bring in new people > > > - gives an easily understandable demo of XML that does something that > HTML > > >can't do (yes, I know that you can do *anything* server-side and send the > > >results to an HTML form, but that misses the point of XML) > > > - gives us experience in per-element programming > > > - gives us experience of developing collaborative environments using > XML. > > >Obviously for games with >2 players the server may have to make some > > >decisions but this should be a valuable area to explore. > > > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Sep 8 17:44:54 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:28 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 References: <3.0.1.16.19980907190338.2a070b12@pop3.demon.co.uk> <3.0.1.16.19980908065237.2dbfb0d8@pop3.demon.co.uk> Message-ID: <35F55071.7204B28C@locke.ccil.org> Peter Murray-Rust wrote: > IOW my motivation is something like: > ' I want a simple license that allows anyone to use my source code but: > to respect authors' moral rights > not to include legal liability > not to imply author support or responsibility for distributed versions > (i.e. if someone else distributes my code, *I* don't suffer if it something > goes wrong). > > I'd probably be quite happy to use and amend James' Clark's license but > there might be small things I want to add. To be able to pick a license off > the shelf would be very useful and also leads to a greater degree of > community support and feeling. James Clark's license is what is called a "BSD" license, because the BSD version of Unix is distributed under it. It's the least restrictive license: basically, anyone can do anything they want to with the code, except hike off the author's name or use his name for advertising purposes. In addition, the author must be acknowledged in uses made of the code. (That's just simple courtesy.) The Artistic License allows people to hack on the code for their own use, and distribute modified versions if they give them new names. (This guarantees, e.g., that "perl" is always Larry Wall's version, but anyone may distribute something called "emereld" that contains modified code.) The heavyweight license is the GPL, which is designed to keep code under it "forever free" by preventing anyone from distributing modified versions except under the GPL. (It does not affect the *output* of GPLed programs, nor is it forbidden for a program to be distributed both under the GPL and otherwise.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bunner at massquantities.com Tue Sep 8 18:20:28 1998 From: bunner at massquantities.com (Andrew Bunner) Date: Mon Jun 7 17:04:28 2004 Subject: Clever ideas to do toc... Message-ID: <199809081620.JAA07371@mail-gw.pacbell.net> Let's say I'm describing the hiearchy of our web site in an XML document like so... In a given section, the user has links to all the other pages in that section as well as top-level links to the other sections. In other words, I only want to "expand" the section that the user is currently in. An XML document that's a part of this hiearchy has some tag that says where it fits in. Maye 1.1.xml will have or something... (e.g. &entity-that-expands-to-site-map; In the XSL proposal, I'd have a field day writing a nifty Java Script function to do exactly this... in the new world, I'm not sure it can be done at all. The crux of the problem is that I don't know how to make the compare the contents or attribute values of one tag to the content or attribute values of another tag. It appears as though the only thing you can do is with the test attribute is test the position of a tag relative to other tags and what attributes it has. I'd like to do something like this... 1: 2: 3: 4: 5: 6: . . . Obviously, line 5 needs some work. If anyone has any ideas or suggestions on how to reach the goal of spitting out something like the table below, I would be very grateful... Section 1 Section 2 Page 2.1 Page 2.2 Section 3 -- Andrew Andrew Bunner President, Founder Mass Quantities, Inc. Professional Supplements for the Perfect Physique http://www.massquantities.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980908/2514a08a/attachment.htm From Kenneth.J.Meltsner at jci.com Tue Sep 8 19:00:54 1998 From: Kenneth.J.Meltsner at jci.com (Meltsner, Kenneth J) Date: Mon Jun 7 17:04:28 2004 Subject: Clever ideas to do toc... Message-ID: <86256679.005D502D.00@Corpnotes.JCI.Com> You could swipe a good idea from the relational database folks, and number the tree nodes sequentially, and then select a sub-tree based on a range of node numbers. I've lost the original reference (from DBMS Magazine) but here's a quick example from a similar problem: Hierarchical organizational trees: 1. Company (1,6) 2. Department A (2,4) 3. Group A1 (3,3) 4. Group A2 (4,4) 5. Department B (5,6) 6. Group B1 (6,6) This allows you to represent the whole company, hierarchical info, etc. in one table. A node that contains additional nodes can be expanded by showing the range of nodes listed for that parent node . It doesn't handle more complicated relationships, such as multiple parents, though. As I'm not enough of an XML type to be sure, should the node number and range info be shoved into an attribute (during authoring) or should it be generated as the document is parsed? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Tue Sep 8 20:19:54 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:28 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 References: <001901bddb1e$ee01a930$2ee044c6@arcot-main> Message-ID: <35F575A3.F4B6B762@infinet.com> Don Park wrote: > Lisa, > > I agree with everything you said except for two things: > > 1. Not all of us can adopt open-source policy. > 2. Top Ramen sucks. You should try Shin Ramen (available in Korean grocery > stores) which is sinfully spicy and cheaper. #2 is very true. But it is nice to have the cash floating around when you want to order a pizza. Either way all of these food products are bad for your health and if eaten in great concentrations will give you a heart attack by age 32. 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 lisarein at finetuning.com Tue Sep 8 20:30:45 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:28 2004 Subject: Licensing policies (was Re: ANN: Docuverse DOM SDK PR2 References: <001901bddb1e$ee01a930$2ee044c6@arcot-main> <35F575A3.F4B6B762@infinet.com> Message-ID: <35F5812C.AE8C2833@finetuning.com> don't worry, i add vegetables ...i don't eat the salt packet ;-) lisa Tyler Baker wrote: > > Don Park wrote: > > > Lisa, > > > > I agree with everything you said except for two things: > > > > 1. Not all of us can adopt open-source policy. > > 2. Top Ramen sucks. You should try Shin Ramen (available in Korean grocery > > stores) which is sinfully spicy and cheaper. > > #2 is very true. But it is nice to have the cash floating around when you want > to order a pizza. Either way all of these food products are bad for your health > and if eaten in great concentrations will give you a heart attack by age 32. > > Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Sep 8 21:14:07 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:28 2004 Subject: More SAX Parsers and Applications? Message-ID: <199809081913.PAA01323@unready.megginson.com> I've just added Silfide's SXP, Docuverse's HTML SDK, and JXML's Coins to the SAX 1.0 applications page: http://www.megginson.com/SAX/applications.html I'm certain that I'm missing more -- could everyone who has released SAX-based software take a glance at this page, and let me know if I have missed you or if my information is out of date? (I'm not including software that has been announced but not released.) I have a feeling that this particular HTML page will soon become a victim of SAX's success -- SAX 1.0 support is becoming so common that it's hardly worth trying to list every piece of Java or Python software that includes it. Thanks, and all the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Sep 8 22:07:25 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:28 2004 Subject: More SAX Parsers and Applications? Message-ID: <003001bddb62$eb8100e0$2ee044c6@arcot-main> David, It might be a Good Thing (tm by Tyler) to setup a SAX Service Directory Server. This way, any SAX client can find the latest and the greatest SAX parser over the Net. Just a thought. Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tgt at lanl.gov Tue Sep 8 22:20:13 1998 From: tgt at lanl.gov (Thierry Thelliez) Date: Mon Jun 7 17:04:28 2004 Subject: XML and behavior description References: <199809081913.PAA01323@unready.megginson.com> Message-ID: <35F58F1C.B7B49233@lanl.gov> Hello, I need to find a solution to exchange complex definitions. I have the following difficulties: 1- Dynamic behavior These 'Entities' can have behavior as value of their attributes. I guess I could do something like and use %script where needed but: 1-a- How can I define the language used ? something like ...in an XML or XSL file, you can post-process the generated HTML file to get back... For many of us, this is more useful than having "x < 1" get transformed to "x < 1". Those that are interested can go to http://www.massquantities.com/xml-kludges/ to download the scripts and get instructions on how to use them. If anyone knows of a better (read: not-so-hacked-up) way to do this, I'd really like to hear about it. -- Andrew Andrew Bunner President, Founder Mass Quantities, Inc. Professional Supplements for the Perfect Physique http://www.massquantities.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Wed Sep 9 07:24:43 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:04:29 2004 Subject: [ANN] Kludgey workarounds for xt In-Reply-To: <199809090121.SAA15093@mail-gw.pacbell.net> (message from Andrew Bunner on Tue, 08 Sep 1998 18:27:03 -0700) Message-ID: <199809090522.BAA11695@ruby.ora.com> [Andrew Bunner] > Some of you may have already found that you can't include <,>,&,' > or " in the element content of an XSL or XML document and expect it > to make it to a generated HTML file without getting escaped to <, > etc. The transformation part of XSL is intended to produce well-formed XML. > If anyone knows of a better (read: not-so-hacked-up) way to do > this, I'd really like to hear about it. There won't be one. In XML, " and " and equivalent. This is also true in HTML; if your browser doesn't accept x < 5 and x < 5 as equivalent, then the browser is broken. I appreciate that this is not your fault and I sympathize, but if XSL attempts to include a workaround for every existing HTML browser implementation, it will do no one any good. Please stop referring to this as an XSL hack-up instead of a broken-browser workaround, and suggesting that XSL has grossly overlooked something because of this problem. Support for pre-XML HTML was explicitly considered and rejected by the Working Group. -Chris, not speaking for the WG in any way -- 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 bunner at massquantities.com Wed Sep 9 08:14:03 1998 From: bunner at massquantities.com (Andrew Bunner) Date: Mon Jun 7 17:04:29 2004 Subject: [ANN] Kludgey workarounds for IE and Netscape In-Reply-To: <199809090522.BAA11695@ruby.ora.com> References: <199809090121.SAA15093@mail-gw.pacbell.net> Message-ID: <199809090613.XAA28064@mail-gw6.pacbell.net> >> Some of you may have already found that you can't include <,>,&,' >> or ... >The transformation part of XSL is intended to produce well-formed XML. If that was the design then it's working exactly as planned. The difference is, I'm approaching this from the stand point of how can I use XSL now to simplify web design and you've probably got a longer term view. By your (perfectly valid) definition, the major 4th generation browsers are broken. I think we can both agree that they'll be in use for quite some time, though. My goal is to produce files that are broken-browser-readable :) >Please stop referring to this as an XSL hack-up >instead of a broken-browser workaround, and suggesting that XSL has >grossly overlooked something because of this problem. I apologize if I sounded insulting--I was probably frustrated when I wrote my last message. I meant to leave open the possibility that there exists a good reason for this design decision. I question the relative importance of insisting that generated documents be well-formed. Perhaps I don't have a full understanding of what good things come from this. -- Andrew Andrew Bunner President, Founder Mass Quantities, Inc. Professional Supplements for the Perfect Physique http://www.massquantities.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ahaeckel at io-software.com Wed Sep 9 09:45:49 1998 From: ahaeckel at io-software.com (Arne Haeckel) Date: Mon Jun 7 17:04:29 2004 Subject: Fwd: Proposal to XML-DEV: Collaborative XML In-Reply-To: <35F5583C.BD9070D4@finetuning.com> Message-ID: <199809090750.JAA25178@miles.io-software.com> Lisa Rein (Lisa Rein ) wrote: > yes an xml-enabled javaservlet is the way to go! (in general :-) > > lisa Why server centric? Peer to Peer would do for a 2 players game. And a peer to peer XML based communicateion would show every one, that XML could be light weight and does not necessarily need expensive servers ;-) My design would be: Java applet for a nice User Interface and input validation, encoding of the new state in XML, transfering this XML document to the other player, decoding the state and presenting this again to the user with java applet. (There is still the question of wire protocol: http, RMI, CORBA, socket, ...) Arne -----< iO >-------------------------------------------------------------- Interactive Objects Software GmbH mailto:Arne.Haeckel@io-software.com http://www.io-software.com Basler Strasse. 63, D-79100 Freiburg, Germany Tel: [+49]-761-40073-0, Fax: [+49]-761-40073-73 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Wed Sep 9 09:48:07 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:29 2004 Subject: More SAX Parsers and Applications? Message-ID: <00d001bddbc6$28bfade0$e96118cb@caleb> -----Original Message----- From: Don Park >It might be a Good Thing (tm by Tyler) to setup a SAX Service Directory >Server. This way, any SAX client can find the latest and the greatest SAX >parser over the Net. This sort of thing is certainly the kind of thing I've been planning for xmlsoftware.com and Lars might have been thinking of it too for his site. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Wed Sep 9 09:48:06 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:29 2004 Subject: SAX Service Directory (was Re: More SAX Parsers and Applications?) Message-ID: <00d101bddbc6$29c31420$e96118cb@caleb> -----Original Message----- From: David Megginson >Don Park writes: > > > It might be a Good Thing (tm by Tyler) to setup a SAX Service > > Directory Server. This way, any SAX client can find the latest and > > the greatest SAX parser over the Net. > >It's a great idea, though it's not one that I have the time to take >on. Anyone interested in giving it a shot? Give me until the end of the week and there'll be something at: http://www.xmlsoftware.com/sax/ (note that there's nothing there at the time of writing this) James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ahaeckel at io-software.com Wed Sep 9 11:03:24 1998 From: ahaeckel at io-software.com (Arne Haeckel) Date: Mon Jun 7 17:04:29 2004 Subject: (Fwd) Re: Proposal to XML-DEV: Collaborative XML Message-ID: <199809090907.LAA25780@miles.io-software.com> ------- Forwarded Message Follows ------- Date sent: Wed, 09 Sep 1998 09:56:43 +0100 To: "Arne Haeckel" From: Peter Murray-Rust Subject: Re: Proposal to XML-DEV: Collaborative XML Thanks very much Arne - you have picked up exactly what I was getting at. [Since I can't post to XML-DEV from where I am could you please forward this reply?] At 09:53 AM 9/9/98 +0200, Arne Haeckel wrote: ARNE>Why server centric? Peer to Peer would do for a 2 players game. >And a peer to peer XML based communicateion would show every >one, that XML could be light weight and does not necessarily need >expensive servers ;-) This is the whole point. If we have a generic Peer to Peer system then the work to be done on the server is minimal and one-off. [The example of chess was simply to something that most people can relate to, but the more exciting areas are domain-specific collaborative working.] > ARNE>My design would be: Java applet for a nice User Interface and input validation, Agreed. ARNE>encoding of the new state in XML, agreed. ARNE>transfering this XML document to the other player, agreed. ARNE> decoding the state and presenting >this again to the user with java applet. (There is still the question of >wire protocol: http, RMI, CORBA, socket, ...) This is my main point - I'm not experienced enough to know what the best approach is. I am only looking for simple ones for proof of concept. I expect http would do fine for a simple demo. What would be required? [Personally I'd prefer to use Java applications simply because I haven't yet got JUMBO2/Swing running in a browser in less than exponential time.] I imagine they could be browser helper applications? P. -----< iO >-------------------------------------------------------------- Interactive Objects Software GmbH mailto:Arne.Haeckel@io-software.com http://www.io-software.com Basler Strasse. 63, D-79100 Freiburg, Germany Tel: [+49]-761-40073-0, Fax: [+49]-761-40073-73 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 9 12:18:06 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:30 2004 Subject: HTML != XML (was Re: [ANN] Kludgey workarounds for xt) In-Reply-To: <199809090522.BAA11695@ruby.ora.com> References: <199809090121.SAA15093@mail-gw.pacbell.net> <199809090522.BAA11695@ruby.ora.com> Message-ID: <199809091017.GAA00201@unready.megginson.com> Chris Maden writes: > Support for pre-XML HTML was explicitly considered and rejected by > the Working Group. Absolutely correct. Since HTML <= 4.0 is *not* XML, it is best to treat it as an output format, like PDF, TeX, RDF, Postscript, etc. -- in other words, first produce your XML, then run it through a filter (such as a SAX-based app) that does a down-translation to HTML syntax. If the XML document contains the same element types as the HTML, the translation will be very simple. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mct at foyt.indyrad.iupui.edu Wed Sep 9 15:28:19 1998 From: mct at foyt.indyrad.iupui.edu (Mark Tucker) Date: Mon Jun 7 17:04:30 2004 Subject: Shocking News: Namespaces and Non-Validation Message-ID: <199809091312.IAA06775@foyt.indyrad.iupui.edu> I was shocked to hear that namespaces invalidate validation. The problem seems to be that DTD validation does not expand prefixes, nor does it apply namespace defaulting. Can you all set me straight? (Apologies in advance to two knowledgable people who gave me advice on this subject in private. They unfortunately disagreed with each other, and now I am at a loss. I hope you'll tell me that namespaces (esp. namespace defaulting) can live peacefully with DTD validation. ) The problem arises if a document uses , with two different content models. Suppose that in the "alpha" namespace, DATE contains DAY and MONTH, while in the "beta" namespace, DATE has an attribute v. Without namespaces, would be ambiguous. It would need to satisfy two different content models. ====================: Validation works with consistent PREFIXES With prefixes, you could say (with appropriate definitions of the ALPHA and BETA prefixes) -- This 10 Sept The above would be valid, if only because a DTD processor could just ignore the namespace, and treat the element name's as ALPHA:DATE and BETA:DATE. ================: Validation fails with locally chosen prefixes Now, suppose the DTD defines xmlns:KAPPA="uri:alpha" ... and the document that uses the "uri:alpha" dtd uses the prefix ALPHA In this case the document would mention MY QUESTION: Would a DTD processor figure out that KAPPA:DATE and ALPHA:DATE are the same element, (since the expansions of KAPPA and ALPHA are the same? ================: Validation dies when namespace defaults are used And finally, DTD's seem to die completely if a document uses namespace defaulting. The DTD validator will not even attempt to think that the first refers to "uri:alpha"+DATE. But with namespace defaulting -- This is just DATE 10 Sept -- This is also just DATE a DTD processor would not figure out that should be from the "beta" DTD, and -- This 10 Sept should be checked against the "alpha" DTD. MY QUESTION: Is there any hope that namespaces and DTD's can get along? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Wed Sep 9 15:56:27 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:30 2004 Subject: Shocking News: Namespaces and Non-Validation Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C036070@WROX3> Here's how I see it (but I'm no expert). Namespaces and DTDs do get along, but only if the declarations of element types in the DTD contain qualified names (prefix:elementname) that match the names of namespaced elements in the doc entity. e.g. (and I'm not sure of the syntax here...) blah blah But if you use two versions of qual:name in the doc then, even if you define the namespace prefix to refer to a different URI in each case, the process of validation will force both versions of qual:name to conform to the same content model. So basically, avoid duplicate prefixes for validation. [For consideration of XML-DEV I don't see why the URI for the namespace prefix could not refer to the address of the DTD for the element concerned, for validation.] > -----Original Message----- > From: Mark Tucker [SMTP:mct@foyt.indyrad.iupui.edu] > Sent: Wednesday, September 09, 1998 2:13 PM > To: xml-dev@ic.ac.uk > Subject: Shocking News: Namespaces and Non-Validation > > > I was shocked to hear that namespaces invalidate validation. > > The problem seems to be that DTD validation does not expand > prefixes, nor does it apply namespace defaulting. > > Can you all set me straight? > > > > (Apologies in advance to two knowledgable people who gave me advice on > this subject in private. They unfortunately disagreed with each > other, and now I am at a loss. > > I hope you'll tell me that namespaces (esp. namespace defaulting) can > live peacefully with DTD validation. > ) > > The problem arises if a document uses , with two different > content models. Suppose that in the "alpha" namespace, DATE contains > DAY and MONTH, while in the "beta" namespace, DATE has an attribute v. > Without namespaces, would be ambiguous. It would need to > satisfy two different content models. > > ====================: Validation works with consistent PREFIXES > > With prefixes, you could say (with appropriate definitions of the > ALPHA > and BETA prefixes) > > > > -- This > 10 > Sept > > > > > > > > The above would be valid, if only because a DTD processor could just > ignore the namespace, and treat the element name's as ALPHA:DATE and > BETA:DATE. > > ================: Validation fails with locally chosen prefixes > Now, suppose the DTD defines > > xmlns:KAPPA="uri:alpha" > > ... > > and the document that uses the "uri:alpha" dtd uses the prefix ALPHA > > In this case the document would mention > > > > MY QUESTION: Would a DTD processor figure out that KAPPA:DATE > and ALPHA:DATE are the same element, (since the expansions of KAPPA > and ALPHA are the same? > > ================: Validation dies when namespace defaults are used > > And finally, DTD's seem to die completely if a document uses > namespace defaulting. The DTD validator will not even attempt > to think that the first refers to "uri:alpha"+DATE. > > > But with namespace defaulting > > > -- This is just DATE > 10 > Sept > > > > -- This is also just DATE > > > > a DTD processor would not figure out that > should be from the "beta" DTD, > and > -- This > 10 > Sept > > should be checked against the "alpha" DTD. > > > MY QUESTION: Is there any hope that namespaces and DTD's > can get along? > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Sep 9 16:17:30 1998 From: jonathan at texcel.no (Jonathan Robie) Date: Mon Jun 7 17:04:30 2004 Subject: Shocking News: Namespaces and Non-Validation In-Reply-To: <199809091312.IAA06775@foyt.indyrad.iupui.edu> Message-ID: <3.0.3.32.19980909101703.02e11b30@pop.mindspring.com> At 08:12 AM 9/9/98 -0500, Mark Tucker wrote: > >I was shocked to hear that namespaces invalidate validation. Well, not quite. As long as you specify the prefix in both the DTD and the document, you can still validate, since the prefix is basically treated as part of the element name or attribute name. >The problem seems to be that DTD validation does not expand >prefixes, nor does it apply namespace defaulting. I think we're hoping for the schema group to fix this for us. The DCD proposal, for instance, provides namespace support. For now, though, I think we're stuck with specifying the prefix in both the DTD and the document. 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 eddie.sheffield at enterworks.com Wed Sep 9 16:44:59 1998 From: eddie.sheffield at enterworks.com (Eddie Sheffield) Date: Mon Jun 7 17:04:30 2004 Subject: HTML != XML (was Re: [ANN] Kludgey workarounds for xt) References: <199809090121.SAA15093@mail-gw.pacbell.net> <199809090522.BAA11695@ruby.ora.com> <199809091017.GAA00201@unready.megginson.com> Message-ID: <35F693BC.7089E4AA@enterworks.com> But it seems that the problem isn't the HTML, but rather with SCRIPTS that might be included in the HTML. I believe that HTML defines the tags, but NOT the actual script that lies within the tags. This is where the problem is. That script might be one of many languages (javascript, jscript, vbscript, ecmascript, etc.) and knowing exactly how to properly post-process the fine would be VERY non-trivial, especially if the script itself has to generate HTML on the fly. For example: What I want: document.write("She said "Run away!""); but the generated code is: document.write("She said "Run away!""); Obviously a post-processor can't simply replace EVERY " in the line, or the script becomes invalid. But how do you know which to replace and which not? I suppose you could parse the script and try replacing the ones that are necessary for the script to be valid, but then you would need separate processors/parsers for each type of script language that might be in the script. As much as possible, a workaround would be to use external scripts that are never processed at all, but are pointed to with the optional SRC attribute on the SCRIPT tag. This only works for scripts that don't have to be dynamically generated, though. It does seem odd that with the advent of the DOM which really eases scripting and makes it much more powerful that almost simultaneously problems occur that make generating those scripts more difficult. Eddie David Megginson wrote: > Chris Maden writes: > > > Support for pre-XML HTML was explicitly considered and rejected by > > the Working Group. > > Absolutely correct. > > Since HTML <= 4.0 is *not* XML, it is best to treat it as an output > format, like PDF, TeX, RDF, Postscript, etc. -- in other words, first > produce your XML, then run it through a filter (such as a SAX-based > app) that does a down-translation to HTML syntax. If the XML document > contains the same element types as the HTML, the translation will be > very simple. > > All the best, > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamsden at us.ibm.com Wed Sep 9 17:28:49 1998 From: jamsden at us.ibm.com (Jim Amsden) Date: Mon Jun 7 17:04:30 2004 Subject: Shocking News: Namespaces and Non-Validation Message-ID: <5040100022254857000002L072*@MHS> The problem is that the namespace spec does not define the semantics of a name. specifies that prefix D corresponds to namespace DAV:, but it does not say what this means. Applications are free to treat the prefix and the namespace name in any way they desire. So the above is NOT equivalent to in any way. This isn't too surprising as DAV: and AV: are two different URIs possibly representing two different namespaces But its not so obvious that this one isn't equivalent either: In this case, the local name for the elements are the same, as are their namespaces. But the namespace spec says these are different elements having different tag names. I think this is putting misplaced implied semantics on tag name prefixes. The semantics should be on the local name and the namespace name with the prefix being a notional convenience used to indicate the namespace name. Then the prefix used in the DTD is independent of the ones used in any document that is validated by it. This allows users to use whatever prefix they need in order to avoid name collisions. If we're forced to use the same prefix as defined in the DTD in order to validate documents, the namespace spec hasn't changed anything. Names collisions will now happen because we can't use the same prefix for more than one namespace. Note that I'm not implying that tag names are the concatenation of the namespace name and the local part of the tag name as specified by WebDAV semantics, only that two elements with the same namespace name and local name are treated as the same element type. owner-xml-dev@ic.ac.uk on 09/09/98 09:27:29 AM Please respond to mct@foyt.indyrad.iupui.edu To: xml-dev@ic.ac.uk cc: Subject: Shocking News: Namespaces and Non-Validation I was shocked to hear that namespaces invalidate validation. The problem seems to be that DTD validation does not expand prefixes, nor does it apply namespace defaulting. Can you all set me straight? (Apologies in advance to two knowledgable people who gave me advice on this subject in private. They unfortunately disagreed with each other, and now I am at a loss. I hope you'll tell me that namespaces (esp. namespace defaulting) can live peacefully with DTD validation. ) The problem arises if a document uses , with two different content models. Suppose that in the "alpha" namespace, DATE contains DAY and MONTH, while in the "beta" namespace, DATE has an attribute v. Without namespaces, would be ambiguous. It would need to satisfy two different content models. ====================: Validation works with consistent PREFIXES With prefixes, you could say (with appropriate definitions of the ALPHA and BETA prefixes) -- This 10 Sept The above would be valid, if only because a DTD processor could just ignore the namespace, and treat the element name's as ALPHA:DATE and BETA:DATE. ================: Validation fails with locally chosen prefixes Now, suppose the DTD defines xmlns:KAPPA="uri:alpha" ... and the document that uses the "uri:alpha" dtd uses the prefix ALPHA In this case the document would mention MY QUESTION: Would a DTD processor figure out that KAPPA:DATE and ALPHA:DATE are the same element, (since the expansions of KAPPA and ALPHA are the same? ================: Validation dies when namespace defaults are used And finally, DTD's seem to die completely if a document uses namespace defaulting. The DTD validator will not even attempt to think that the first refers to "uri:alpha"+DATE. But with namespace defaulting -- This is just DATE 10 Sept -- This is also just DATE a DTD processor would not figure out that should be from the "beta" DTD, and -- This 10 Sept should be checked against the "alpha" DTD. MY QUESTION: Is there any hope that namespaces and DTD's can get along? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tgt at lanl.gov Wed Sep 9 18:38:07 1998 From: tgt at lanl.gov (Thierry Thelliez) Date: Mon Jun 7 17:04:30 2004 Subject: XML graphical viewer Message-ID: <35F6AC90.31270562@lanl.gov> What is the best XML viewer available today ? I am looking for a graphical view of the XML. Thanks Thierry -- ..................................................................... . Thierry Thelliez Los Alamos National Laboratory . . Email: tgt@lanl.gov CIC-15 . . Voice: (505) 665 8631 MS M310 . . Fax: (505) 665 5725 Los Alamos NM 87545 . . URL: http://www.lanl.gov/cgi-bin/phone/113845 USA . ..................................................................... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980909/0e21410b/attachment.htm From cowan at locke.ccil.org Wed Sep 9 18:51:32 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:30 2004 Subject: External subset/external PE equivalence? Message-ID: <35F6B194.1DF3DEB@locke.ccil.org> Are these guaranteed to be the same? and %hitherto-unheard-of-param-entity; ]> -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bunner at massquantities.com Wed Sep 9 20:04:23 1998 From: bunner at massquantities.com (Andrew Bunner) Date: Mon Jun 7 17:04:30 2004 Subject: HTML != XML (was Re: [ANN] Kludgey workarounds for xt) In-Reply-To: <35F693BC.7089E4AA@enterworks.com> References: <199809090121.SAA15093@mail-gw.pacbell.net> <199809090522.BAA11695@ruby.ora.com> <199809091017.GAA00201@unready.megginson.com> Message-ID: <199809091804.LAA05055@mail-gw6.pacbell.net> >It does seem odd that with the advent of the DOM which really eases scripting and >makes it much more powerful that almost simultaneously problems occur that make >generating those scripts more difficult. Odd is on way to describe it, I would say "frustrating". >> Since HTML <= 4.0 is *not* XML, it is best to treat it as an output >> format, like PDF, TeX, RDF, Postscript, etc. -- in other words, first >> produce your XML, then run it through a filter (such as a SAX-based >> app) that does a down-translation to HTML syntax. This doesn't have to be a very complicated animal. If I wanted to, I could generate something that is ~almost~ HTML by doing things like
and . From there, a one line regular expression would make my pages be readable by the major browsers. (Interesting aside, IE will display the right thing if you close a stand-along tag with />, but Netscape will not) It sounds like the smart thing to do is write an XML to HTML converter as you suggest. The scripting workaround isn't as hard as it seems. You're example of... document.write("She said "run"") ...would actually get turned into... document.write("She said &quot;run&quot;") So, if we just go through and replace all the predefined entities with the literal characters they represent, the workaround works. The fact that including a script in the generated file requires a seperate utility will, I expect, become a non-trivial barrier to the broader acceptance of XSL. I hope the working group chooses to address this in their second draft. Java Script engines are not easy things to write. I think it's unlikely that developers are going to redefine the Java Script language to interpret < as < ... my opinion (hope) is that the standard should accomodate this. -- Andrew Andrew Bunner President, Founder Mass Quantities, Inc. Professional Supplements for the Perfect Physique http://www.massquantities.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mct at foyt.indyrad.iupui.edu Wed Sep 9 20:07:34 1998 From: mct at foyt.indyrad.iupui.edu (Mark Tucker) Date: Mon Jun 7 17:04:30 2004 Subject: Namespace Prefix should be Purely Convienience Message-ID: <199809091752.MAA14874@foyt.indyrad.iupui.edu> Jim Amsden jm> The semantics should be on the local name and the namespace name jm> with the prefix being a notional convenience I agree. The prefix should be "purely notational convenience." Which makes me say: "Give us a way to write element tags with namespaces but bypassing the prefix." So, instead of xmlns:FOO="someUniqueString" we could just write <"someUniqueString":FOO> .... and be done with the problem of prefix collisions! I wish Namespaces didn't try to be so helpful! jm> Note that I'm not implying that tag names are the concatenation of the jm> namespace name and the local part of the tag name as specified by jm> WebDAV semantics, only that two elements with the same namespace name jm> and local name are treated as the same element type. If you say "two elements with the same namespace name and local name are treated as the same element type.", isn't this saying that, operationally, the "effective ELEMENT tag name" is the concatenation of the namespace string and the local tag name? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Sep 9 20:16:16 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:04:30 2004 Subject: Namespace Prefix should be Purely Convienience Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA71C@RED-MSG-08> The "effective element name" is illustrated in section 6.3 of the proposed spec. -----Original Message----- From: Mark Tucker [mailto:mct@foyt.indyrad.iupui.edu] Sent: Wednesday, September 09, 1998 10:52 AM To: xml-dev@ic.ac.uk Subject: Namespace Prefix should be Purely Convienience Jim Amsden jm> The semantics should be on the local name and the namespace name jm> with the prefix being a notional convenience I agree. The prefix should be "purely notational convenience." Which makes me say: "Give us a way to write element tags with namespaces but bypassing the prefix." So, instead of xmlns:FOO="someUniqueString" we could just write <"someUniqueString":FOO> .... and be done with the problem of prefix collisions! I wish Namespaces didn't try to be so helpful! jm> Note that I'm not implying that tag names are the concatenation of the jm> namespace name and the local part of the tag name as specified by jm> WebDAV semantics, only that two elements with the same namespace name jm> and local name are treated as the same element type. If you say "two elements with the same namespace name and local name are treated as the same element type.", isn't this saying that, operationally, the "effective ELEMENT tag name" is the concatenation of the namespace string and the local tag name? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 9 20:28:55 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:30 2004 Subject: HTML != XML (was Re: [ANN] Kludgey workarounds for xt) In-Reply-To: <199809091804.LAA05055@mail-gw6.pacbell.net> References: <199809090121.SAA15093@mail-gw.pacbell.net> <199809090522.BAA11695@ruby.ora.com> <199809091017.GAA00201@unready.megginson.com> <35F693BC.7089E4AA@enterworks.com> <199809091804.LAA05055@mail-gw6.pacbell.net> Message-ID: <199809091828.OAA02266@unready.megginson.com> Andrew Bunner writes: > Java Script engines are not easy things to > write. I think it's unlikely that developers > are going to redefine the Java Script language to interpret < as > < ... my opinion (hope) is that the standard should accomodate > this. The problem is that the HTML 4.0 DTD defines the tags, but NOT the actual script that lies within > the tags. This is where the problem is. That script might be one of many > languages (javascript, jscript, vbscript, ecmascript, etc.) and knowing exactly > how to properly post-process the fine would be VERY non-trivial, especially if > the script itself has to generate HTML on the fly. For example: > > What I want: > > document.write("She said "Run away!""); > > but the generated code is: > > document.write("She said "Run away!""); > > Obviously a post-processor can't simply replace EVERY " in the line, or the > script becomes invalid. But how do you know which to replace and which not? I > suppose you could parse the script and try replacing the ones that are necessary > for the script to be valid, but then you would need separate processors/parsers > for each type of script language that might be in the script. > > As much as possible, a workaround would be to use external scripts that are never > processed at all, but are pointed to with the optional SRC attribute on the > SCRIPT tag. This only works for scripts that don't have to be dynamically > generated, though. > > It does seem odd that with the advent of the DOM which really eases scripting and > makes it much more powerful that almost simultaneously problems occur that make > generating those scripts more difficult. > > Eddie The approach I use for the XML Formatter I have is to have a boolean setting that can be optionally set which will either auto-replace occurrences of entity values in character data and attribute values with entity names (this includes character entities) or else do none of this. Another alternative is to wrap any character data that includes processed text that is read for output which includes entity references in some special object that is essentially a flag saying do not process this stuff or even normalize it. This is what I do now for CDATA Sections and this same technique is pretty much what is used for the DOM so you can distinguish between text that can be normalized and text that should not be normalized. Maybe XT should have something like: document.writeAsIs(""); which does not auto-replace instances of <, >, &, ", '. 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 richard at goon.stg.brown.edu Thu Sep 10 02:27:15 1998 From: richard at goon.stg.brown.edu (Richard L. Goerwitz III) Date: Mon Jun 7 17:04:31 2004 Subject: Are elements allowed to nest within themselves? Message-ID: <199809100027.UAA24286@goon.stg.brown.edu> Just for future reference, this sort of question is easily answered by a validator. E.g., go to http://www.stg.brown.edu/service/xmlvalid/ and paste in a brief document like the one you posted be- fore (with a few bits of sugar to make it taste good to the validator): ]> this one that one the other one Richard Goerwitz Brown 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 jtauber at jtauber.com Thu Sep 10 06:01:56 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:31 2004 Subject: [ANN] Kludgey workarounds for IE and Netscape Message-ID: <018801bddc6f$fc2055a0$e16118cb@caleb> -----Original Message----- From: Andy Dent >The contrast with most of the tools I've looked at (and books I've read) is >to an XSL community that appear concerned with transforming one set of XML >to another. To be honest, I keep feeling there's something I've missed here >- if the transformation is just generating more XML I don't see that >containing enough information for a renderer. That's what the formatting object vocabulary is all about. You transform your XML into XML that expresses formatting objects and their properties. My software FOP, is an example that takes formatting objects and generates a PDF file. I am planning on also doing the same with Tk widgets for screen display. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Sep 10 08:25:38 1998 From: ricko at allette.com.au (Rick Jellife) Date: Mon Jun 7 17:04:31 2004 Subject: Shocking News: Namespaces and Non-Validation References: <199809091312.IAA06775@foyt.indyrad.iupui.edu> Message-ID: <35F7708D.72E0E594@allette.com.au> Mark Tucker wrote: > I was shocked to hear that namespaces invalidate validation. This is only sort-of true. > The problem seems to be that DTD validation does not expand > prefixes, nor does it apply namespace defaulting. DTD validation is completely namespace unaware. So no prefix expansion takes place.Namespaces are a layer. Namespace defaulting is superficially more disruptive to DTDs. It means that you may indeed have two element types from different schemas which would (if you used a single DTD to directly model them) have the same GI and content model. Under these circumstances, the content model would tend to become ANY, of course. But it is not really more disruptive: if you do not want to use defaulting, dont use it! Put a note in your products or documents saying "NO DEFAULTING" and encourage people not to ue it. At the moment, when you combine 2 DTDs, you have to rename element types or combine content models. The namespace procedure does not alter this, so even though it is superficially alarming, it is not much different from what happens now. 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 larsga at ifi.uio.no Thu Sep 10 08:39:03 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:31 2004 Subject: More SAX Parsers and Applications? In-Reply-To: <00d001bddbc6$28bfade0$e96118cb@caleb> Message-ID: <3.0.1.32.19980910083559.00738398@ifi.uio.no> * Don Park > >It might be a Good Thing (tm by Tyler) to setup a SAX Service Directory >Server. This way, any SAX client can find the latest and the greatest SAX >parser over the Net. * James Tauber > >This sort of thing is certainly the kind of thing I've been planning for >xmlsoftware.com and Lars might have been thinking of it too for his site. I didn't, but it's certainly a good idea. I will be evaluating the OMG COS Trader service shortly, and this looks like a possible way to make a real evaluation of it. If an ORB becomes part of JDK 1.2 we may not even need a lightweight alternative. BTW: David, if you have problems keeping track of which products support SAX you can look here: I can make an index of the products that use it as well, if you think that will be useful. I've got the information in my XML docs, I just don't use it yet. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Sep 10 12:13:47 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:04:31 2004 Subject: HTML != XML In-Reply-To: David Megginson's message of "Wed, 9 Sep 1998 14:28:05 -0400" References: <199809090121.SAA15093@mail-gw.pacbell.net> <199809090522.BAA11695@ruby.ora.com> <199809091017.GAA00201@unready.megginson.com> <35F693BC.7089E4AA@enterworks.com> <199809091804.LAA05055@mail-gw6.pacbell.net> <199809091828.OAA02266@unready.megginson.com> Message-ID: David> David Megginson 0> In article <199809091828.OAA02266@unready.megginson.com>, David 0> wrote: David> The problem is that the HTML 4.0 DTD defines the