From rc370 at columbia.edu Sat May 1 03:57:21 1999 From: rc370 at columbia.edu (Richard) Date: Mon Jun 7 17:11:35 2004 Subject: Do you need prior knowlege to learn XML Message-ID: <372A5E16.DB78CB92@columbia.edu> Do you need to have prior knowledge of html or other langauges to learn XML? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat May 1 16:38:05 1999 From: jgarrett at navix.net (Jim Garrett) Date: Mon Jun 7 17:11:35 2004 Subject: dinky/buttons in lower case 88x31 version Message-ID: <002701be93df$34ccf530$58c8c8c8@jgp400> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: new_x_009.GIF Type: image/gif Size: 27636 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990501/18fff558/new_x_009.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: new_x_009_88x31.GIF Type: image/gif Size: 2141 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990501/18fff558/new_x_009_88x31.gif From tbray at textuality.com Sat May 1 17:35:17 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:11:35 2004 Subject: XML/XSL Icons. Message-ID: <3.0.32.19990501083209.0114b1a0@pop.intergate.bc.ca> At 02:31 PM 4/30/99 +1000, Alan Kennedy wrote: >Since several people replied with suggested graphics for use as >Logos/Icons for XML and XSL, I thought it would be a good idea to >gather them all onto one page. Nice to see all this creativity, but the "powered by" text has to go. XML is per definition *internationalized* and designed for use on the WORLD WIDE web... so English slogans are really inappropriate. -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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tgraham at mulberrytech.com Sat May 1 18:33:48 1999 From: tgraham at mulberrytech.com (Tony Graham) Date: Mon Jun 7 17:11:35 2004 Subject: XML/XSL Icons. In-Reply-To: <3729322B.582840DD@iol.ie> References: <3729322B.582840DD@iol.ie> Message-ID: <14122.62003.600000.593671@menteith.com> At 30 Apr 1999 14:31 +1000, Alan Kennedy wrote: > Since several people replied with suggested graphics for use as > Logos/Icons for XML and XSL, I thought it would be a good idea to > gather them all onto one page. ... > Meantime, if anyone else has any icons to propose, feel free to > send them to me. What about icons for valid XML and well-formed XML? XML+CSS? Regards, Tony Graham ====================================================================== Tony Graham mailto:tgraham@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9632 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jelks at jelks.nu Sat May 1 23:33:37 1999 From: jelks at jelks.nu (Jelks Cabaniss) Date: Mon Jun 7 17:11:35 2004 Subject: XML/XSL Icons. In-Reply-To: <14122.62003.600000.593671@menteith.com> Message-ID: Tony Graham wrote: > > Meantime, if anyone else has any icons to propose, feel free to > > send them to me. > > What about icons for valid XML and well-formed XML? XML+CSS? What about icons for invalid and unparseable XML? ... /Jelks xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Sun May 2 01:40:17 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:11:35 2004 Subject: intercepting internal entities? References: <84285D7CF8E9D2119B1100805FD40F9F2551E6@MDYNYCMSX1> Message-ID: <372B7624.12C5EC2F@w3.org> "DuCharme, Robert" wrote: > > Here's my problem: let's say I have a document with ä in it > somewhere and auml properly declared as an internal entity in the DTD > along with the other 589 internal entities shown at > http://www.oasis-open.org/cover/xml-ISOents.txt. My application will > write to one file headed for a Windows app (in which case I want the > ä mapped to byte 228), a Mac document (where I want it mapped to > byte 138) a DOS one (byte 132), a web page ("ä") and a Bloomberg > terminal ("a"). You appear to be mixing up bytes and characters. > In SGML, we would declare auml as an SDATA entity and the conversion > tools would let me trap the internal entity event and map it > appropriately depending on the output format. Using Java and SAX, I > don't see any equivalent event to trap. Right. For the reasons that you mention. Instead, try using the same Unicode character throughout and letting the client map to whatever internal character set it may prefer, if it needs to. -- Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Sun May 2 01:40:18 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:11:37 2004 Subject: Dinky little XML and XSL GIFs for web pages? References: <8EAE75D3D142D211A45200A0C99B602393570C@ZEUS> <3728822A.407C142@finetuning.com> Message-ID: <372B7093.771B971A@w3.org> Lisa Rein wrote: > > i agree there should be an icon. but is should be TEXT-BASED! :-) > let's keep things clean, shall we? Grin. OK, so here is a *text based* icon. Indeed, it is well formed XML. Its even valid. And when gzipped, simulating the transmission size over HTTP/1.1, it is 2,687 bytes which is fair enough. I attach a PNG to show what it actually looks like. A 128color, 96 by 61 pixel GIF was 3,022 bytes, the same image was 2,620 bytes as a PNG and the 24-bit version was 3,610 bytes as a q85, 444, progressive JPEG (anything less and it looked awful. Logos are bad for jpef compression). The path data was programatically generated, and I didn't write the program, so I can't give it out yet. The rest was hand written. -------------- next part -------------- A non-text attachment was scrubbed... Name: xmlsl.png Type: image/png Size: 25065 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990502/5c7f7a5c/xmlsl.png From tbray at textuality.com Sun May 2 02:07:02 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:11:37 2004 Subject: Dinky little XML and XSL GIFs for web pages? Message-ID: <3.0.32.19990501170429.011f4460@pop.intergate.bc.ca> At 11:22 PM 5/1/99 +0200, Chris Lilley wrote: >Grin. OK, so here is a *text based* icon. Cool. Since people here presumably favor *standards based* approaches, how about an icon that pumps up real done&delivered stable standards, i.e. XML+CSS. Or XML+CSS+DOM. Or... how about just XML? -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eisen at pobox.com Sun May 2 02:15:50 1999 From: eisen at pobox.com (Jonathan Eisenzopf) Date: Mon Jun 7 17:11:37 2004 Subject: Perl-XML FAQ 1.1 Message-ID: <372B9934.C84EECC3@pobox.com> Perl XML FAQ 1.1 This FAQ contains information related to using and manipulating XML with Perl. It can be found on the Web at: http://www.perlxml.com/faq/perl-xml-faq.html Information in this FAQ is based on discussions and information transmitted to the Perl XML email list. To join, send an email to Lyris@ActiveState.com with the message: SUBSCRIBE Perl-XML. Jonathan. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Sun May 2 02:26:16 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:11:37 2004 Subject: Dinky little XML and XSL GIFs for web pages? References: <3.0.32.19990501170429.011f4460@pop.intergate.bc.ca> Message-ID: <372B9A28.40F642C9@w3.org> Tim Bray wrote: > > At 11:22 PM 5/1/99 +0200, Chris Lilley wrote: > >Grin. OK, so here is a *text based* icon. > > Cool. Since people here presumably favor *standards based* approaches, > how about an icon that pumps up real done&delivered stable standards, > i.e. XML+CSS. Or XML+CSS+DOM. Or... how about just XML? -T. It would be neat to do an icon for XML+CSS, written in XML+CSS. For just XML on its ownsome, though, I guess you can't have an icon. Well, okay, perhaps you can. Another missing icon would be the "written in XML, honest, but I transform to HTML server side and provide no link to the XML so tough luck" icon. -- Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun May 2 05:50:24 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:11:37 2004 Subject: Dinky little XML and XSL GIFs for web pages? In-Reply-To: <3.0.32.19990501170429.011f4460@pop.intergate.bc.ca> Message-ID: <3.0.5.32.19990501234817.013994b0@nexus.polaris.net> At 05:05 PM 5/1/99 -0700, Tim Bray wrote: >Or... how about just XML? -T. Sorry. "Just XML" is taken . ========================================================== John E. Simpson | The secret of eternal youth simpson@polaris.net | is arrested development. http://www.flixml.org | -- Alice Roosevelt Longworth xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun May 2 18:52:09 1999 From: jgarrett at navix.net (Jim Garrett) Date: Mon Jun 7 17:11:37 2004 Subject: where to put these dinky buttons Message-ID: <000601be94bb$8494ebe0$58c8c8c8@jgp400> ...who am I supposed to send the dinky buttons samples to so that all list members can view them... rather than continue to bog the list server down... please advise Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990502/8b4e372a/attachment.htm From jgarrett at navix.net Sun May 2 18:53:26 1999 From: jgarrett at navix.net (Jim Garrett) Date: Mon Jun 7 17:11:37 2004 Subject: dinky buttons - post3 - xml/+css 88x31 - lowercase Message-ID: <000001be94ba$8b955480$58c8c8c8@jgp400> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: new_x_008_+css_04_88x31.GIF Type: image/gif Size: 2303 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990502/42956b17/new_x_008_css_04_88x31.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: new_x_008_+css_04.GIF Type: image/gif Size: 29387 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990502/42956b17/new_x_008_css_04.gif From sean at westcar.com Sun May 2 20:12:15 1999 From: sean at westcar.com (Sean Brown) Date: Mon Jun 7 17:11:38 2004 Subject: XML/XSL Logo Announcement Message-ID: XML / XSL Logo selection Alan Kennedy and I have collaborated to provide the xml/xsl community a framework for submitting, viewing and voting on logos. http://www.iol.ie/%7ealank/xml/icons.htm Alan is maintaining the Image Gallery where you can view all of the submittied buttons, logo's and graphics. The Image Gallery also contains links to important information, and basicaly is the official home for the project. We have agreed to accept image submissions until 12 noon [EDT] Friday May 7th. Durrign the submission process you interested parties can provide valuable feedback to the image designers by casting unoffical votes and leaving comments. The unofficial votes and comments are available for anyone to view. Offical voting will open the afternoon of May 7th and continue until 12 noon [EDT] May 14th. SUBMITTING IMAGES: Please DO NOT send images to this list as file attachments! - Email them to Alan Kennedy Also, please consider that many of the subscribers to this list may not be insterested in hearing about every new image you design. Those who are interested are encouraged to check the web site Alan is maintaining regularly. -Sean Brown xml-dev@ic.ac.uk xsl-list@mullberrytech.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From stockett at quadralay.com Sun May 2 22:26:05 1999 From: stockett at quadralay.com (Stockett, Jeff) Date: Mon Jun 7 17:11:38 2004 Subject: problem using java.util.Stack with SAX Message-ID: <5C7FC46ADA5FD2118A3A00C04F8ED47B020C7F@khan.quadralay.com> Hello. I'm relatively new to Java, so please forgive if this is a simple question. I'm using SAX to render a treeview table of contens from XML where the source content looks something like: To handle tracking what level in the tree I'm at, I thought I'd use a stack so my handler is as follows: public class TOCHandler extends HandlerBase { private java.util.Stack stack; public void startElement(String name, AttributeList atts) { System.out.println("Start element: " + name); if (name.equals("tocitem")) { String text = atts.getValue("text"); if (stack.empty()) { symantec.itools.awt.TreeNode child = new symantec.itools.awt.TreeNode(text, Contents); Contents.append(child); stack.push(child); } else { symantec.itools.awt.TreeNode child = new symantec.itools.awt.TreeNode(text, Contents); symantec.itools.awt.TreeNode parent = (symantec.itools.awt.TreeNode) stack.peek(); stack.push(child); Contents.addChild(child, parent); } } } public void endElement(String name) { System.out.println("End element: " + name); if (name.equals("toc")) Contents.redraw(); if (name.equals("tocitem")) stack.pop(); } } Now I get a SAXException of type null when the first check to stack.empty() happens? What gives? This was all working fine before I added the stack, but I fail to see what I'm doing wrong. Does it have something to do with the fact that the stack methods are declared synchronized? Best Regards, Jeff Stockett Quadralay Corporation xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun May 2 22:37:42 1999 From: jgarrett at navix.net (Jim Garrett) Date: Mon Jun 7 17:11:38 2004 Subject: css dinky button w/o plus sign - as per requested Message-ID: <000401be94d9$9bdf7680$58c8c8c8@jgp400> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: new_x_008_css_05.GIF Type: image/gif Size: 28296 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990502/741a8ee6/new_x_008_css_05.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: new_x_008_css_05_88x31.GIF Type: image/gif Size: 2208 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990502/741a8ee6/new_x_008_css_05_88x31.gif From srn at techno.com Mon May 3 01:36:28 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:11:38 2004 Subject: XML Europe 99 slides Message-ID: <199905022335.SAA00518@bruno.techno.com> My slides on the industrial benefits of adopting the grove paradigm, given last week during the HyTime Track at XML Europe 99, are available at http://www.hytime.org/papers/xmle99/. I'd be happy to post other relevant materials from XML Europe, or links to them, at the hytime.org website. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Mon May 3 10:01:28 1999 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:11:38 2004 Subject: ECG data and XML Message-ID: <199905030625.IAA09015@chimay.loria.fr> I am working on a system to handle ECG (Electrocardiogram) binary data. I am using XML to manage all the meta-data (concerning identification, patient, folder, ...). I was wondering if someone else has already put his hands in this kind of data. I would like to encapsulate the ECG binary data within the XML document containing the remaining information. For instance, ECG data are stored in some external files. Thanks 4 all information, Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jalal at swol.de Mon May 3 10:11:59 1999 From: jalal at swol.de (jalal ) Date: Mon Jun 7 17:11:38 2004 Subject: problem using java.util.Stack with SAX Message-ID: On Sun, 2 May 1999 15:24:30 -0500, Stockett, Jeff wrote: > >Now I get a SAXException of type null when the first check to stack.empty() >happens? I don't see the stack being initialised anywhere... jalal xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Mon May 3 15:19:44 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:11:38 2004 Subject: Difference between a FIXED attribute vs enum with one value? Message-ID: <372DA2AD.CF277507@mitre.org> Is there any difference between versus In the first case I define an attribute xml:link to have a CDATA type that is fixed at the value "simple". In the second case I define an attribute xml:link to have an enumeration type with one possible value, and it defaults to that one value. Seems to me like these definitions are semantically equivalent. Yes? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon May 3 16:33:17 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:38 2004 Subject: Difference between a FIXED attribute vs enum with one value? References: <372DA2AD.CF277507@mitre.org> Message-ID: <372DB387.35629B65@locke.ccil.org> Roger L. Costello wrote: > In the first case I define an attribute xml:link to have a CDATA type > that is fixed at the value "simple". In the second case I define an > attribute xml:link to have an enumeration type with one possible value, > and it defaults to that one value. Seems to me like these definitions > are semantically equivalent. Yes? /Roger In this case, yes; in general, no, because enumerated values must be nmtokens, whereas a CDATA FIXED attribute can have any value, like an URL. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Mon May 3 16:37:51 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:11:38 2004 Subject: intercepting internal entities? Message-ID: <84285D7CF8E9D2119B1100805FD40F9F25521B@MDYNYCMSX1> >Instead, try using the same >Unicode character throughout and letting the client map to whatever >internal character set it may prefer, if it needs to. I can't put that much faith in the clients; the world is not yet 100% Unicode-compliant. (I mentioned the Bloomberg terminals, and I know that we're running older releases of the Mac OS.) I found out that my problem is easily solved by Java when I specify the appropriate encoding to the OutputStreamWriter. Bob DuCharme www.snee.com/bob "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Mon May 3 16:59:07 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:11:39 2004 Subject: Difference between a FIXED attribute vs enum with one value? References: <372DA2AD.CF277507@mitre.org> <372DB387.35629B65@locke.ccil.org> Message-ID: <005c01be9575$c3709480$0300000a@cygnus.uwa.edu.au> > > In the first case I define an attribute xml:link to have a CDATA type > > that is fixed at the value "simple". In the second case I define an > > attribute xml:link to have an enumeration type with one possible value, > > and it defaults to that one value. Seems to me like these definitions > > are semantically equivalent. Yes? /Roger > > In this case, yes; in general, no, because enumerated values must > be nmtokens, whereas a CDATA FIXED attribute can have any value, > like an URL. And whitespace normalisation is different, too. and will only be treated as the same in the case of the enum. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Mon May 3 17:16:08 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:11:39 2004 Subject: Example of using conditional sections? Message-ID: <372DBDF4.6E3DAFD8@mitre.org> Can someone give me a practical example of using conditional sections in a DTD? I am having a hard time seeing any real use for it. Every example that I come up with is better solved using the optional "?" operator. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 3 17:21:49 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:39 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model Message-ID: <14125.43607.286104.891452@localhost.localdomain> The more I work with RDF, the more I find it fascinating in the abstract but annoying in the concrete. The biggest problem is that RDF claims an extremely simple data model statement: subject, predicate, object but that the model does not even come close to describing what information actually appears in an RDF statement. Let's start with the most naive mapping into a Java object model: public interface RDFStatement { public abstract String getSubject (); public abstract String getPredicate (); public abstract String getObject (); } This will work fine for something like the following: Megginson Technologies statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Title" statement.getObject() => "Megginson Technologies" However, it falls apart quickly when the value of the property is a resource: statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Creator" statement.getObject() => "http://home.sprynet.com/sprynet/dmeggins/" In the first case, the object was a literal, and in the second case, the object is a resource; however, the naive interface does not make this information available. The only solution is to add a new property to the Java interface: public interface RDFStatement { public abstract String getSubject (); public abstract String getPredicate (); public abstract String getObject (); public abstract boolean objectIsResource (); } Now, for the first example, we have statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Title" statement.getObject() => "Megginson Technologies" statement.objectIsResource() => false and for the second example, we have statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Creator" statement.getObject() => "http://home.sprynet.com/sprynet/dmeggins/" statement.objectIsResource() => true Unfortunately, we're not nearly through yet. The next nasty bit comes from the aboutEachPrefix attribute. For example, here's a modified version of the first example: Megginson Technologies Now, this description no longer applies just to http://www.megginson.com/, but to *all* resources whose URIs begin with http://www.megginson.com/ (a constantly-changing set, and, in the case of CGIs or Servlets, potentially infinite). As a result, the following information is no longer sufficient: statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Title" statement.getObject() => "Megginson Technologies" statement.objectIsResource() => false We need to modify the interface once again public interface RDFStatement { public abstract String getSubject (); public abstract String getPredicate (); public abstract String getObject (); public abstract boolean subjectIsPrefix (); public abstract boolean objectIsResource (); } statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Title" statement.getObject() => "Megginson Technologies" statement.subjectIsPrefix() => true statement.objectIsResource() => false But wait -- there's more. The RDF spec states that the 'xml:lang' attribute does not modify the data model, but rather, is a property of the (underspecified) literal. Consider the following (RDF purists would perfer to use an RDF:Alt, but let's keep things simple): markup balisage statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Subject" statement.getObject() => "markup" statement.subjectIsPrefix() => true statement.objectIsResource() => false statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Subject" statement.getObject() => "balisage" statement.subjectIsPrefix() => true statement.objectIsResource() => false The language distinction is missing from our model, so we have to add yet another property to the Java interface: public interface RDFStatement { public abstract String getSubject (); public abstract String getPredicate (); public abstract String getObject (); public abstract boolean subjectIsPrefix (); public abstract boolean objectIsResource (); public abstract String getObjectLang (); } statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Subject" statement.getObject() => "markup" statement.subjectIsPrefix() => true statement.objectIsResource() => false statement.getObjectLang() => "en" statement.getSubject() => "http://www.megginson.com/" statement.getPredicate() => "http://www.purl.org/dc#Subject" statement.getObject() => "balisage" statement.subjectIsPrefix() => true statement.objectIsResource() => false statement.getObjectLang() => "fr" We're still not done. Take a look at the following: Roses are red, Violets are blue Sugar is sweet, And I love you. Since the element sets the 'rdf:parseType' attribute to "Literal", the contents of the element will not be interpreted as RDF markup. As a result, the value of this statement is a literal string: statement.getObject() => " Roses are red, Violets are blue Sugar is sweet, And I love you. " statement.objectIsLiteral() => true If I were to round-trip this back to XML, however, how would I know that it was meant to be XML markup? My software might just as easily generate the following: <poem> <line>Roses are red,</line> <line>Violets are blue</line> <line>Sugar is sweet,</line> <line>And I love you.</line> </poem> This probably isn't what I want. As a result, I have to add more information to my Java interface to note whether the literal value is meant to be read as XML markup: public interface RDFStatement { public abstract String getSubject (); public abstract String getPredicate (); public abstract String getObject (); public abstract boolean subjectIsPrefix (); public abstract boolean objectIsResource (); public abstract boolean objectIsXML (); public abstract String getObjectLang (); } At this point, it might make sense to split this out into different classes: public interface RDFComponent { public abstract String getValue (); } public interface RDFSubject extends RDFComponent { public abstract boolean isPrefix (); } public interface RDFPredicate extends RDFComponent { } public interface RDFObject extends RDFComponent { public abstract boolean isResource (); public abstract boolean isXML (); } public interface RDFStatement { public abstract RDFSubject getSubject (); public abstract RDFPredicate getPredicate (); public abstract RDFObject getObject (); } Obviously, there's a much more complex model underlying RDF than the spec lets on, and that model affects not only the ease or difficulty of implementing an object model, but also the difficult of many standard operations like queries against a collection of RDF statements and storage in a relational database. I'd love to hear from others on this list who've worked with RDF. It's full of some very good ideas, but I'm afraid that the underlying (and hidden) conceptual complexity might stunt any serious implementation. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Mon May 3 18:02:53 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:39 2004 Subject: Example of using conditional sections? References: <372DBDF4.6E3DAFD8@mitre.org> Message-ID: <372DC846.7A74D4BD@pacbell.net> "Roger L. Costello" wrote: > > Can someone give me a practical example of using conditional sections in > a DTD? I am having a hard time seeing any real use for it. Every > example that I come up with is better solved using the optional "?" > operator. /Roger Look at the XHTML modularization working draft ... conditional sections are used for conditionally including feature modules (which may not be the term from that WD!) such as XHTML tables. Only if you want that feature would you define the parameter entity so it is conditionally included. That's a typical use. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Mon May 3 18:52:40 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:11:39 2004 Subject: Experiment Message-ID: Hi, I am searching a NDS directory for an experiment. I do not have a NDS directory available. Here is the experiment: a) a XML document is parsed and its elements are stored in a grove b) The grove itself is composed of NDS objects. Each object being defined by a NDS schema. c) Each grove element is then accessed though LDAP or NDS queries. I only need access for a certain period and won't take too much memory. The experiment will be limited to small documents. Thus, I only need a root directory element with a schema named "document" (I'll provide the schema) and then all children are "documentElement" objects. email me if you have such installation and some space for the experiment. Thanks in advance, This experiment may help build bridges between two worlds ignoring each other. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Mon May 3 19:35:43 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:11:39 2004 Subject: ECG data and XML Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF416@RED-MSG-08> Patrice Bonhomme asks how to put binary data into an XML instance. Obviously, one cannot just put binary data inline without some form of encoding. Here one has choices, and no specific encoding for this purpose is presently endorsed by the W3C or IETF, though some recommendations may come from the W3C XML schemas effort. Microsoft's MSXML parser, shipped with IE5, supports MIME base64 encoding. You can read about this at http://www.microsoft.com/xml. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wperry at fiduciary.com Mon May 3 19:59:25 1999 From: wperry at fiduciary.com (W. E. Perry) Date: Mon Jun 7 17:11:39 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model References: <14125.43607.286104.891452@localhost.localdomain> Message-ID: <372DE3E1.55E5CD3D@fiduciary.com> David Megginson wrote: > Obviously, there's a much more complex model underlying RDF than the > spec lets on, and that model affects not only the ease or difficulty > of implementing an object model, but also the difficult of many > standard operations like queries against a collection of RDF > statements and storage in a relational database. May I respectfully submit that the problem is not the complexity of the model underlying RDF, but its simplicity and relative freedom from restriction, permitting the very sort of extension that leads to the implementational problems David Megginson illustrates. Or, stated from the opposite perspective, obvious real-world implementations of RDF build upon the assumption that the standard specifies, or at least implies, a more holistic view of metadata than it does. The unfortunate truth is that implementations of RDF--even as they grow step-by-step as complex as David Megginson illustrates--never model anything more than individual resources: they do not, even as a by-product, model the body of modeled resources as a whole. Effectively it is just such a cumulative body of metadata which David Megginson is seeking. It would provide the ability to refer to components larger than simple subjects, predicates and objects, such as resources as objects or prefixes as subjects. Such a framework would comprehend and permit reference to any such objects either top-down, from the perspectives of their larger containers, or bottom-up from the perspective of their sub-components. In fact, it appears that this inability to implement the innate human assumption of a larger framework, not specified by the simple details of RDF, is a shortcoming not just of RDF but of structured markup generally. Recent debates on this list about the unification of XSL and XLink revolve around symptoms of the same problem. The increasingly centrifugal nature of the whole body of XML standards could reasonably be described as the failure of building upon the details to produce as a by-product a framework which multiplies the interconnections and the interdependence among them. My own work is in implementing a database engine which operates directly upon XML markup. Its first premise is that XML markup describes, primarily, structure and that manipulating XML documents on their own terms means managing them on the terms of whatever structure the instance markup describes. From my (hardly disinterested) perspective, it is this ability which David Megginson seems to be wishing for in describing the implementational difficulties of RDF: if, for example, an object is a resource, it should be manipulable as either (and both) an object and a resource. Implementation of the simple details of RDF will not provide that, but database tools which can operate on structure described by XML markup, to whatever level of complexity, can. As David Megginson's examples illustrate, the implementation strategy implied by RDF (and other XML specification) details is agglutinative, an inherently linear process. We need implementation tools--and not just for RDF--which are also agglomerative, building a larger ball or sphere of interconnected structure from the details of instance markup as it is processed. Walter Perry xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Mon May 3 20:29:29 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:11:39 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model References: <14125.43607.286104.891452@localhost.localdomain> Message-ID: <372DEB39.422E24F@mitre.org> David, I see where you are going with this - develop an API for RDF. Out of curiosity, why isn't the SAX API adequate? After all, RDF is just XML. Let the application deal with it. /Roger David Megginson wrote: > > The more I work with RDF, the more I find it fascinating in the > abstract but annoying in the concrete. > > The biggest problem is that RDF claims an extremely simple data model > > statement: subject, predicate, object > > but that the model does not even come close to describing what > information actually appears in an RDF statement. Let's start with > the most naive mapping into a Java object model: > > public interface RDFStatement > { > public abstract String getSubject (); > public abstract String getPredicate (); > public abstract String getObject (); > } > > This will work fine for something like the following: > > xmlns:dc="http://www.purl.org/dc#"> > > Megginson Technologies > > > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Title" > statement.getObject() => "Megginson Technologies" > > However, it falls apart quickly when the value of the property is a > resource: > > xmlns:dc="http://www.purl.org/dc#"> > > > > > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Creator" > statement.getObject() => "http://home.sprynet.com/sprynet/dmeggins/" > > In the first case, the object was a literal, and in the second case, > the object is a resource; however, the naive interface does not make > this information available. The only solution is to add a new > property to the Java interface: > > public interface RDFStatement > { > public abstract String getSubject (); > public abstract String getPredicate (); > public abstract String getObject (); > public abstract boolean objectIsResource (); > } > > Now, for the first example, we have > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Title" > statement.getObject() => "Megginson Technologies" > statement.objectIsResource() => false > > and for the second example, we have > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Creator" > statement.getObject() => "http://home.sprynet.com/sprynet/dmeggins/" > statement.objectIsResource() => true > > Unfortunately, we're not nearly through yet. The next nasty bit comes > from the aboutEachPrefix attribute. For example, here's a modified > version of the first example: > > xmlns:dc="http://www.purl.org/dc#"> > > Megginson Technologies > > > > Now, this description no longer applies just to > http://www.megginson.com/, but to *all* resources whose URIs begin > with http://www.megginson.com/ (a constantly-changing set, and, in the > case of CGIs or Servlets, potentially infinite). As a result, the > following information is no longer sufficient: > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Title" > statement.getObject() => "Megginson Technologies" > statement.objectIsResource() => false > > We need to modify the interface once again > > public interface RDFStatement > { > public abstract String getSubject (); > public abstract String getPredicate (); > public abstract String getObject (); > public abstract boolean subjectIsPrefix (); > public abstract boolean objectIsResource (); > } > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Title" > statement.getObject() => "Megginson Technologies" > statement.subjectIsPrefix() => true > statement.objectIsResource() => false > > But wait -- there's more. The RDF spec states that the 'xml:lang' > attribute does not modify the data model, but rather, is a property of > the (underspecified) literal. Consider the following (RDF purists > would perfer to use an RDF:Alt, but let's keep things simple): > > xmlns:dc="http://www.purl.org/dc#"> > > markup > balisage > > > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Subject" > statement.getObject() => "markup" > statement.subjectIsPrefix() => true > statement.objectIsResource() => false > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Subject" > statement.getObject() => "balisage" > statement.subjectIsPrefix() => true > statement.objectIsResource() => false > > The language distinction is missing from our model, so we have to add > yet another property to the Java interface: > > public interface RDFStatement > { > public abstract String getSubject (); > public abstract String getPredicate (); > public abstract String getObject (); > public abstract boolean subjectIsPrefix (); > public abstract boolean objectIsResource (); > public abstract String getObjectLang (); > } > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Subject" > statement.getObject() => "markup" > statement.subjectIsPrefix() => true > statement.objectIsResource() => false > statement.getObjectLang() => "en" > > statement.getSubject() => "http://www.megginson.com/" > statement.getPredicate() => "http://www.purl.org/dc#Subject" > statement.getObject() => "balisage" > statement.subjectIsPrefix() => true > statement.objectIsResource() => false > statement.getObjectLang() => "fr" > > We're still not done. Take a look at the following: > > xmlns:megg="http://www.megginson.com/ns#"> > > > > Roses are red, > Violets are blue > Sugar is sweet, > And I love you. > > > > > > Since the element sets the 'rdf:parseType' attribute to > "Literal", the contents of the element will not be interpreted as RDF > markup. As a result, the value of this statement is a literal string: > > statement.getObject() => " > > Roses are red, > Violets are blue > Sugar is sweet, > And I love you. > > " > statement.objectIsLiteral() => true > > If I were to round-trip this back to XML, however, how would I know > that it was meant to be XML markup? My software might just as easily > generate the following: > > xmlns:megg="http://www.megginson.com/ns#"> > > > <poem> > <line>Roses are red,</line> > <line>Violets are blue</line> > <line>Sugar is sweet,</line> > <line>And I love you.</line> > </poem> > > > > > This probably isn't what I want. As a result, I have to add more > information to my Java interface to note whether the literal value is > meant to be read as XML markup: > > public interface RDFStatement > { > public abstract String getSubject (); > public abstract String getPredicate (); > public abstract String getObject (); > public abstract boolean subjectIsPrefix (); > public abstract boolean objectIsResource (); > public abstract boolean objectIsXML (); > public abstract String getObjectLang (); > } > > At this point, it might make sense to split this out into different > classes: > > public interface RDFComponent > { > public abstract String getValue (); > } > > public interface RDFSubject extends RDFComponent > { > public abstract boolean isPrefix (); > } > > public interface RDFPredicate extends RDFComponent > { > } > > public interface RDFObject extends RDFComponent > { > public abstract boolean isResource (); > public abstract boolean isXML (); > } > > public interface RDFStatement > { > public abstract RDFSubject getSubject (); > public abstract RDFPredicate getPredicate (); > public abstract RDFObject getObject (); > } > > Obviously, there's a much more complex model underlying RDF than the > spec lets on, and that model affects not only the ease or difficulty > of implementing an object model, but also the difficult of many > standard operations like queries against a collection of RDF > statements and storage in a relational database. > > I'd love to hear from others on this list who've worked with RDF. > It's full of some very good ideas, but I'm afraid that the underlying > (and hidden) conceptual complexity might stunt any serious > implementation. > > 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/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 3 20:49:11 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:40 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model In-Reply-To: <372DE3E1.55E5CD3D@fiduciary.com> References: <14125.43607.286104.891452@localhost.localdomain> <372DE3E1.55E5CD3D@fiduciary.com> Message-ID: <14125.60701.227468.366853@localhost.localdomain> W. E. Perry writes: > David Megginson wrote: > > > Obviously, there's a much more complex model underlying RDF than the > > spec lets on, and that model affects not only the ease or difficulty > > of implementing an object model, but also the difficult of many > > standard operations like queries against a collection of RDF > > statements and storage in a relational database. > May I respectfully submit that the problem is not the complexity of > the model underlying RDF, but its simplicity and relative freedom > from restriction, permitting the very sort of extension that leads > to the implementational problems David Megginson illustrates. I'm not certain that I follow -- I did not consider extensions at all in my essay. Certainly, it is possible to build complex layers on top of a simple data model, and much of what is in the RDF-syntax spec (such as the containers, rdf:type, rdf:value, rdf:Statement, etc.) together with all of the RDF-schema spec can be taken in that light; as a result, I considered none of that in my model. The problem is that the bottom-level, primitive model required for RDF support is itself rather complicated. It is certainly fair, in the model, to include Statement --------- - Subject - Predicate - Object but you also have to specify what a Subject, Predicate, and Object are. They are not simply resources/URIs, but have properties of their own: Subject ------- - value - isPrefix? Predicate --------- - value Object ------ - value - language - isResource? - isXML? This is the bare-bones RDF data model, according to my reading of the spec. Now, I will certainly admit that I have not been involved in the RDF design process, and may have misunderstood something: I encourage all members of XML Dev to feel free to correct me, no matter how experienced or inexperienced they may be with RDF. > Effectively it is just such a cumulative body of metadata which > David Megginson is seeking. It would provide the ability to refer > to components larger than simple subjects, predicates and objects, > such as resources as objects or prefixes as subjects. Such a > framework would comprehend and permit reference to any such objects > either top-down, from the perspectives of their larger containers, > or bottom-up from the perspective of their sub-components. I don't think that that's what I was looking for, though it certainly sounds interesting. Right now, I'm just considering the smallest possible data model required for implementing the RDF-syntax specification. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon May 3 21:16:23 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:11:40 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model Message-ID: <3.0.32.19990503121511.017214d0@pop.intergate.bc.ca> At 11:21 AM 5/3/99 -0400, David Megginson wrote: >The more I work with RDF, the more I find it fascinating in the >abstract but annoying in the concrete. Hmm, as I write this, I'm chewing away on a data set with about half a million RDF tuples. I'm having an easier time of it than David, but I think that's because I'm trying to do less. Mostly, my software needs to answer two questions: (a) what are all the properties of URL XXX? variation: what is the value (if any) of URL XXX's property YYY? (b) what URLs have ? There are two bits of complexity - one is that you have a boolean associated with each property value saying whether it's a literal or a URL. Although I haven't actually used it - in my data set, some properties always have literal values, others always have URL values. The second is the "aboutPrefix" stuff, which on reflection I consider a hideous bogosity. I know how it got into RDF, they had a drop-dead requirement to be able to emulate PICS, which has this prefix stuff. I can even understand how you might use it, but I still think it's a mistake. It doesn't get in the way of question (a) above, but it certainly plays hell with (b). Perhaps the key is that I'm not trying to construct a comprehensive object model - I'm just trying to use metadata to look things up. I find RDF just fine for that. -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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 3 21:31:23 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:40 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model In-Reply-To: <3.0.32.19990503121511.017214d0@pop.intergate.bc.ca> References: <3.0.32.19990503121511.017214d0@pop.intergate.bc.ca> Message-ID: <14125.62991.577360.858340@localhost.localdomain> Tim Bray writes: > Hmm, as I write this, I'm chewing away on a data set with about > half a million RDF tuples. I'm having an easier time of it than > David, but I think that's because I'm trying to do less. [snip] Just so -- personally, I've had no need to use most of the stuff either (it's a classic 80/20 thing), and I've written ad-hoc RDF libraries that work just fine for my customers' real-world requirements, including one for WavePhore that's happily processing streaming RDF data records for over 2,000 newswire stories (probably more than that by now) every day at dozens of customer sites. Certainly, we can define formats that happen to be RDF-compatible (like XMLNews-Meta [1]), but to create a general-purpose RDF processing software that will make it worthwhile to standardize on RDF, we have to implement all of the bogosity in the spec. -- hence my complaint. I have no problem writing an RDF/Foo engine for customer A, and RDF/Bar engine for customer B, and an RDF/Hack engine for customer C -- heck, I'm billing for them -- but they should all be able to share the same RDF engine(s); otherwise, why not just define the Foo, Bar, and Hack formats directly, without worrying about RDF compatibility? > Perhaps the key is that I'm not trying to construct a comprehensive > object model - I'm just trying to use metadata to look things up. > I find RDF just fine for that. Exactly, but you're free to implement only the subset that you need for your project -- as you know, people do exactly the same with XML (though with so many good parsers now, most just use the DOM or SAX). All the best, David [1] http://www.xmlnews.org/docs/xmlnews-meta.html -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 3 21:32:08 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:40 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model In-Reply-To: <372DEB39.422E24F@mitre.org> References: <14125.43607.286104.891452@localhost.localdomain> <372DEB39.422E24F@mitre.org> Message-ID: <199905031931.PAA02776@megginson.com> Roger L. Costello writes: > I see where you are going with this - develop an API for RDF. Out > of curiosity, why isn't the SAX API adequate? After all, RDF is > just XML. Let the application deal with it. /Roger I haven't decided if I want to do this kind of thing myself. I still owe it to everyone to get moving again with SAX2, after spending so much of my time and energy on XMLNews. As for the API, the SAX API would certainly go a long way, but it's not adequate; after all, Java already has the java.io.Reader class, and XML documents contain characters, so the application could deal with that too and skip SAX altogether. What RDF is trying to do is very important -- XML itself is very low-level, like IP (I know I've beat that analogy nearly to death), and we can benefit from standard, higher-level layers built on top. Now it happens that RDF defines a layer for exchanging objects and their properties, and a good, production-grade engine that could important and export RDF would be extremely useful. The XML spec shipped without a data model, and the RDF spec shipped with a badly underspecified one. Which is better? 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 3 22:42:35 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:40 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model References: <14125.43607.286104.891452@localhost.localdomain> <372DEB39.422E24F@mitre.org> Message-ID: <372DDAAB.16864864@prescod.net> "Roger L. Costello" wrote: > > David, > > I see where you are going with this - develop an API for RDF. Out of > curiosity, why isn't the SAX API adequate? After all, RDF is just XML. > Let the application deal with it. /Roger RDF has its own data model *expressed in* XML. In the same way, XML has a data model expressed in Unicode. One could ask: "Why do we need an XML API when every programming language has a character reading API." But the XML data model is not the Unicode data model. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Diplomatic term: "We had a frank exchange of views." Translation: Negotiations stopped just short of shouting and table-banging. (Brill's Content, Apr. 1999) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 3 23:20:11 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:40 2004 Subject: One million new XML documents before May 31 (was Re: Short Essay: Squeezing RDF into a Java Object Model) In-Reply-To: <14125.62991.577360.858340@localhost.localdomain> References: <3.0.32.19990503121511.017214d0@pop.intergate.bc.ca> <14125.62991.577360.858340@localhost.localdomain> Message-ID: <14126.4427.108170.95357@localhost.localdomain> David Megginson writes: > Just so -- personally, I've had no need to use most of the stuff > either (it's a classic 80/20 thing), and I've written ad-hoc RDF > libraries that work just fine for my customers' real-world > requirements, including one for WavePhore that's happily processing > streaming RDF data records for over 2,000 newswire stories > (probably more than that by now) every day at dozens of customer > sites. I just found out that WavePhore's actually sending out 26,000 newswire stories every day now: that's 26,000 XMLNews-Meta (RDF) records *and* 26,000 XMLNews-Story (NITF) documents, for a total of 52,000 new XML documents every day, or over one million new XML documents every 20 days.* I don't know the numbers from others using XMLNews. All the best, David * Or over 1 billion new XML documents every 53 years -- not quite as fast as MacDonald's flips burgers, but people cannot read as fast as they can eat. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Mon May 3 23:21:49 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:11:40 2004 Subject: Short Essay: Squeezing RDF into a Java Object Model In-Reply-To: <372DE3E1.55E5CD3D@fiduciary.com> (wperry@fiduciary.com) References: <14125.43607.286104.891452@localhost.localdomain> <372DE3E1.55E5CD3D@fiduciary.com> Message-ID: <199905032057.PAA06649@bruno.techno.com> [Walter E. Perry:] > We need implementation tools--and not just for RDF--which are also > agglomerative, building a larger ball or sphere of interconnected > structure from the details of instance markup as it is processed. Sounds like you are at a point where you can recognize that the grove paradigm is, in the end, the right solution. It's already an international standard: ISO/IEC 10744:1997 Annex A.4. It's a common fallacy that the interchange syntax of an information set (such as might be constrained by an XML DTD) should also be the API to that information set. But APIs are a completely different animal from interchange syntaxes, in which, for example, redundancy is desirable, instead of undesirable. I've noticed that at least some proponents of RDF tend to be trapped in this fallacy, and David Megginson's efforts to make sense of RDF dramatizes some of the problems that this fallacy causes, such as the many unnamed properties that turn out to be both implicit and required. (Indeed, RDF itself appears to be designed to promulgate the "syntax is API" fallacy.) The "syntax is API" fallacy is a well-intentioned simplifying assumption that, instead of simplifying, creates complexity and significantly reduces human productivity. Einstein once said something to the effect that things should be as simple as possible, and no simpler. In the domain of information interchange, groves, inheritable information architectures, and property sets for inheritable information architectures make things as simple as possible, and no simpler. The hidden and implicit properties of information expressed in RDF, for example, can be formalized, named, and made addressable by means of a property set. The exercise of creating such a property set, in turn, allows re-usable software modules for RDF to be used as a partners to applications that need to manipulate information that is interchanged according to RDF syntax. My company has developed an implementation of the ISO grove paradigm called "GroveMinder". Those who want the demo should contact me. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Tue May 4 01:55:48 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:11:40 2004 Subject: One million new XML documents before May 31 (was Re: Short Essay: Squeezing RDF into a Java Object Model) In-Reply-To: <14126.4427.108170.95357@localhost.localdomain> Message-ID: On Mon, 3 May 1999, David Megginson wrote: > David Megginson writes: > > > Just so -- personally, I've had no need to use most of the stuff > > either (it's a classic 80/20 thing), and I've written ad-hoc RDF > > libraries that work just fine for my customers' real-world > > requirements, including one for WavePhore that's happily processing > > streaming RDF data records for over 2,000 newswire stories > > (probably more than that by now) every day at dozens of customer > > sites. > > I just found out that WavePhore's actually sending out 26,000 newswire > stories every day now: that's 26,000 XMLNews-Meta (RDF) records *and* > 26,000 XMLNews-Story (NITF) documents, for a total of 52,000 new XML > documents every day, or over one million new XML documents every 20 > days.* I don't know the numbers from others using XMLNews. Cool! We should also not forget another relatively behind-the-scenes XML/RDF application (even if the details are a little hokey). Netscape's "What's Related" application is massively deployed on thousands of desktops; when punters click on the whats-related widget in recent copies of Navigator, it makes a simple HTTP query to their metadata server which returns a chunk of XML-shaped text. For example see http://www-rl.netscape.com/wtgn?www.xmlnews.org The Netscape folks had plenty of stick on the RDF-DEV list for various problems with the actual file format used (see notes at [1]) but looking beyond that, it's still rather cool. Also next to invisible despite the presumably vast amounts of XMLish data flowing between www-rl.netscape.com and desktop browsers. Dan [1] http://www.ilrt.bris.ac.uk/discovery/rdf-dev/files/wtgn-notes/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Tue May 4 03:23:44 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:40 2004 Subject: Dreadfully tedious questions Message-ID: <3.0.1.32.19990503212026.00697180@tiac.net> I know you must get these a lot, but I've been unable to find the answers in any of the usual FAQs. Also, I've only read about the past month's archive of this list (which did answer one of my questions, thanks), so I apologize if this is old dirt -- just point me to the right month and I'll find the answers myself! My company is working on a really cool browser plug-in, and I'm thinking of switching to an XML-derived language for use as the plug-in's scripting language. I want to do this in a way which is consistent with other uses of XML, and I have some pretty basic questions: 0) What FAQ did I miss which answered these must-be-frequently-asked quesions?!?! 1) What case do I use? Judging from MathML and SVG documents I've read, it looks like the trend is toward all lower case tags. Is this the consensus style out there? What if my tag is two words? Would: or some other style be the preferred approach? I know this may seem unimportant to you, but believe me, programmers care about case A LOT! I want to be consistent with what everyone else is doing. ] The next question *was* going to be: ] ]2) How the heck do I decide whether to use an attribute or an element? ] ] But after reading about 100 messages on the subject in the Oasis ] archives, I've concluded there is no answer to this question! ] ] I'll rephrase... 2) Will the forthcoming very smart XML editors do better with one of these over another? [attributes/elements that is; this question derives from a common answer that the editor you are using is a big determiner of what is a better design, which struck me as a bizarre way to choose] 3) Is expat the best choice for embedding an XML parser in my plug-in (the plug-in is written in C++, of course)? 4) Should I use one of the schema contenders to define my DTD? I have a lot more to say about my elements and attributes than just their syntax. At a minimum I'd like to document each of them with a little comment-size blurb. If there's a good chance I could capture this together with the syntax using one of the XML schema approaches, run that through a program to produce the DTD, and later have the schema ready to provide to a very smart XML editor (which could pop up tips based on my embedded documentation), I'd rather invest the time to do that now. Is one of the schema approaches winning the standards battle? Do schema->DTD translator tools exist? Do the XML editor writing companies realize how cool this capability would be? 5) Have the browser guys figured out how they're going to farm out individual elements to plug-ins? It's kind of obvious that XML is a really good way to fix the headache of plugin/ActiveX/applet incompatibilities in HTML. Isn't it? Thanks in advance. I promise future questions won't be so basic! ;) -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 4 12:31:31 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:41 2004 Subject: Dreadfully tedious questions In-Reply-To: <3.0.1.32.19990503212026.00697180@tiac.net> References: <3.0.1.32.19990503212026.00697180@tiac.net> Message-ID: <14126.51662.100229.38930@localhost.localdomain> Joshua E. Smith writes: > 0) What FAQ did I miss which answered these must-be-frequently-asked > quesions?!?! That one that you can write and distribute when you've finished collecting the answers (??). > 1) What case do I use? > > Judging from MathML and SVG documents I've read, it looks like the > trend is toward all lower case tags. Is this the consensus style > out there? What if my tag is two words? Would: > > > > > > > or some other style be the preferred approach? I know this may > seem unimportant to you, but believe me, programmers care about > case A LOT! I want to be consistent with what everyone else is > doing. I rarely see , but both and seem fairly common, and shows up occasionally. > ] The next question *was* going to be: > ] > ]2) How the heck do I decide whether to use an attribute or an element? > ] > ] But after reading about 100 messages on the subject in the Oasis > ] archives, I've concluded there is no answer to this question! Correct. > ] I'll rephrase... > > 2) Will the forthcoming very smart XML editors do better with one > of these over another? [attributes/elements that is; this question > derives from a common answer that the editor you are using is a big > determiner of what is a better design, which struck me as a bizarre > way to choose] Although this will not necessarily be the case (especially with smart stylesheets), the general trend is for element content to be visible on the screen and attribute values to be visible only when you call up a dialog box. From an editing perspective, I tend to use elements for most of the important information, and attributes for stuff that I don't need always to see (such as ID's). > 3) Is expat the best choice for embedding an XML parser in my plug-in (the > plug-in is written in C++, of course)? Expat's been well tested. SP has been even better tested, and unlike Expat, it supports DTD validation; however, SP has a basically undocumented and extremely complicated interface, and it's really a full SGML parser. IBM has a brand-new parser, xml4c++ (I think), at alphaworks.ibm.com. This hasn't had the field testing that Expat and SP have had, but it looks promising. > 4) Should I use one of the schema contenders to define my DTD? Sure, if it's helpful. One nice thing about most of the contenders is that you can mix the schema and its documentation in a single document for easier maintenance (as you mention below). Be prepared, though, to write a program to generate a DTD from your schema, and eventually, to write a transformation tool to convert the schema to whatever the XML Schema group chooses. > I have a lot more to say about my elements and attributes than just their > syntax. At a minimum I'd like to document each of them with a little > comment-size blurb. > If there's a good chance I could capture this together with the syntax > using one of the XML schema approaches, run that through a program to > produce the DTD, and later have the schema ready to provide to a very smart > XML editor (which could pop up tips based on my embedded documentation), > I'd rather invest the time to do that now. > > Is one of the schema approaches winning the standards battle? Do > schema->DTD translator tools exist? Do the XML editor writing companies > realize how cool this capability would be? You'll know what's happening when the Schema WG releases its working draft. Personally, I expect to see something completely different, with individual features chosen from each of the contenders. > 5) Have the browser guys figured out how they're going to farm out > individual elements to plug-ins? I'm sure that Microsoft has, but don't count on the Web community marching in step. > It's kind of obvious that XML is a really good way to fix the headache of > plugin/ActiveX/applet incompatibilities in HTML. Isn't it? Yeah, well, maybe. At least, you can keep the data for your plugin/ActiveX/applet in the same format -- otherwise, the incompatibilities are still there. > Thanks in advance. I promise future questions won't be so basic! ;) Nothing too basic here -- you proved yourself by looking up the FAQ on elements and attributes before posting. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Tue May 4 13:38:00 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:11:41 2004 Subject: RDF Schema Question: range of values of an rdfs:Class? Message-ID: <372EDC53.468D8FE5@mitre.org> I will state my question, then give an example to demonstrate my question, and then restate my question. Question: if I create an RDF Schema Class, then what is its rdf:range of values? Example: In section 7 of the RDF Schema spec there are a number examples. My question pertains to Example 1. In Example 1 a Person Class is defined. A maritalStatus property is then defined and its domain property is set to Person (i.e., the maritalStatus property can be used with Person). The range of maritalStatus is the Class MaritalStatus. Here are the definitions: The class of people. In the example it says that the possible values for the maritalStatus property are: {Married, Divorced, Single, Widowed}. Here is where I have a question. How did the range of possible values for maritalStatus suddenly get restricted to these four values? In the example it creates four instances of the MaritalStatus Class: Presumably, this is where the four values were gotten from. Something seems fishy here. I am having difficulty relating this to my Java background. In Java, if I create a class MaritalStatus: public class MaritalStatus {...} then in another class create some instances of MaritalStatus: MaritalStatus married = new MaritalStatus(); MaritalStatus divorced = new MaritalStatus(); MaritalStatus single = new MaritalStatus(); MaritalStatus widowed = new MaritalStatus(); and now if I create a variable maritalStatus, of type MaritalStatus: MaritalStatus maritalStatus; then its range of possible values is not {married, divorced, single, widowed}. Certainly, maritalStatus can be set equal to one of these instance variables. For example: maritalStatus = married; However, it can take on values other than these as well. For example: maritalStatus = new MaritalStatus(); Okay, now that I've convinced myself that I don't understand the example in the RDF Schema spec, let me restate my question: how did that example come up with just those four values for the maritalStatus property? In general, if I create a Class, how do I specify its range of values? Cheers! /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Tue May 4 13:48:36 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:11:41 2004 Subject: RDF Question: just need to reference the parent class for domain? Message-ID: <372EDED0.4779757A@mitre.org> Consider this RDF Schema definition: Note that SLR is a subClass of Camera. In the definition of the f-stop property I indicate what domains the property may be used in - Camera and SLR. My question is this: since SLR is a subclass of Camera then can I omit the second domain property, i.e., just use: f-stop can be used in any sublasses of Camera and I don't have to specify all the subclasses that it may be used in. Correct? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Tue May 4 13:49:06 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:41 2004 Subject: ECG data and XML In-Reply-To: <199905030625.IAA09015@chimay.loria.fr> Message-ID: <000801be9622$f0dd1df0$1b19da18@ne.mediaone.net> Patrice Bonhomme wrote: > > I am working on a system to handle ECG (Electrocardiogram) binary > data. I am > using XML to manage all the meta-data (concerning identification, > patient, > folder, ...). I was wondering if someone else has already put his > hands in > this kind of data. Yes, certainly there are several options for handling binary data, as is pointed out in the article at http://www.xml.com/xml/pub/98/07/binary/binary.html namely: 1) maintain binary data in an external file and use notations/links to reference 2) maintain binary data inline in a base64 encoded element, to see an example send a MIME e-mail with a binary attachment, e.g. your ECG file, to test-xmtp@jabr.ne.mediaone.net and it will send it back to you in XML encoded MIME format. 3) use a MIME multipart/related message to maintain an XML part (metadata) and a binary part (or parts) in a single document 4) convert the 'binary' ECG data into vector format and transmit as XML e.g. in SVG format. SVG is particularly well positioned to handle ECG data (as opposed to x-ray data). Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Tue May 4 13:51:59 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:41 2004 Subject: Dreadfully tedious questions In-Reply-To: <14126.51662.100229.38930@localhost.localdomain> References: <3.0.1.32.19990503212026.00697180@tiac.net> <3.0.1.32.19990503212026.00697180@tiac.net> Message-ID: <3.0.1.32.19990504074815.0105149c@tiac.net> Thanks for the quick response! Follow ups... > > 0) What FAQ did I miss which answered these must-be-frequently-asked > > quesions?!?! > >That one that you can write and distribute when you've finished >collecting the answers (??). Maybe I will... > [blah blah blah]attributes[blah blah]elements[blah blah blah] In looking for other stylistic examples to follow, I've notice some really serious inconsistency in approach, particularly in the W3C's documents. At one extreme, you've got MathML with almost no attributes at all, and at the other extreme, you've got SVG with almost no elements (and every attribute has it's own exotic syntax). I found a DTD prototype for VRML which was similar to SVG (everything in the attributes, attributes require MORE PARSING by the application). How do y'all react when you see attributes like this one from a VRML DTD: ... Now, I suppose that's a lot leaner than breaking out all the 3D and 4D vectors as elements (or their w,x,y,z parts as attributes), but isn't it a bit squirrley to hide that much of the syntax inside strings? > > 3) Is expat the best choice for embedding an XML parser in my plug-in (the > > plug-in is written in C++, of course)? > >Expat's been well tested. SP has been even better tested, and unlike >Expat, it supports DTD validation; however, SP has a basically >undocumented and extremely complicated interface, and it's really a >full SGML parser. > >IBM has a brand-new parser, xml4c++ (I think), at alphaworks.ibm.com. >This hasn't had the field testing that Expat and SP have had, but it >looks promising. xml4c++'s disclaimers ("this software sucks" is the general drift, sort of like the mozilla disclaimers) are pretty scary. Also, how big is the redistributable DLL? (I'm not going to sign their license unless there's a chance it'll be small enough to be practical in a plug-in) What's SP? Does that have a different name, because I haven't seen it in my web travels. -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 4 14:59:14 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:41 2004 Subject: SP APIs (was re: Dreadfully tedious questions) In-Reply-To: <3.0.1.32.19990504074815.0105149c@tiac.net> References: <3.0.1.32.19990503212026.00697180@tiac.net> <14126.51662.100229.38930@localhost.localdomain> <3.0.1.32.19990504074815.0105149c@tiac.net> Message-ID: <14126.60877.411308.972294@localhost.localdomain> Joshua E. Smith writes: > What's SP? Does that have a different name, because I haven't seen > it in my web travels. That's James Clark's original C++ class library for parsing SGML. http:/www.jclark.com/sp/ You'd better be able to recite the GOF book and the ANSI C++ standard backwards from memory before you try to puzzle out the undocumented native API from the *.h files. The few of us who have attacked the native SP API without such preparation have ended up clearly insane, and amuse ourselves only by posting long, rambling messages to mailing lists. SP also has a simple API (with documentation) that might do. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Tue May 4 16:01:54 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:11:41 2004 Subject: RDF Schema Question: range of values of an rdfs:Class? In-Reply-To: <372EDC53.468D8FE5@mitre.org> Message-ID: On Tue, 4 May 1999, Roger L. Costello wrote: > Question: if I create an RDF Schema Class, then what is its rdf:range of > values? [...] > In the example it says that the possible values for the maritalStatus > property are: {Married, Divorced, Single, Widowed}. Here is where I > have a question. How did the range of possible values for maritalStatus > suddenly get restricted to these four values? In the example it creates > four instances of the MaritalStatus Class: > > > > > > > Presumably, this is where the four values were gotten from. Something > seems fishy here. I see your concern. The main thing to say on this is that it is a trust issue: "Whether resources declared to be of type MaritalStatus in another graph are trusted is an application level decision." (from http://www.w3.org/TR/PR-rdf-schema/ 7.1) In other words, the core schema machinery only lets you say that 'maritalStatus' makes sense for values that are of rdf:type MaritalStatus. What this minimalistic spec doesn't itself give you is a comprehensive framework for figuring out whose data to trust. How one sets about this is likely to depend on details of your application; in some contexts, for example, it might be rather useful to learn about new instances of such classes. In others, this could be a security concern (as could trusting the contents of random XML or RDF data in general). Earlier working drafts listed this topic as an open issue (which was resolved ultimately in favour of minimalism). Here's the text from http://www.w3.org/TR/1998/WD-rdf-schema-19980814/ C.12. Class Sealing We would like to define a mechanism for 'sealing' an RDF Class, so that it becomes illegal to make certain RDF statements involving it. This is loosely analogous to the notion of 'final' classes in Java / OO programming. We might, for example, want to stop people creating subclasses of the class, or creating property types which have that class as their domain. The degree of sophistication required of the class sealing mechanism is as yet unclear: we might (for example) wish to consider the feasibility of using digital signatures in this context. I am having difficulty relating this to my Java > background. In Java, if I create a class MaritalStatus: [...] The analogy with Java can be overstretched, but this was a good comparison. In both cases, any object/resource that was known to be of the appropriate type would be allowed. The difference is that in RDF/Web context, we won't necessarily believe every assertion that some resource is of a certain type. hope this helps, 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. phone:+44(0)117-9287096 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Tue May 4 16:11:08 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:11:42 2004 Subject: RDF Question: just need to reference the parent class for domain? In-Reply-To: <372EDED0.4779757A@mitre.org> Message-ID: On Tue, 4 May 1999, Roger L. Costello wrote: > Note that SLR is a subClass of Camera. In the definition of the f-stop > property I indicate what domains the property may be used in - Camera > and SLR. My question is this: since SLR is a subclass of Camera then > can I omit the second domain property[...] > f-stop can be used in any sublasses of Camera and I don't have to > specify all the subclasses that it may be used in. Correct? /Roger Yes. If you say that f-stop has a domain of class 'Camera', you're claiming that it makes sense (ie. is consistent) to apply f-stop properties to resources that are members of that class. "Sub-class" just says that one set of resources is a subset of another. So we know that if a resource is of type SLR, and all SLRs are Cameras (ie. SLR--subClassOf-->Camera), then that resource is also a camera. And if its a camera, we can use properties applicable to cameras on it. Dan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 4 16:48:06 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:42 2004 Subject: RDF Schema Question: range of values of an rdfs:Class? References: <372EDC53.468D8FE5@mitre.org> Message-ID: <372F0880.6118F1CC@locke.ccil.org> Roger L. Costello wrote: > Okay, now that I've convinced myself that I don't understand the example > in the RDF Schema spec, let me restate my question: how did that > example come up with just those four values for the maritalStatus > property? In general, if I create a Class, how do I specify its range > of values? That is part of a general unsolved problem having to do with "How do you know when there are (no) more relevant RDF statements?" In this case, the example is taking a "closed world" assumption that says "No instances of MaritalStatus exist except the ones created in this RDF document." In other cases, of course, an "open world" assumption prevails. Hopefully some mechanism for indicating closure will eventually be created. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Tue May 4 16:59:04 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:42 2004 Subject: Do I need to use a validating parser? Message-ID: <3.0.1.32.19990504105427.0077e59c@tiac.net> More questions from the new guy... First, an easy one: If a language is defined in XML, you would say that language is XML-______. Compliant? Derived? ish? ey? Compatible? Now the harder ones... I'm trying to choose a parser to use in my plugin. I see a choice between expat, which is non-validating, and will increase my download size by <100K, and SP which is validating, and will increase my download size by about 1MB. Gak. I suppose that the validation should really be done a priori by the content developer using a validating editor, so doing validation in my plugin is really unnecessary. Is that true? Do commercial validating XML editors exist yet? I also suppose that my DTD is going to be pretty big by the time it's done, and downloading it every time someone wants to use my plugin is kind of stupid. Right? So that's another reason NOT to use a validating parser. I think I'm starting to understand why they went to the trouble of distinguishing well-formed from valid. But in my reading [XML Specification Guide: Graham, Quin, 1999], it appears that non-validating parsers are allowed to ignore tons of stuff. Is there ANY documentation of what expat actually *does*? (For that matter, is there any documentation at all?) I assume it ignores external entities, right? That means I can't rely on putting boilerplate (think C #include files) into an external parsed general entity if I go with expat, right? If you were using a programming language which is XML-ish, what XML features would you be annoyed to see left out (substitution of entities is an obvious one, which I've seen 3DML slammed for)? Of those features, which does expat not do (and therefore I'll have to do in my application, or extend expat to do -- three cheers for open source!)? I'd rather not have any DLLs hanging around with my plugin -- do any of you have experience linking xmltok and xmlparse statically under Win32? Any surprises, or tricks I need to know about? I have another related question, but I'll post it separately. Thanks in advance for any insights!!!! -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Tue May 4 17:17:35 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:11:42 2004 Subject: RDF Schema Question: adding new domains to a property? Message-ID: <372F0FC6.5C36296D@mitre.org> As a followup to my last question, where I had the Camera example: Here I show (using the rdfs:domain definitions) f-stop as being usable by Camera and SLR objects. Suppose that I create a new Class (not a subclass of Camera), and I wish to be able to use the f-stop property with that new Class. What do I need to do? Add a new line to the f-stop property definition? In general, what advantage is there in forcing a property to be used specifically with a Class? When would you ever want to do this? It seems like there would not be many, if any, cases where you would want to restrict where a property could be used. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 4 17:25:41 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:42 2004 Subject: The Syntax is API Fallacy (was Re: Short Essay: Squeezing RDF into a Java Object Model) In-Reply-To: <199905032057.PAA06649@bruno.techno.com> References: <14125.43607.286104.891452@localhost.localdomain> <372DE3E1.55E5CD3D@fiduciary.com> <199905032057.PAA06649@bruno.techno.com> Message-ID: <14127.3202.902977.914788@localhost.localdomain> Steven R. Newcomb writes: > The "syntax is API" fallacy is a well-intentioned simplifying > assumption that, instead of simplifying, creates complexity and > significantly reduces human productivity. Just so. When we're working in the database world, it should be quite easy to explain the place of structured markup by referring to the different layers of information models: 1. Data Model - the physical organization of the information in storage (such as a collection of SQL tables with primary keys, etc.). 2. Object Model - the logical organization of the information from a programmer's point of view (for example, a collection of Classes that are derived from and/or contain other classes). 3. Interchange Model - the static, serial view of the information for archiving or interchange with external systems (for example, an XML document type). Data system designers are used to thinking about the data and (more recently) the object models, but are just starting to get their minds around the interchange model, now that the Web is enabling (or forcing) them to open up their systems and share more information with outsiders. The most important point in this structure is that the layers are isolated: there is an n:n relationship between interchange models and related object models, and an n:n relationship between object models and related data models. > Einstein once said something to the effect that things should be as > simple as possible, and no simpler. In the domain of information > interchange, groves, inheritable information architectures, and > property sets for inheritable information architectures make things > as simple as possible, and no simpler. Fair enough, but there is no single data model or object model that is appropriate for all systems, whether they happen to use XML or not: Groves (or the DOM, for that matter, or the RDF data model) can serve as an intermediate layer, but there needs to be a domain-specific object model built on top that hides and abstracts the details. XML should rarely be the central focus of a system's design, any more than SQL or CORBA should be; it's just a (very good) enabling standard for the interchange layer, just as SQL is an enabling standard for the data layer and CORBA is an enabling standard for the object layer. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 4 17:38:02 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:42 2004 Subject: Do I need to use a validating parser? In-Reply-To: <3.0.1.32.19990504105427.0077e59c@tiac.net> References: <3.0.1.32.19990504105427.0077e59c@tiac.net> Message-ID: <14127.4484.111378.578548@localhost.localdomain> Joshua E. Smith writes: > First, an easy one: If a language is defined in XML, you would say that > language is XML-______. Compliant? Derived? ish? ey? Compatible? Conformant. > Now the harder ones... > > I'm trying to choose a parser to use in my plugin. I see a choice > between expat, which is non-validating, and will increase my > download size by <100K, and SP which is validating, and will > increase my download size by about 1MB. Gak. Or you could use Java -- Microstar's non-validating AElfred parser, in a compressed JAR, will increase your download size by only about 15K (plus another 5 or 6K if you use the SAX interfaces). > I suppose that the validation should really be done a priori by the > content developer using a validating editor, so doing validation in > my plugin is really unnecessary. Is that true? It's your call. Remember that XML Validation means only rudimentary structural validation anyway. > Do commercial validating XML editors exist yet? PSGML for Emacs is DTD-driven and free, but will scare away any user who'd be too nervous, say, to install and use Linux. WordPerfect 9.0 has a DTD-driven XML editor built in, and XMetaL from SoftQuad is, I assume, DTD-driven as well. As far as I know, WP 9 and XMetaL are still in beta, and I don't know about the release dates for products from ArborText. There are also some editors that simply use a tree widget to provide an unformatted view of the document -- I haven't kept track of those, but they might be useful for some applications. > I also suppose that my DTD is going to be pretty big by the time > it's done, Possibly not -- it depends on how complex your DTD is. > and downloading it every time someone wants to use my plugin is kind of > stupid. Right? So that's another reason NOT to use a validating parser. A non-validating parser may *still* download the DTD (AElfred does, for example) if you provide a pointer to one. > I think I'm starting to understand why they went to the trouble of > distinguishing well-formed from valid. They're not separate: valid is a subset of well-formed, not an alternative to it. > But in my reading [XML Specification Guide: Graham, Quin, 1999], it > appears that non-validating parsers are allowed to ignore tons of stuff. > Is there ANY documentation of what expat actually *does*? (For that > matter, is there any documentation at all?) I assume it ignores external > entities, right? That means I can't rely on putting boilerplate (think C > #include files) into an external parsed general entity if I go with expat, > right? Or you can preprocess on the server side to expand entities, insert defaulted attribute values, etc. > If you were using a programming language which is XML-ish, what XML > features would you be annoyed to see left out (substitution of entities is > an obvious one, which I've seen 3DML slammed for)? I find it very hard to imagine coding in a Turing-complete programming language that is XML-ish -- markup languages are usually quite clumsy for representing programming languages. What exactly do you mean, here? > Of those features, which does expat not do (and therefore I'll have > to do in my application, or extend expat to do -- three cheers for > open source!)? Expat does not validate the document or expand external text entities (including the external DTD subset, if any). > I'd rather not have any DLLs hanging around with my plugin -- do > any of you have experience linking xmltok and xmlparse statically > under Win32? Any surprises, or tricks I need to know about? The easy solution is to reformat the hard drive and install Linux, but then you wouldn't be able to play Flight Simulator any more (you could play DOOM and Quake, though) -- personally, I keep a small Windows partition for games when I'm not working. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Tue May 4 17:39:56 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:42 2004 Subject: Is it OK to rely on invalidity? Message-ID: <3.0.1.32.19990504113255.0073f3f8@tiac.net> Are my questions getting hard enough yet? I wouldn't want you all to be bored! ;) Suppose you were using XML to define an object oriented programming language. The language has an object model behind it which is chock full o' classes. For example, there's a class "color" with attributes of "red" "blue" and "green". So in my XML-ish programming language, I can state: to make an instance. Presumably, this would be backed up by a DTD like: Now suppose that I am going to allow the users of my language to create their own classes. A user-defined class would specify the member objects which are to be instanced when the class is instanced. For example, Now wouldn't it be cool, if my user could then instance his own class like this: and my application will make all those constituent members: my-color.whole-color my-color.red-part my-color.blue-part my-color.green-part I think so, but to pull that off, my user would have to extend the DTD do declare his class. Otherwise, while being well-formed, this program is not valid. To make it valid, the programmer would have to extend the DTD with a lot of gobledegook I bet the programmer won't really get (I'm assuming that the XML community will be split between those who write DTDs and those who use them). The alternative, which doesn't require DTD extension, would be to instance user-defined classes using the slightly uglier mechanism: Now instances of user-defined classes look different from built-in classes, which is almost never the case in OO languages. Another problem which pops up is making references to the generated objects. If I want to refer to my-color.red-part in some other object's attributes, I cannot use an IDREF and still be valid (since, as far as the XML parser is concerned, there is no such object -- my-color and red-part are two different things). Instead, I'd have to use a NMTOKEN, which sucks because in most cases the attribute really is an IDREF, and I bet some cool editors are going to be able to show those inter-object relationships graphically to the user. So the question: is it OK to rely on invalidity? If I just let validity slide, I can provide a nicer interface for user-defined classes. What do I lose? Will a validating editor barf if it sees a just-well-formed element? Or will it just gracefully mark the element as being suspect (which I think the user of the language can handle, since it is a user-defined class). Whatchathink? Is there a way to get the slick syntax I want without giving up validity? -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue May 4 18:27:59 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:11:42 2004 Subject: Do I need to use a validating parser? Message-ID: <3.0.32.19990504092706.011b6210@pop.intergate.bc.ca> At 10:54 AM 5/4/99 -0400, Joshua E. Smith wrote: >First, an easy one: If a language is defined in XML, you would say that >language is XML-______. Compliant? Derived? ish? ey? Compatible? XML-based? >I'm trying to choose a parser to use in my plugin. I see a choice between >expat, which is non-validating, and will increase my download size by ><100K, and SP which is validating, and will increase my download size by >about 1MB. Gak. James is working on a version of expat which compiles to substantially less, at the cost of some performance (i.e. it'll still be faster than anything else, I bet). I don't think SP is appropriate in the general case for XML apps. >I suppose that the validation should really be done a priori by the content >developer using a validating editor, so doing validation in my plugin is >really unnecessary. Is that true? Depends whether you trust the source. If you're writing both ends, you're probably OK (once you've got the system debugged). >Do commercial validating XML editors exist yet? Yes. From Arbortext (Adept) and (shipping any day now) SoftQuad (XMetaL). Frame+SGML is, as the name suggests, SGML not XML, but it'll work OK with XML. >I also suppose that my DTD is going to be pretty big by the time it's done, >and downloading it every time someone wants to use my plugin is kind of >stupid. Right? So that's another reason NOT to use a validating parser. Maybe the best reason. >But in my reading [XML Specification Guide: Graham, Quin, 1999], it >appears that non-validating parsers are allowed to ignore tons of stuff. >Is there ANY documentation of what expat actually *does*? (For that >matter, is there any documentation at all?) .h files :) >I assume it ignores external >entities, right? Wrong. Mind you, you have to do some extra work to deal with 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Tue May 4 18:58:27 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? In-Reply-To: <14127.4484.111378.578548@localhost.localdomain> References: <3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504105427.0077e59c@tiac.net> Message-ID: <3.0.1.32.19990504125402.0113cc48@tiac.net> XML-Conformant. Cool, I'll add that to the FAQ you wanted me to write. ;) > > If you were using a programming language which is XML-ish, what XML > > features would you be annoyed to see left out (substitution of entities is > > an obvious one, which I've seen 3DML slammed for)? > >I find it very hard to imagine coding in a Turing-complete >programming language that is XML-ish -- markup languages are usually >quite clumsy for representing programming languages. > >What exactly do you mean, here? I really meant what I wrote. I'm assuming that most programmers will not actually write in the markup language, but rather will use editors which produce markup as their output. If you think about it, that's what's already happening with tools like Access or Delphi (users work in an editor, and for the most part, don't touch the code), and of course that's almost the only way anyone can deal with HTML anymore. So from that perspective, even if it was clumsy, it wouldn't really matter. The right question is: Can a program be represented as a tree? And the answer is always yes. For example, think about LISP. What is that if not a tree structured language? And XML is *GREAT* for representing trees. Now consider what happens to your favorite ALGOL-derived language (say, Java) when you compile it. It gets formatted by YACC into a parse tree. So represent the parse tree in XML to begin with, and get rid of the compiler front end. My language isn't anything like LISP or ALGOL, but I think this gets the point across. It's pretty easy to write programming languages which are XML-Conformant. My language doesn't use constructs like "if-then" or "for-next" so the user wouldn't be exposed to any nasty parse trees anyway; but even if it did, I don't know that stuff is all that clumsier than the non-tagged equivalent. -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Tue May 4 19:23:23 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? References: <3.0.1.32.19990504105427.0077e59c@tiac.net> <14127.4484.111378.578548@localhost.localdomain> Message-ID: <372F2BDA.4DFF353A@jclark.com> David Megginson wrote: > > Of those features, which does expat not do (and therefore I'll have > > to do in my application, or extend expat to do -- three cheers for > > open source!)? > > Expat does not validate the document or expand external text entities > (including the external DTD subset, if any). Expat can expand external general text entities. It doesn't expand external parameter entities or the external DTD subset. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 4 19:33:31 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? References: <3.0.1.32.19990504105427.0077e59c@tiac.net> Message-ID: <372F2F48.B67BD7F5@locke.ccil.org> Joshua E. Smith wrote: > I suppose that the validation should really be done a priori by the content > developer using a validating editor, so doing validation in my plugin is > really unnecessary. Is that true? It depends on whether you are going to take action dependent on the XML you get, in which case validating provides some (but not all) of the sanity checks you will need. If you are just going to display the content (or do something else that can't damage the user or the client) then there is no real need. > I assume it ignores external > entities, right? That means I can't rely on putting boilerplate (think C > #include files) into an external parsed general entity if I go with expat, > right? Correct. Other non-validating parsers do read external entities, though. > If you were using a programming language which is XML-ish, what XML > features would you be annoyed to see left out (substitution of entities is > an obvious one, which I've seen 3DML slammed for)? Of those features, > which does expat not do (and therefore I'll have to do in my application, > or extend expat to do -- three cheers for open source!)? Expat does everything except read external entities and validate. Therefore, it doesn't read an external DTD, but it will process attribute defaults and such from the internal DTD. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 4 19:36:36 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:43 2004 Subject: RDF Schema Question: adding new domains to a property? References: <372F0FC6.5C36296D@mitre.org> Message-ID: <372F2FEB.EB6A516@locke.ccil.org> Roger L. Costello wrote: > In general, what advantage is there in > forcing a property to be used specifically with a Class? It allows you to make it an error when someone defines the f-stop property of a person, or a Web page, or a book, or what have you. As a result, your f-stop-aware application (if front-ended with a schema-validity checker) need not cope with such semantically foolish f-stop properties. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Tue May 4 21:37:33 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? References: <3.0.1.32.19990504105427.0077e59c@tiac.net> <14127.4484.111378.578548@localhost.localdomain> <372F2BDA.4DFF353A@jclark.com> Message-ID: <372F3C83.8215FA1B@pacbell.net> James Clark wrote: > > David Megginson wrote: > > > > Of those features, which does expat not do (and therefore I'll have > > > to do in my application, or extend expat to do -- three cheers for > > > open source!)? > > > > Expat does not validate the document or expand external text entities > > (including the external DTD subset, if any). > > Expat can expand external general text entities. It doesn't expand > external parameter entities or the external DTD subset. Expat also doesn't report "ignorable" whitespace as such, from what I can tell (just recently started to look at it). - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed May 5 00:30:13 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? References: <3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504125402.0113cc48@tiac.net> Message-ID: <372F55DA.75FA0ED1@prescod.net> "Joshua E. Smith" wrote: > > My language doesn't use constructs like "if-then" or "for-next" so the user > wouldn't be exposed to any nasty parse trees anyway; but even if it did, I > don't know that > > > stuff > A couple of questions: How much syntax does a variable refrence take? What does a function call look like? I'm trying to determine how much you are actually building on the XML parser and how much you intend to do yourself. > I'm assuming that most programmers will not > actually write in the markup language, but rather will use editors which > produce markup as their output. If you think about it, that's what's > already happening with tools like Access or Delphi (users work in an > editor, and for the most part, don't touch the code). I don't think that Access dialog building is programming. Real programmers, developing their own algorithms and interfaces will likely find any non-textual programming user interface to be an impediment. Delphi and Visual Basic have pretty decent text editors built in -- for a reason. I encourage you to design the user interface before focusing on the syntax of your markup language. If people like the user interface then the behind-the-scenes XML issues will be comparatively trivial. But if programmers hate the user interface then the XML part will become irrelevant. My experience is that XML editors are optimized for prose documents and are poor for most other stuff. They aren't ideal user interfaces for databases, programming languages, schemas etc. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The first three Noble Truths of Python: All that is not Python is suffering. The origin of suffering lies in the use of not-Python. The cessation of suffering can be achieved by not using not-Python. http://www.pauahtun.org/4nobletruthsofpython.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smo at jst.com.au Wed May 5 03:30:13 1999 From: smo at jst.com.au (Steve Oldmeadow) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? References: <3.0.1.32.19990504105427.0077e59c@tiac.net><3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504125402.0113cc48@tiac.net> Message-ID: <002201be9696$20297040$0201a8c0@pikachu> ----- Original Message ----- From: Joshua E. Smith To: XML Developers' List Sent: 05/05/1999 12:54 Subject: re: Do I need to use a validating parser? > I really meant what I wrote. I'm assuming that most programmers will not > actually write in the markup language, but rather will use editors which > produce markup as their output. If you think about it, that's what's > already happening with tools like Access or Delphi (users work in an > editor, and for the most part, don't touch the code), and of course that's > almost the only way anyone can deal with HTML anymore. > What sort of editor do you imagine? If you are thinking of using an XML editor constrained by the DTD then I think that would be a very clumsy way of programming. > Now consider what happens to your favorite ALGOL-derived language (say, > Java) when you compile it. It gets formatted by YACC into a parse tree. > So represent the parse tree in XML to begin with, and get rid of the > compiler front end. I think you are getting confused with your compiler terminology. The only thing that I can see marking up your program using XML helping with is the lexing stage i.e. recognising the tokens. Using a DTD would help with some syntax validation but I'm sure there are rules that you would want to enforce that can't be expressed in the DTD. Also think about what sort of error messages you want to give back to the programmer and how well your proposed solution will handle that. > My language isn't anything like LISP or ALGOL, but I think this gets the > point across. It's pretty easy to write programming languages which are > XML-Conformant. You might be able to define a language easily but XML isn't going to help with the interpretation. At least using tools like yacc/lex, javac and antlr you can link the grammar to what you want to do with the language which aids maintenance. I agree with David, I don't think programming languages marked up using XML is a good way to go. I know people are doing it but it strikes me as a case of a man with a hammer thinking everything looks like a nail. Steve Oldmeadow Justice Systems Technologies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smo at jst.com.au Wed May 5 03:47:14 1999 From: smo at jst.com.au (Steve Oldmeadow) Date: Mon Jun 7 17:11:43 2004 Subject: Dreadfully tedious questions References: <3.0.1.32.19990503212026.00697180@tiac.net><3.0.1.32.19990503212026.00697180@tiac.net> <3.0.1.32.19990504074815.0105149c@tiac.net> Message-ID: <003d01be9698$804edd00$0201a8c0@pikachu> ----- Original Message ----- From: Joshua E. Smith To: XML Developers' List Sent: 04/05/1999 7:48 Subject: re: Dreadfully tedious questions > xml4c++'s disclaimers ("this software sucks" is the general drift, sort of > like the mozilla disclaimers) are pretty scary. Also, how big is the > redistributable DLL? (I'm not going to sign their license unless there's a > chance it'll be small enough to be practical in a plug-in) > Currently the DLL is 597Kb. They give you the source so you could try to optimise the size yourself, my understanding is you are allowed to do this under the license but you must give what you produce to IBM which I think is fair enough considering what they are giving you. You have to understand this is early alpha code so you would be crazy to base a shipping product on it but I think it will be a good bet for the future. Steve Oldmeadow Justice Systems Technologies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Wed May 5 03:59:02 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:43 2004 Subject: Should I use defaults in my DTD? Message-ID: <3.0.1.32.19990504214903.00766068@tiac.net> Two more questions were raised as I memorized the XML spec (heh, heh). 1) Should I specify defaults in my DTD? My application knows what all the default values should be, so, technically, all the attributes on my elements could be #IMPLIED. However, it would seem likely to me that a good editor might tell the user what attributes exist for a given element they've inserted, and show them the default values from the DTD. The user could then easily decide what attributes need non-default values without looking in the object model documentation. However, I'm a little paranoid that some not-so-smart editors might read the DTD, get all the defaults, treat them as though they were specified by the user, and dump tons of default attributes into the saved file causing massive bloat. Would an editor really do that? (In their book, Ian & Liam seemed to imply that they thought one might.) 2) Should I use entities for URL attributes? Since the XML spec has gone to all that trouble to support external unparsed entities, it seems a little callous for me to call my attributes which are URLs ordinary CDATA. However, I have a really hard time seeing any value in making the user of my DTD go to the trouble of declaring the various JPGs and such as entities, when I know I'm just going to use the URL string anyway. Am I missing something? Is there a reason why: [Up in the DTD...] [Down in the document...] is preferable to: [Alone in the document...] The latter is so much simpler... -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Wed May 5 04:09:39 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? In-Reply-To: <372F55DA.75FA0ED1@prescod.net> References: <3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504125402.0113cc48@tiac.net> Message-ID: <3.0.1.32.19990504220617.00c24898@tiac.net> >A couple of questions: How much syntax does a variable refrence take? What >does a function call look like? I'm trying to determine how much you are >actually building on the XML parser and how much you intend to do >yourself. This application is more of what would be typically called a "scripting language" than a "programming language." I know that's a fuzzy distinction, but basically it means that you aren't going to be writing a quicksort in this language. It's a way to tie objects together to do interesting things. "Functions" and "Variables" don't really exist in this language (well, variables do, but it isn't obvious from the way you write programs that they do). It's a little hard to explain. Give me a few weeks to get the transition to XML worked out, then I'll give y'all a peek at it. >I don't think that Access dialog building is programming. I wasn't referring to dialog building, I was referring to the query builder which hides SQL from the access developer. I know very successful Access programmers who can't understand a lick of SQL, thanks to that very good query tool. That was my only point about Access. > Real >programmers, developing their own algorithms and interfaces will likely >find any non-textual programming user interface to be an impediment. >Delphi and Visual Basic have pretty decent text editors built in -- for a >reason. Fair enough. Those people aren't really my target audience. I'm going for web developers who understand HTML and want to dabble with something more expressive. >I encourage you to design the user interface before focusing on the syntax >of your markup language. If people like the user interface then the >behind-the-scenes XML issues will be comparatively trivial. But if >programmers hate the user interface then the XML part will become >irrelevant. > >My experience is that XML editors are optimized for prose documents and >are poor for most other stuff. They aren't ideal user interfaces for >databases, programming languages, schemas etc. Well, I'm hoping to avoid developing a user interface for developers at all, instead relying on the XML editors to do the job for me (at least for the first year or so). So far, that doesn't look like such a long shot. I downloaded a handful of the early editors (XML Spy, XML Notepad, a neat little demo of one written in Java who's name I forget, etc.), fed in a mock-up of one of my programs cast in XML, and was pretty impressed with what they could do. And I haven't written a DTD yet! (Some were *VERY* clever about figuring out the implied DTD from the elements.) -Joshua Smith -Joshua Smith jesmith@kaon.com http://www.kaon.com 978-355-6148 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Wed May 5 04:18:56 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? In-Reply-To: <002201be9696$20297040$0201a8c0@pikachu> References: <3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504125402.0113cc48@tiac.net> Message-ID: <3.0.1.32.19990504221521.00c392a8@tiac.net> >I think you are getting confused with your compiler terminology. The only >thing that I can see marking up your program using XML helping with is the >lexing stage i.e. recognising the tokens. Using a DTD would help with some >syntax validation but I'm sure there are rules that you would want to >enforce that can't be expressed in the DTD. Also think about what sort of >error messages you want to give back to the programmer and how well your >proposed solution will handle that. This is all academic. When I can show you what this "language" looks like, you'll laugh that I was calling it "programming" in the first place. Nonetheless, always up for the academic discussion, you can express the entire syntax of the LISP programming language in less than a page of DTD, I bet. DTD's syntax is almost as expressive as that of XML itself. > >> My language isn't anything like LISP or ALGOL, but I think this gets the >> point across. It's pretty easy to write programming languages which are >> XML-Conformant. > >You might be able to define a language easily but XML isn't going to help >with the interpretation. I already have the interpretation done in my own software. I'm looking for XML to help with editing, not compiling/interpreting. >At least using tools like yacc/lex, javac and antlr you can link the grammar >to what you want to do with the language which aids maintenance. I agree >with David, I don't think programming languages marked up using XML is a >good way to go. I know people are doing it but it strikes me as a case of a >man with a hammer thinking everything looks like a nail. Well, that wouldn't seem to apply here since I didn't know squat about XML until three days ago when I bought a book. ;) It's more a case of I have a tack, and I see this really cool hammer, and I just need to figure out how to use the hammer on tacks when it was designed for nails. Or something like that.... ;) -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smo at jst.com.au Wed May 5 05:21:38 1999 From: smo at jst.com.au (Steve Oldmeadow) Date: Mon Jun 7 17:11:43 2004 Subject: Do I need to use a validating parser? References: <3.0.1.32.19990504105427.0077e59c@tiac.net><3.0.1.32.19990504105427.0077e59c@tiac.net><3.0.1.32.19990504125402.0113cc48@tiac.net> <3.0.1.32.19990504221521.00c392a8@tiac.net> Message-ID: <012101be96a5$a9c85000$0201a8c0@pikachu> ----- Original Message ----- From: Joshua E. Smith To: Sent: 05/05/1999 10:15 Subject: Re: Do I need to use a validating parser? > Nonetheless, always up for the academic discussion, you can express the > entire syntax of the LISP programming language in less than a page of DTD, > I bet. DTD's syntax is almost as expressive as that of XML itself. > I don't know LISP but how would you express scoping rules such as a locally defined variable can only be accessed within the block it is defined such as in Java? I don't think this can be done using a DTD. It could however be expressed in some language marked up using XML. I don't want to seem like I'm trying to rain on your parade or anything, I was just wanting to save you some of the frustration I've been through. If DTDs were adequate there would be no push for another schema language. Once you do come up with your language I'm sure you will still need to write code to interpret it. All the current tools are going to help you with is to turn sentences in your language into an abstract syntax tree. Actually doing something with the tree is the hard part. I came to the conclusion that XML added very little and that you were better off just using the traditional tools to generate a parser for your language. One thing I toyed with was whether a yacc like tool would be useful for XML-ish languages, in other words it would help you generate parsers for languages that are marked up using XML. I'd be interested in your thoughts once you've come up with your solution. Steve Oldmeadow Justice Systems Technologies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From marcelo at mds.rmit.edu.au Wed May 5 05:28:41 1999 From: marcelo at mds.rmit.edu.au (Marcelo Cantos) Date: Mon Jun 7 17:11:44 2004 Subject: Do I need to use a validating parser? In-Reply-To: <3.0.1.32.19990504125402.0113cc48@tiac.net>; from Joshua E. Smith on Tue, May 04, 1999 at 12:54:02PM -0400 References: <3.0.1.32.19990504105427.0077e59c@tiac.net> <3.0.1.32.19990504105427.0077e59c@tiac.net> <14127.4484.111378.578548@localhost.localdomain> <3.0.1.32.19990504125402.0113cc48@tiac.net> Message-ID: <19990505132819.A3575@io.mds.rmit.edu.au> On Tue, May 04, 1999 at 12:54:02PM -0400, Joshua E. Smith wrote: > XML-Conformant. Cool, I'll add that to the FAQ you wanted me to write. ;) > > > > If you were using a programming language which is XML-ish, what XML > > > features would you be annoyed to see left out (substitution of entities is > > > an obvious one, which I've seen 3DML slammed for)? > > > >I find it very hard to imagine coding in a Turing-complete > >programming language that is XML-ish -- markup languages are usually > >quite clumsy for representing programming languages. > > > >What exactly do you mean, here? > > I really meant what I wrote. I'm assuming that most programmers will not > actually write in the markup language, but rather will use editors which > produce markup as their output. If you think about it, that's what's > already happening with tools like Access or Delphi (users work in an > editor, and for the most part, don't touch the code), and of course that's > almost the only way anyone can deal with HTML anymore. This is not true. It is still extremely common for HTML authors to code raw HTML in a text editor. In fact, if any degree of sophistication is required of your web site, a high level HTML editor will, more than likely, just get in the way. We gave up looking for a good HTML authoring environment because we almost always found that it was easier just to knock it up in a text editor. Moreover, any site that contains a large number of dynamic pages will not benefit at all from an fancy editor. If people do find themselves depending more and more on smart editors, this can hardly be used as an argument in _favour_ of HTML. It would be nonsensical to say we should use HTML _because_ there are ways to cope with its arcana! > So from that perspective, even if it was clumsy, it wouldn't really > matter. > > The right question is: Can a program be represented as a tree? And > the answer is always yes. For example, think about LISP. What is > that if not a tree structured language? And XML is *GREAT* for > representing trees. What about C/C++ with their goto and switch constructs? How would you represent this as a tree? void f(int i) { switch(i) { case 1: if (foo()) { while(baz()) { case 2: bar(i); continue; aa: bar2(); } case 3: bar2(); if (!foo()) { goto aa; } } } } Sure you can squeeze this into a tree, but it would be a mess. For instance, how would you introduce case 2 within the scope of the switch statement (as opposed to the scope of while(baz()) or global scope)? Likewise, how would you introduce label aa at function scope? XML simply cannot do this without implicit help from something like XQL. > Now consider what happens to your favorite ALGOL-derived language (say, > Java) when you compile it. It gets formatted by YACC into a parse tree. > So represent the parse tree in XML to begin with, and get rid of the > compiler front end. No it doesn't. I believe yacc is a LALR(1) parser, which means it never builds a parse tree. Rather, it invokes user-defined code snippets when productions are matched. (This is, of course, not to say you can't build a parse tree within your own code.) Furthermore, you are not removing the front end, but simply replacing it. And I am not at all convinced that this is a good thing. > My language isn't anything like LISP or ALGOL, but I think this gets the > point across. It's pretty easy to write programming languages which are > XML-Conformant. I think a more interesting project would be a meta-language, like Knuth's WEB. Under this scheme, a program would be represented as an XML document, and this would be used to generate the source code for a compiler. Hence the XML is not considered the final source, but is instead translated through a 'formatter' into the language of choice. With such an approach, the XML document would not represent the complete parse tree, but would instead store snippets of target language code to be emitted at appropriate points in the generation process. One thing to note is that the meta-language may actually constrain the compiler language constructs that can be output. For instance, an SGML representation of a switch statement might look like this: ... This scheme does not have the capacity to produce my original C example with its cases and label/goto. Whether this is a good or a bad thing is, I'm sure, a topic for lively debate. > My language doesn't use constructs like "if-then" or "for-next" so the user > wouldn't be exposed to any nasty parse trees anyway; but even if it did, I > don't know that > > > stuff > > > is all that clumsier than the non-tagged equivalent. It also wouldn't work: for i = 100/f(j) to int(sqrt(k) do stuff; could not become: stuff Instead, it would have to be:
Hence, even your simple example would be more like this: stuff Now, you could always reduce the size of these constructs a little by removing some of the redundant elements, such as , and , but that would actually be a net loss in clarity, IMHO. My primary objection to all of this, however, has nothing to do with complexity or feasibility (it most certainly could be done). The right question is not _can_ a program be represented as a tree, but _should_ it. C++ compilers, for instance, all have numerous bugs and many of them have quite serious bugs when it comes to combining templates, destructors and exceptions. But the problems they have have nothing to do with the difficulty of parsing and everything to do with the complexity of the C++ object model. This is not an attempt to defend C++ syntax, which is indeed something of a bug-bear to parse. But the point to note is that this is _not_ the area where compilers come to grief, and therefore it is not where efforts should be focused. So my question is, what do you gain? How will my life be improved if I have an XML conformant programming language? All I seem to have gained is an extra layer of complexity (the custom editor) that I am forced to deal with because trying to work directly with the underlying code is the stuff of my worst nightmares. I am not into climbing mountains just because they're there. Cheers, Marcelo -- http://www.simdb.com/~marcelo/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Wed May 5 09:26:13 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:44 2004 Subject: The Syntax is API Fallacy (was Re: Short Essay: Squeezing RDF into a Java Object Model) References: <14125.43607.286104.891452@localhost.localdomain> <372DE3E1.55E5CD3D@fiduciary.com> <199905032057.PAA06649@bruno.techno.com> <14127.3202.902977.914788@localhost.localdomain> Message-ID: <372FF1EA.83E05C15@pacbell.net> David Megginson wrote: > > Steven R. Newcomb writes: > > > The "syntax is API" fallacy is a well-intentioned simplifying > > assumption that, instead of simplifying, creates complexity and > > significantly reduces human productivity. > > Just so. When we're working in the database world, it should be quite > easy to explain the place of structured markup by referring to the > different layers ... You know, I was thinking of commenting on this same fallacy from the network protocol world. The "Interchange Model" fits into part of that ... protocols involve interactions though, and they're not just request/response models in the way APIs often are made out to be. > 1. Data Model - the physical organization of the information in > storage (such as a collection of SQL tables with primary keys, > etc.). > > 2. Object Model - the logical organization of the information from a > programmer's point of view (for example, a collection of Classes > that are derived from and/or contain other classes). > > 3. Interchange Model - the static, serial view of the information for > archiving or interchange with external systems (for example, an XML > document type). I'd either add one, or augment the "Interchange" model to capture the dynamic messaging patterns; I need to see system dynamics in my models! 4. Protocol Model - the messages interchanged, and the rules for concurrently interchanging them over time. There are lots of ways to slice a system ... for example, many folk like to couple the "data" (storage) and "object" (API) models closely in a "single level store" model, like an object database rather than a relational one. > Data system designers are used to thinking about the data and (more > recently) the object models, but are just starting to get their minds > around the interchange model, now that the Web is enabling (or > forcing) them to open up their systems and share more information with > outsiders. Network application designers go the other way around, and start from that "open systems" world ... but have only slowly begun to back into object models as a tool to facilitate the evolution of applications. One of the reasons I spent a bunch of time in the CORBA world was to try to encourage that to happen more quickly. It didn't happen to my own satisfaction ... and the reason is IMHO what one might call the "Protocol is API Fallacy". Folk focussed on the object aspects and treated those protocol issues more as afterthoughts than primary goals; so they ended up with a system that works better for APIs than for protocols. (And yes, there was lots of attention on integrating the storage and API models automatically too -- similar effect.) > The most important point in this structure is that the layers are > isolated: there is an n:n relationship between interchange models and > related object models, and an n:n relationship between object models > and related data models. And similarly, protocol models ... > > Einstein once said something to the effect that things should be as > > simple as possible, and no simpler. In the domain of information > > interchange, groves, inheritable information architectures, and > > property sets for inheritable information architectures make things > > as simple as possible, and no simpler. > > Fair enough, but there is no single data model or object model that is > appropriate for all systems, whether they happen to use XML or not: > Groves (or the DOM, for that matter, or the RDF data model) can serve > as an intermediate layer, but there needs to be a domain-specific > object model built on top that hides and abstracts the details. Developers looking at a large system will start to seem very much like those blind men feeling the different parts of an elephant. Each will need a domain-specific model (trunk, ear, tail, side, etc.) and the model that's most effective for their particular problem domain (data, object, interchange, protocol, etc) may not be very useful for the other problem domains. While the universal model ("elephant", or "application" depending on which side of the metaphor you're working with :-) isn't suited for detailed work. > XML should rarely be the central focus of a system's design, any more > than SQL or CORBA should be; it's just a (very good) enabling standard > for the interchange layer, just as SQL is an enabling standard for the > data layer and CORBA is an enabling standard for the object layer. Right. The "Protocol is API Fallacy" makes the same mistake that the "Syntax is API Fallacy" does: assumes that one tool can and should enable standards at more than one layer. To the extent that it does so, it often does so by sacrificing important functionality. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From raimondba at infosupport.com Wed May 5 09:47:43 1999 From: raimondba at infosupport.com (Raimond Bakkes) Date: Mon Jun 7 17:11:44 2004 Subject: xml-dev unsubscribe Message-ID: <50428ACA709ED211A4BB0060087A2A6F509D7A@exchange.infosupport.nl> xml-dev unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From raimondba at infosupport.com Wed May 5 10:04:26 1999 From: raimondba at infosupport.com (Raimond Bakkes) Date: Mon Jun 7 17:11:44 2004 Subject: unsubscribe xml-dev Message-ID: <50428ACA709ED211A4BB0060087A2A6F509D87@exchange.infosupport.nl> unsubscribe xml-dev xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From raju at wipinfo.soft.net Wed May 5 10:09:39 1999 From: raju at wipinfo.soft.net (raju) Date: Mon Jun 7 17:11:44 2004 Subject: unsubscribe ! Message-ID: xml-dev unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From menbo at super.ime.ncku.edu.tw Wed May 5 10:45:32 1999 From: menbo at super.ime.ncku.edu.tw (menbo) Date: Mon Jun 7 17:11:44 2004 Subject: The benefit of XML Message-ID: <37300859.14EDF90A@super.ime.ncku.edu.tw> Hi: I am a beginner to XML. I have known a lot about XML. But I can't find the great advantage of XML. Are there any good examples that illustrate the great difference between XML and 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Wed May 5 12:28:19 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:11:44 2004 Subject: Do I need to use a validating parser? Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A186B@eukbant101.ericsson.se> > -----Original Message----- > From: Marcelo Cantos [SMTP:marcelo@mds.rmit.edu.au] > > > I really meant what I wrote. I'm assuming that most programmers will > not > > actually write in the markup language, but rather will use editors which > > produce markup as their output. If you think about it, that's what's > > already happening with tools like Access or Delphi (users work in an > > editor, and for the most part, don't touch the code), and of course > that's > > almost the only way anyone can deal with HTML anymore. > > This is not true. It is still extremely common for HTML authors to > code raw HTML in a text editor. In fact, if any degree of > sophistication is required of your web site, a high level HTML editor > will, more than likely, just get in the way. > > We gave up looking for a good HTML authoring environment because we > almost always found that it was easier just to knock it up in a text > editor. Moreover, any site that contains a large number of dynamic > pages will not benefit at all from an fancy editor. > > One word: Homesite. Makes a damn good syntax highlighting XML editor too. And with IE5 installed it's a quick click on the Browse button and you see your XML+CSS in all it's glory. For Joshua's information, he may be (or may not be) interested in Mozilla.org's XUL - it's an XML application building language that uses Javascript as it's programming language. Netscape 5's gui will be completely built using XUL - it's a very cool technology. However it doesn't go as far as to lower the scripting language to being XML itself - I think that's crazy, but each to his own. Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wegrzyn at garbagedump.com Wed May 5 12:49:25 1999 From: wegrzyn at garbagedump.com (C Wegrzyn) Date: Mon Jun 7 17:11:44 2004 Subject: The Syntax is API Fallacy (was Re: Short Essay: Squeezing RDF into a Java Object Model) In-Reply-To: <372FF1EA.83E05C15@pacbell.net> Message-ID: A non-text attachment was scrubbed... Name: smime.p7m Type: application/x-pkcs7-mime Size: 9121 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990505/4738d4a4/smime.bin From costello at mitre.org Wed May 5 13:40:38 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:11:44 2004 Subject: DTD for RDF? How is that possible? Message-ID: <37302E67.BCBED196@mitre.org> I recall seeing a posting a few months back where someone posted a DTD for RDF. Upon reflection I find this puzzling. How could you possibly create a DTD for RDF? By definition, the child elements in rdf:Description are arbitrary: It is my understanding that RDF documents can only be "well-formed". There is no such thing as a "valid" RDF document. Correct? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Wed May 5 14:51:24 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:44 2004 Subject: XML-Conformant Programming Languages Message-ID: <3.0.1.32.19990505084700.0103ce30@tiac.net> {I am *very* pleased with the intellectual quality of discussions on this group!} To summarize this thread: Everyone thinks I'm nuts. That's fine. I'm used to that. I usually take that as a sign I'm going in the right direction. ;) Yes, XML doesn't do me any good helping me parse or interpret the programs the user has written. Many of you don't seem to get this: I *already* have a working scripting language written (your classic "little language"). That means I can already get from declarations to moving the program counter around. So I don't *need* XML to help me parse (except, I don't have anything like &entity substitution, so that will be a nice benefit I get for free on the processing end). I know that folks like you *and me* write all our HTML, XML, Perl, Java, etc. in Emacs. On Linux. However, you cannot release a product to Jane Q. Public (even for free) which uses a "little language" and tell her she needs to write her programs in Notepad. She needs a tool to make organizing the constructs of the language easy. (They call this "Visual Programming" and it's actually pretty cool when it's done right -- which is almost never, because people keep trying to put visual wrappers around glorified machine languages like Java.) However, I'm sure you can relate, the *last* thing I want to do is write a custom editor. I can't stand to use them, much less write one. XML *can* solve this problem for me. I'll be able to tell Jane to just fire up Homesite, or Office 2000, or whatever, and it'll know how to edit programs in my language. This is a REALLY BIG step forward, folks. You know how you can get a funky set of .el files which makes emacs know how to edit every language you work in? Well imagine folks in the rest of the world being able to fiddle with their web pages and all the stuff which integrates into their web pages (maybe including database front-ends, too) in a common environment. XML could make that possible. You and I will never use it, but trust me, this could be huge! Oh, and some of you have a pretty jaded view of programming languages. Do yourself a favor and go learn LISP and FORTH. You'll see that very useful programming languages don't have to be an unholy mess like C, Java, Perl, and VB. Check the back issues of Dr. Dobbs for a good article on FICL, for example. Yes, YACC is a LALR parser, but what you *almost always* do in the production rules is stuff $1, $2, and $3 into a parse tree which you munch on the back end. Most multi-CPU targeting compilers use a parse _tree_ as the internal representation of the program (the original MIPS compiler actually saved it out to disk). Writing an ALGOL derivative language in XML basically gets rid of the need for a language specific parser, and makes the programmer responsible for parsing the language herself. While that would be a nightmare in C (as one of you showed quite clearly), it is no big deal in LISP, FORTH, and hundreds of other well designed languages. -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SCampana at bluestone.com Wed May 5 15:00:54 1999 From: SCampana at bluestone.com (Campana, Sal) Date: Mon Jun 7 17:11:44 2004 Subject: ibm xmlj1.1.16 XML Validation Message-ID: <512EBEF97F02D311B89900A0C9D17760129DC0@thor.operations.bluestone.com> Has anyone successfully validated an XML document with an external DTD using IBM's xmlj1.1.16 parser? I have been unable to get this to work....It checks that the document is well-formed but it does not seem to validate against the DTD... Thanks, Sal xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed May 5 15:12:54 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:44 2004 Subject: The Syntax is API Fallacy Message-ID: <027801be96f7$d7c9d5d0$0b2e249b@fileroom.Synapse> David Brownell wrote: >David Megginson wrote: >> >> Steven R. Newcomb writes: >> >> > The "syntax is API" fallacy is a well-intentioned simplifying >> > assumption that, instead of simplifying, creates complexity and >> > significantly reduces human productivity. >> >> Just so. When we're working in the database world, it should be quite >> easy to explain the place of structured markup by referring to the >> different layers ... > >You know, I was thinking of commenting on this same fallacy from the >network protocol world. The "Interchange Model" fits into part of >that ... protocols involve interactions though, and they're not just >request/response models in the way APIs often are made out to be. > First, let me preface this by commenting that I am a proponent of layering, and there is much useful insight gained by layer analysis in system design. That being said, the RPC model, now the distributed object model defines a specific mapping between a syntax layer above the network layer (e.g. DCE-RPC/NDR over TCP/IP) which defines a direct correlation between the "API" generated by an IDL compiler and network PDUs. So the 7 layer OSI model can be applied to systems design. Where does XML fit into this equation? XML-RPC replaces NDR PDU representation with XML PDU representation. E.g. 1) transport = TCP/IP 2) protocol = HTTP (POST), 3) PDU is a MIME message of content-type: text/xml or application/xml and whose contents are an XML document Via this mapping, one can *compile* IDL e.g. CORBA or DCOM into an HTTP/XML binding. HTTP/XML replaces the IIOP or DCE-RPC. This is what is known as XML-RPC. This formalism is useful for distributed object calls where the objects maintain their own distributed identity (e.g. a URI) and communicate via network PDUs (so the API call *does* map onto a request-response at the HTTP procotol level). Another method is to send 'copies' of objects over the network. Is is called 'marshal by value' (MBV). XMOP (see http://jabr.ne.mediaone.net/xmop.htm) describes a method to MBV Java and COM objects via XML. In general when MBV is employed, the object has a 'save' and 'load' method that serializes the object to a stream. The contents of this stream can just as easily be an arbitrary XML document. In this case, the XML document IS EXACTLY the network wire level representation of the object. Regarding the DOM: A DOM object is a special case object whose serialized format is an arbitrary XML document. Other objects (e.g. user object) may choose to serialize their state into an XML stream directly, or via code reuse, employ a parser object to assist with this serialization. SAX and DOM objects are two types of parsers. Hence one type of object serialization implementation may choose: load(DOMDocument x) and save(DOMDocument y) as a method to implement persistence. An advantage of this approach is that it allows the same implementation to be used for both network marshalling as well as storage into a database which provides a DOM wrapper. If databases arrive which support the SAX interface, this too would provide the same benefit of code reuse to the object implementor. API, Syntax Protocol etc describe different layers in a system. When well known/standard interfaces are developed to link different layers in a system, system developers can concentrate on the important tasks of system design and object analysis and allow the plumbing to do its job. The Grove formalism is one mechanism of converting between serialization formats (e.g. XML) and an object API (e.g. the DOM). IDL is another mechanism to convert between object APIs (e.g. interfaces) and network protocols (e.g. HTTP/XML, DCE-RPC and/or IIOP). What I am still wrestling with is where RDF sits in this picture e.g. does it describe objects better than IDL? Does it describe systems better than UML? (perhaps!!)Does it describe graphs better than XML+XSL/XPointer+XLink? In the continuum between object and document, what the heck is a 'resource' anyways? What I am waiting for is a mechanism to 'compile' or bind RDF into a set of Java, COM and/or CORBA interfaces (clearly this ought be possible). In the distributed object world, the interface (which here is called the 'API') is primary and the network plumbing and serialization format is a detail to be taken care of by the system. In the document world, the serialization is primary and the API is merely a mechanism to allow access to the data. Clearly both views are important and ought to be equally incorporated into the 'new world view'. I call this 'Web centric distributed computing' for lack of a better catch phrase. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Wed May 5 15:25:39 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:11:44 2004 Subject: Do I need to use a validating parser? References: <3.0.1.32.19990504105427.0077e59c@tiac.net> Message-ID: <3730456A.AC9349D6@w3.org> "Joshua E. Smith" wrote: > > More questions from the new guy... > > First, an easy one: If a language is defined in XML, you would say that > language is XML-______. Compliant? Derived? ish? ey? Compatible? I would say "an application of XML" or "written in XML" depending on who I was talking to. For the language definition, if it was defined using DTD syntax, I might say it was valid (if it was). For a document instance, if it was well formed, then you could say it was a "well-formed XML document"; otherwise, you would say it was "stuff". If an instance was in addition valid, then you could say that too. > I'm trying to choose a parser to use in my plugin. I see a choice between > expat, which is non-validating, and will increase my download size by > <100K, and SP which is validating, and will increase my download size by > about 1MB. Gak. Great if there was a way to ask the browser if you could use *it's* XML parser that it already has, huh? > Do commercial validating XML editors exist yet? Yes. > I also suppose that my DTD is going to be pretty big by the time it's done, > and downloading it every time someone wants to use my plugin is kind of > stupid. Right? So that's another reason NOT to use a validating parser. Using a DTD is a separate thing from validation. And, assuming you use the browser cache, you only need to get it once. > But in my reading [XML Specification Guide: Graham, Quin, 1999], it > appears that non-validating parsers are allowed to ignore tons of stuff. Yes. Which means it has to occur explicitly in each document that you create, rather than once in the DTD, thus giving you a per-download filesize hit on your content. > Is there ANY documentation of what expat actually *does*? (For that > matter, is there any documentation at all?) I assume it ignores external > entities, right? That means I can't rely on putting boilerplate (think C > #include files) into an external parsed general entity if I go with expat, > right? That is my understanding. -- Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed May 5 15:42:51 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:44 2004 Subject: XML-Conformant Programming Languages Message-ID: <02d101be96fc$049a2b10$0b2e249b@fileroom.Synapse> Have you looked at XSL (not that it is a full featured programming language however it is getting closer and closer). Jonathan Borden http://jabr.ne.mediaone.net > >Everyone thinks I'm nuts. That's fine. I'm used to that. I usually take >that as a sign I'm going in the right direction. ;) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at metalab.unc.edu Wed May 5 19:15:14 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:11:45 2004 Subject: IE5 brain damage Message-ID: <3730A636.D44392D0@metalab.unc.edu> IE5 has some sort of stupid integration with my desktop (NT) such that when I try toopen a file off my local hard drive it opens in TextPad instead. The reason TextPad is picked is because that's what I've registered to handle XML files. But I'd still like to be able to use IE to open it directly. Does anyone know how to fix this so that IE does not hand off XML files to a helper app? It will open the XML file directly if (and only if) I follow a link to a file on the hard drive rather than simply opening it on my hard drive. Any suggestions? +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Java I/O (O'Reilly & Associates, 1999) | | http://metalab.unc.edu/javafaq/books/javaio/ | | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed May 5 19:23:11 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:45 2004 Subject: Dreadfully tedious questions Message-ID: <87256768.005F5745.00@d53mta03h.boulder.ibm.com> > >>Expat's been well tested. SP has been even better tested, and unlike >>Expat, it supports DTD validation; however, SP has a basically >>undocumented and extremely complicated interface, and it's really a >>full SGML parser. >> >>IBM has a brand-new parser, xml4c++ (I think), at alphaworks.ibm.com. >>This hasn't had the field testing that Expat and SP have had, but it >>looks promising. > >xml4c++'s disclaimers ("this software sucks" is the general drift, sort of >like the mozilla disclaimers) are pretty scary. Also, how big is the >redistributable DLL? (I'm not going to sign their license unless there's a >chance it'll be small enough to be practical in a plug-in) > Just to protected my honor here... The intent of any disclaimers is not to say that it sucks by any means. This is the very first public release, so you can obviously expect it to be a little less stable and mature than something that's been out for years. But its certainly not Suckware at all. Its actually quite good, since it draws on three previous parser efforts, and it will definitely get better. As to the DLL size, that is partly temporary. We depend upon the ICU (IBM internationalization classes) for our transcoding services. They have not been ready to release that as a separate product so far so we physically embedded it into our stuff. However, very soon they will do so and we will split that out. They will also be better layering their stuff so that we only have to get the lowest level parts of it, which are all we need. This will reduce our footprint as well. And, once the ICU is split out, it will be exposed to the client code so that they can actually do many useful things with this Unicode text that we are spitting at them. Right now, we don't expose that ICU interface so you have to provide the tools to do useful stuff with the resulting XML text in its Unicode format. So, on both fronts it will be improving. So judge it on its potential (and its very flexible and extensible architecture gives it a lot of potential) for what it will be able to do soon. Give us a couple of Alphaworks releases and we will get it much cleaner and more conformant. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Wed May 5 19:32:38 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:45 2004 Subject: The Protocol [was: Syntax] is API Fallacy References: <027801be96f7$d7c9d5d0$0b2e249b@fileroom.Synapse> Message-ID: <37308020.CDC23BB8@pacbell.net> Jonathan Borden wrote: > > First, let me preface this by commenting that I am a proponent of > layering, and there is much useful insight gained by layer analysis in > system design. That being said, the RPC model, now the distributed object > model defines a specific mapping between a syntax layer above the network > layer (e.g. DCE-RPC/NDR over TCP/IP) which defines a direct correlation > between the "API" generated by an IDL compiler and network PDUs. So the 7 > layer OSI model can be applied to systems design. And if done in that way, you run right into the "Protocol is API" fallacy. I've been doing distributed systems since the mid 1980s and have come to understand that there exist major limitations in the RPC model. > Via this mapping, one can *compile* IDL e.g. CORBA or DCOM into an > HTTP/XML binding. HTTP/XML replaces the IIOP or DCE-RPC. This is what is > known as XML-RPC. The fact that one "can" do it doesn't make it a good idea for all, or even very many, cases. The fallacy is that one focusses on the API rather than the protocol; and APIs have an unfortunate pattern of not addressing protocol problems. Moreover, there's major resistance to getting them to be addressed; the problems strike at the heart of RPC, which is to enable an API mapping by removing message patterns and system structures that are essential for working in real systems. - To design a protocol, design a protocol. - To design an API, design an API. - Understand the severe limitations of mapping APIs to protocols. You need both protocols and APIs. But there is no one-to-one mapping that works in all cases. Good protocols support many APIs, and vice versa. RPC systems remove that flexibility; they force API changes when protocols change, and vice versa. > API, Syntax Protocol etc describe different layers in a system. When > well known/standard interfaces are developed to link different layers in a > system, system developers can concentrate on the important tasks of system > design and object analysis and allow the plumbing to do its job. There's a signifcant issue with the quality of the linking. RPC systems hide significant parts of the network, which need to be surfaced. They don't expose faults well, or recovery mechanisms; they complicate callback style messaging patterns unduly; they bury encoding issues, and impose specific protocol-to-API mappings even in environments where they're not at all appropriate. Consider that no RPC system in the world (CORBA, ONC, DCE, etc) has had the reach of some rather basic non-RPC systems like E-Mail (SMTP, POP, IMAP) or the web (HTTP, HTML, XML, etc). For folk who have spent a lot of time working on architectural issues, this is telling: it says that there's quite likely a problem with the RPC approach. I think that is fundamental to the approach at this point; the very thing that makes RPCs seem easy to understand is the thing that makes it a weak paradigm in the big picture. It's just not a rich enough model. > In the distributed object world, the interface (which here is called > the 'API') is primary and the network plumbing and serialization format is a > detail to be taken care of by the system. Which is the fallacy: it doesn't work as well as defining protocols first. Because that plumbing isn't a mere detail, it's extremely significant to the overall evolution of the system and it needs to be designed with that in mind. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From LippmannJ at mmanet.com Wed May 5 20:01:41 1999 From: LippmannJ at mmanet.com (Lippmann, Jens) Date: Mon Jun 7 17:11:45 2004 Subject: IE5 brain damage Message-ID: <1CEC4A85AB34D21181C900A0C9CFE1279A789A@NY_EXCH_01> Open Explorer. Go to View|Folder Options. Go to the File Types Tab look XML document in the Registered file types box, click edit and edit the "open" command to ""D:\PROGRA~1\Plus!\MICROS~1\iexplore.exe" -nohome " or wherever iexplorer.exe resides on your machine. If that is already your Open command path, check whether you have "Open" as a default command and not "Edit". Good luck! Jens -----Original Message----- From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu] Sent: Wednesday, May 05, 1999 4:13 PM To: xml-dev@ic.ac.uk Subject: IE5 brain damage IE5 has some sort of stupid integration with my desktop (NT) such that when I try toopen a file off my local hard drive it opens in TextPad instead. The reason TextPad is picked is because that's what I've registered to handle XML files. But I'd still like to be able to use IE to open it directly. Does anyone know how to fix this so that IE does not hand off XML files to a helper app? It will open the XML file directly if (and only if) I follow a link to a file on the hard drive rather than simply opening it on my hard drive. Any suggestions? +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Java I/O (O'Reilly & Associates, 1999) | | http://metalab.unc.edu/javafaq/books/javaio/ | | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed May 5 21:13:05 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:45 2004 Subject: The Protocol [was: Syntax] is API Fallacy Message-ID: <035701be972a$1812abd0$0b2e249b@fileroom.Synapse> David Brownwell wrote: > >There's a signifcant issue with the quality of the linking. RPC systems >hide significant parts of the network, which need to be surfaced. They >don't expose faults well, or recovery mechanisms; they complicate callback >style messaging patterns unduly; they bury encoding issues, and impose >specific protocol-to-API mappings even in environments where they're not >at all appropriate. > This isn't the problem with RPC systems at all (including CORBA, Java RMI, DCOM, DCE-RPC etc), and certainly the current defacto web 'protocol' namely a form and www-form-encoding or a CGI query string is hardly a robust way for programs to communicate. Rather, the ubiquity of firewalls allows HTTP and SMTP traffic to flow where no RPC can go. You are missing the picture. Designing your own network protocol for each new application is as useful as writing your own XML parser for each new application. We have learned something from layering, interfaces and code reuse (despite your protests). Why should a developer need understand network issues etc when all they wish to do is send a message across the network. This is what libraries are for. All modern languages are object oriented (e.g. Java, Python, C++ etc.). One of the hallmarks of object orientation is enabling code reuse. Why reinvent a protocol when a library implements it? >Consider that no RPC system in the world (CORBA, ONC, DCE, etc) has had >the reach of some rather basic non-RPC systems like E-Mail (SMTP, POP, >IMAP) or the web (HTTP, HTML, XML, etc). For folk who have spent a lot >of time working on architectural issues, this is telling: it says that >there's quite likely a problem with the RPC approach. > That's exactly my point, there is no reason not to layer IDL on top of perfectly good protocols such as HTTP and SMTP. There is no reason not to use perfectly good standards such as MIME. Why reinvent the wheel when you can *interface* to the wheel. Change the body of the car and reuse the wheel. This is what layering is all about. Why do you compare RPC to XML? They are different species. This confuses the issue. XML and HTML are document standards, CORBA is a distributed object standard. The fact that SMTP can punch through firewalls like no CORBA is important (and one reason why the reach is so extended). I'm suggesting that HTTP and SMTP are to be used as the protocol. Are you suggesting otherwise? I'm suggesting that the abstraction afforded by IDL and RPC can be layered on top of HTTP and SMTP via XML? Do you have a problem with this? Web native distributed computing means using XML and HTTP and SMTP. This doesn't replace the need to specify interfaces (for example the DOM is delivered as an IDL specification). The point here is whether distributed objects are good or bad (this becomes nothing more than your personal opinion ... others would differ) rather how can object technology, including distributed objects and object modelling be integrated with internet standards such as XML,RDF,HTTP and SMTP. This is my suggestion (feel free to propose another): Distributed systems can communicate via HTTP and SMTP using XML documents as the contents of their MIME messages and function in the same fashion as distributed systems which employ IIOP or DCE-RPC. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wunder at infoseek.com Wed May 5 23:12:32 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:11:45 2004 Subject: The Protocol [was: Syntax] is API Fallacy In-Reply-To: <035701be972a$1812abd0$0b2e249b@fileroom.Synapse> Message-ID: <3.0.5.32.19990505135813.00b8cdb0@corp> At 02:58 PM 5/5/99 -0400, Jonathan Borden wrote: > > This is my suggestion (feel free to propose another): Distributed >systems can communicate via HTTP and SMTP using XML documents as the >contents of their MIME messages and function in the same fashion as >distributed systems which employ IIOP or DCE-RPC. Some important parts of the GO Network portal backend use this approach. It has pluses and minuses, but it is clearly good enough for 24/7 online systems. If anyone wants to dig into models for concurrency, I recommend this paper: Hugh C. Lauer, Roger M. Needham: On the Duality of Operating System Structures. Operating Systems Review 13(2): 3-19 (1979) It arose out of hallway arguments over message-passing versus monitor programming styles. They prove the two equivalent, then go on to describe the flavor of each style. Very useful perspective. wunder -- Walter R. Underwood wunder@infoseek.com wunder@best.com (home) http://software.infoseek.com/cce/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ti64877 at imcnam.sbi.com Wed May 5 23:41:58 1999 From: ti64877 at imcnam.sbi.com (Ingargiola, Tito) Date: Mon Jun 7 17:11:45 2004 Subject: The Protocol [was: Syntax] is API Fallacy Message-ID: <3994C79D0211D211A99F00805FE6DEE249C026@exchny15.corp.smb.com> Hi, [JonathonBorden states:] > This isn't the problem with RPC systems at all (including CORBA, Java > RMI, DCOM, DCE-RPC etc), and certainly the current defacto web 'protocol' > namely a form and www-form-encoding or a CGI query string is hardly a > robust > way for programs to communicate. Rather, the ubiquity of firewalls allows > HTTP and SMTP traffic to flow where no RPC can go. > This seems a hard argument to make given that popular corba implementations which support firewalls via tunneling techniques have been around for a number of years, yet have not had much impact on corba's (lack of) popularity. The reason that http & friends have had the impact corba had hoped for has to do primarily with the fact that they're simple ("web-weasels" don't typically write CORBA servers); other reasons include ubiquity, performance and tools (emacs, vi, or notepad all work pretty well along with one of the many free, stable httpds available to anyone). [JonathonBorden states:] > That's exactly my point, there is no reason not to layer IDL on top of > perfectly good protocols such as HTTP and SMTP. There is no reason not to > use perfectly good standards such as MIME. > Certainly this can be done, but one has to wonder why one wants to do it. I've played extensively with manipulating DOM structures remotely via CORBA (see http://www.objdev.org/index.html for some details) and the bottom line is that the granularity of the DOM is inappropriate for significant use in a distributed system. You're better off in nearly all cases simply firing a stream of XML at whoever needs it. I think that one could happily integrate all sorts of wonderful XML-derived benefits into a CORBA environment by having both stream and remote invocation interfaces (I'm working on such a system now). However, "layering" CORBA on top of XML will prove to yield little of value except a reminder of how precious performance really is ;-> Regards, Tito. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu May 6 01:14:30 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:45 2004 Subject: The Protocol [was: Syntax] is API Fallacy Message-ID: <03bd01be974b$e2cfc080$0b2e249b@fileroom.Synapse> Ingargiola, Tito wrote: >[JonathonBorden states:] >> That's exactly my point, there is no reason not to layer IDL on top of >> perfectly good protocols such as HTTP and SMTP. There is no reason not to >> use perfectly good standards such as MIME. >> >Certainly this can be done, but one has to wonder why one wants to do it. >I've played extensively with manipulating DOM structures remotely via CORBA >(see http://www.objdev.org/index.html for some details) and the bottom line >is that the granularity of the DOM is inappropriate for significant use in a >distributed system. You're better off in nearly all cases simply firing a >stream of XML at whoever needs it. You are suggesting using the DOM to model your distributed objects. This is a bad idea. You are correct in your conclusion that this is a bad use of granularity, though I've never tested this out myself because it is evident by a quick analysis of round trips. What I had suggested was to use XML to marshal objects by value (MBV) which specifically gets around the network roundtrip killer. Furthermore I am suggesting that by enabling use of web native protocols under currently available distributed object systems we can move toward a better integration of distributed objects and the web. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smo at jst.com.au Thu May 6 03:44:52 1999 From: smo at jst.com.au (Steve Oldmeadow) Date: Mon Jun 7 17:11:45 2004 Subject: XML-Conformant Programming Languages References: <3.0.1.32.19990505084700.0103ce30@tiac.net> Message-ID: <005601be9761$54ea0f80$0201a8c0@pikachu> ----- Original Message ----- From: Joshua E. Smith To: XML Developers' List Sent: 05/05/1999 8:47 Subject: XML-Conformant Programming Languages > However, you cannot release a product to Jane Q. Public (even for free) > which uses a "little language" and tell her she needs to write her programs > in Notepad. She needs a tool to make organizing the constructs of the > language easy. (They call this "Visual Programming" and it's actually > pretty cool when it's done right -- which is almost never, because people > keep trying to put visual wrappers around glorified machine languages like > Java.) One thing you missed in your summary was whether DTDs can support what you want to do. I think you have a wonderful vision and I am sure it is shared by many people here. I just don't think a DTD is going to do what you want. Hopefully with the new schema language we can start developing tools like the one you envisage. As far as "Visual Programming" environments go (especially for "non programmers") I think it is invaluable to have the ability to step through the code and see what is happening which implies an IDE rather than a simple editor. > Oh, and some of you have a pretty jaded view of programming > languages. Do yourself a favor and go learn LISP and FORTH. You'll see > that very useful programming languages don't have to be an unholy mess like > C, Java, Perl, and VB. Check the back issues of Dr. Dobbs for a good > article on FICL, for example. To quote the Tao Te Ching "He who understands does not preach, he who preaches does not understand" ;) Seriously though, I would love to learn LISP and FORTH unfortunately time is limited and there isn't much demand where I am for LISP and FORTH programmers. Steve Oldmeadow xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wperry at fiduciary.com Thu May 6 07:21:44 1999 From: wperry at fiduciary.com (W. E. Perry) Date: Mon Jun 7 17:11:45 2004 Subject: The Protocol [was: Syntax] is API Fallacy References: <03bd01be974b$e2cfc080$0b2e249b@fileroom.Synapse> Message-ID: <373126DC.B957ACD3@fiduciary.com> Jonathan Borden wrote: > Furthermore I am suggesting that by enabling use of web native protocols > under currently available distributed object systems we can move toward a > better integration of distributed objects and the web. This is an admirable goal, and one which I believed in and pursued for some time. However, 'currently available distributed object systems' were designed for closed enterprise networks and have proved (are proving?) to be utterly unsuitable for the web. The web remains overwhelmingly text-based (HTML mostly, of course). Objects are fundamentally inimical to the text-based assumptions underlying most of what is done on the web. The history of non-text additions, from .jpeg and .gif, to real audio, shockwave and flash has been in essentially the opposite direction from interoperable objects or distributed components. Simply put, the object-and-interface paradigm has not been well received in an open market. I think that this was Dave Brownell's point, from a somewhat different perspective, earlier in this thread: > Consider that no RPC system in the world (CORBA, ONC, DCE, etc) has had > the reach of some rather basic non-RPC systems like E-Mail (SMTP, POP, > IMAP) or the web (HTTP, HTML, XML, etc). For folk who have spent a lot > of time working on architectural issues, this is telling: it says that > there's quite likely a problem with the RPC approach. > It may be a reasonable argument that there are some (few) cases where a truly authoritative object should be invoked via an RPC mechanism--perhaps to use the inventor's own implementation of a process or an algorithm. In most real-world cases I am familiar with, however, the marshalling and de-marshalling are simply too expensive and potentially error-prone to be competitive alternatives to performing locally the processing for which the local node is responsible. In the best examples we have of truly distributed systems in production today, each local node may have no idea of how, by whom, for what, or in what context the output of its local processing is used by any other node (or for that matter what processes its input comes from--an essential consideration if its own processes change in a way which affects how input must be marshalled to them). Efficient designs concentrates on the performance which can be achieved in those local processes and will not burden the local node with knowing too much about other nodes in the system, especially since that knowledge can go out of date quickly and in ways which may not be easily discoverable. The promise of XML for solving these problems stems in part from its differences from objects: primarily, where objects are opaque and require prior knowledge of their interfaces, documents display openly not only the data they might convey but also the structure described by their markup. I would agree with Tito Ingargiola: > You're better off in nearly all cases simply firing a stream of XML at whoever needs it. I think that > one could happily integrate all sorts of wonderful XML-derived benefits into a CORBA environment > by having both stream and remote invocation interfaces > though my own preference (and the best solution in the overwhelming majority of the situations I see) is for the stream of XML over the remote invocation interface. Walter Perry xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 oofile.com.au Thu May 6 11:01:38 1999 From: dent at oofile.com.au (Andy Dent) Date: Mon Jun 7 17:11:45 2004 Subject: XML-Data and database mapping Message-ID: I've been wrestling with issues for encoding databases (and report definitions) into a single XML file and restoring them, for some time. I would appreciate some feedback on the following. I would be ecstatic to be told I'm blind, stupid, lazy and have missed some very obvious postings covering all these issues :-) ----- EMBEDDED SCHEMA My current compromise is to have other tags where the schema describes all following tags but obviously not the root tag. Note: I'm using the MS convention of rather than strict XML-Data name . ----- MAPPING FIELD TYPES AND TABLES The most serious problem I see with mapping database schemae using XML-Data or the other published suggestions is the lack of scoping. As I understand the (suggested) specifications and the current MS versions, fields within database tables will be handled by definitions and referred to from within a table's by tags. This means that fields within tables are globally scoped in their definition, unlike the usual DB practice that a field is defined within the context of a database table (relation). At a trivial level, "Name" might be a compatible data type such as fixed-length string, but a different length, within and . I would vastly prefer to use an agreed standard for our schema export/import but this restriction makes it impossible. Once you accept that field definitions can be scoped within tables, it's a much nicer syntax to define field data types within the tag as shown below. This approach can co-exist with defining separately as separate definitions would be seen as instead of ----- EXAMPLE OUTPUT FWIW the following is the current output of our report writer, which I am in the process of enhancing so it can read such a report document back in again. Note: 1) we encode layout separately from style 2) the style strings are mainly CSS compliant except if we have things like graphs where we use CSS-like syntax to describe graph attributes 3) our layout has a CSS object model where possible and includes an assumption of nested styles - an element within the layout inherits styles from its containing elements.
Page 1 Set your school name in 'Preferences' Outcomes achieved by this student
Josef ABRAMSON
KIDMAP 99 for Macintosh Printed by KIDMAP Manager on 5/5/1999
Number of outcomes listed: 24
ARDA11 Draws upon play 16th Mar 1999 MANAGER ARDA21 Use experience 16th Mar 1999 MANAGER ARDA31 Explore ideas 16th Mar 1999 MANAGER ARDA41 Experiment - ideas 16th Mar 1999 MANAGER 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.oofile.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paxamr at unix.ccc.nottingham.ac.uk Thu May 6 12:34:38 1999 From: paxamr at unix.ccc.nottingham.ac.uk (adam moore) Date: Mon Jun 7 17:11:45 2004 Subject: XML-Conformant Programming Languages In-Reply-To: <005601be9761$54ea0f80$0201a8c0@pikachu> Message-ID: On Thu, 6 May 1999, Steve Oldmeadow wrote: > > in Notepad. She needs a tool to make organizing the constructs of the > > language easy. > > One thing you missed in your summary was whether DTDs can support what you > want to do. Surely this is exactly what DTD's can do - 'organize the constructs of a language' - and with a DTD and something like Xeena from IBM I think it's possible now? (Xeena is an editor that uses a DTD to constrain the authors into only writing valid syntax: http://www.alphaworks.ibm.com/tech/xeena). > As far as "Visual Programming" environments go (especially for "non > programmers") I think it is invaluable to have the ability to step through > the code and see what is happening which implies an IDE rather than a simple > editor. > I agree - but to have a tool which ONLY LETS YOU WRITE VALID CODE IN THE FIRST PLACE will surely be a big leap up from trying to debug code you wrote in a standard editor and then try and find the typo's/missing separators/line-breaks/etc.? Just my tuppence h'penny worth *8-) Adam Moore Virtual School of Molecular Sciences School of Pharmaceutical Science, University of Nottingham http://www.vsms.nottingham.ac.uk/vsms/ Personal Page:http://www.ccc.nottingham.ac.uk/~paxamr/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at metalab.unc.edu Thu May 6 15:56:42 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:11:46 2004 Subject: IE5 brain damage In-Reply-To: <85256768.006149B1.00@mail.copeland.com> Message-ID: >If I understand you correctly it sounds like you need to change the program >associated with your.xml files. Everyone has suggested changing the associations, buct that's not the issue. I am aware of how to do that. The problem is that despite the association with Textpad I should still be able to open an XML file in IE and I can't. Think of it this way. By going to File->Open in Word, you can open a WordPerfect document in Word even if WordPerfect is installed on the system and registered to handle Wordperfect files. Now imagine that when you try to open a WordPerfect file in Word, it instead launches WordPerfect and opens the file in WordPerfect. That's more or less what's happening when I try to read an XML file in IE5. The associations should affect what program is launched when I double-click a file of a particular type. It should not affect what happens when I specifically ask a particular program to open a particular file. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Java I/O (O'Reilly & Associates, 1999) | | http://metalab.unc.edu/javafaq/books/javaio/ | | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Thu May 6 16:21:10 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:11:46 2004 Subject: IE5 brain damage Message-ID: <93CB64052F94D211BC5D0010A800133170EE5D@wwmess3.bra01.icl.co.uk> > The associations should affect what > program is launched when I double-click a file of a > particular type. It should not affect what happens when I specifically ask a > particular program to open a particular file. > This is Microsoft trying to persuade us that the browser is part of the operating system, not just an application. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Thu May 6 16:27:14 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:46 2004 Subject: XML-Conformant Programming Languages In-Reply-To: <005601be9761$54ea0f80$0201a8c0@pikachu> References: <3.0.1.32.19990505084700.0103ce30@tiac.net> Message-ID: <3.0.1.32.19990506102314.01058930@tiac.net> >As far as "Visual Programming" environments go (especially for "non >programmers") I think it is invaluable to have the ability to step through >the code and see what is happening which implies an IDE rather than a simple >editor. That's a really good point, and it's probably why I won't be able to get away without writing an IDE forever. However, there are some pretty good examples of languages for which an integerated editor/debugger came long after acceptance (thinking javascript here). By then, though, there will be some great XML editor in open source written in Java, and I can extend someone else's editor, rather than writing my own! ;) Or maybe we can all agree on some APIs (God, let it not be ActiveX!) which editors should provide, so we can tell them (from a running program) to highlight a given line and character position, to add an item (like "Stop Here") to their menu bar, etc. I could see that being useful even when you use XML for more traditional document applications (imagine being able to single-step through the interpretation of the document by your formatter and being able to show the user what all the &entities are expanding into). -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 at xmltree.com Thu May 6 16:49:20 1999 From: james at xmltree.com (james@xmlTree.com) Date: Mon Jun 7 17:11:46 2004 Subject: Fw: IE5 brain damage Message-ID: <020d01be97cf$87d65e30$0500a8c0@fourleaf.com> Elliotte One solution would be to add some applications to your SendTo directory. In mine I have 3? Floppy (A), ColdFusion Studio 4.0, Desktop. Internet Explorer, Mail Recipient, Notepad. You can add applications by selecting properties on the taskbar, selecting the Start Menu Programs tab, clicking on Advanced, and adding Windows shortcuts to the folder called SendTo (just above StartMenu). Once you have done this, you can manipulate an XML file by right-clicking on it and selecting Send To from the popup menu. You can then select the application you want to open the XML file with. Hope this helps, Best regards, James Carlyle james@xmltree.com Wavefront Limited 70 Acton Street London WC1X 9NB UK (44) 171 813 0665 www.xmltree.com - directory of XML content on the web xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ti64877 at imcnam.sbi.com Thu May 6 17:23:57 1999 From: ti64877 at imcnam.sbi.com (Ingargiola, Tito) Date: Mon Jun 7 17:11:46 2004 Subject: The Protocol [was: Syntax] is API Fallacy Message-ID: <3994C79D0211D211A99F00805FE6DEE249C02B@exchny15.corp.smb.com> Hi, [ Jonathan Borden states: ] > You are suggesting using the DOM to model your distributed objects. > This is a bad idea. You are correct in your conclusion that this is a bad > use of granularity, though I've never tested this out myself because it is > evident by a quick analysis of round trips. > agreed > What I had suggested was to use > XML to marshal objects by value (MBV) which specifically gets around the > network roundtrip killer. > Actually, the idea of using XML as the means of achieving MBV doesn't seem too good to me. Why? First, one of the great attractions of a distributed object system is precisely that I'm not typically zapping objects about the network, but am rather dealing with the more interesting objects in different address spaces by (remote) reference. So, as an an application developer using corba, I really don't care too much how my corba implementation (as provided by Iona or whomever) does its business (e.g., marshalling). I just care that it does it correctly and, hopefully efficiently. The question then becomes: "does a corba implementation developer (e.g., someone writing orbix at Iona) want to use xml as the underlying representation for the marshalling of objects?" I still think the answer to this question is likely "no." It'll likely be less efficient than other such implementations, and adds little value otherwise. Finally, I'm not convinced that a corba/RPC-style of remote method invocation is typically well suited to web-oriented interactions -- most things on the web can be treated naturally and efficiently as streams. Why add the extra weight (which seems to buy me little) of corba to a domain in which it seems a mis-fit? > Furthermore I am suggesting that by enabling use of web native > protocols > under currently available distributed object systems we can move toward a > better integration of distributed objects and the web. > I certainly share your enthusiasm for a better integration between distributed objects and the web. My experience thus far tells me that layering corba (or some other rpc -like mechanism) on top of more ubiquitous streaming protocols costs a lot and yields little benefit. However, efforts like http-ng offer the promise of such an integration without carrying some of the baggage that might come with trying to shoehorn a big heavy thing like corba on top of something so umm svelte ;-> as http and friends. Naturally, your mileage may vary... Best regards, Tito. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 6 18:10:50 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:11:46 2004 Subject: Do I need to use a validating parser? Message-ID: <001201be97d2$f7585440$27f96d8c@NT.JELLIFFE.COM.AU> From: Joshua E. Smith >My language isn't anything like LISP or ALGOL, but I think this gets the >point across. It's pretty easy to write programming languages which are >XML-Conformant. >From one point of view, all interaction actions with a computer corresponds to "programming" in a language (in that a grammar, however complicated, can be constructed to model it: I suppose this is an implication of Church's Thesis). While true, that viewpoint deprives "programming" of its specific meaning; it makes "programming language"=="markup language"=="interaction modeling language". It ignores that a markup language is designed to be data with processing instructions embedded, while a programming language is processing instuctions with data embedded. Of course, there are middle grounds: there are data-ish programming languages such as LISP, and programmish DTDs such as ISMID. If you are looking at making programming languages in XML, look at ISMID, which is a compiled format for IETMS (Interactive Electronic Technical Manuals). You can see it at the US Navy site (www.ietm.net) or (better) at the ISO site: http://www.jtc1.org/Navigation.asp?Area=Structure&Mode=Browse&SubComm=SC *space*34&x=7&y=6 then go "documents" then search for "MID" (remember to click the "Search by title" button") then clock on document 7, "Revised Text of MID". 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Thu May 6 18:18:37 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:46 2004 Subject: The Protocol [was: Syntax] is API Fallacy References: <3994C79D0211D211A99F00805FE6DEE249C026@exchny15.corp.smb.com> Message-ID: <3731BF1C.5967924F@pacbell.net> "Ingargiola, Tito" wrote: > > [JonathonBorden states:] > > > This isn't the problem with RPC systems at all (including CORBA, Java > > RMI, DCOM, DCE-RPC etc), and certainly the current defacto web 'protocol' > > namely a form and www-form-encoding or a CGI query string is hardly a > > robust > > way for programs to communicate. Rather, the ubiquity of firewalls allows > > HTTP and SMTP traffic to flow where no RPC can go. [ Though note that this comment didn't actually respond to any of my points that it was positioned as responding to ... ] > This seems a hard argument to make given that popular corba implementations > which support firewalls via tunneling techniques have been around for a > number of years, yet have not had much impact on corba's (lack of) > popularity. The reason that http & friends have had the impact corba had > hoped for has to do primarily with the fact that they're simple > ("web-weasels" don't typically write CORBA servers); other reasons include > ubiquity, performance and tools (emacs, vi, or notepad all work pretty well > along with one of the many free, stable httpds available to anyone). Right. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Thu May 6 18:54:27 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:46 2004 Subject: The Protocol [was: Syntax] is API Fallacy References: <035701be972a$1812abd0$0b2e249b@fileroom.Synapse> Message-ID: <3731C91D.3D2128F7@pacbell.net> Jonathan Borden wrote: > > David Brownell wrote: > > >There's a signifcant issue with the quality of the linking. RPC systems > >hide significant parts of the network, which need to be surfaced. They > >don't expose faults well, or recovery mechanisms; they complicate callback > >style messaging patterns unduly; they bury encoding issues, and impose > >specific protocol-to-API mappings even in environments where they're not > >at all appropriate. > > This isn't the problem with RPC systems at all (including CORBA, Java > RMI, DCOM, DCE-RPC etc), Which of those six points are you referring to? I assure you I've seen at least half of those problems in each "RPC" system you mention. > and certainly the current defacto web 'protocol' > namely a form and www-form-encoding or a CGI query string is hardly a robust > way for programs to communicate. For three years now, I've advised folk to use HTTP "POST" with request bodies that encode data in some useful form ... e.g. XML documents. Query strings only appropriate for requests where parameters can safely be logged (no credit card info!) or exposed to third party sites (watch those "Referer:" headers) and also are idempotent (which very few are). > Rather, the ubiquity of firewalls allows > HTTP and SMTP traffic to flow where no RPC can go. That's an issue I raise separately. CORBA was designed to support the notion of firewall bridging, and in fact I wrote that into the spec. Few other RPC systems have the technical wherewithal to handle that; you need an exposed, queriable type system. (Preferably a lot better than XML DTDs!) > You are missing the picture. Designing your own network protocol for > each new application is as useful as writing your own XML parser for each > new application. Apples and oranges. Exactly what do you think any RPC's IDL is doing, if not defining a new protocol? (And causing problems by equating it to API?) Are you perhaps confusing lower level protocols with higher level ones? > We have learned something from layering, interfaces and > code reuse (despite your protests). Why should a developer need understand > network issues etc when all they wish to do is send a message across the > network. Sending messages is what defines a protocol. Sending new messages is what defines a new protocol. Not all sequences of messages can work in the face of the inevitable failures, and that's part of why developers need to have some understanding of network issues. > >Consider that no RPC system in the world (CORBA, ONC, DCE, etc) has had > >the reach of some rather basic non-RPC systems like E-Mail (SMTP, POP, > >IMAP) or the web (HTTP, HTML, XML, etc). For folk who have spent a lot > >of time working on architectural issues, this is telling: it says that > >there's quite likely a problem with the RPC approach. > > That's exactly my point, there is no reason not to layer IDL on top of > perfectly good protocols such as HTTP and SMTP. You're then missing my point in its entirety. The problem is the model, the notion that the system building block is an "RPC" of any kind. Protocol isn't the issue; after all, in an RPC system, it doesn't matter right? Since nobody sees it. > Why do you compare RPC to XML? > They are different species. This confuses the issue. I don't think I compared them except by context; but the reason it's an interesting comparision is because they _are_ different species. XML based systems can be designed without some of the flaws of RPC based systems. Or -- they could recreate those flaws. I vote for the former. > I'm suggesting that the abstraction afforded by IDL and RPC can be > layered on top of HTTP and SMTP via XML? Do you have a problem with this? Yes. I stated it pretty succinctly above: > > they bury encoding issues, and impose > > specific protocol-to-API mappings even in environments where they're not > > at all appropriate. Or as I said later in that post, you have to change API and protocol in lockstep. > This is my suggestion (feel free to propose another): Distributed > systems can communicate via HTTP and SMTP using XML documents as the > contents of their MIME messages So far so good; people have agreed on that one for some time. Though I'm waiting to see details on how SMTP really fits in. Store-and-forward messaging is usually done through a different API model than RPC. > and function in the same fashion as > distributed systems which employ IIOP or DCE-RPC. That's where I have problems. Those systems impose the RPC model. And I have stopped liking that model for "real systems". It's an appealing way to get started; there's a seeming simplicity from the academic point of view. But such systems don't grow/evolve so well. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fitzhugh at cup.hp.com Thu May 6 19:06:16 1999 From: fitzhugh at cup.hp.com (Andrew Fitzhugh) Date: Mon Jun 7 17:11:46 2004 Subject: The Protocol [was: Syntax] is API Fallacy In-Reply-To: <373126DC.B957ACD3@fiduciary.com> Message-ID: <000801be97e2$7ef5e5c0$ba5a000f@samba.cup.hp.com> W. E. Perry wrote: > Jonathan Borden wrote: > > > Furthermore I am suggesting that by enabling use of web native protocols > > under currently available distributed object systems we can move toward a > > better integration of distributed objects and the web. > > This is an admirable goal, and one which I believed in and pursued for some time. However, > 'currently available distributed object systems' were designed for closed enterprise networks > and have proved (are proving?) to be utterly unsuitable for the web. Whether or not an XML-RPC based distributed computing system is technically superior/correct/elegant/efficient to me is not so important. To me HTML + HTTP opened the door to an explosion of *content* publishing, where laymen were as successful as SGML experts. Nobody ever argued that HTML was superior to SGML; it was obviously more accessible, though. XML-RPC + HTTP can allow a similar explosion of *functionality* publishing. It allows distributed computing laymen to build remotely accessible applications with orders of magnitude less effort than it takes to build CORBA/DCOM/IIOP/etc. based distributed apps today. HTML is really a primitive layout format, yet it became pervasive overnight. XML-RPC based distributed apps could be seen as quite primitive compared to mature, rigorously designed distributed object frameworks, but they are so simple that they could become pervasive. I see it as the gentrification of distributed object computing. -- Andy ________________________________________________________________________ Andrew Fitzhugh fitzhugh@cup.hp.com HP Internet Imaging Operation xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu May 6 19:26:57 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:46 2004 Subject: IE5 brain damage References: Message-ID: <3731D0C9.E3593B37@locke.ccil.org> Elliotte Rusty Harold wrote: > The associations should affect what > program is launched when I double-click a file of a particular type. It > should not affect what happens when I specifically ask a particular program > to open a particular file. For the most part IE is (and always has been) a simple container for ActiveX controls (including the HTML one) rather than an application per se. An interesting illustration: if you open a file://c:/foo/bar/baz URL, where baz is a directory, you get an ordinary Windows Explorer window displaying the contents of the directory! -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 6 19:39:05 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:11:46 2004 Subject: DTD for RDF? How is that possible? Message-ID: <001501be97df$4a8194e0$27f96d8c@NT.JELLIFFE.COM.AU> From: Roger L. Costello >I recall seeing a posting a few months back where someone posted a DTD That was me! See http://www.ascc.net/xml/en/utf-8/resource_index.html >for RDF. Upon reflection I find this puzzling. How could you possibly >create a DTD for RDF? Not at all. It was trivial to make a DTD for almost all of the RDF syntax. I think the DTD is a lot clearer than their formal syntax. In fact, their formal syntax leaves out rdf:subject, rdf:object, rdf:predicate, rdf:type and rdf:type. I have put these in today. The only thing that eludes DTDs is the unlimited number of rdf:_n attributes; I have put in 8 and you can add as many more as you need; they seem a particularly gratuitous carbuncle on RDF to me: I trust everyone will boycott that abbreviated form (the GratAbbCarb ?). >It is my understanding that RDF documents can only be "well-formed". >There is no such thing as a "valid" RDF document. Correct? /Roger But for any particular group of documents you can make up a DTD for them. And you can use a variant of the DTD to constrain your users to prevent them from using the rdf:_n attributes. That would be a prudent move. So in fact you can have lots of DTDs which generate data that complies with RDF. And you can generate a DTD (like mine) which should accept any RDF document (providing, of course, that you include complete the DTD to include any domain-specific element names: these can be included in the internal prolog). >... By definition, the child elements in >rdf:Description are arbitrary: > > > > In order to think about the DTDs, we need to split the structure into levels: * The first is the direct structure (this is the DTD that I give)--it says that an rdf:RDF element has a declared content type of ANY--that is easy, and it is what the RDF spec says, under all the fluff; Similarly, rdf:Description can have a content model of ANY. It is important to realize that "ANY" signifies this arbitrariness... * The second is the "architectural" structure (I didn't give a DTD for this: I just put it in comments and a parameter entity; I could have used ISO's Architectural Forms declarations to declare this architectural structure): this says that a child of an rdf:RDF must be ( rdf:Description | rdf:Bag | rdf:Set | rdf:Seq ) and gives the appropriate attributes for these. Because these are architectural elements, they do not have to be signified in the element type identifier (i.e., you can use any name, as long as you have the correct attributes and the correct content models). Rdf:Description would have an architectural content model of (rdf:PropertyElement )* and the rdf:PropertyElement has its due attributes. So conventional DTD modeling sees this as two structures, each of which can be described using DTDs. Since the RDF people didn't use architectures, they are forced to use BNF (which is incomplete w.r.t. XML, and incomplete and confusing w.r.t. RDF) and are banished to cry for other forms of extended context declarations. The document can be validated against the direct DTD only, but the indirect DTD, if constructed, could be used to valid using an architectural validator. (Probably that XAF tool could do it. You could also use XSL to do this kind of validation: I have an article on the same site "Using XSL for Structural Validation" which looks into it: of course, unless XSL has some way to check for names generated from numbers, it cannot validate all possible rdf:_n attributes, but that is a flaw in RDF.) At least the RDF stands as a notable application that doesn't use the direct element type identifier to key the content model. Following Murata Makoto's excellent XTech99 talk about performing set operations on content models, I have been a little afraid that other forms of validation (e.g. architectural validation using attribute names, or content model validations that follow IDREFs instead of subelements) have been thrown out. Which is a shame, because parallel content models provide some nice capabilities (as RDF may, in about a million years, prove). I still find it difficult to see RDF as anything other than a way of making implicit relationships, which every DTD designer builds into their DTD, explicit. This allows generic tools which understands the relationships. But the generic tools still need to understand the schemas, so I think RDF does not take us very far in practise, apart from the drab tasks of managing, navigating and visualizing. It is not a very thick layer, so it is a pity they have such a restrictive syntax: the whole thing should have been an architecture that could have been retrofitted to any existing DTD. A great opportunity missed, IMHO. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 6 20:01:46 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:46 2004 Subject: XML-Conformant Programming Languages In-Reply-To: <005601be9761$54ea0f80$0201a8c0@pikachu> References: <3.0.1.32.19990505084700.0103ce30@tiac.net> <005601be9761$54ea0f80$0201a8c0@pikachu> Message-ID: * Steve Oldmeadow | | To quote the Tao Te Ching "He who understands does not preach, he | who preaches does not understand" ;) Seriously though, I would love | to learn LISP and FORTH unfortunately time is limited and there | isn't much demand where I am for LISP and FORTH programmers. However, there is demand for good programmers, and for that reason alone it is well worth your while to learn Lisp. (Certainly, it was worth mine.) My recommendation to anyone who is serious about programming is to get hold of SICP[1] and a book on Common Lisp[2] and get started. SICP should pay off immediately, but Common Lisp requires you to get used to it before you start getting any benefits from it. Oh, and you can earn a living writing Common Lisp. --Lars M. [1] [2] Maybe 'ANSI Common Lisp' and 'On Lisp' by Paul Graham. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu May 6 20:56:22 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:46 2004 Subject: The Protocol [was: Syntax] is API Fallacy Message-ID: <007f01be97f0$fcbc32d0$0b2e249b@fileroom.Synapse> David, Although IDL started life as a way to specify RPC interfaces, more recently it has become a way to specify interfaces in general (e.g. the DOM which few intend to access via RPC). I don't mean to suggest that 'integration' or layering of IDL onto web protocols need actually mean implementing any specific RPC protocol via XML (e.g. XML-RPC), rather, my intention is to discuss a mechanism to integrate the abstraction of IDL onto the data of XML or SGML. Let me try to rephrase this. The current popular style of object specification describes an object as being composed of interfaces which contain properties and methods (a property is comprised of a getX() setX() method pair). Methods are intended to specify actions. There are benefits to describing systems in this fashion. When we talk about an API, if we are talking about an object system, we are typically talking about a defined set of interfaces. In this way of thinking, in the object world, the API is the primary specification. In the object world, the idea is that if the API is properly specified all the other details will fall into place (e.g. implementation). The document world has a sharply different world-view, the primary focus being data. When the data is properly specified e.g. property sets and groves, all the details fall into place. What I am working on are methods to integrate these two world views. I believe many of the arguments on both sides of the picture. We need to rigorously define interfaces between components and we need to rigorously define data formats. >> >> David Brownell wrote: >> >> >There's a signifcant issue with the quality of the linking. RPC systems >> >hide significant parts of the network, which need to be surfaced. They >> >don't expose faults well, or recovery mechanisms; they complicate callback >> >style messaging patterns unduly; they bury encoding issues, and impose >> >specific protocol-to-API mappings even in environments where they're not >> >at all appropriate. >> When I say: >> This isn't the problem with RPC systems at all (including CORBA, Java >> RMI, DCOM, DCE-RPC etc), > >Which of those six points are you referring to? I assure you I've seen >at least half of those problems in each "RPC" system you mention. Perhaps I worded this incorrectly. We could argue the utility of RPC for years. I find the abstraction of the RPC a very powerful one, regardless of any problems with specific implementations. I think the abstraction of a distributed object or remote method call will become integrated with the web rather than replaced by the web. My main problems with specific implementations is that firewalls are killers even for firewall enabled RPC systems for these reasons: 1) Network address translation. 2) buggy firewalls that choke on binary data but work fine with text. and most importantly !!!! 3) Sys admins already open the HTTP and SMTP ports but get very nervuous or refuse to open selected ports for RPC protocols. These problems are compounded when you have complex networks of firewalls. In the Boston medical environment, for example, each department in a hospital may have its own firewall which links to the hospital which in turn has links to both corporate as well as academic networks and internet connections each passing through different firewalls. E-mail seems to always work, HTTP usually works, otherwise all bets are off. I do believe that the abstraction of the RPC is an important enough one that problems with specific implementations e.g. callbacks and faults, and generally difficult things like recovery mechanisms (as opposed to detection of transaction failure) are worth solving. > > >> and certainly the current defacto web 'protocol' >> namely a form and www-form-encoding or a CGI query string is hardly a robust >> way for programs to communicate. > >For three years now, I've advised folk to use HTTP "POST" with request >bodies that encode data in some useful form ... e.g. XML documents. Then we argee :-) Why are we arguing? > >Apples and oranges. Exactly what do you think any RPC's IDL is doing, if >not defining a new protocol? (And causing problems by equating it to API?) > >Are you perhaps confusing lower level protocols with higher level ones? > One person's low level protocol is another's high level protocol. Perhaps here is the problem. There are a few 'terms' object, protocol, data etc, which get used for a variety of purposes. My point about the need for layering (and invoking the OSI model) is that an analysis at one level may not be appropriate at another level. Is the interface the protocol or DEC-RPC NDR (or ONC-XDR) the protocol? (point only that one 'protocol' may change with each interface while the other remains the same across interfaces). The protocols I am considering are HTTP and SMTP. If you are discussing a need for protocols at a higher level than these, i.e. layered on top of HTTP and SMTP I have no argument. > > >> >Consider that no RPC system in the world (CORBA, ONC, DCE, etc) has had >> >the reach of some rather basic non-RPC systems like E-Mail (SMTP, POP, >> >IMAP) or the web (HTTP, HTML, XML, etc). For folk who have spent a lot >> >of time working on architectural issues, this is telling: it says that >> >there's quite likely a problem with the RPC approach. >> >> That's exactly my point, there is no reason not to layer IDL on top of >> perfectly good protocols such as HTTP and SMTP. > >You're then missing my point in its entirety. The problem is the model, >the notion that the system building block is an "RPC" of any kind. Protocol >isn't the issue; after all, in an RPC system, it doesn't matter right? Since >nobody sees it. No my point is that you equate IDL which is a specific way to define interfaces (or APIs) and RPC which defines a network protocol to effect procedure calls across networks. I am saying IDL not RPC. For example, is it wrong to consider a web site as a type of 'distributed object'. Each 'page' in a subdirectory corresponds on an abstract level to a method in an interface. This might allow integration of UML tools for example and web tools. Communications between client and server under this model are between HTTP user agent/browser and HTTP server. > > >> This is my suggestion (feel free to propose another): Distributed >> systems can communicate via HTTP and SMTP using XML documents as the >> contents of their MIME messages > >So far so good; people have agreed on that one for some time. Though >I'm waiting to see details on how SMTP really fits in. Store-and-forward >messaging is usually done through a different API model than RPC. > I am not proposing an RPC model but for the sake of argument, in Microsoft's COM+, for example, async method calls operate via an MSMQ transport of MS-RPC. MSMQ is a messaging protocol. I see no reason that COM+ async method calls couldn't be implemented over SMTP if MS had the inclination. I see SMTP as useful for async messaging where HTTP is useful for sync messaging. Both transmit MIME messages. A concrete benefit of SMTP is that it can go anywhere, even where HTTP is not enabled, for example I have used this for ship to shore telemedicine links via bandwidth challenged satellite links. Again this is a comparison done xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From spreitze at parc.xerox.com Thu May 6 21:17:09 1999 From: spreitze at parc.xerox.com (Mike Spreitzer) Date: Mon Jun 7 17:11:46 2004 Subject: XML-Data and database mapping In-Reply-To: Message-ID: <001101be97f4$efb91090$27d1000d@deimos.parc.xerox.com> I think you'll find some (not necessarily all) of your issues are addressed in the first draft output of the XML Schema WG, just announced at . xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Thu May 6 21:56:51 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:11:47 2004 Subject: RDF Question: attaching multiple types to a resource Message-ID: <3731F43E.60473329@mitre.org> In an earlier posting it was clarified (to me) how a resource type property could be used as the resource element, i.e., [other properties] can be equivalently expressed as: [other properties] This morning I read in the RDF spec that you can associate multiple type properties to a resource, e.g., [other properties] If I wanted to create the alternate syntax as I did above, which type would I migrate up? Would the equivalent syntax be: [other properties] or [other properties] or both? I apologize for not stating my question very well. I am at a loss for the correct terminology. What is the correct terminology for morphing the syntax from: [other properties] to: [other properties] How about: "The type property has migrated up to resource element"? /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Thu May 6 22:11:18 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:47 2004 Subject: Some answers to my questions... Message-ID: <3.0.1.32.19990506160747.0103f1b4@tiac.net> FYI (stuff for that FAQ I'll never get around to writing): 1) It's trivial to link expat statically in a Windows environment. Just do the obvious and it just works. (James Clark is clearly a programmer who knows what he's doing.) Also, expat *can* read external general entities, you just have to help it a little. 2) There *are* already XML editors which look at the DTD and do very smart things. More than validating, they *prompt* you for stuff. The xeena editor at alphaworks (mentioned by someone earlier) is a bit slow (read: UI in Java) but very clever. On a really fast machine (faster than my P266 laptop), it'd be a terrific tool. 3) Looks like it's OK to trust an editor not to dump all your default values out into output files, so it's OK to put your default values in the DTD. Xeena does the right thing with them, so I presume others will follow suit. 4) Again, just judging from Xeena, I'm going to have to find a way to make my XML-Conformant programming lanugage valid, as well as well-formed. As I feared, it's hard for a validating editor to deal with invalid stuff. And xeena deals with valid stuff in very cool ways. Question still pending: Why should I use an external unparsed entity for URL attributes, when CDATA seems to be just fine? Oh, and a small amusement for you... LISP: (defun factorial (x) (if (= x 1) 1 (* x (- x 1)))) XML-LISP: The latter is a little more bloated in emacs, but it looks really nice in an XML editor. Q.E.D. ;) -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From LippmannJ at mmanet.com Thu May 6 22:38:00 1999 From: LippmannJ at mmanet.com (Lippmann, Jens) Date: Mon Jun 7 17:11:47 2004 Subject: IE5 brain damage Message-ID: <1CEC4A85AB34D21181C900A0C9CFE1279A78AC@NY_EXCH_01> > Everyone has suggested changing the associations, buct that's not the > issue. I am aware of how to do that. The problem is that despite the > association with Textpad I should still be able to open an > XML file in IE > and I can't. Can you describe the symptoms. I actually changed the association of "Open" to XMLPad.exe and was still able to use the File|Open command IE5 to open a "foo.xml" file. The only issue is that it doesn't have a filter for XML files, so you have to select "All Files" in order to be able to see your XML file. But this is regardless of the association. Do you want to create a filter for XML files? Jens xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From terje at in-progress.com Thu May 6 23:08:59 1999 From: terje at in-progress.com (Terje Norderhaug) Date: Mon Jun 7 17:11:47 2004 Subject: LISP + XML [was Re: XML-Conformant Programming Languages] Message-ID: At 11:01 AM 5/6/99, Lars Marius Garshol wrote: >* Steve Oldmeadow >| >| To quote the Tao Te Ching "He who understands does not preach, he >| who preaches does not understand" ;) Seriously though, I would love >| to learn LISP and FORTH unfortunately time is limited and there >| isn't much demand where I am for LISP and FORTH programmers. > >However, there is demand for good programmers, and for that reason >alone it is well worth your while to learn Lisp. (Certainly, it was >worth mine.) [...] Oh, and you can earn a living writing Common Lisp. My company is very interested in people that are savvy both in LISP and XML. We develop commercial XML and web software, included the Emile XML editor, the XPublish XML based website publishing system, the Cascade CSS style sheets editor, and the Interaction web server companion that uses server-side XML for dynamic, personalized websites. All implemented in ANSI Common LISP during the past four years (we supported extensible markup before XML was a term). Those that qualify and are interested in being on our list of candidates for positions are welcome to let me know by sending a resumee. In addition, we have an internship position for summer/fall available for students or recent graduates that have working knowledge of XML and LISP. We are also interested in people and companies that have the required competence to use Common LISP for customizing our XML software solutions for local customers and specific markets. Media Design in*Progress is located in San Diego, California. -- Terje Norderhaug President & Chief Technologist Media Design in*Progress San Diego, California Software for Mac Web Professionals at xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 6 23:36:49 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:47 2004 Subject: Do I need to use a validating parser? In-Reply-To: <012101be96a5$a9c85000$0201a8c0@pikachu> References: <3.0.1.32.19990504105427.0077e59c@tiac.net><3.0.1.32.19990504105427.0077e59c@tiac.net><3.0.1.32.19990504125402.0113cc48@tiac.net> <3.0.1.32.19990504221521.00c392a8@tiac.net> <012101be96a5$a9c85000$0201a8c0@pikachu> Message-ID: * Joshua E. Smith | | Nonetheless, always up for the academic discussion, you can express | the entire syntax of the LISP programming language in less than a | page of DTD, I bet. You can, but then you lose some of the really interesting things, such as read-macros and dispatching characters. It's hard to see any valid equivalents of those. For good examples of read-macros, see * Steve Oldmeadow | | I don't know LISP but how would you express scoping rules such as a | locally defined variable can only be accessed within the block it is | defined such as in Java? Like type-checking this is generally considered to be semantics and so one wouldn't normally expect a grammar to be able to express this. (In fact, I don't think it's possible using a context-free grammar.) | I came to the conclusion that XML added very little and that you | were better off just using the traditional tools to generate a | parser for your language. I certainly have to agree here. I think I prefer the approach taken by someone else recently: parse the language syntax into XML and then apply stylesheets and parsers to the XML for documentation, pretty-printing and whatever. | One thing I toyed with was whether a yacc like tool would be useful | for XML-ish languages, in other words it would help you generate | parsers for languages that are marked up using XML. This is probably possible, and I think this is what some of the alphaWorks tools do. Also, I already have an unreleased Python package which can turn some kinds of XML documents into sets of elements using some simple rules. This completely does away with the entire application-specific parser notion and just lets you use the objects. It doesn't work for all kinds of documents, though, but I think it might be possible to extend it to do so. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mads at pacbell.net Fri May 7 01:14:22 1999 From: mads at pacbell.net (MP) Date: Mon Jun 7 17:11:47 2004 Subject: Java based XML parsers for server use. Message-ID: <00ca01be9816$14e420f0$4526578b@ops.3com.com> Hello, Are there any Java based XML parsers that are suitable for server side use? One of the primary requirements for such a parser is that should be thread safe. i.e.., more than one thread should be able to use the parser simultaneously. According to IBM's alphaworks discussion group, their XML4J parser is NOT thread safe. Not sure about other parsers. Any pointers are appreciated. Thanks, Madhu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clovett at microsoft.com Fri May 7 02:38:43 1999 From: clovett at microsoft.com (Chris Lovett) Date: Mon Jun 7 17:11:47 2004 Subject: Java based XML parsers for server use. Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F36298A@RED-MSG-56> The ActiveX Control (MSXML.DLL - Microsoft XML Version 2.0) in IE5 provides a thread safe DOM with the progid "Microsoft.FreeThreadedXMLDOM". Attached is a document describing how to use this from Java. -----Original Message----- From: MP [mailto:mads@pacbell.net] Sent: Thursday, May 06, 1999 4:14 PM To: xml-dev@ic.ac.uk Subject: Java based XML parsers for server use. Hello, Are there any Java based XML parsers that are suitable for server side use? One of the primary requirements for such a parser is that should be thread safe. i.e.., more than one thread should be able to use the parser simultaneously. According to IBM's alphaworks discussion group, their XML4J parser is NOT thread safe. Not sure about other parsers. Any pointers are appreciated. Thanks, Madhu begin 600 javadom.htm M/&AT;6P^#0H-"CQH96%D/@T*#0H\;65T82!N86UE/2)'14Y%4D%43U(B(&-O M;G1E;G0](DUI8W)O2!B M9V-O;&]R/2(C1D9&1D9&(CX-"@T*/&@Q/E5S:6YG('1H92!)134@6$U,($1/ M32!FF4](C(B(&9A8V4](D-O;6EC(%-A;G,@35,B/D%F=&5R#0II;G-T86QL M:6YG('1H92!)134@=F5RF4](C(B(&9A8V4](D-O;6EC(%-A;G,@ M35,B/FAT='`Z+R]X;6QW96(O;7-X;6PO:6YS=&%L;"YH=&T\+V9O;G0^/"]A M/CQF;VYT(&-O;&]R/2(C.#`P,#@P(B!S:7IE/2(R(B!F86-E/2)#;VUI8R!3 M86YS($U3(CXI('EO=2!C86X@=7-E('1H90T*5FES=6%L($HK*R`V+C`@;65N M=2!I=&5M("9Q=6]T.U!R;VIE8W0O061D($-/32!7&UL)G%U;W0[+B9N8G-P.R!4:&5N('EO=2!C86X@ M=7-E('1H97-E(&%S(&9O;&QO=W,Z/"]F;VYT/CPO<#X-"@T*/&)L;V-K<75O M=&4@7-T96TN;W5T+G!R:6YT;&XH)G%U;W0[3&]A9&5D M("9Q=6]T.R`K(&1O8RYG971$;V-U;65N=$5L96UE;G0H*2YG971.;V1E3F%M M92@I*3L\8G(^#0H@("`@)FYBF4](C(B(&9A8V4](D-O;6EC(%-A;G,@35,B/E1H:7,@;&]A9',-"F$@,RXX M(&UE9V%B>71E('1E&UL(&9R;VT@=&AE('-U;B!R96QI M9VEO;B!E>&%M<&QE*0T*:6X@86)O=70@,B!S96-O;F1S("AO;B!A(%`R-C8I M+B!2;W5G:&QY('1H92!S86UE(&%S('1H92!#*RL@<&%R2`S+C0@=&EM97,@2!D:69F97)E M;F-E(&ES('1H92!U6QE M/2)-05)'24XM4DE'2%0Z(#!P>"(^#0H@("`@/'`^/&9O;G0@8V]L;W(](B,P M,#`P1D8B('-I>F4](C(B(&9A8V4](D-O=7)I97(@3F5W(CY)6$U,1$]-3F]D M90T*("`@(')O;W0Q(#T@9&]C+F=E=$1O8W5M96YT16QE;65N="@I.SQBF4](C(B(&9A8V4](D-O;6EC(%-A;G,@35,B M/DE834Q%;&5M96YT*BPF;F)S<#L\+V9O;G0^/"]L:3X-"B`@("`\;&D^/&9O M;G0@8V]L;W(](B,X,#`P.#`B('-I>F4](C(B(&9A8V4](D-O;6EC(%-A;G,@ M35,B/DE834Q%&UL7V5RF4] M(C(B(&9A8V4](D-O;6EC(%-A;G,@35,B/E1H:7,-"F)R:6YG6]U(&-A;B!P2!P96%R(&ET(&1O=VX@ M2!D96QE=&EN9R!T:&4@9F]L;&]W:6YG(&5X=')A;F5O M=7,@=&AI;F=S.CPO9F]N=#X\+W`^#0H-"CQU;#X-"B`@("`\;&D^/&9O;G0@ M8V]L;W(](B,X,#`P.#`B('-I>F4](C(B(&9A8V4](D-O;6EC(%-A;G,@35,B M/D1/349R9654:')E861E9$1O8W5M96YT#0H@("`@("`@("T@=6YL97-S('EO M=2!P;&%N('1O('5S92!T:&4@6$U,(&1O8W5M96YT(&9R;VT@;75L=&EP;&4- M"B`@("`@("`@=&AR96%DF4](C(B(&9A M8V4](D-O;6EC(%-A;G,@35,B/EA-3$AT='!297%U97-T#0H@("`@("`@("T@ M=6YL97-S('EO=2!W86YT('1O('1A;&L@=&\@F4](C(B(&9A8V4](D-O M;6EC(%-A;G,@35,B/DE85$Q2=6YT:6UE#0H@("`@("`@("T@6%-,('-T>6QE M('-H965T('-CF4](C(B(&9A8V4](D-O;6EC(%-A M;G,@35,B/EA-3$133T-O;G1R;VP-"B`@("`@("`@+2!UF4](C(B(&9A8V4](D-O;6EC(%-A;G,@35,B/E1H:7,-"F)R M:6YG65RF4](C(B(&9A8V4](D-O;6EC(%-A;G,@35,B M/D1/341O8W5M96YT+`T*("`@("`@("!)6$U,1$]-1&]C=6UE;G0\+V9O;G0^ M/"]L:3X-"B`@("`\;&D^/&9O;G0@8V]L;W(](B,X,#`P.#`B('-I>F4](C(B M(&9A8V4](D-O;6EC(%-A;G,@35,B/DE834Q$3TU.;V1E*CPO9F]N=#X\+VQI M/@T*("`@(#QL:3X\9F]N="!C;VQOF4](C(B(&9A8V4](D-O;6EC(%-A;G,@35,B/DE834Q$3TU$;V-U;65N=$9R M86=M96YT*CPO9F]N=#X\+VQI/@T*("`@(#QL:3X\9F]N="!C;VQOF4](C(B(&9A8V4](D-O;6EC(%-A;G,@35,B M/D%N9"!I9B!Y;W4-"FYE960@=&\@<&QA>2!W:71H($141"!I;F9OF4](C(B(&9A M8V4](D-O;6EC(%-A;G,@35,B/DE834Q$3TU$;V-U;65N=%1Y<&4\+V9O;G0^ M/"]L:3X-"B`@("`\;&D^/&9O;G0@8V]L;W(](B,X,#`P.#`B('-I>F4](C(B M(&9A8V4](D-O;6EC(%-A;G,@35,B/DE834Q$3TU%;G1I='D-"B`@("`@("`@ M/"]F;VYT/CPO;&D^#0H@("`@/&QI/CQF;VYT(&-O;&]R/2(C.#`P,#@P(B!S M:7IE/2(R(B!F86-E/2)#;VUI8R!386YS($U3(CY)6$U,1$]-3F]T871I;VX\ M+V9O;G0^/"]L:3X-"CPO=6P^#0H-"CQP/CQF;VYT(&-O;&]R/2(C.#`P,#@P M(B!S:7IE/2(R(B!F86-E/2)#;VUI8R!386YS($U3(CY!;&P@;F]D97,-"FEN M(&%N(%A-3"!D;V-U;65N="!A7!E("$A(0T*F4](C(B M(&9A8V4](D-O;6EC(%-A;G,@35,B/DE834Q$3TU!='1R:6)U=&4\+V9O;G0^ M/"]L:3X-"B`@("`\;&D^/&9O;G0@8V]L;W(](B,X,#`P.#`B('-I>F4](C(B M(&9A8V4](D-O;6EC(%-A;G,@35,B/DE834Q$3TU#1$%405-E8W1I;VX\+V9O M;G0^/"]L:3X-"B`@("`\;&D^/&9O;G0@8V]L;W(](B,X,#`P.#`B('-I>F4] M(C(B(&9A8V4](D-O;6EC(%-A;G,@35,B/DE834Q$3TU#:&%R86-T97)$871A M/"]F;VYT/CPO;&D^#0H@("`@/&QI/CQF;VYT(&-O;&]R/2(C.#`P,#@P(B!S M:7IE/2(R(B!F86-E/2)#;VUI8R!386YS($U3(CY)6$U,1$]-0V]M;65N=#PO M9F]N=#X\+VQI/@T*("`@(#QL:3X\9F]N="!C;VQO6]U(&AA=F4@=&\@=7-E($E834Q$3TU.;V1E+F=E=$%T=')I8G5T97,H M*2YS971.86UE9$ET96TH+BXN*2D\+V9O;G0^/"]L:3X-"B`@("`\;&D^/&9O M;G0@8V]L;W(](B,X,#`P.#`B('-I>F4](C(B(&9A8V4](D-O;6EC(%-A;G,@ M35,B/DE834Q$3TU0F4](C(B(&9A8V4] M(D-O;6EC(%-A;G,@35,B/DE834Q$3TU%;G1I='E2969EF4](C(B M(&9A8V4](D-O;6EC(%-A;G,@35,B/DE834Q$3TU497AT#0H@("`@("`@("AU M;FQE6]U(&QI:V4@=&AE('-T; from Joshua E. Smith on Thu, May 06, 1999 at 10:23:14AM -0400 References: <3.0.1.32.19990505084700.0103ce30@tiac.net> <005601be9761$54ea0f80$0201a8c0@pikachu> <3.0.1.32.19990506102314.01058930@tiac.net> Message-ID: <19990507111629.D12431@io.mds.rmit.edu.au> On Thu, May 06, 1999 at 10:23:14AM -0400, Joshua E. Smith wrote: > Or maybe we can all agree on some APIs (God, let it not be ActiveX!) which > editors should provide, so we can tell them (from a running program) to > highlight a given line and character position, to add an item (like "Stop > Here") to their menu bar, etc. Delphi actually exposes just such an API, which editors such as Multi-Edit put to good use. Whether that approach (and I don't know the details) is appropriate for a standard/convention I'll leave to others to debate. In the more general case, it is, in fact, extremely simple to invoke almost any other tool from Delphi by using the Tools configuration dialog, which provides macros that expand to current file, current line, current path, etc. Cheers, Marcelo -- http://www.simdb.com/~marcelo/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mads at pacbell.net Fri May 7 03:39:09 1999 From: mads at pacbell.net (MP) Date: Mon Jun 7 17:11:47 2004 Subject: Java based XML parsers for server use. References: <2F2DC5CE035DD1118C8E00805FFE354C0F36298A@RED-MSG-56> Message-ID: <010301be982a$4dbb4700$4526578b@ops.3com.com> Thanks for pointer. However, I'm looking for a pure Java solution. Our servers run on multiple platforms. Thanks, Madhu ----- Original Message ----- From: Chris Lovett To: 'MP' ; xml-dev@ic.ac.uk Sent: Thursday, May 06, 1999 5:37 PM Subject: RE: Java based XML parsers for server use. The ActiveX Control (MSXML.DLL - Microsoft XML Version 2.0) in IE5 provides a thread safe DOM with the progid "Microsoft.FreeThreadedXMLDOM". Attached is a document describing how to use this from Java. -----Original Message----- From: MP [mailto:mads@pacbell.net] Sent: Thursday, May 06, 1999 4:14 PM To: xml-dev@ic.ac.uk Subject: Java based XML parsers for server use. Hello, Are there any Java based XML parsers that are suitable for server side use? One of the primary requirements for such a parser is that should be thread safe. i.e.., more than one thread should be able to use the parser simultaneously. According to IBM's alphaworks discussion group, their XML4J parser is NOT thread safe. Not sure about other parsers. Any pointers are appreciated. Thanks, Madhu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri May 7 04:34:19 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:47 2004 Subject: The Protocol [was: Syntax] is API Fallacy In-Reply-To: <3994C79D0211D211A99F00805FE6DEE249C02B@exchny15.corp.smb.com> Message-ID: <003601be9831$03388dd0$1b19da18@ne.mediaone.net> Tito, > > What I had suggested was to use > > XML to marshal objects by value (MBV) which specifically gets around the > > network roundtrip killer. > > > Actually, the idea of using XML as the means of achieving MBV doesn't seem > too good to me. > > Why? First, one of the great attractions of a distributed object > system is > precisely that I'm not typically zapping objects about the network, but am > rather dealing with the more interesting objects in different > address spaces > by (remote) reference. So, as an an application developer using corba, I > really don't care too much how my corba implementation (as > provided by Iona > or whomever) does its business (e.g., marshalling). I just care that it > does it correctly and, hopefully efficiently. To David Brownell: I see your argument very clearly now. Sometimes, in order to get things working efficiently you need to get concerned with protocols. Fine grained object access across process boundaries is slow. There is no getting around this. Sometimes it is alot more efficient to zap a document across a network in one fell swoop and the zap back changes rather than updating it character by character. Like any development system there are good and bad uses. Techniques such as MBV help distributed object systems designers avoid the pitfalls of find grained object access across process boundaries. > > Finally, I'm not convinced that a corba/RPC-style of remote method > invocation is typically well suited to web-oriented interactions -- most > things on the web can be treated naturally and efficiently as > streams. Why > add the extra weight (which seems to buy me little) of corba to a > domain in > which it seems a mis-fit? > Agreed, who needs it! Precisely what I am suggesting is that sending large grained packets of information (e.g. documents) across the web is the proper way to develop distributed object systems. I do believe there is a role for object analysis and design and that object methodologies including interface development can and should be applied to web development. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smo at jst.com.au Fri May 7 05:23:33 1999 From: smo at jst.com.au (Steve Oldmeadow) Date: Mon Jun 7 17:11:47 2004 Subject: XML-Conformant Programming Languages References: <3.0.1.32.19990505084700.0103ce30@tiac.net> <005601be9761$54ea0f80$0201a8c0@pikachu> Message-ID: <007b01be9838$410093e0$0201a8c0@pikachu> ----- Original Message ----- From: Lars Marius Garshol To: Sent: 07/05/1999 2:01 Subject: Re: XML-Conformant Programming Languages > However, there is demand for good programmers, and for that reason > alone it is well worth your while to learn Lisp. (Certainly, it was > worth mine.) > Can you elaborate on why Lisp made you a better programmer? Please bear in mind though that where I am located (and I don't want to relocate) I have a snowball's chance in hell of making a living out of Lisp so how would learning Lisp help make me a better developer given I have to work with Java and C++? Honestly though, I have trouble staying on top of what is happening in Java/OO/XML so taking time to learn another language would need to have a big payback. Steve Oldmeadow xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smo at jst.com.au Fri May 7 06:09:06 1999 From: smo at jst.com.au (Steve Oldmeadow) Date: Mon Jun 7 17:11:47 2004 Subject: XML-Conformant Programming Languages References: Message-ID: <00ce01be983e$a487a560$0201a8c0@pikachu> ----- Original Message ----- From: adam moore To: Steve Oldmeadow Cc: Sent: 06/05/1999 6:34 Subject: Re: XML-Conformant Programming Languages > On Thu, 6 May 1999, Steve Oldmeadow wrote: > Surely this is exactly what DTD's can do - 'organize the constructs of a > language' - and with a DTD and something like Xeena from IBM I think it's > possible now? (Xeena is an editor that uses a DTD to constrain the authors > into only writing valid syntax: http://www.alphaworks.ibm.com/tech/xeena). I apologise. I was expecting too much from the grammar alone but my point still is a language with out the tools to interpret it is not very useful. Take writing an XSL processor as an example, does being able to parse an XSL document into a DOM tree help you with writing an XSL processor? I don't think it does. How useful is XSL without XSL processors? > > > As far as "Visual Programming" environments go (especially for "non > > programmers") I think it is invaluable to have the ability to step through > > the code and see what is happening which implies an IDE rather than a simple > > editor. > > > I agree - but to have a tool which ONLY LETS YOU WRITE VALID CODE IN THE > FIRST PLACE will surely be a big leap up from trying to debug code you > wrote in a standard editor and then try and find the typo's/missing > separators/line-breaks/etc.? I think it has a lot to do with the complexity of the language. With Joshua's example of a Lisp program I can certainly see how a DTD constrained editor would be fine. However, if someone gave me the DTD for Java and said I can use Xeena or JBuilder I would choose JBuilder. I wouldn't even want to imagine what writing C++ would be like under Xeena! Steve Oldmeadow xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 7 08:31:59 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:47 2004 Subject: XML-Conformant Programming Languages In-Reply-To: <007b01be9838$410093e0$0201a8c0@pikachu> References: <3.0.1.32.19990505084700.0103ce30@tiac.net> <005601be9761$54ea0f80$0201a8c0@pikachu> <007b01be9838$410093e0$0201a8c0@pikachu> Message-ID: * Steve Oldmeadow | | Can you elaborate on why Lisp made you a better programmer? Sure. Bear in mind when reading the below that I'm talking about both learning Scheme, learning and using Common Lisp and reading SICP. Also bear in mind that I'm no expert on CL, just at the end of the novice stage. I learned a lot about program design and now see it in a different way from before. This comes partly from being exposed to the 'design a language to write your program in'-philosophy, partly from seeing how Scheme (and Common Lisp through MOP) lets you build your own object systems and from getting used to a truly different object system. Another thing I learned a lot about was the differences and strengths of different families of programming languages (functional, imperative, OOP, etc). This was mainly from SICP. There's probably some improvement in the way I write individual lines of code as well, from being exposed to a language that is enormously much more expressive, but I'm not really sure. I also see data structures and working with them in a different light. A final, and major benefit, is the realization that there is much more to the world than just Java and C++, and that this world beyond those two has a lot to offer. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 7 08:34:27 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:48 2004 Subject: Java based XML parsers for server use. In-Reply-To: <00ca01be9816$14e420f0$4526578b@ops.3com.com> References: <00ca01be9816$14e420f0$4526578b@ops.3com.com> Message-ID: * mads@pacbell.net | | Are there any Java based XML parsers that are suitable for server | side use? One of the primary requirements for such a parser is that | should be thread safe. i.e.., more than one thread should be able to | use the parser simultaneously. I have to confess that I haven't looked at this aspect of parsers, but if you want a list of parsers to serve as a starting point you can look at: --Lars M: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From volker.wend at poet.de Fri May 7 09:07:31 1999 From: volker.wend at poet.de (Volker Wend) Date: Mon Jun 7 17:11:48 2004 Subject: IE5 brain damage In-Reply-To: <1CEC4A85AB34D21181C900A0C9CFE1279A78AC@NY_EXCH_01> Message-ID: <001301be9857$7c03e7c0$160f0fc0@poet.de> Please make also sure that the MIME type is text/xml. This is also specified in the File Extension Dialog. Volker Wend > -----Original Message----- > From: owner-xml-dev@ic.ac.uk > [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Lippmann, Jens > Sent: Thursday, May 06, 1999 10:35 PM > To: 'Elliotte Rusty Harold'; xml-dev@ic.ac.uk > Subject: RE: IE5 brain damage > > > > Everyone has suggested changing the associations, buct > that's not the > > issue. I am aware of how to do that. The problem is that despite the > > association with Textpad I should still be able to open an > > XML file in IE > > and I can't. > > Can you describe the symptoms. I actually changed the > association of "Open" > to XMLPad.exe and was still able to use the File|Open command > IE5 to open a > "foo.xml" file. The only issue is that it doesn't have a > filter for XML > files, so you have to select "All Files" in order to be able > to see your XML > file. But this is regardless of the association. Do you want > to create a > filter for XML files? > > Jens > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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.powell at bbc.co.uk Fri May 7 10:43:03 1999 From: james.powell at bbc.co.uk (James Powell) Date: Mon Jun 7 17:11:48 2004 Subject: examples of aelfred use in applets required Message-ID: I've been trying to use the small aelfred java parser. I've had problems when using it in an applet. Netscape gives out security errors due to loading the XML file off of a webpage. This is even true when I compile and run the demo applet in the distribution from a webserver. Of course, the demo applet at http://www.microstar.com works perfectly. Does anyone have the source for this and/or working examples? thanks, James Powell ps - is there a digest mode for this list? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Moncef.Mezghani at wanadoo.fr Fri May 7 10:56:51 1999 From: Moncef.Mezghani at wanadoo.fr (MEZGHANI) Date: Mon Jun 7 17:11:48 2004 Subject: =?iso-8859-1?Q?La_soci=E9t=E9_DISTAL_d=E9m=E9nage_=E0_Boulogne?= =?iso-8859-1?Q?_Billancourt?= Message-ID: <01BE9876.C795D1C0@bvlzy1-1-252.abo.wanadoo.fr> *** Si vous n'?tes pas concern?s par ce message, Ayez l'obligeance de l'ignorer. *** Je vous prie de noter qu'? partir du 10/5/1999 nous d?m?nageons ?: DISTAL SA 122 rue d'Aguesseau, 92100 Boulogne Billancourt France T?l?copie : 01 49 09 23 94 T?l?phone Support Clients: 01 49 09 28 88 Vous pouvez me joindre directement au: 01 49 09 28 72 Moncef MEZGHANI. Directeur Technique. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arthur.rother at ovidius.com Fri May 7 12:36:39 1999 From: arthur.rother at ovidius.com (Arthur Rother) Date: Mon Jun 7 17:11:48 2004 Subject: Some answers to my questions... In-Reply-To: <3.0.1.32.19990506160747.0103f1b4@tiac.net> Message-ID: <4.1.19990507123307.03de8c30@bodoni.ovidius.local> At 16:07 06.05.99 -0400, somebody wrote: >1) It's trivial to link expat statically in a Windows environment. Just do >the obvious and it just works. (James Clark is clearly a programmer who >knows what he's doing.) Also, expat *can* read external general entities, >you just have to help it a little. In my case, I don't have to care so much about the size of the parser and I found, that SP is much faster than expat. Is this true, or must I have made mistakes in integrating expat ? Arthur Rother xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri May 7 13:51:38 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:48 2004 Subject: Thread-safe SAX parsing (was Re: Java based XML parsers for server use.) In-Reply-To: References: <00ca01be9816$14e420f0$4526578b@ops.3com.com> Message-ID: <14130.52740.240367.323083@localhost.localdomain> Lars Marius Garshol writes: > * mads@pacbell.net > | > | Are there any Java based XML parsers that are suitable for server > | side use? One of the primary requirements for such a parser is that > | should be thread safe. i.e.., more than one thread should be able to > | use the parser simultaneously. > > I have to confess that I haven't looked at this aspect of parsers [snip] You could start with this: ====================8<====================8<==================== import java.io.IOException; import java.util.Locale; import org.xml.sax.Parser; import org.xml.sax.InputSource; import org.xml.sax.EntityResolver; import org.xml.sax.DTDHandler; import org.xml.sax.DocumentHandler; import org.xml.sax.ErrorHandler; import org.xml.sax.SAXException; public class SafeParser implements Parser { public SafeParser (Parser parser) { super(); this.parser = parser; } public synchronized void setLocale (Locale locale) throws SAXException { parser.setLocale(locale); } public synchronized void setEntityResolver (EntityResolver resolver) { parser.setEntityResolver(resolver); } public synchronized void setDTDHandler (DTDHandler handler) { parser.setDTDHandler(handler); } public synchronized void setDocumentHandler (DocumentHandler handler) { parser.setDocumentHandler(handler); } public synchronized void setErrorHandler (ErrorHandler handler) { parser.setErrorHandler(handler); } public synchronized void parse (InputSource source) throws SAXException, IOException { parser.parse(source); } public synchronized void parse (String systemId) throws SAXException, IOException { parser.parse(systemId); } private Parser parser; } ====================8<====================8<==================== Although I am far from an expert in concurrent programming, my feeble brain thinks that this should work provided that the following conditions hold true: 1. the implementor of the original parser doesn't use static variables to store parse information -- in other words, the parser is reentrant (they all should be: anyone competent enough to write an XML parser in the first place would probably write a reentrant one); and 2. no two instantiations of the parser use the same Reader or InputStream instantiation (that would be dumb anyway). Once the parse begins, the SAX parser itself controls flow of processing, so I cannot imagine how another thread could mess up the actual parsing (there's no way to change the parser's state externally once it begins parsing). To be perfectly safe, you could always synchronize on the InputSource and/or the InputStream/Reader that you are using. Perhaps people with more experience in Java concurrent programming can take (friendly) shots at this suggestion. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri May 7 13:54:58 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:48 2004 Subject: examples of aelfred use in applets required In-Reply-To: References: Message-ID: <14130.54189.940850.605844@localhost.localdomain> James Powell writes: > I've been trying to use the small aelfred java parser. > > I've had problems when using it in an applet. Netscape > gives out security errors due to loading the XML file > off of a webpage. The default security model in most browsers allows an applet to open TCP/IP connections only to the host from which it was loaded. For example, if your applet is at http://www.foo.com/javastuff/stuff.jar, it will be able to load http://www.foo.com/docs/bar.xml but *not* http://www.hack.com/documents/snarf.xml I think that that's getting better in newer browsers, but I haven't looked for a while. The JDK plug-in from Sun might also help. Look at the bright side -- at least there's no equivalent of Melissa in the Java world, yet (imagine if hostile applets could start connecting to arbitrary SMTP hosts). 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Fri May 7 14:25:54 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:48 2004 Subject: Java based XML parsers for server use. References: <00ca01be9816$14e420f0$4526578b@ops.3com.com> Message-ID: <3732DBA4.1DBC76C4@pacbell.net> MP wrote: > > Hello, > Are there any Java based XML parsers that are suitable for server side use? > One of the primary requirements for such a parser is that should be > thread safe. i.e.., more than one thread should be able to use the > parser simultaneously. Use Sun's. - Dave > According to IBM's alphaworks discussion group, their XML4J parser is > NOT thread safe. Not sure about other parsers. > > Any pointers are appreciated. > > Thanks, > Madhu > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri May 7 15:27:14 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:48 2004 Subject: RDF Question: attaching multiple types to a resource In-Reply-To: <3731F43E.60473329@mitre.org> from "Roger L. Costello" at May 6, 99 03:57:50 pm Message-ID: <199905071336.JAA11752@locke.ccil.org> Roger L. Costello scripsit: > If I wanted to create the alternate syntax as I did above, which type > would I migrate up? Would the equivalent syntax be: Any one you like. "Migrating the type" is just a minimization with no effect on meaning, so if "type" is a multi-valued property, any of the values can be minimized. RDF minimizations are primarily for 1) people creating RDF by hand, and 2) older XML metadata so that it can be viewed as RDF. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From huck at darmstadt.gmd.de Fri May 7 16:11:50 1999 From: huck at darmstadt.gmd.de (Gerald Huck) Date: Mon Jun 7 17:11:48 2004 Subject: ANNOUNCE: Update of GMD-IPSI XQL engine Message-ID: <000a01be9893$ec9c6700$ba200c8d@darmstadt.gmd.de> The GMD-IPSI XQL engine, a Java based storage and query application for large XML documents, has been updated to the first non-beta release 1.0.0. The distribution contains: 1. A full, persistent implementation of the W3C-DOM 2. A full implementation of the XQL language The download site is http://xml.darmstadt.gmd.de/xql/ . New Features for PDOM: - Support for all W3C-DOM operations, including updates and inserts. - PDOM files are build using SAX events, main memory no longer is a limit for file size. - PDOM now includes a fully fledged org.w3c.dom.Document interface. - The PDOM file can be compressed on the fly, saving disk space. - The PDOM is thread-safe for read and write access. - New command line interface for multithreaded benchmarks. - New public package with DOM utility functions, including: - pretty-printing XML from a DOM, - instantiating a DOM from RTF and HTML (requires Swing). - The Entity_Reference interface is supported. New Features for XQL: - Added regression test suite. - Command line interface improvements: - Allow user to choose any SAX parser and DOM implementation. - Option to control whitespace treatment. - Accept URL and filenames as input source. - Queries can be posed against HTML, returning XHTML - Support of name:* in queries. - Speed improvement for queries involving attributes. Fixed Defects: - Greatly improved API documentation. - Queries of the form //@* and //@name missed parts of the result. - Subscript, filter and function calls had wrong precedence. - The jar file for 1.0b1 was not working with JDK 1.2.x. - Fixed wrong mixed usage of 'current set of reference nodes' and 'search context'. - Corrected XQL functions end() and index(). - API change: User defined functions are now passed the current reference node and a set of reference nodes. - Upgraded to JavaCC 1.0. - Removed hardcoded dependencies on xml4j. For further questions or bug reports contact the authors below: [1] mailto:huck@gmd.de [2] mailto:macherius@gmd.de xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pwilson at gorge.net Fri May 7 16:49:55 1999 From: pwilson at gorge.net (Peter Wilson) Date: Mon Jun 7 17:11:48 2004 Subject: Do I need to use a validating parser? References: <3.0.1.32.19990504105427.0077e59c@tiac.net><3.0.1.32.19990504105427.0077e59c@tiac.net><3.0.1.32.19990504125402.0113cc48@tiac.net> <3.0.1.32.19990504221521.00c392a8@tiac.net> <012101be96a5$a9c85000$0201a8c0@pikachu> Message-ID: <3732FD76.E658EE35@GORGE.NET> Some time ago I wrote a structured editor where I parsed java source and allowed the user to edit an action diagram. The editor looked after the nesting of compound statements/methods etc. I allowed the user to free type method calls, assignments and conditions. The problem was that I could not reliably re-parse the source if it contained syntax errors. A single } could unhinge the whole scheme. The answer was to use XML to delimit the gross structure of the program source and to let the user type whatever they wanted - but not structure tags. Program source can then be reliably re-parsed. Aside. I am still working towards this goal but have become stuck in the XML/DOM tar pit. I have been working on the idea of compiled XML but came to the realization that the internal structure was not very different from DOM. However, when making the conversion I discover that DOM has been designed with desktop bloatware in mind. The NodeList requirement is one of the worst. The compile function idea still works. You get a binary representation of a DOM tree. This occupies half the size of the original XML and requires no parsing to re-load. The original XML is still recoverable. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri May 7 18:06:45 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:11:48 2004 Subject: Some answers to my questions... References: <4.1.19990507123307.03de8c30@bodoni.ovidius.local> Message-ID: <3732D6E0.A984F201@jclark.com> Arthur Rother wrote: > In my case, I don't have to care so much about the size of the parser and I > found, > that SP is much faster than expat. Is this true, or must I have made mistakes > in integrating expat ? The latter. Expat is much faster than SP. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sdemuth at artemisalliance.com Fri May 7 23:32:27 1999 From: sdemuth at artemisalliance.com (Steve Demuth) Date: Mon Jun 7 17:11:48 2004 Subject: Can't subclass ElementNode in applet Message-ID: <4.1.19990507162715.00be5e60@mail.salamander.com> I've got an application which subclasses ElementNode with, for example, a class com.artemisalliance.xml.ModelNode. ModelNode implements some methods which wrap various features of the Node interface. This works fine when I have the com.sun.xml package exploded into my class path for the IDE, but if I try to run it with the package in the jar, either in the ide or in a browser, I get an IllegalAccessError: java.lang.IllegalAccessError: try to access class com/sun/xml/tree/ParentNode from class com/artemisalliance/xml/client/ModelNode I've got three questions: 1) Why is ParentNode not a public class? 2) Why does the JVM throw this only when the package is jar'd? 3) Any ideas what I can do about this? It would be very inconvenient not to be able to subclass ElementNode. TIA Steve Demuth Artemis Alliance, Inc. An Inprise Premier Partner 289 East Fifth St, Suite 211 St. Paul, MN 55101 sdemuth@artemisalliance.com 651-227-7172 or 319-382-0593 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mode at nine.eng.sun.com Sat May 8 00:10:08 1999 From: mode at nine.eng.sun.com (Rajiv Mordani [CONTRACTOR]) Date: Mon Jun 7 17:11:48 2004 Subject: Can't subclass ElementNode in applet In-Reply-To: <4.1.19990507162715.00be5e60@mail.salamander.com> from "Steve Demuth" at May 7, 99 04:34:09 pm Message-ID: <199905072208.PAA13396@nine.eng.sun.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 2090 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990507/a94cdd60/attachment.bat From roddey at us.ibm.com Sat May 8 01:01:47 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:48 2004 Subject: Confused about & in entity literal Message-ID: <8725676A.007E5E5A.00@d53mta03h.boulder.ibm.com> Ok, I'm a little confused about the issues with & in entity literals. Here is one JC test: "> ]> &e; In this one, there is definitely an ampersand in an entity literal which is not part of a numeric character reference or an intrinsic character reference. The spec does not seem to day "No raw & in an entity value unless its a numeric ref or intrinsic ref, or some other reference that's just left unexpanded", right? It just says that there can be no ampersands in an entity value unless its part of a numeric reference or an intrinsic reference. So am I really supposed to parse all general references in an entity value and expand character references and intrinsic references and just ignore all others? Where does it really say that that's what's supposed to happen? And, while I'm at it, am I losing my mind or is this test from JC really not correct: "> ]> &e; This would expand to: which is obviously wrong since foo has no end tag and is not empty? But its in the valid\sa bucket. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From coopercc at netheaven.com Sat May 8 01:02:34 1999 From: coopercc at netheaven.com (Clark Cooper) Date: Mon Jun 7 17:11:48 2004 Subject: Benchmark of 6 XML parsers on Linux Message-ID: <199905072257.SAA00828@camel> There's an article of mine on: http://www.xml.com/ That compares the performance of 6 XML parsers using 4 languages: 1) James Clark's Expat (C) 2) Richard Tobin's RXP (C) 3) James Clark's XP (Java) 4) IBM's XML4J (Java) 5) My XML::Parser (Perl) 6) Jack Jansen's Pyexpat (Python) The same program is implemented in each language and using each parser and then compared with different test cases in the same environment. Please check it out and critique as necessary. Thanks, Clark -- Clark Cooper Software Engineer Home: coopercc@netheaven.com Schenectady, NY USA Work: cccooper@ltionline.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Sat May 8 01:31:24 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:11:48 2004 Subject: Confused about & in entity literal In-Reply-To: roddey@us.ibm.com's message of Fri, 7 May 1999 17:00:15 -0600 Message-ID: <12492.199905072331@doyle.cogsci.ed.ac.uk> > > "> > ]> > &e; Hmmm, this one *is* a little strange. Let's consider the other one first: > > "> > ]> > &e; The < is *not* expanded when the entity is defined. It is a general entity (that it's built-in makes no difference) and is "bypassed" in the terminology of section 4.4. So it's just as if the body had been <foo> which is perfectly well-formed. Back to the first example. What's strange about it is that I believe that "> (note the missing semicolon) would not be well-formed, even though there turns out not to be an entity reference when it is expanded in the body! In the original, &foo; is (by production 9) an entity reference when it appears in the entity definition (and it is bypassed), but is not an entity reference when it is parsed in the body. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 8 03:03:23 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:49 2004 Subject: A gem of a paper Message-ID: <002b01be98ee$c6cfd420$4af2fea9@w21tp> If you are into Case-based Reasoning (CBR) like I am, you might be interested in a little gem of a paper on a distributed CBR system that uses XML for case representation. The paper was apparently written sometime ago but I found it only today. CBR and XML is an obvious fit but I found very little info except this paper and some blurp about Inference Corp doing something with XML. Anyway, here is the link: http://www.cs.tcd.ie/Conor.Hayes/cbrnet/publish.html Enjoy, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From graydon at pobox.com Sat May 8 03:05:25 1999 From: graydon at pobox.com (Graydon Hoare) Date: Mon Jun 7 17:11:49 2004 Subject: interpolating tree fragments in xslt Message-ID: <19990507210511X.graydon@pobox.com> hey, I've noticed you can pass around output tree fragments in xslt as param-variables, which is nice, it's almost like using sosofos again, but the burning question I have is "how do I interpolate variables of this type into a template"? for example, lets say I do this: Beetles, arachnids, and chickens
The problem is probably really simple but I don't see in the xslt spec anything about interpolating variables of this type into the body of a template. There's the which will stringify the output fragment, but aside from that I'm at a loss as to how to make templates operate on fragments. Or am I thinking too dsssl-like here? -graydon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sat May 8 08:25:21 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:11:49 2004 Subject: interpolating tree fragments in xslt References: <19990507210511X.graydon@pobox.com> Message-ID: <3733C470.FAAD8C6B@jclark.com> Graydon Hoare wrote: > hey, I've noticed you can pass around output tree fragments in xslt as > param-variables, which is nice, it's almost like using sosofos again, > but the burning question I have is "how do I interpolate variables of > this type into a template"? Use xsl:copy-of. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun May 9 19:30:38 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:11:49 2004 Subject: A milestone in XML Message-ID: <4.2.0.37.19990509093952.01c59c60@mail.userland.com> Dear XML-DEV people, In March we decided that RSS-based syndication was too good to pass up, so we quickly built a syndication server in Frontier 6 to compete with My.Netscape.Com. Netscape welcomed us by adding them to their directory. (Thanks Netscape!) RSS is an XML-based format that represents what we in the Frontier community call a "weblog". It's frequently updated site that points to stories on and off-site, that identifies an audience and feeds links to them. Until RSS came along the only format people were using was HTML. RSS changed that. The Motley Fool, Mozilla.Org and Slashdot are examples of online services that are supporting RSS. We're rendering them using Frontier's content management system, for now in HTML. But we are also getting ready to do an open source release of our server software, and all its interfaces will be in XML and XML-RPC, so we're not wanting to be in a controlling position from a standpoint of software or registrations. We are not using RSS to artificially drive sales of our CMS, we want to win because we're the best, not because we have a corner on the market. (Hint to Vignette.) We've decided to open the whole thing. It's too good to try to hold onto. We're doing easy to use software to develop and maintain weblog sites, and of course they will all aggregate using the next generation of RSS and today's RSS. Who knows in what perverted ways this content will flow around the net? I'm totally looking forward to participate in the creative chaos that's coming! Today's milestone is that we're publishing the list of URLs that have been registered so far. This is a dynamic list, it's recalc'd every time you hit the page. http://my.userland.com/xml/serviceList.xml From the XML-DEV perspective, the milestone is that XML is catching up with content developers. It's not too complex and the rewards are not elusive. Put up an RSS version of your site, and you get more flow. An obvious benefit. Tomorrow we'll release the source code for the server and during the next few weeks we'll add XML-RPC interfaces and document them. Dave Winer UserLand Software PS: This message is also at http://discuss.userland.com/msgReader$5891. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun May 9 19:37:36 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:11:49 2004 Subject: Benchmark of 6 XML parsers on Linux In-Reply-To: <199905072257.SAA00828@camel> Message-ID: <4.2.0.37.19990509103348.01c58d30@mail.userland.com> Interesting article! Now I'm curious to know why Perl, Python and Java are so much slower than the C parsers? Don't you implement the parser in C? It seems like this is an important function to fully optimize or it won't scale. FWIW, the parser built into Frontier is fully native. No script code executed when parsing XML. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun May 9 19:50:43 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:11:49 2004 Subject: RDF via XML style sheets (or 'nice model, shame about the syntax' ;-) Message-ID: hi all I'm hoping that someone with more XSL expertise might provide a little advise here. I'm looking into feasibility of using XSL transformations as an alternative mechanism for derriving an RDF[1] directed labelled graph from XML instance data. This could be either via a transforming XML data into RDF 1.0 Syntax, or into some other format more trivially converted into triples of (Resource subject, Property predicate, RDFnode object) for pouring into an RDF-consuming application[eg. 2]. I've had variations of this working on my desktop using MS IE5.0, just by hacking the XML-to-HTML demos to output RDF instead. What I'd like to know now is how one might set about doing this in a principled fashion. Suppose, for common scenario, that I have an application which can be conceptually mapped into RDF nodes and arcs, but for one of several good reasons I don't feel inclined to use the relatively verbose RDF Syntax to make this explicit. A number of other options for RDF compatibility come to mind... 1. write code that builds in knowledge about proper interpretation of my markup to create a stream of RDF assertions(triples) 2. use an alternative graph-serialisation convention (eg. Andrew Layman's proposal) 3. interpret DTDs,DCDs, schemata etc to figure out which RDF triples are implied by my data 4. Represent the mapping to RDF in an XSL style sheet IMHO there's probably a role for all of these in various contexts. The latter is the one I'm currently concerned with, as it raises prospect of derriving a unified representation of a lot of deployed XML without having to use the RDF syntax for all apps. First question is: what convention, if any, might we use to make it mechanically evident that an associated style sheet serves to transform into machine-friendly RDF (as against, for example, human-friendly (X)HTML)? thanks for any suggestions, Dan [1] http://www.w3.org/RDF/ [2] http://www.w3.org/RDF/Implementations/SiRPAC/ (aside...) SiRPAC is the w3c parser for RDF syntax and has recently acquired a more abstract design allowing for alternative sources of RDF assertions; RDF Syntax 1.0 simply becomes one way for creating a stream of facts to write into an RDF graph. 'Resource','Property','RDFnode' mentioned above show up as classes in SiRPAC; the latter is a convenience superclass of the Literals and the Resources, since an RDF property may have either as its value (we can use Java's instanceof to check which we've got). see also CVS inteface to SiRPAC files at http://dev.w3.org/cgi-bin/cvsweb/java/classes/org/w3c/rdf/ http://dev.w3.org/cgi-bin/cvsweb/java/classes/org/w3c/rdf/ConsumerDemo.java?rev=1.1&content-type=text/x-cvsweb-markup In passing -- does anyone have any thoughts on how this interface might better be intergrated into the SAX filter way of doing things? ie. XML plus interpretation rules in one end, RDF triples come out the other... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 9 20:12:25 1999 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:11:49 2004 Subject: [ANN] Silfide XML Parser - 0.85 Released Message-ID: <199905091810.UAA25687@chimay.loria.fr> Silfide XML Parser 0.85 Release is now available at: http://www.loria.fr/projets/XSilfide/EN/sxp/ Changes from last revision: - SXP provides now a DocumentLoader (was XDOM) generic class to load a DOM Document from a String, an URL, an InputStream or even a SAX InputSource. From an instance of the DocumentLoader it is possible to configure the parser (validating, handle cross-references ID/IDREF, set a NamespaceHandler, etc...). - A new package fr.loria.xml.ns for XML Namespace handler with generic interfaces and default implementations. - A lot of bugs has been fixed (thanks for your bug reports) Java source files, java classes, some samples and documentation are freely available here: http://www.loria.fr/projets/XSilfide/EN/sxp/ Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sean at westcar.com Sun May 9 21:04:16 1999 From: sean at westcar.com (Sean Brown) Date: Mon Jun 7 17:11:49 2004 Subject: ANNOUNCE: XML Icon contest Message-ID: This message was originally posted on friday, but has not appeared on either mailing list yet, so I am resending it. Announcing: The final submissions have been made, and the voting will continue until 12 noon friday EDT. The location of the XML/XSL Icons is now: http://www.javanet.com/~sbrown/icons.html You will need to register to vote by submitting oyur email address. A password wil then be sent to you. There are three categories: 1. Best XML icon. 2. Best XML/XSL icon. 3. Best XML/CSS icon. You may vote for your favorite each category, but you only get one chance to vote, so select the favorite in each of the 3 categories before pressing the submit button. The results of the continuing voting will be available for review throughout the voting period. I will send a msg. with a link to the results page in a day or so... -Sean --if you have any problems voting pls. email the error messages along with the date and time of error-- -- #! /usr/bin/perl my %signature = ('name' => 'Sean Brown', 'email' => '', 'org' => 'Westcar Consulting Group', 'eCard' => 'http://www.westcar.com/sbrown/eCard.html'); print map qq|$_ : $signature{$_}\n|, sort keys %signature; xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Sun May 9 21:51:25 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:49 2004 Subject: Benchmark of 6 XML parsers on Linux In-Reply-To: <4.2.0.37.19990509103348.01c58d30@mail.userland.com> References: <4.2.0.37.19990509103348.01c58d30@mail.userland.com> Message-ID: (Not sent to the Perl list.) * Dave Winer | | Interesting article! Now I'm curious to know why Perl, Python and | Java are so much slower than the C parsers? For one thing, the Python application seems to spend somewhere around 40 % of its time counting UTF-8 characters. If the character-counting code were to be replaced by a C Unicode implementation (either that of Fredrik Lundh or the one by Martin von Löwis in the XML-SIG package) Python would show much better performance. (I'd send in a version that did this if I had the time to spare.) Another thing is that although Perl and Python both use a C parser (in this benchmark) calling from C into the interpreters is slow, and you have to do that once for each element as well as once for each and every piece of text. Since the example application also performs a fair bit of work most of the time spent is probably spent in the application code and not in the parser. | FWIW, the parser built into Frontier is fully native. No script code | executed when parsing XML. Does this mean that Frontier doesn't have a callback mode? How do you deal with huge documents, then? --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Mon May 10 00:10:59 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:11:49 2004 Subject: Benchmark of 6 XML parsers on Linux In-Reply-To: References: <4.2.0.37.19990509103348.01c58d30@mail.userland.com> <4.2.0.37.19990509103348.01c58d30@mail.userland.com> Message-ID: <4.2.0.37.19990509150518.01be7630@mail.userland.com> >>Does this mean that Frontier doesn't have a callback mode? How do you deal with huge documents, then? First, thanks for the explanation. It helps me understand what the issues are, and what they are not. Frontier's parser does not have a callback mode. It generates a tree in our object database, and then the script code can walk the tree and do whatever it wants. It's the same thing, and my guess is that a real-world Frontier application would probably perform no better or worse than a Python or Perl one. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon May 10 00:20:17 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:49 2004 Subject: A milestone in XML References: <4.2.0.37.19990509093952.01c59c60@mail.userland.com> Message-ID: <007601be9a6a$54bf8100$4d27fea9@w21tp> Dave, RSS sounds interesting. Where can I find more information on it? A search of Netscape's developer site using "RSS" doesn't find anything. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Mon May 10 00:40:11 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:11:49 2004 Subject: A milestone in XML In-Reply-To: <007601be9a6a$54bf8100$4d27fea9@w21tp> References: <4.2.0.37.19990509093952.01c59c60@mail.userland.com> Message-ID: <4.2.0.37.19990509153541.01b73ee0@mail.userland.com> RSS *is* interesting.. http://my.netscape.com/publish/help/quickstart.html It still needs to carry more info, but it's an excellent start. Dave At 03:21 PM 5/9/99 , Don Park wrote: >Dave, > >RSS sounds interesting. Where can I find more information on it? A search >of Netscape's developer site using "RSS" doesn't find anything. > >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/ and on >CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Mon May 10 02:01:14 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:49 2004 Subject: Can't subclass ElementNode in applet References: <199905072208.PAA13396@nine.eng.sun.com> Message-ID: <37362155.643B14AC@pacbell.net> "Rajiv Mordani [CONTRACTOR]" wrote: > > Hi Steve, > This error occurs when you use jdk1.1.x. Try using jdk1.2. This > problem doesn't occur with jdk1.2. Or to be more specific: don't use the JDK 1.1.x "javac" (or ones that work like it), just use the JDK 1.2 one (or ones that have that bug fixed). The compiler was generating bad code for accessing interface memebers, ergo "illegal access" ... the correct code runs on JDK 1.1 virtual machines. Re why that class isn't public ... it didn't need to be, and it exposes various internals that were not intended to be supported. In fact, you couldn't subclass it outside of that package anyway. - Dave > If you have any more problems please do > let me know. > > - Rajiv > > > > > I've got an application which subclasses ElementNode with, for example, a > > class com.artemisalliance.xml.ModelNode. ModelNode implements some methods > > which wrap various features of the Node interface. > > > > This works fine when I have the com.sun.xml package exploded into my class > > path for the IDE, but if I try to run it with the package in the jar, > > either in the ide or in a browser, I get an IllegalAccessError: > > > > java.lang.IllegalAccessError: try to access class > > com/sun/xml/tree/ParentNode from class com/artemisalliance/xml/client/ModelNode > > > > I've got three questions: > > > > 1) Why is ParentNode not a public class? > > > > 2) Why does the JVM throw this only when the package is jar'd? > > > > 3) Any ideas what I can do about this? It would be very inconvenient not > > to be able to subclass ElementNode. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Mon May 10 02:05:30 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:49 2004 Subject: Confused about & in entity literal References: <8725676A.007E5E5A.00@d53mta03h.boulder.ibm.com> Message-ID: <37362270.9F145C50@pacbell.net> roddey@us.ibm.com wrote: > > Ok, I'm a little confused about the issues with & in entity literals. Here is > one JC test: > > > "> > ]> > &e; > > In this one, there is definitely an ampersand in an entity literal which is not > part of a numeric character reference or an intrinsic character reference. The > spec does not seem to day "No raw & in an entity value unless its a numeric ref > or intrinsic ref, or some other reference that's just left unexpanded", right? > It just says that there can be no ampersands in an entity value unless its part > of a numeric reference or an intrinsic reference. Have a closer look at production 9: [9] EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"' | "'" ([^%&'] | PEReference | Reference)* "'" Which _does_ say that you can't have a raw '&' in an entity value etc. That's what the excslusion syntax means. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Mon May 10 02:44:40 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:49 2004 Subject: Thread-safe SAX parsing (was Re: Java based XML parsers for server use.) References: <00ca01be9816$14e420f0$4526578b@ops.3com.com> <14130.52740.240367.323083@localhost.localdomain> Message-ID: <37362BA2.6073E818@pacbell.net> David Megginson wrote: > > > * mads@pacbell.net > > | > > | Are there any Java based XML parsers that are suitable for server > > | side use? One of the primary requirements for such a parser is that > > | should be thread safe. i.e.., more than one thread should be able to > > | use the parser simultaneously. By the way "conventional wisdom" for multithreaded programming is that sharing data structures is to be avoided as a default assumption. Synchronizing kills performance, and confuses most programmers; so there's little win in sharing data when it's not absolutely required. That is, the conventional way to be "Thread Safe" is _not_ to have threads sharing a parser. Instead, each thread would have its own parser object -- which makes sense, parsers are quite cheap and you want to be able to have multiple threads _parsing concurrently_ (vs. just parsing sequentially). Another way to put this: the parser "class" is reentrant, but any given parser instance would typically be used by only one thread at a time. > > [ example deleted ] > > ====================8<====================8<==================== > > Although I am far from an expert in concurrent programming, my feeble > brain thinks that this should work provided that the following > conditions hold true: > > 1. the implementor of the original parser doesn't use static variables > to store parse information -- in other words, the parser is > reentrant (they all should be: anyone competent enough to write an > XML parser in the first place would probably write a reentrant > one); and Right, essentially every class should be reentrant unless explicitly documented otherwise. However, I certainly wouldn't expect a given _parser object_ to be reentrant from the application point of view. If a callback decides to parse a new document, it should do so using some other parser rather than expect the parser to keep track of two concurrent parses from the same thread! > 2. no two instantiations of the parser use the same Reader or > InputStream instantiation (that would be dumb anyway). That doesn't quite do it. Consider what happens when two threads try to use the same parser object concurrently (contrary to my advice above, that they should have their own parser object): THREAD 1 THREAD 2 parser.setDocumentHandler (H1); parser.setDocumentHandler (H2); parser.parse (doc1); parser.parse (doc2); What happens there is that handler H2 gets two streams of parse events, and handler H1 gets none. Depending on how things get scheduled, either Doc1 or Doc2 could get parsed first. > Once the parse begins, the SAX parser itself controls flow of > processing, so I cannot imagine how another thread could mess up the > actual parsing (there's no way to change the parser's state externally > once it begins parsing). To be perfectly safe, you could always > synchronize on the InputSource and/or the InputStream/Reader that you > are using. > > Perhaps people with more experience in Java concurrent programming can > take (friendly) shots at this suggestion. See above ... :-) If you want two threads to share a parser, you'll have to agree on rules for how they do so. While that's something I'd discourage, you could do it with any SAX parser (no "safe" wrapper necessary) like this: // the ONLY use of the parser that each thread makes // would be inside this synchronized() block !! synchronized (parser) { parser.setLocale (locale); parser.setDocumentHandler (handler); ... parser.parse (input); } There are parsers out there which don't work correctly like that, since they don't parse more than one document (bug!!) but if that's really the desired mode of operation, and you've got a parser which truly conforms to the SAX specificaiton, that's how to do it. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mjkoo at kistmail.kist.re.kr Mon May 10 10:38:56 1999 From: mjkoo at kistmail.kist.re.kr (Mi-Jeong Koo) Date: Mon Jun 7 17:11:50 2004 Subject: Locale Example for SAX(Sun's XML parser) Message-ID: <37369BA9.A0F8FB47@kistmail.kist.re.kr> Hi~ I'm a Korean and developing a project using the 'Project X'. I'm trying to process tag names written in Korean characters but I have some problem. Can I get some example codes about locale? Thank you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon May 10 13:53:13 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:50 2004 Subject: Locale Example for SAX(Sun's XML parser) In-Reply-To: <37369BA9.A0F8FB47@kistmail.kist.re.kr> References: <37369BA9.A0F8FB47@kistmail.kist.re.kr> Message-ID: * Mi-Jeong Koo | | I'm a Korean and developing a project using the 'Project X'. | I'm trying to process tag names written in Korean characters but I have | some problem. | Can I get some example codes about locale? The SAX Locale shouldn't affect things like that. Which characters are allowed in element type names is written is defined in the XML recommendation and parsers just have to follow that. The Locale is more intended for things like localized error messages and so on. So I would suggest that you look in the XML recommendation to see which characters you're allowed to use and then either file a bug report, switch parser and/or change to using legal characters. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Mon May 10 14:48:35 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:11:50 2004 Subject: Xml.com Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A18A3@eukbant101.ericsson.se> Is it just me that thinks it's ironically amusing that xml.com's web pages don't validate against the HTML 4 Transitional DTD... must be just me... ;-) (struggling to view xml.com's web pages in Netscape on Linux...) Matt. -- http://come.to/fastnet Perl, XML, ASP, Database, mod_perl, High Performance Solutions perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)' It's Matt. My name is Matt... See http://sergeant.org/notmatthew.txt xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Mon May 10 15:11:42 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:50 2004 Subject: Benchmark of 6 XML parsers on Linux In-Reply-To: <199905072257.SAA00828@camel> Message-ID: <3.0.1.32.19990510090754.0078ae98@tiac.net> Interesting article. The speed increase you saw as the Java parser ate bigger documents was probably due to the JIT compiler, dontchathink? I wonder what would happen if you compiled the JIT down to machine code, rather than p-code (like you can with Symantec's tools on x86). It'd then be interesting to see how the Java implementation compares to the C ones. I also wonder how much of the Perl time is spent starting the interpreter. Since the primary use of Perl to munch XML is going to be in a web server environment, I would expect it to be done using a technique like the .PLX thing my sysadmin guy did on our NT machine (I don't know exactly how that worked, but it somehow eliminated lots of process startup time and made all our Perl scripts run much, much faster). -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shecter at darmstadt.gmd.de Mon May 10 15:57:09 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:11:50 2004 Subject: Benchmark of 6 XML parsers on Linux References: <3.0.1.32.19990510090754.0078ae98@tiac.net> Message-ID: <3736E55A.37175CD7@darmstadt.gmd.de> "Joshua E. Smith" wrote: > The speed increase you saw... Hmm... I read the article and checked out the perl script: It looks to me like there's a problem with how the test was conducted. Maybe I don't understand what's going on, but this looks obvious: The tests were apparently done with the unix "time" command, by shelling out, and starting a new process for each document. This means that the interpreter-based languages get hit with two disadvantages: 1) They're penalized for VM startup and shutdown times. 2) After parsing a document, all loaded objects, references, and knowledge gained are thrown away, and can't be used for the next document. To me, this is a valid issue because the test environment wasn't a good approximation of real-world use: The test most closely modeled a CGI environment, which is a dying programming style. My guess is that if the test more closely modelled real-world use: a server that, in its lifetime, parses many documents, then the results may not have been so exagerated. I'm thinking of something like Servlets in the Java world, mod_perl in the Perl world, etc. The interpreters would still have lost, but maybe it wouldn't have been so extreme. - Robb xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Mon May 10 16:46:20 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:50 2004 Subject: Locale Example for SAX(Sun's XML parser) References: <37369BA9.A0F8FB47@kistmail.kist.re.kr> Message-ID: <3736F0D3.96FC79B8@pacbell.net> Lars Marius Garshol wrote: > > * Mi-Jeong Koo > | > | I'm a Korean and developing a project using the 'Project X'. > | I'm trying to process tag names written in Korean characters but I have > | some problem. > | Can I get some example codes about locale? > > The SAX Locale shouldn't affect things like that. Which characters are > allowed in element type names is written is defined in the XML > recommendation and parsers just have to follow that. > > The Locale is more intended for things like localized error messages > and so on. And since Sun doesn't provide a resource with Korean localizations (a com/sun/xml/parser/resources/Messages_ko.java file), if you set the Korean locale for diagnostics you'll just see the message IDs rather than diagnostics in Korean. (You have source, and could provide such a resource file if you like.) > So I would suggest that you look in the XML recommendation to see > which characters you're allowed to use and then either file a bug > report, switch parser and/or change to using legal characters. The usual problems I've seen relate to character encodings. If you don't use UTF-8 or UTF-16 (not many editors do, yet :-) then you must declare the encoding at the beginning of each file, perhaps something like or "ISO-2022-KR" etc. (Perhaps "cp949", for a PC-oriented encoding?) The official list of encoding name supported by Java is linked through the package docs for the parser, at http://java.sun.com/products/jdk/1.2/docs/guide/internat/encoding.doc.html One problem you may have is that some of the standard encoding names are not recognized, even for encodings which _are_ supported. A bug has been filed against the Java i18n support, but I don't know when the more standard names will get better support. So if the standard encoding names don't work, use the ones listed in the URL above. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 10 17:07:02 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:50 2004 Subject: "Geek Cruises" include XML Component Message-ID: <14134.62887.690989.554150@localhost.localdomain> Take a look: http://www.geekcruises.com/ 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From kandikattu at yahoo.com Mon May 10 17:39:53 1999 From: kandikattu at yahoo.com (Srinivas Kandikattu) Date: Mon Jun 7 17:11:50 2004 Subject: Good XML Book Message-ID: <19990510154046.25756.rocketmail@web113.yahoomail.com> Hi, Can some of you suggest to me what is a good XML Book for beginners and Intermediate. I am just starting to lean XML. regards Srini === -- Srinivas Kandikattu (650) 574-4000 x5023 (W) kandikattu@yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon May 10 17:41:17 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:11:50 2004 Subject: "Geek Cruises" include XML Component Message-ID: <3.0.32.19990510082925.009de100@pop.intergate.bc.ca> At 11:06 AM 5/10/99 -0400, David Megginson wrote: >Take a look: > > http://www.geekcruises.com/ Don't forget to follow the "future cruises" link. How 'bout a SAX cruise? -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon May 10 18:44:59 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:50 2004 Subject: Thread-safe SAX parsing (was Re: Java based XML parsers for server use.) Message-ID: <8725676D.005BE0F9.00@d53mta03h.boulder.ibm.com> > > * mads@pacbell.net > > | > > | Are there any Java based XML parsers that are suitable for server > > | side use? One of the primary requirements for such a parser is that > > | should be thread safe. i.e.., more than one thread should be able to > > | use the parser simultaneously. > > > > I have to confess that I haven't looked at this aspect of parsers > > [snip] > >You could start with this: > [snip] >Once the parse begins, the SAX parser itself controls flow of >processing, so I cannot imagine how another thread could mess up the >actual parsing (there's no way to change the parser's state externally >once it begins parsing). To be perfectly safe, you could always >synchronize on the InputSource and/or the InputStream/Reader that you >are using. > >Perhaps people with more experience in Java concurrent programming can >take (friendly) shots at this suggestion. > We take the approach that thread safety, at least from the perspective of parsing, should be at the actual parser/scanner instance level. So, you cannot have two threads using the same parser, but you can have as many threads as you want, each with its own parser. This makes the system almost totally synchronization free, so its fast and cheap. There are a few static data bits, but they are generally read only once initialized, so there is really little to no synchronization required. But that's just for parsing. The events that come out of the scanner/parser are in the context of that one thread that is running that parse, so that is no problem as well as long as the recipient handles any synchronization on the target data structures. DOM of course is a another specification of worms and has its own issues. It would often be the case that multiple threads would be in a DOM structure all at the same time, so it generally has to be overly synchronized and more granular level (i.e. it costs whether you are using it or not.) >From a server's perspective though, the 'thread per parser' scenario seems optimal. It would basically equate to a 'thread per served client', which also is very common and useful. In that kind of situation, there would be very little synchronization required as relates to the XML parser. We don't forsee any useful reason, that's worth the gotchas it raises for everyone else, to have multiple threads in a single parser at a time. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon May 10 18:47:43 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:50 2004 Subject: Java based XML parsers for server use. Message-ID: <8725676D.005C1C14.00@d53mta03h.boulder.ibm.com> > According to IBM's alphaworks discussion group, their XML4J parser is > NOT thread safe. Not sure about other parsers. > > Any pointers are appreciated. See my other response on the related thread. We have chosen what we consider the correct level of granularity for thread safety, which is at the per-parser level. I'm discussing the 2.x versions here, Java and C++ are the same in this respect. We see little use in having multiple threads in a single parser. It is more appropriate to have a parser per-thread. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 10 19:18:42 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:50 2004 Subject: Java based XML parsers for server use. In-Reply-To: <8725676D.005C1C14.00@d53mta03h.boulder.ibm.com> References: <8725676D.005C1C14.00@d53mta03h.boulder.ibm.com> Message-ID: <14135.5059.855744.655517@localhost.localdomain> roddey@us.ibm.com writes: > See my other response on the related thread. We have chosen what we > consider the correct level of granularity for thread safety, which > is at the per-parser level. I'm discussing the 2.x versions here, > Java and C++ are the same in this respect. We see little use in > having multiple threads in a single parser. It is more appropriate > to have a parser per-thread. The point here, I suspect, is not that it is not a good idea to have multiple threads inside the same parser, but that it is not a good idea to use the same parser in multiple threads outside of it. I can imagine a parser some day running several internal threads on a multiprocessor machine -- one, perhaps, for I/O, one for tokenisation, one for structure recognition, and one for schema-based validation. I don't know if I'd bother doing this right now, since single-threaded parsers are so fast anyway, but who knows what tomorrows technology and business requirements will be? 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlangdon at copeland.com Mon May 10 19:23:07 1999 From: jlangdon at copeland.com (Jeff Langdon) Date: Mon Jun 7 17:11:50 2004 Subject: Good XML Book Message-ID: <8525676D.005F3068.00@mail.copeland.com> I found XML in Action Web Technology William J. Pardi from Microsoft Press ISBN 0-7356-0562-9 to be very helpful I have read XML IE5 Alex Homer Wrox Books ISBN 1-861001-57-6 XML By Example Sean McGrath (Goldfarb Series) ISBN 0-13-960162-7 XML Extensible Markup Language Elliotte Rusty Harold ISBN 0-7645-3199-9 They are all very good books, but they were initially all a little over my head until I read the book from Pardi. Incidentally, I am not a programmer. Jeff Langdon Senior Web Developer The Copeland Companies Srinivas Kandikattu on 05/10/99 11:40:46 AM Please respond to Srinivas Kandikattu To: xml-dev@ic.ac.uk cc: (bcc: Jeff Langdon/IT/The Copeland Companies) Subject: Good XML Book Hi, Can some of you suggest to me what is a good XML Book for beginners and Intermediate. I am just starting to lean XML. regards Srini === -- Srinivas Kandikattu (650) 574-4000 x5023 (W) kandikattu@yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon May 10 19:29:13 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:50 2004 Subject: Confused about & in entity literal Message-ID: <8725676D.005FEB88.00@d53mta03h.boulder.ibm.com> >> In this one, there is definitely an ampersand in an entity literal which is not >> part of a numeric character reference or an intrinsic character reference. The >> spec does not seem to day "No raw & in an entity value unless its a numeric ref >> or intrinsic ref, or some other reference that's just left unexpanded", right? >> It just says that there can be no ampersands in an entity value unless its part >> of a numeric reference or an intrinsic reference. > >Have a closer look at production 9: > > [9] EntityValue ::= > '"' ([^%&"] | PEReference | Reference)* '"' | > "'" ([^%&'] | PEReference | Reference)* "'" > >Which _does_ say that you can't have a raw '&' in an entity value etc. >That's what the excslusion syntax means. So its like you have to parse the entity value and, if you find an ampersand, you have to parse it like an entity reference. If it happens to be either a numeric reference or the name happens to match one of the intrinsic entity names, then you should expand that and escape the character it generates? Otherwise, if it happens to look like a reasonable entity reference, I guess you are supposed to ignore it and just pass it through as is? If it does not look like a reasonable entity reference, then you give an error? What about this scenario? In this scenario, the entity is an encoded value of some sort, which just happens to start with an ampersand and end with a semi-colon. It has no illegal name chars in it and no spaces. You are supposed to buffer up all of that text, and if it happens to end with a semicolon, assume that it is a legal reference and pass it through? Yes I know that the ampersands should have been escaped technically, but how many parsers would blow up in this situation trying to buffer up that much text? How would the end user of that text figure out again where the escaped ampersands are in the text since its basically a totally meaningless sequence of characters to begin with? I know that these are pathological cases, but I just want to make sure that I understand what's required and that everyone has throught it through before I commit (yet again) to writing this part of the code, since I obviously flubbed it slightly the first time around. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon May 10 19:40:23 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:50 2004 Subject: New schema spec Message-ID: <8725676D.0060F1A1.00@d53mta03h.boulder.ibm.com> I am interested in some comments on the new Schema spec. In particular, what are people's thoughts about the fact that the AND connector has been reintroduced and that SEQ,ALT,AND blocks now support an optional min/max repetition count? Is there any way that such a system could be reasonably confirmed to be non-ambigious (and by reasonable I mean very fast and small amount of code.) And, given that, is there any way that it could be validated against in some less than exhaustive search way? The scenarios that scare me are say you have a node that can take 1 to 5 of some complex scenario, and each of those did similar things. How can you guarantee that if you only ate 2 of the top level that something down stream would not have matched better? Or if you ate only one at any one level that that wouldn't be a suboptimal match than if you had eat 3 of them? I'd be interested to hear from some our more pointy headed breathren (just kidding of course :-) about the theoretical implications of such a system. It seems obvious that DFAs, and the very fast and compact mechanisms they represent, would go out the door immediately, right? And that would remain true even if the AND connector was left out. Just the m to n repetition system means that DFAs wouldn't work anymore right? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Zev.Khazanovich at tfn.com Mon May 10 20:17:03 1999 From: Zev.Khazanovich at tfn.com (Khazanovich, Zev) Date: Mon Jun 7 17:11:50 2004 Subject: Good XML Book Message-ID: <6B3564D8EF82D2118D9B00E029273BCD1BFD64@tfsmamsg4.tfn.com> I would recommend "The XML Companion" by Neil Bradley Published by Addison-Wesley ISBN: 0-201-34285-5 This is an excellent book for beginners. It covers such topics as XML,DTD,XLL,CSS,XSL,SAX,DOM,RDF And provides explanations and examples in a very clear language; an important quality, which, in my opinion, is missing in most XML books. -Zev -----Original Message----- From: Srinivas Kandikattu [mailto:kandikattu@yahoo.com] Sent: Monday, May 10, 1999 11:41 AM To: xml-dev@ic.ac.uk Subject: Good XML Book Hi, Can some of you suggest to me what is a good XML Book for beginners and Intermediate. I am just starting to lean XML. regards Srini === -- Srinivas Kandikattu (650) 574-4000 x5023 (W) kandikattu@yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jabuss at cessna.textron.com Mon May 10 20:43:55 1999 From: jabuss at cessna.textron.com (Buss, Jason A) Date: Mon Jun 7 17:11:50 2004 Subject: "Geek Cruises" include XML Component Message-ID: Wow... I wonder if I can get my company to spring for that... (yeah, right....) >=P <---The look I will get when I submit the paperwork for it Have fun, -Jason > -----Original Message----- > From: Tim Bray [SMTP:tbray@textuality.com] > Sent: Monday, May 10, 1999 10:40 AM > To: David Megginson; XML Developers' List > Subject: Re: "Geek Cruises" include XML Component > > At 11:06 AM 5/10/99 -0400, David Megginson wrote: > >Take a look: > > > > http://www.geekcruises.com/ > > Don't forget to follow the "future cruises" link. How 'bout a > SAX cruise? -T. > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Mon May 10 20:47:40 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:11:51 2004 Subject: Good XML Book Message-ID: <84285D7CF8E9D2119B1100805FD40F9F25524A@MDYNYCMSX1> www.xmlbooks.com has a pretty long list. Bob DuCharme www.snee.com/bob "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii -------------------------------------- Srinivas Kandikattu on 05/10/99 11:40:46 AM Please respond to Srinivas Kandikattu To: xml-dev@ic.ac.uk cc: (bcc: Jeff Langdon/IT/The Copeland Companies) Subject: Good XML Book Hi, Can some of you suggest to me what is a good XML Book for beginners and Intermediate. I am just starting to lean XML. regards Srini === -- Srinivas Kandikattu (650) 574-4000 x5023 (W) kandikattu@yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Mon May 10 20:54:22 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:11:51 2004 Subject: How to access the DTD? Message-ID: <01BE9AF4.0362FFF0@cc398234-a.etntwn1.nj.home.com> I'm writing a Visual Basic application that needs to access all the information in a user-specified DTD. I'm looking for a validating XML parser that can be invoked via COM and that provides access to the DTD. Any ideas? It would be great if the Microsoft XML Parser provided access to the DTD, but it does not. I know there are some validating XML parsers that are written in Java and that provide access to the DTD. My VB app could access one of these parsers via COM. However, not all of my users will have a Java Virtual Machine on their PCs. My VB app could invoke James Clark's SP parser (written in C++) via COM. However, I suspect that this would be difficult for me to do, since I don't know C++. I am familiar with C. Thanks. Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon May 10 21:26:06 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:11:51 2004 Subject: New schema spec Message-ID: <003001be9b12$e95b1650$3ff96d8c@NT.JELLIFFE.COM.AU> From: roddey@us.ibm.com >I am interested in some comments on the new Schema spec. In particular, what are >people's thoughts about the fact that the AND connector has been reintroduced >and that SEQ,ALT,AND blocks now support an optional min/max repetition count? Excellent things. XML was right to simplify SGML and get rid of & and exceptions. I hope XSchema will reintroduce both of them, and more. >Just the m to n repetition system means that DFAs wouldn't work anymore right n{2 to 5} can be replaced by (n, n, (n, (n, (n)?)?)?) (n, m){2,5} can be replaced by ((n,m), (n,m), (n,m, (n,m (n,m)?)?)?) (n|m){2,5} can be replaced by ((n|m), (n|m), (n, ((n, (n|m)) | (m, (n|m)))) | (m, (n, (n|m)) | (m, (n|m)))) (n&m){2 to 5} can be replaced by ( ((n, m)| (m,n)), ((n, m)| (m,n)), ( ((n, m)| (m,n)), ( ((n, m)| (m,n)), ((n, m)| (m,n))?)?)? ) What would upset things is if (n&m){2 to 5} could be satisfied by the input n n n n n m m m m m Also, content models such as (n?, m?){2 to 5} are ambiguous, but so would (n?, m?)* or (n?, m?)+ Rick Jelliffe P.S. Am I the only one freaking out that the current Schema draft is not compatible with XML 1.0? It introduces a new class "nearly well-formed" which is not WF: thus all current XML processors will treat these documents in error. This is a terrible excercise in backwards incompatability--all existing XML processors will be incompatible: the only reason they have this class is because they try to cram into the Schema spec some way to declare entities (I thought that XLink was our way to improve entities: now we have 3 ways to do them...Yikes). It reduces XSchema's credibility a lot--it makes it look like there is a petty dislike of XML's markup declaration syntax which was so strong that it overweighed the requirement to conform to XML 1.0 WF rules. P.P.S. The archetype and datatype parts of the Schema proposal are excellent, IMHO. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Mon May 10 21:34:16 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:51 2004 Subject: Confused about & in entity literal References: <8725676D.005FEB88.00@d53mta03h.boulder.ibm.com> Message-ID: <37373458.E0A296EF@pacbell.net> > >Have a closer look at production 9: > > > > [9] EntityValue ::= > > '"' ([^%&"] | PEReference | Reference)* '"' | > > "'" ([^%&'] | PEReference | Reference)* "'" > > > >Which _does_ say that you can't have a raw '&' in an entity value etc. > >That's what the excslusion syntax means. > > So its like you have to parse the entity value and, if you find an ampersand, > you have to parse it like an entity reference. If it happens to be either a > numeric reference or the name happens to match one of the intrinsic entity > names, then you should expand that and escape the character it generates? See section 4.5 on how the replacement text for an entity value is defined; there's no special case for general entities that happen to be built-in. Also see appendix D for more elaboration of how the rules in that section interact with the entity expansion rules in section 4.4 ... Briefly, entity references will get expanded eventually, just not at the time the entity's replacement text is constructed. (It is not possible to do the expansions then, since the general entities aren't required to be defined at that time!) > Otherwise, if it happens to look like a reasonable entity reference, I guess you > are supposed to ignore it and just pass it through as is? If it does not look > like a reasonable entity reference, then you give an error? Again, see section 4.5 (etc) which is pretty clear about this. Try running your parser through a conformance test suite -- e.g. James Clark's XMLTEST and Sun's (which incorporates some examples from the XML spec, avoiding any issues about interpretation). > What about this scenario? > > encrypted piece of text];"> > > In this scenario, the entity is an encoded value of some sort, which just > happens to start with an ampersand and end with a semi-colon. It has no illegal > name chars in it and no spaces. You are supposed to buffer up all of that text, > and if it happens to end with a semicolon, assume that it is a legal reference > and pass it through? Absolutely. If that assumption is untrue, it's the fault of whoever provided that illegal entity declaration. > Yes I know that the ampersands should have been escaped technically, but how > many parsers would blow up in this situation trying to buffer up that much text? Curiously, not Sun's parser. The XML specification places no limitations on the size of XML names; that wasn't the (single) place I found it convenient to impose such a limitation. (I forget whether I removed that limitation in the next version of the parser.) > How would the end user of that text figure out again where the escaped > ampersands are in the text since its basically a totally meaningless sequence of > characters to begin with? I don't understand the question. Are you perhaps assuming that the replacement text is not going to have such entity references expanded at the proper time? (Namely, when the entity, "Foo" in the example above, is referenced.) - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon May 10 21:52:02 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:51 2004 Subject: New schema spec References: <003001be9b12$e95b1650$3ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <373739E6.C8E5D925@locke.ccil.org> Rick Jelliffe wrote: > P.S. Am I the only one freaking out that the current Schema draft is not > compatible with XML 1.0? It introduces a new class "nearly well-formed" > which is not WF: thus all current XML processors will treat these > documents in error. You are not. I am preparing a blast which will shred this nonsense once and for all ^W^W^W^W^W^W^W^W^W^W well-reasoned comment explaining to the Schema WG the error of their ways. I'll post it here when done as well as to the official comments list. > This is a terrible excercise in backwards > incompatability--all existing XML processors will be incompatible: the > only reason they have this class is because they try to cram into the > Schema spec some way to declare entities (I thought that XLink was our > way to improve entities: now we have 3 ways to do them...Yikes). It > reduces XSchema's credibility a lot--it makes it look like there is a > petty dislike of XML's markup declaration syntax which was so strong > that it overweighed the requirement to conform to XML 1.0 WF rules. Furthermore, it means that a document as read by a 1.0-compliant read-all-entities non-validating parser may have different *content* from one read by a schema-reading non-schema-validating parser, if both external DTD and schema are specified, and they have different definitions for the same entities. XLink fully displaces entities only if the "data:" URL scheme (RFC 2397) is widely supported; this is the URL equivalent of internal entities. (More accurately, it allows external entities that are represented internally.) -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Mon May 10 21:52:40 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:51 2004 Subject: Java based XML parsers for server use. References: <8725676D.005C1C14.00@d53mta03h.boulder.ibm.com> <14135.5059.855744.655517@localhost.localdomain> Message-ID: <373738AF.977E569E@pacbell.net> > > See my other response on the related thread. We have chosen what we > > consider the correct level of granularity for thread safety, which > > is at the per-parser level. In fact, many of us long ago concluded that the term "thread safe" was so ambiguous as to be confusing. There are different levels of safety, and then there's also being "multithread-hot" in some applications. > The point here, I suspect, is not that it is not a good idea to have > multiple threads inside the same parser, but that it is not a good > idea to use the same parser in multiple threads outside of it. I confess to having parsing problems with that sentence ... what's the antecedent to that last "it" ? :-) > I can imagine a parser some day running several internal threads on a > multiprocessor machine -- one, perhaps, for I/O, one for tokenisation, > one for structure recognition, and one for schema-based validation. I > don't know if I'd bother doing this right now, since single-threaded > parsers are so fast anyway, but who knows what tomorrows technology > and business requirements will be? Surely not me! But parsing isn't normally thought of as something that's naturally parallel. I think that it's the higher level tasks (perhaps driven by application-specific schemas) that will be the places where "multithread-hot" applications start to kick in. That gets again to those rules of thumb I alluded to earlier: first, that synchronization is confusing and not free, so avoid it; second, in consequence, only do synchroniziation (concurrent operations) at a relatively coarse grain, where there's a significant win! That's often higher up in the application stack (e.g. N clients working at the same time) than it is low down in that stack. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Mon May 10 21:57:57 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:51 2004 Subject: Good XML Book References: <6B3564D8EF82D2118D9B00E029273BCD1BFD64@tfsmamsg4.tfn.com> Message-ID: <373739B7.A5F8C1C5@pacbell.net> "Khazanovich, Zev" wrote: > > I would recommend > "The XML Companion" by Neil Bradley > Published by Addison-Wesley > ISBN: 0-201-34285-5 > > This is an excellent book for beginners. > It covers such topics as XML,DTD,XLL,CSS,XSL,SAX,DOM,RDF > And provides explanations and examples in a very > clear language; an important quality, which, in my opinion, is > missing in most XML books. I know a lot of folk who liked this one in particular, since it was relatively concise and free of fluff. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 10 23:03:31 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:51 2004 Subject: New schema spec References: <8725676D.0060F1A1.00@d53mta03h.boulder.ibm.com> Message-ID: <37373E1E.288173A7@prescod.net> roddey@us.ibm.com wrote: > > Is > there any way that such a system could be reasonably confirmed to be > non-ambigious (and by reasonable I mean very fast and small amount of code.) > And, given that, is there any way that it could be validated against in some > less than exhaustive search way? I haven't been completely through the schema spec yet, but let me ask you two questions: what definition of ambiguity are you using and why do you care? XML DTDs explicitly allow ambiguity in content models so why wouldn't schemas? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco And so, in one of history's little ironies, the global triumph of bad software in the age of the PC was reversed by a surprising combination of forces: the social transformation initiated by the network, a long-discarded European theory of political economy, and a small band of programmers throughout the world mobilized by a single simple idea. - http://old.law.columbia.edu/my_pubs/anarchism.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 10 23:21:57 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:51 2004 Subject: Argh...Entities Message-ID: <37373E75.1B85E066@prescod.net> I am disappointed that the schema working group decided to extend SGML and XML's conflation of resource provision (entities) and document structure constraints. I would be glad to work on an XML instance-syntax resource provision specification if it would help you to split it off. I am already experimenting in that direction. I am not the first to point out that allowing parsed entities to be specified in a schema is violently incompatible with XML 1.0's notion of well-formedness. Even were that not the case it seems clear to me that validating a document and *completing it* are two different steps. Preumably the document's structure should be complete before validation begins. Surely now is the right time to correct this 13 year old mistake! -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco And so, in one of history's little ironies, the global triumph of bad software in the age of the PC was reversed by a surprising combination of forces: the social transformation initiated by the network, a long-discarded European theory of political economy, and a small band of programmers throughout the world mobilized by a single simple idea. - http://old.law.columbia.edu/my_pubs/anarchism.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From grifmike at tinet.ie Mon May 10 23:57:20 1999 From: grifmike at tinet.ie (grifmike) Date: Mon Jun 7 17:11:51 2004 Subject: XML and EDIFACT Message-ID: <373755F4.E87F9EE9@tinet.ie> I just wanted to ask if anyone has any info or experience developing an XML (DTD) to interface with EDIFACT? I have just begun work in this area and if someone has any personal knowledge/insight in this area it would be appreciated!! Michael Griffin, National University of Ireland, Galway. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue May 11 00:20:09 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:51 2004 Subject: minOccur, maxOccur Message-ID: <37374D64.36D5FE1A@prescod.net> I dispute the usefulness of minOccur and maxOccur. I would like to hear about where people would use these features. I find that people often want them but can find a clearer way of expressing their document type when they are not available. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco And so, in one of history's little ironies, the global triumph of bad software in the age of the PC was reversed by a surprising combination of forces: the social transformation initiated by the network, a long-discarded European theory of political economy, and a small band of programmers throughout the world mobilized by a single simple idea. - http://old.law.columbia.edu/my_pubs/anarchism.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Tue May 11 00:40:24 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:11:51 2004 Subject: Redirecting XML files? In-Reply-To: <01BE9AF4.0362FFF0@cc398234-a.etntwn1.nj.home.com> Message-ID: <4.2.0.37.19990510153224.01ade250@mail.userland.com> A problem that comes up in running My.UserLand.Com is a sysop moving their RSS file to another location or server. We're allowing people other than the author of the file to do registrations. I think this is important. If RSS catches on and there are other registration servers, we will want *users* of the site to be able to tell our server about a RSS file. However, we want to enable webmasters to be able to move a file to a different directory or server. In the real world, this happens often enough that we want to have a general solution. What I'd like to say is that the webmaster should change the old file to "redirect" to the new file. Something like this: http://www.fool.com/directory/file.xml Then when we read the file we'd check for a redirect and update the services table, which in turn would update services.xml automatically. This uses the webmaster's security to assure that we're pointing to the right place, gives them full control, and also allows users of the site to do the registration. Is there any provision in the XML specs for redirecting in this manner or a similar one? Dave Winer UserLand 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Tue May 11 00:52:39 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:11:51 2004 Subject: Confused about & in entity literal In-Reply-To: roddey@us.ibm.com's message of Mon, 10 May 1999 11:27:39 -0600 Message-ID: <15984.199905102252@doyle.cogsci.ed.ac.uk> > Yes I know that the ampersands should have been escaped technically, Why "technically"? If it wasn't meant to be an entity reference, the document is just plain wrong. If it *is* meant to be an entity reference, why is it any stranger than, say, <[128K of name characters]/> or any of the other places where a name occurs? > but how many parsers would blow up in this situation trying to > buffer up that much text? It's tempting to use fixed-size buffers for such things, but when I've done that in the past it's usually turned out to be a mistake. Have you found parsers that "blow up" in this case? Of course, an implementation is perfectly free to warn about absurdly long names. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue May 11 01:12:05 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:11:51 2004 Subject: Argh...Entities In-Reply-To: <37373E75.1B85E066@prescod.net> Message-ID: <199905102311.TAA01044@hesketh.net> At 03:15 PM 5/10/99 -0500, Paul Prescod wrote: >I am disappointed that the schema working group decided to extend SGML and >XML's conflation of resource provision (entities) and document structure >constraints. I would be glad to work on an XML instance-syntax resource >provision specification if it would help you to split it off. I am already >experimenting in that direction. I agree with Paul 100% on this one. For precisely this reason, DDML remained entity free for a very long time (though I got outvoted on unparsed entities in the end.) In my more recent project, XML Processing Description Language (XPDL), I've separated constraints, entities, and attribute defaulting, and will be adding notations to that list, from my list of parts. (See http://purl.oclc.org/NET/xpdl for details on XPDL.) Do we really need to specify content in the same place as constraints? I really hope not. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whump at onradio.com Tue May 11 01:24:10 1999 From: whump at onradio.com (Bill Humphries) Date: Mon Jun 7 17:11:51 2004 Subject: Redirecting XML files? In-Reply-To: <4.2.0.37.19990510153224.01ade250@mail.userland.com> Message-ID: <002301be9b3c$480b5d80$8879b9d1@ariel.onradio.com> I think this is something better handled by the server than the XML. In the Apache framework, that would be to put a Redirect directive in one of the server's configuration files. In the Frontier framework, a responder could send the Location: http://newsserver/path/to/rss/file header. On a related topic, isn't someone working on XMLizing Linux configuration, or was that just something I saw in someone's slides at a talk somewhere... ----- Bill Humphries , Software Engineer Onradio.com, Scotts Valley, CA 1 813 440 0300 x182 "The more you know, the more jokes you get." -- unknown > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Dave Winer > However, we want to enable webmasters to be able to move a file to a > different directory or server. In the real world, this happens > often enough > that we want to have a general solution. > > What I'd like to say is that the webmaster should change the old file to > "redirect" to the new file. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jelks at jelks.nu Tue May 11 01:32:45 1999 From: jelks at jelks.nu (Jelks Cabaniss) Date: Mon Jun 7 17:11:51 2004 Subject: "Geek Cruises" include XML Component In-Reply-To: <14134.62887.690989.554150@localhost.localdomain> Message-ID: > http://www.geekcruises.com/ Interested. It *will* have live satellite broadband feeds of xml-dev available, right? /Jelks xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue May 11 01:33:18 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:52 2004 Subject: Mixed content considered harmful... Message-ID: <37375E61.42B0CA2F@prescod.net> XML Schema Part 1 seems to import a mistake from SGML and XML. This is the idea that content models must either be text-containing, "mixed" or element containing and that the former sort of model must not constrain the ordering of elements and text nodes. "A content model for mixed content provides for mixing elements with character data in document instances. The allowed element types are named, but neither their order or their number of occurrences are constrained." SGML had a separation between mixed and text-containing nodes but it did not have this constraint that it not be possible to constrain the order and occurence of text nodes and element nodes. #PCDATA was just a token and you could use it where you wanted. What it did have was a massive bug in its parsing algorithm that made these "constrained" mixed content models impossible to use. The bug had nothing to do with validation -- it was a parser problem. There sprung up a superstition that these mixed content models were evil when the truth is that the particular bug in SGML was the real problem. Before it was clear that we could change SGML, XML adopted a ridiculously confusing rule about the use of mixed content. It didn't occur to me (or probably anyone else) that it would have been better to just fix the bug. We probably didn't know at that point that we had that option. Now this rule has been imported into XML Schema. The rule is even more out of place in XML schema than it was in XML itself. Then we had the opportunity to fix the bug. Today the bug is not even relevant -- XML schema works on the result of the parse....it does not influence the parse. #PCDATA is just a data type that is unconstrained. You should be able to mix data type refs, #PCDATA and element type refs in content models with impunity (barring real parsing ambiguity). Using old syntax: You can handle any of these with wrappers but I claim that the instinct to wrap these things arises more from exposure to the superstition than from fundamental design considerations. We can make XSchema more uniform by removing the concept of "mixed content" and by introducing a PCDATA content token type. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco And so, in one of history's little ironies, the global triumph of bad software in the age of the PC was reversed by a surprising combination of forces: the social transformation initiated by the network, a long-discarded European theory of political economy, and a small band of programmers throughout the world mobilized by a single simple idea. - http://old.law.columbia.edu/my_pubs/anarchism.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 01:46:28 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:52 2004 Subject: Redirecting XML files? References: <4.2.0.37.19990510153224.01ade250@mail.userland.com> Message-ID: <000c01be9b3f$7ceb6880$4d27fea9@w21tp> Dave, This is usually done using the HTTP redirect feature. Another way to do it is to use public identifiers. Best, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srnm at yahoo.com Tue May 11 03:08:00 1999 From: srnm at yahoo.com (Steven Marcus) Date: Mon Jun 7 17:11:52 2004 Subject: Benchmark of 6 XML parsers on Solaris Message-ID: <19990511010756.29212.rocketmail@web109.yahoomail.com> The article at http://www.xml.com/xml/pub/Benchmark/article.html made me curious as to whether Java on Solaris would fair any better. The results are at: http://www.awaretechnologies.com/XML/xmlbench/solaris.html In case you don't want to follow the link: 1. Java is faster than Perl/Python for _all_ test cases 2. expat still wins (surprise!) -Steven Marcus _________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue May 11 05:27:18 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:52 2004 Subject: Redirecting XML files? References: <4.2.0.37.19990510153224.01ade250@mail.userland.com> Message-ID: <37376352.5490C66@prescod.net> Dave Winer wrote: > > What I'd like to say is that the webmaster should change the old file to > "redirect" to the new file. > > Something like this: > > > http://www.fool.com/directory/file.xml > > ... > > Is there any provision in the XML specs for redirecting in this manner or a > similar one? No, but I think that there should be. Existing mechanisms are server-specific and thus not open. You could use an XLink with "auto"/"replace" but the behavior of the XLink behavioral attributes are massively underspecified and downright dangerous. I hope that they are gone by the time the specification goes gold. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco And so, in one of history's little ironies, the global triumph of bad software in the age of the PC was reversed by a surprising combination of forces: the social transformation initiated by the network, a long-discarded European theory of political economy, and a small band of programmers throughout the world mobilized by a single simple idea. - http://old.law.columbia.edu/my_pubs/anarchism.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 06:18:46 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:52 2004 Subject: PI target names Message-ID: <000a01be9b65$98d12c80$350cfea9@w21tp> Are there any efforts to organize processing instruction target names? PI target names are not affected by namespaces except losing colon as a legal character to fit in with XML 1.0 production rules. How should one go about naming processing instruction targets? Shouldn't we have some kind of guidelines like the way MIME types are defined? For example, it seems appropriate to use a processing instruction for solving Dave Winer's XML redirection problem. Yet I am clueless as to how it should be named to avoid conflict. looks right except I am using a rather common word as the target name and the problem grows if there is a need for more target names in the XML redirection proposal. There is also the problem of PI target names used in the SGML world. I think we should address this issue before it gets out of control. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Tue May 11 06:51:38 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:52 2004 Subject: PI target names References: <000a01be9b65$98d12c80$350cfea9@w21tp> Message-ID: <3737B73B.37CDBB17@pacbell.net> Don Park wrote: > > Are there any efforts to organize processing instruction target names? There's the suggestion in the XML spec that notations be used, e.g. ... would be equivalent to ... Now, I'm not sure I like that approach, but it does provide a clear way to associate a managed namespace with PI names. One problem with that approach: the W3C hasn't used it yet, it's been looking to reserve PI target names. Of course, there are also folk in the W3C on a jihad against PIs and other things which are not compatible with most HTML parsers, so I'm not sure that's the real issue. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Tue May 11 07:11:31 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:52 2004 Subject: Redirecting XML files? References: <4.2.0.37.19990510153224.01ade250@mail.userland.com> Message-ID: <3737BBC0.786FE340@pacbell.net> HTTP supports both temporary and permanent redirection; pass the appropriate response status and a "Location:" header field, and the client reissues the request. I agree with the person who said that mechanism should be used ... it'll need to be supported anyway, no sense in having two client side mechanisms to implement and debug (one of which is already widely deployed). On the server side, there's the question of how to flag that such a redirection is needed. Different servers have different solutions for that, and I suspect you're trying to avoid needing to spend the effort in the server to see if it's needed. You implied there was structural logic that could be applied to speed things up; that's the approach I'd take, then! - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mda at discerning.com Tue May 11 07:23:21 1999 From: mda at discerning.com (Mark D. Anderson) Date: Mon Jun 7 17:11:52 2004 Subject: Benchmark of 6 XML parsers on Solaris Message-ID: <01c301be9b6e$55756f60$0200a8c0@mdaxke.mediacity.com> >1. Java is faster than Perl/Python for _all_ test cases there are substantial variations in VM performance across vendor and OS; see: http://www.javaworld.com/jw-03-1999/jw-03-volanomark.html?022399ibd Also, for reasons that I can only attribute to laziness on the part of implementors, java VMs seem to take a ridiculous amount of time to start up. Beats me what they are doing. This is particularly striking given that java was first promulgated for browser applets. Judging from the level of discussion on various other lists I'm on, none of java, perl, or python were designed with lightweight, accurate, and meaningful profiling of their own run time built in. So people interested in improving performance are left pouring over the leavings of gprof. Confronted with that, one quickly concludes it isn't necessary work, because in the real world one is always waiting on network or disk anyway :). -mda xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mda at discerning.com Tue May 11 07:45:21 1999 From: mda at discerning.com (Mark D. Anderson) Date: Mon Jun 7 17:11:52 2004 Subject: Benchmark of 6 XML parsers on Solaris Message-ID: <01e701be9b71$6e928b60$0200a8c0@mdaxke.mediacity.com> btw, one thing that would be interesting to add would be the time to process a zero-size (or near-zero size) file. That would aid in giving gross estimates to the constant component of what is presumably a close-to-linear equation. -mda xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From reschke at medicaldataservice.de Tue May 11 08:00:06 1999 From: reschke at medicaldataservice.de (Julian Reschke) Date: Mon Jun 7 17:11:52 2004 Subject: minOccur, maxOccur In-Reply-To: <37374D64.36D5FE1A@prescod.net> Message-ID: <000501be9b73$6b186de0$cf00a8c0@nbreschke> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Paul Prescod > Sent: Monday, May 10, 1999 11:20 PM > To: www-xml-schema-comments@w3.org; xml-dev > Subject: minOccur, maxOccur > > > I dispute the usefulness of minOccur and maxOccur. I would like to hear > about where people would use these features. I find that people often want > them but can find a clearer way of expressing their document type when > they are not available. Interesting statemen. How about an example. How would you define a schema where can only contain and , each of which exactly one time? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 08:19:21 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:52 2004 Subject: Redirecting XML files? References: <4.2.0.37.19990510153224.01ade250@mail.userland.com> <3737BBC0.786FE340@pacbell.net> Message-ID: <000f01be9b76$681e1240$350cfea9@w21tp> > On the server side, there's the question of how to flag that such > a redirection is needed. Different servers have different solutions > for that, and I suspect you're trying to avoid needing to spend > the effort in the server to see if it's needed. You implied there > was structural logic that could be applied to speed things up; > that's the approach I'd take, then! Actually, Dave Winer was talking about an old issue which is that most web sites consist of passive contents only. Most web sites are hosted by ISPs and contents are poured in using FTP. Active components such as scripts, CGI, or servlets are not available and changes to the server is not even dreamed of. This issue came up almost two years ago during a dinner (many Net folks were there although I can only remember Dr. Goldfarb and Dave Siegel) in context of XML. Our conclusion was that shrinkwrapped vertical website builder applications that generates XML contents will be coming soon to solve the most of the problem. I think we overestimated the rate of change because most of us saw the problem as a business opportunity. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 10:47:57 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:52 2004 Subject: PI target names References: <000a01be9b65$98d12c80$350cfea9@w21tp> <3737B73B.37CDBB17@pacbell.net> <007301be9b84$0de4a830$04c2c6c3@phone.com> Message-ID: <000701be9b8b$2eeb8920$350cfea9@w21tp> > One can wonder why PIs were specified in the first place, if W3C doesn't > want anyone to use them. What I would like to know is WHY W3C does not want to encourage folks to use PI. Perhaps I'll agree with them once I hear all the arguments, perhaps not. I would like to know what the arguments are. If it is just compatibility with HTML browsers, I think it is wrong. As far as I am concerned, it takes only two engineers (one from Microsoft and one from Netscape) to make HTML browsers support PI. By the time XHTML becomes available for general use, we'll likely be looking at IE 6 and NS 6. Legacy browsers can be supported with patches. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Tue May 11 10:57:40 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:11:52 2004 Subject: Argh...Entities Message-ID: <01BE9B9C.B90F1750@grappa.ito.tu-darmstadt.de> Simon St. Laurent: > I agree with Paul 100% on this one. For precisely this reason, DDML > remained entity free for a very long time (though I got outvoted on > unparsed entities in the end.) As one of those who helped outvote Simon, I'd just like to say that I have completely recanted. Including unparsed entity definitions in DDML was a mistake and I now regret it. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From barsteng at 263.net Tue May 11 11:08:30 1999 From: barsteng at 263.net (barsteng@263.net) Date: Mon Jun 7 17:11:52 2004 Subject: query info from database to xml Message-ID: <19990511074335.13512.fmail@263.net> Hello Xml-dev, Can anybody tell me that how to query info from database and construct the result to xml? There are some problems: 1.How to define the table's struct and the field's info?where can I find the standard? 2.How to represent the binary type of the field? Best regards, barsteng mailto:barsteng@126.com __________________________________________________ »¶Ó­Ê¹ÓÃÊ׶¼ÔÚÏßÃâ·Ñµç×ÓÓÊÏähttp://freemail.263.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hvram at wipinfo.soft.net Tue May 11 11:24:40 1999 From: hvram at wipinfo.soft.net (Harihara Vinayakaram) Date: Mon Jun 7 17:11:52 2004 Subject: IE5 brain damage Message-ID: <00d601be9b90$68b5e6a0$3a35a8c0@cream.wipinfo.soft.net> Select the document . Shift + Right - click should be able to give you an option of Open with . (even though you have associated this file type with something else) Hope this helps Regards Hari -----Original Message----- From: Elliotte Rusty Harold To: xml-dev@ic.ac.uk Date: Thursday, May 06, 1999 7:55 PM Subject: Re: IE5 brain damage >>If I understand you correctly it sounds like you need to change the program >>associated with your.xml files. > >Everyone has suggested changing the associations, buct that's not the >issue. I am aware of how to do that. The problem is that despite the >association with Textpad I should still be able to open an XML file in IE >and I can't. > >Think of it this way. By going to File->Open in Word, you can open a >WordPerfect document in Word even if WordPerfect is installed on the system >and registered to handle Wordperfect files. Now imagine that when you try >to open a WordPerfect file in Word, it instead launches WordPerfect and >opens the file in WordPerfect. That's more or less what's happening when I >try to read an XML file in IE5. The associations should affect what >program is launched when I double-click a file of a particular type. It >should not affect what happens when I specifically ask a particular program >to open a particular file. > > >+-----------------------+------------------------+-------------------+ >| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | >+-----------------------+------------------------+-------------------+ >| Java I/O (O'Reilly & Associates, 1999) | >| http://metalab.unc.edu/javafaq/books/javaio/ | >| http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | >+----------------------------------+---------------------------------+ >| Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | >| Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | >+----------------------------------+---------------------------------+ > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Tue May 11 11:29:12 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:52 2004 Subject: Benchmark of 6 XML parsers on Solaris In-Reply-To: <01c301be9b6e$55756f60$0200a8c0@mdaxke.mediacity.com> References: <01c301be9b6e$55756f60$0200a8c0@mdaxke.mediacity.com> Message-ID: * Mark D. Anderson | | Judging from the level of discussion on various other lists I'm on, | none of java, perl, or python were designed with lightweight, | accurate, and meaningful profiling of their own run time built in. Python comes with a profiler that I've been using heavily to optimize xmlproc as much as possible. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Tue May 11 11:42:53 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:11:53 2004 Subject: Redirecting XML files? In-Reply-To: <000f01be9b76$681e1240$350cfea9@w21tp> References: <4.2.0.37.19990510153224.01ade250@mail.userland.com> <3737BBC0.786FE340@pacbell.net> Message-ID: <4.2.0.37.19990511023700.01c59640@mail.userland.com> Yup you got it. Even if the hosting is done on site, the webmaster and sysadmin are often two different people. We'll just go with the approach, it makes sense in our application and probably will make sense to our users. For this app, btw, the channel developers (there are hundreds of them at all sizes and shapes of sites) are mostly webmasters not system operators. Dave At 11:20 PM 5/10/99 , Don Park wrote: > > On the server side, there's the question of how to flag that such > > a redirection is needed. Different servers have different solutions > > for that, and I suspect you're trying to avoid needing to spend > > the effort in the server to see if it's needed. You implied there > > was structural logic that could be applied to speed things up; > > that's the approach I'd take, then! > >Actually, Dave Winer was talking about an old issue which is that most web >sites consist of passive contents only. Most web sites are hosted by ISPs >and contents are poured in using FTP. Active components such as scripts, >CGI, or servlets are not available and changes to the server is not even >dreamed of. > >This issue came up almost two years ago during a dinner (many Net folks were >there although I can only remember Dr. Goldfarb and Dave Siegel) in context >of XML. Our conclusion was that shrinkwrapped vertical website builder >applications that generates XML contents will be coming soon to solve the >most of the problem. I think we overestimated the rate of change because >most of us saw the problem as a business opportunity. > >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/ and on >CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jfallot at infovista.fr Tue May 11 11:56:06 1999 From: jfallot at infovista.fr (Jean-Francois Allot) Date: Mon Jun 7 17:11:53 2004 Subject: Guidelines to describe an User Interface ? Message-ID: I would like to describe User Interface elements (textfields with styles, frames, images, ...) in XML. I want to use a format which is technology and platform independent. Is there any Guidelines to follow ? I've heard about something started by Netscape and used in Gecko. What is your opinion about it ? Does anyone use XML to describe UI elements ? Thank you, Jean-Francois ALLOT InfoVista SA mailto:jfallot@infovista.com http://www.infovista.com tel: +33 (0)1 60 92 31 31 fax: +33 (0)1 60 92 31 39 France xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Tue May 11 12:29:06 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:11:53 2004 Subject: Guidelines to describe an User Interface ? Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A18AD@eukbant101.ericsson.se> Mozilla's XUL is what you're looking for. It uses xml to describe complex UI components such as toolbars, menus, etc, and HTML to describe anything that can be described in HTML. See http://www.mozilla.org - the easiest thing to do is download the current nightly build and play around with the XUL files in the res directory. Matt. -- http://come.to/fastnet Perl, XML, ASP, Database, mod_perl, High Performance Solutions perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)' It's Matt. See http://sergeant.org/notmatthew.txt > -----Original Message----- > From: Jean-Francois Allot [SMTP:jfallot@infovista.fr] > Sent: Tuesday, May 11, 1999 11:03 AM > To: xml-dev@ic.ac.uk > Subject: Guidelines to describe an User Interface ? > > > I would like to describe User Interface elements (textfields with styles, > frames, images, ...) in XML. > I want to use a format which is technology and platform independent. > > Is there any Guidelines to follow ? > > I've heard about something started by Netscape and used in Gecko. > What is your opinion about it ? > > Does anyone use XML to describe UI elements ? > > Thank you, > Jean-Francois ALLOT > InfoVista SA > mailto:jfallot@infovista.com > http://www.infovista.com > tel: +33 (0)1 60 92 31 31 > fax: +33 (0)1 60 92 31 39 > France > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 14:34:23 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:53 2004 Subject: Guidelines to describe an User Interface ? In-Reply-To: References: Message-ID: <14136.9017.866655.122336@localhost.localdomain> Jean-Francois Allot writes: > Does anyone use XML to describe UI elements ? I think that Gnome and Mozilla both do. You can poke around http://www.gnome.org/ and http://www.mozilla.org/ for details, or try some Altavista searches: +xml +host:gnome.org +xml +host:mozilla.org 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shecter at darmstadt.gmd.de Tue May 11 14:58:50 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:11:53 2004 Subject: Guidelines to describe an User Interface ? References: <14136.9017.866655.122336@localhost.localdomain> Message-ID: <37382930.D6F2952E@darmstadt.gmd.de> Hi, You might also want to check out: http://www.bluestone.com/xml/XwingML/ http://www.pierlou.com/prototype http://cs.nyu.edu/phd_students/fuchs/ - Robb xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 16:43:10 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:53 2004 Subject: Argh...Entities References: <199905102311.TAA01044@hesketh.net> Message-ID: <373842FF.E4A55127@locke.ccil.org> Simon St.Laurent wrote: > I agree with Paul 100% on this one. Simon, this isn't just meant for you, but for Paul and everybody. I hope you are protesting to www-xml-schema-comments@w3.org. I know that looks like a black hole, but it's the *only* chance of getting this bogosity stopped, due to a Procedural Blunder in the creation of the WD. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 16:43:36 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:53 2004 Subject: Redirecting XML files? References: <4.2.0.37.19990510153224.01ade250@mail.userland.com> Message-ID: <3738431B.C5375A03@locke.ccil.org> Dave Winer wrote: > Something like this: > > > http://www.fool.com/directory/file.xml [snip] > Is there any provision in the XML specs for redirecting in this manner or a > similar one? Sort of. ]> &pyrzqxgl; Of course, you have to use a parser that handles external entities. Note that this won't handle redirection to redirections, because an external entity can't have its own DTD. But rolling your own isn't bad either. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue May 11 16:54:53 1999 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:11:53 2004 Subject: RDF et IDL ? Message-ID: <199905111452.QAA18888@chimay.loria.fr> 1/ Could it be possible to do a mapping between an RDF schema specification and an IDL interface (a kind of rdftoidl) ? Looking for some information... 2/ Is someone using the DOM IDL specification within a real CORBA application ? Thanks, Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 17:25:20 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:53 2004 Subject: Argh...Entities References: <01BE9B9C.B90F1750@grappa.ito.tu-darmstadt.de> Message-ID: <37384CEA.792DF8F1@locke.ccil.org> Ronald Bourret wrote: > > I agree with Paul 100% on this one. For precisely this reason, DDML > > remained entity free for a very long time (though I got outvoted on > > unparsed entities in the end.) > > As one of those who helped outvote Simon, I'd just like to say that I have > completely recanted. Including unparsed entity definitions in DDML was a > mistake and I now regret it. I remain unreconstructed. If we are to have validatable ENTITY/ENTITIES attributes, then we must have unparsed entity declarations as well. Either lose both or keep both, say I. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Tue May 11 17:41:12 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:11:53 2004 Subject: Redirecting XML files? References: <4.2.0.37.19990510153224.01ade250@mail.userland.com> <3738431B.C5375A03@locke.ccil.org> Message-ID: <373846EA.624D04B3@jclark.com> John Cowan wrote: > > ]> > &pyrzqxgl; That's not actually well-formed. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Tue May 11 18:42:33 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:53 2004 Subject: Benchmark of 6 XML parsers on Solaris References: <01c301be9b6e$55756f60$0200a8c0@mdaxke.mediacity.com> Message-ID: <37385DD1.79040236@pacbell.net> "Mark D. Anderson" wrote: > > >1. Java is faster than Perl/Python for _all_ test cases > > there are substantial variations in VM performance across > vendor and OS; see: > http://www.javaworld.com/jw-03-1999/jw-03-volanomark.html?022399ibd > > Also, for reasons that I can only attribute to laziness on > the part of implementors, java VMs seem to take a ridiculous > amount of time to start up. Beats me what they are doing. I suspect that nobody's ever placed aggressive tuning targets on the startup time. There's operating system overhead for setting up processes (including setting up shared libraries and intitializing data structures), and often some JIT costs (since JVMs don't yet cache JIT results AFAIK). That's not to disagree that startup costs shouldn't be cut, only to point out that there are reasons for them that don't have a thing to do with laziness. Many apps have startup times that are substantial, so they run faster when they're used. > Judging from the level of discussion on various other lists I'm > on, none of java, perl, or python were designed with lightweight, > accurate, and meaningful profiling of their own run time built in. Not so. With Java 2, check out "java -Xrunhprof:help" output to see the built in profiler. Works nicely on SPARC out of the box, but the Win32 version at one point needed a JIT update to get CPU profiling to work (by default it only does memory profiling). - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 19:16:35 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:53 2004 Subject: Redirecting XML files? References: <4.2.0.37.19990510153224.01ade250@mail.userland.com> <3738431B.C5375A03@locke.ccil.org> <373846EA.624D04B3@jclark.com> Message-ID: <3738670A.F4B95102@locke.ccil.org> James Clark wrote: > > > > > > "http://www.fool.com/directory/file.xml">]> > > &pyrzqxgl; > > That's not actually well-formed. Foo, you are right. How annoyingly unsymmetrical. Anybody know why the root element can't be inside a general 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 19:18:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:53 2004 Subject: Argh...Entities In-Reply-To: <373842FF.E4A55127@locke.ccil.org> References: <199905102311.TAA01044@hesketh.net> <373842FF.E4A55127@locke.ccil.org> Message-ID: <14136.25852.143612.741715@localhost.localdomain> John Cowan writes: > Simon, this isn't just meant for you, but for Paul and everybody. > I hope you are protesting to www-xml-schema-comments@w3.org. > I know that looks like a black hole, but it's the *only* chance > of getting this bogosity stopped, due to a Procedural Blunder > in the creation of the WD. Panic might be premature. Schemas are the bound to be the most controversial part of the new XML activity, and we should be grateful that the WG had the courage to put out a public snapshot of their current (and still incomplete) work rather than maintaining the W3C shroud of secrecy that has drawn so much criticism. My recommendation is to send brief, formal comments to www-xml-schema-comments@w3.org and more general discussion to XML-Dev. We can leave the horse heads out of the beds until we see what happens in the next WD. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mda at discerning.com Tue May 11 19:33:17 1999 From: mda at discerning.com (Mark D. Anderson) Date: Mon Jun 7 17:11:53 2004 Subject: Benchmark of 6 XML parsers on Solaris Message-ID: <026001be9bd3$9d579500$0200a8c0@mdaxke.mediacity.com> >> Judging from the level of discussion on various other lists I'm >> on, none of java, perl, or python were designed with lightweight, >> accurate, and meaningful profiling of their own run time built in. > >Not so. With Java 2, check out "java -Xrunhprof:help" output to >see the built in profiler. Works nicely on SPARC out of the box, >but the Win32 version at one point needed a JIT update to get CPU >profiling to work (by default it only does memory profiling). All the languages I mentioned have profiling hooks for "end programmers" using the language, of varying usability and accuracy. That is different from the kind of profiling that language implementors need, which ideally would allow for easy delving into the behavior of the runtime (typically C functions) in addition to the language-level profiling. This would be complemented by things like VM instruction histogramming, and introspection into other counters (the moral equivalent of oracle's V$ tables). In the case of a proprietary language like java, this lack of public implementor tools is understandable, as such tools represent a competitive advantage for VM implementors. For example, the implementors of the microsoft VM and the implementors of the sun VM have each created completely different private interfaces for performance instrumentation of their own VMs. -mda xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 19:38:23 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:53 2004 Subject: New schema spec Message-ID: <8725676E.0060C2F5.00@d53mta03h.boulder.ibm.com> >Excellent things. XML was right to simplify SGML and get rid of & and >exceptions. I hope XSchema will reintroduce both of them, and more. > Hmmm. But if schema becomes "thu way" that structural validation is done, then it won't be some optional part of XML. It will be basically a core part of XML, in very single implementation out there. So, if XML was right to leave it out to begin with, why is it a good thing to bring it back now? Have the reasons for having left it out changed? >>Just the m to n repetition system means that DFAs wouldn't work anymore right > >n{2 to 5} can be replaced by (n, n, (n, (n, (n)?)?)?) > >(n, m){2,5} can be replaced by ((n,m), (n,m), (n,m, (n,m (n,m)?)?)?) > >(n|m){2,5} can be replaced by > ((n|m), (n|m), (n, ((n, (n|m)) > | (m, (n|m)))) > | (m, (n, (n|m)) > | (m, (n|m)))) > >(n&m){2 to 5} can be replaced by > ( ((n, m)| (m,n)), > ((n, m)| (m,n)), > ( ((n, m)| (m,n)), ( ((n, m)| (m,n)), ((n, m)| (m,n))?)?)? ) > Well, that's true on the 'just thinking bout it' level. But is it practical? What if its n{20 to 1000} or something of that nature? That wouldn't be at all unreasonable from a user's standpoint, but what would be the practical implications for the data structures used during the creation of the DFA and the transition table itself? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 19:41:24 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:53 2004 Subject: Confused about & in entity literal Message-ID: <8725676E.00610751.00@d53mta03h.boulder.ibm.com> >> Otherwise, if it happens to look like a reasonable entity reference, I guess you >> are supposed to ignore it and just pass it through as is? If it does not look >> like a reasonable entity reference, then you give an error? > >Again, see section 4.5 (etc) which is pretty clear about this. > >Try running your parser through a conformance test suite -- e.g. James >Clark's XMLTEST and Sun's (which incorporates some examples from the >XML spec, avoiding any issues about interpretation). > That's what got me confused in the first place. My original implementation was just to ignore ampersands in the original scan of the entity value. But, if raw ampersands are not allowed, then I'm just asking whether I'm obligated to prove that any ampersand is at least provisionally part of a general entity (even if it later turns out not to be a legal one) during the scan of the entity value. And, if I think its not, that it should be considered in error? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue May 11 19:43:57 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:53 2004 Subject: minOccur, maxOccur References: <000501be9b73$6b186de0$cf00a8c0@nbreschke> Message-ID: <37390C59.60D2159D@prescod.net> Julian Reschke wrote: > > Interesting statement. How about an example. How would you define a schema > where can only contain and , each of which exactly one time? I must not follow your question. The following seems to meet your criteria: -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Diplomatic term: "Emerging Markets" Translation: Poor countries. The great euphemism of the Asian financial meltdown. Investors got much more excited when they thought they could invest in up-and-comers than when they heard they could invest in the Third World.(Brills Content, Apr. 1999) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue May 11 19:45:00 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:54 2004 Subject: Argh...Entities References: <01BE9B9C.B90F1750@grappa.ito.tu-darmstadt.de> <37384CEA.792DF8F1@locke.ccil.org> Message-ID: <37390B9E.4A09C7B2@prescod.net> John Cowan wrote: > > I remain unreconstructed. > > If we are to have validatable ENTITY/ENTITIES attributes, then > we must have unparsed entity declarations as well. Either > lose both or keep both, say I. First: Well, I am perfectly happy to lose ENTITY/ENTITIES and while we're at it ID/IDREF. URLs and XPointers can do both jobs better. Let's keep our layers clean and separate! Second: Even so, I don't follow your argument. The schema needs to validate that there is a unparsed entity with a particular name. Why does the declaration have to be done in the schema? It makes perfect sense to me that a *document* should declare what external resources it needs (through a URL or entity declaration) and that the *schema* would verify that an element that is supposed to reference a resource actually does (whether through a URL or entity). Your argument seems analgous to arguing that IDs should indirect through an "ID object" in the schema. Entities and IDs are a type of object that are tied to a document. Constraints on them apply to a class of documents. The former should go in a document and the latter in a schema. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco And so, in one of history's little ironies, the global triumph of bad software in the age of the PC was reversed by a surprising combination of forces: the social transformation initiated by the network, a long-discarded European theory of political economy, and a small band of programmers throughout the world mobilized by a single simple idea. - http://old.law.columbia.edu/my_pubs/anarchism.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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 19:54:13 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:54 2004 Subject: New schema spec Message-ID: <8725676E.00621F62.00@d53mta03h.boulder.ibm.com> >> >> Is >> there any way that such a system could be reasonably confirmed to be >> non-ambigious (and by reasonable I mean very fast and small amount of code.) >> And, given that, is there any way that it could be validated against in some >> less than exhaustive search way? > >I haven't been completely through the schema spec yet, but let me ask you >two questions: what definition of ambiguity are you using and why do you >care? XML DTDs explicitly allow ambiguity in content models so why >wouldn't schemas? > Well, its kind of a practical matter. From a support perspective (kind o' important to a company our size) proving that the content model is ambiguous means never have to say you're sorry, or at least have to say you're sorry less often. We don't want people pounding us with suspected bugs that are really the result of ambiguous content models. The existing DFA system makes it quite straightforward to catch this, and anything that makes it hard is a bad thing, IMHO. And, before anyone calls me on it... no the existing XML4C2 out there now does not do this check! It'll be in the next one :-) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 20:03:33 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:54 2004 Subject: minOccur, maxOccur References: <000501be9b73$6b186de0$cf00a8c0@nbreschke> <37390C59.60D2159D@prescod.net> Message-ID: <3738720A.91905BFC@locke.ccil.org> Paul Prescod wrote: > > Julian Reschke wrote: > > > > Interesting statement. How about an example. How would you define a schema > > where can only contain and , each of which exactly one time? > > I must not follow your question. The following seems to meet your > criteria: > > Julian's wording is ambiguous, but I take him to mean . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 20:21:01 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:54 2004 Subject: Confused about & in entity literal References: <8725676E.00610751.00@d53mta03h.boulder.ibm.com> Message-ID: <373875FF.A6666D74@locke.ccil.org> roddey@us.ibm.com wrote: > That's what got me confused in the first place. My original implementation was > just to ignore ampersands in the original scan of the entity value. Be sure to greedily expand character references, though; the ability to define "lt" and the like depends on that ability. > But, if raw > ampersands are not allowed, then I'm just asking whether I'm obligated to prove > that any ampersand is at least provisionally part of a general entity (even if > it later turns out not to be a legal one) during the scan of the entity value. BNF rule 9 says that EntityValues can't contain random & except as part of a well-formed PEReference or Reference, so it's a WF error (which you must catch) to have them, even if the entity is never referenced. All you actually have to do is to ensure that the next character (if not #, see above) is a NAMESTRT character, and that all characters until ; are either NAME or NAMESTRT characters. There is no need (and in fact it is forbidden) to look up the supposed entity name anywhere. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 20:23:06 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:54 2004 Subject: Argh...Entities References: <01BE9B9C.B90F1750@grappa.ito.tu-darmstadt.de> <37384CEA.792DF8F1@locke.ccil.org> <37390B9E.4A09C7B2@prescod.net> Message-ID: <37387686.7C3428D4@locke.ccil.org> Paul Prescod wrote: > Even so, I don't follow your argument. The schema needs to validate that > there is a unparsed entity with a particular name. Why does the > declaration have to be done in the schema? > > It makes perfect sense to me that a *document* should declare what > external resources it needs (through a URL or entity declaration) and that > the *schema* would verify that an element that is supposed to reference a > resource actually does (whether through a URL or entity). Your argument is sound. I am converted. Down with all entity declarations in XSchema! -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 11 20:32:48 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:54 2004 Subject: Mixed content considered harmful... References: <37375E61.42B0CA2F@prescod.net> Message-ID: <373878C8.F1055657@locke.ccil.org> Paul Prescod wrote: > #PCDATA is just a data type that is unconstrained. You should be able to > mix data type refs, #PCDATA and element type refs in content models with > impunity (barring real parsing ambiguity). Using old syntax: > > > > I need to be convinced of this. Can you sketch an algorithm that will convert SGML-style (or &-less SGML-style) content models involving #PCDATA into content models involving #PCDATA and #WS, where #WS is a data type that matches only white space, such that random white space around tags will be properly accounted for? Remember that XML parsers are required to pass along all whitespace, (i.e. it all appears in the infoset, barring whitespace outside the root element), so it needs to be accounted for somehow, when it is #PCDATA and when it isn't. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue May 11 20:38:09 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:11:54 2004 Subject: PI target names Message-ID: <002c01be9bd5$58321890$50f96d8c@NT.JELLIFFE.COM.AU> From: Don Park >> One can wonder why PIs were specified in the first place, if W3C doesn't >> want anyone to use them. > >What I would like to know is WHY W3C does not want to encourage folks to use >PI. Perhaps I'll agree with them once I hear all the arguments, perhaps >not. I would like to know what the arguments are. We should be careful not to mythologize that everyone involved in W3C is anti-PI. Some people perhaps feel that XML is a technology preview to prototype ideas for HTML; that is a credible view to have (though I don't hold it personally); for them PIs represent a dead-end because it is too late to retrofit them into HTML, they think. * To me PIs represent, above all, a proposal of humility by SGML/XML's designers: to admit that even within the most carefully constructed schema, there may in practise be kinds of tags required that the schema designer has not anticipated or expected. These tags may represent kinds of structures which simply do not fit into the element structure. (And the people who detect these different structures may not have the authority or capability to alter the schema.) * Furthermore, there may be conflicting ideas about interesting points within a document, and that such different ideas should be allowed, but only by using the "low-hanging fruit" of point-based tags, not a full concurrent or asynchronous (wrong word) element tree. For example, in what schema language can you say "a document entity must start with this encoding header"? Or, before the top element you must associated a stylesheet? If entities were forced to start with elements and always to contain at least on element, then we could do away with these kinds of PIs: we could use attributes on elements. There is always a problem that in most DTDs (and in some of the schemas, EDD is an exception) that there are many possible root element types, and it is not possible to define attribute requirements based on tree locations (actually, SGML's attribute LINKing allowed some kinds of variant attribute-requirements based on tree-position): this creates a kind of aberrant category of attributes which belong to tree-locations rather than element types. * PIs also represent a method of extensibility in which the PI tags do not alter validation against the DTD. It would be nice to have a schema declaration language which allowed kinds of validity (or at least some kind of notation well-formedness) of PIs. But we should not think that extensibility was entirely missing from SGML: the trouble with PIs as traditionally practised in SGML was that there was no "target" convention enforced or defined, so the extensibility never was able to get organized. * In the absense of a standard way of pointing to individual character positions (numerical character indexing) there is no standard way to have out-of-line markup inside entities which does not disrupt element structures. PIs provide a way of tagging positions, both to accomplish inline parallel structures, if needed, or as targets for out-of-line markup. Unnormalized Unicode has a big ambiguity problem which makes, for many written scripts, numerical character indexing unreliable or problematic: so it may be useful to have the back-up of being able to index to particular PIs within an element instead. * The classic use of PIs is a tag to hang publication-dependencies on. (SGML also had another kind of attribute, the PI attribute, which allowed you to hang PIs off elements too. I don't know whether this can be simulated by ENTITY attributes, where the entity contains a marked-up PI, but I doubt it.) So, for example, you might decide that all pagebreaks and newlines should be signified by PIs. This simplifies content models no end (I can show examples, but they are for Chinese documents). If HTML had PIs, these could have been used to hide scripts (instead of &barfoo; If it is OK for the physical processor to check that the second is valid, it is also OK for the physical processor to check that the first is valid. That the first can be checked post-parse is a red herring. Second, separating physical and logical definitions necessarily implies splitting validity into physical validity (Entity Declared, Standalone Document Declaration, etc.) and logical validity (Element Valid, Required Attribute, etc.). Physical validity is the responsibility of the parser and logical validity is the responsibility of the schema-processing module (which may be part of the parser). In response to Tim's point that it would be nice for schemas to be a pure superset of DTDs, why not have separate physical and logical schema languages? The physical language could be used on a per-document basis and the logical language on a per-document-class basis. The only reason I could think of for schemas being a superset of DTDs -- other than familiarity -- was converting DTDs to schemas on the fly for backwards compatibility of schema-driven software to documents with DTDs. However, this reason doesn't hold water. My experiments with converting DTDs to DDML showed me that I would have to build an intermediate object model -- streaming was not possible -- so there is no reason I couldn't build separate models for physical and logical definitions. (By the way, who needs entity definitions in instance syntax, anyway? The only example I have seen is the document fragment specification. Granted, this is a very convincing customer, but a separate physical schema language would satisfy their needs. Are there others?) -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed May 12 14:01:56 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:55 2004 Subject: XLink: behavior must go! Message-ID: <373964B5.73572354@prescod.net> This probably isn't the best week to send this but you can't always choose when inspiration (or religious fervor) will come to you. The message is widely crossposted because it crosses disciplines but I would like to see discussion be restricted to XML-DEV or offline. (I choose XML-DEV over xlxp because more people are subscribed there right now. I believe that the XLink behavioral attributes should be removed. Theoretically they mix presentation and structure. This causes all kinds of practical problems addressed below: Problem: No data model. No processing model. In my experience, the most useless language features are those where the interpretation is completely up to the software. The most useful features are those that either have a well defined underlying data model *or* a well-defined processing model. XML notations are useless not because they are a bad idea but because nobody has defined the data model or processing implications of the associated system identifier. The XLink behavior attributes have this problem. Just what do these behaviors *do*? What do they look like? They take us half-way down the path to inline presentation and arguably that is worse than taking us down that path whole hog. What does it look like to traverse a multi-ended link? How are the anchors represented? Do Netscape and Microsoft get to decide? After working for years to give them pixel-perfect stylesheet languages are designers back to trusting that vendors will give them a reasonable rendition? We could go whole hog and specify exactly what they look like (e.g. popup menus, buttons, hotlinks, etc.) and provide options for styling them. But that would further violate a major tenet of the XML religion: the separation of presentation and structure. Problem: media dependence That this is already a problem can be demonstrated by trying to imagine what it means to do an "auto/replace" in a printed document or "auto/embed" in a command-driven text-based user interface. Problem: stylesheet interoperability if XSL and CSS define to the pixel what the rendition of a document in a graphical browser should look like then what room is there for the browser's automatic anchor display behavior? Can they insert icons or buttons that adjust the flow? Can they override colors specified in the stylesheets? There are dozens of little issues like this where the stylesheet and the built-in linking behavior have the possibility of conflicting. Who wins? What are the rules? Do we have to add a concept like CSS's cascade to XSL? Problem: traversal path the behaviors are attached to *anchors* but the correct behavior probably depends both on the source and target anchors. The XLink specification says: "Link formatting and link behavior are inextricably connected" but then goes on to disconnect them. What will happen when we try to reconnect them? Problem: heresy Even if we could attach behaviors to both the source and target, the document is the *wrong place to do it*. We don't put "FONT" elements in our documents because the right font depends on the context of the viewer. Well the right link behavior also depends on the context of the viewer. Some viewers will have low-bandwidth connections and will want to explicitly initiate embedding. Some viewers will have sophisticated tree browsers an will want to treat what the author considered a "replace" links as an "embed". I have used browsers that treat HTML IMGs as "user/embed" (NS,IE images off), "user/new" (user-invoked helper app), "auto/embed"(NS,IE default) and "auto/new" (auto-invoked helper app). Obviously the right one depends on the situation. Other combinations might also make sense in some situations. I have used user agents that treat HTML "A"s as "user/replace"(typical), "user/embed" (Documentor), "user/new"(www-Emacs), "auto/new" (site downloaders). We've got to move this stuff to stylesheets so that people can make stylesheets that are optimized for various media. Even if we ignore UA-display and bandwidth limitations there are lots of other reasons to have anchors behave differently based on the stylesheet. I think three different site designers and/or end users could all disagree on whether the best way to handle a reference to an item in the glossary is an inline expansion (keeps context), a new window (screen clutter) or a replace. Maybe someone new to the topic would like every glossary entry expanded inline by default. Maybe some people want the glossary entry to pop up when the mouse moves over it. Another example: perhaps one view of some document is for "textual" people (pictures on demand) and another for "visual" people (pictures inline). Problem: incompatible implementations Okay, so to get around the fact that the client will and should do whatever it wants, we could refer to the links behaviors as just "hints". "Hints" are a sure sign that something is wrong in language design. They are usually an excuse for not doing the right thing. In this case, the right thing is to move all behavioral specifications into the stylesheet. Web designers should run screaming from underspecified behavioral attributes of all types. They are still trying to clean up the mess left by the (unavoidable) delay between the creation of HTML: "trust your browser" and CSS: "designers know better than software engineers." The behaviors chosen by browser authors were not always interoperable and then when we tried to "layer" the CSS standard on top it became a total mess because the "built-in" stylesheets of various browsers were different. The only way to get 100% portable rendering is to carefully and completely override the built-in behaviors of the browsers. So what is the use of the hints then? Also, XLink's behavior attribute is a car-wreck waiting to happen. What if Microsoft and Netscape use it differently? Problem: confusion Many, many people want to interpret the auto/embed command as an instruction to embed the nodes at the target at the current location and thus do node reuse. But this interpretation is not supported by the XLink specification. The target of an auto/embed could be a language that has no concept of "nodes" (barring definition of grove property sets) such as a JPEG or MPEG. Furthermore, I've thought about making a transclusion syntax for XML and there are some hard problems that XLink has not solved. For instance what if IDs clash. What happens to pointers and links? etc. The specification also suggests that auto/replace can be used for forwarding. To me this is just further evidence that these attribute are medium-specific presentational tricks. Is AltaVista or Google supposed to recognize an auto/replace as a request to update the entry for a document? The argument that these are "invariant semantics of link types" does not strike me as a good one. There is nothing semantic about "when you click here you go there." That's all about behavior. Problem: non-sensical combinations What if a document has a hundred anchors that all have auto/replace? Should it open a hundred documents in the current window *one at a time*? Problem: complexity Let's radically simplify the XLink specification and *get it out the door*. Taking behaviors out will help. Solution: Take all references to behavior and traversal out of the XLink spec. Move it all into a pair of specification called "Extensions to XSL for Link Rendering" and "Extensions to CSS for Link Rendering." In CSS, the basic model would be that link anchor-handling rules would be processed as part of the cascade. The "ordinary" rule might make some text bold and the "linking" rule would make it blue, underlined and clickable. Some simple rules could also render extended links as popup menus, lists of buttons, lists of icons, etc. In XSL, the model would be that link anchor-handling rules would have a higher priority than ordinary rules (either in general or through manual priority setting). They would specify some details of formatting and behavior (e.g. underline and clickability) and then invoke the rules that would otherwise have applied (e.g. to actually process text and sub-elements). Merging of adjacent clickable links can occur in the back-end. (e.g. blah blah blahblah blah blah would be rendered as a single link). -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Diplomatic term: "Emerging Markets" Translation: Poor countries. The great euphemism of the Asian financial meltdown. Investors got much more excited when they thought they could invest in up-and-comers than when they heard they could invest in the Third World.(Brills Content, Apr. 1999) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 12 15:33:44 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:55 2004 Subject: XLink: behavior must go! References: <373964B5.73572354@prescod.net> Message-ID: <37398453.FEB5336C@locke.ccil.org> Paul Prescod wrote: [XLink complaints snipped] A hypothetical question: How much of your concerns would be alleviated if XLink explicitly modeled traversal arcs and moved the behavior attributes to individual arcs? Not all, obviously, but not zero either. The pure presentation concerns, IMHO, go away if we concede that stylesheet languages should understand links as objects (as opposed to treating them like all other elements), as your last section proposes. However, I don't see how a stylesheet can sensibly prescribe behavior like "replace". -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 12 15:51:40 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:55 2004 Subject: Mixed content considered harmful... References: <37375E61.42B0CA2F@prescod.net> <373878C8.F1055657@locke.ccil.org> <373885E8.459FE5E2@prescod.net> Message-ID: <3739887B.25770CA0@locke.ccil.org> Paul Prescod wrote: > I don't think that you would convert the content models. You leave the > content models alone and just change your matching algorithm slightly. That is very clear. Thanks. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed May 12 16:35:37 1999 From: eriblair at mediom.qc.ca (=?iso-8859-1?Q?=C9ric_Riblair?=) Date: Mon Jun 7 17:11:55 2004 Subject: Samples of XML4J ... Message-ID: <010c01be9c84$f03c1c80$1f9ccb84@grr.ulaval.ca> Does anyone know where I will find some examples for XML4J of IBM ... that use the applet way... Regards, ?ric Riblair, Agronome (eriblair@mediom.qc.ca) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990512/7bf44b1d/attachment.htm From sjs at portal.com Wed May 12 17:00:29 1999 From: sjs at portal.com (Steve Schow) Date: Mon Jun 7 17:11:55 2004 Subject: Samples of XML4J ... References: <010c01be9c84$f03c1c80$1f9ccb84@grr.ulaval.ca> Message-ID: <37399713.5CEBB224@portal.com> The Applet way? the IBM stuff has to work as an applet or can it work in the web server? -steve ?ric Riblair wrote: > Does anyone know where I will find some examples for XML4J of IBM ... > that use the applet way... Regards, ?ric Riblair, > Agronome > (eriblair@mediom.qc.ca) -- ----------------------------- Steve Schow - Portal Software sjs@portal.com http://www.bstage.com/ ----------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Wed May 12 17:28:26 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:55 2004 Subject: Entities and Expat (was Re: Confused about & in entity literal) In-Reply-To: <005301be9be5$e16d3800$1a5e360a@tetondata.com> References: <8725676E.00610751.00@d53mta03h.boulder.ibm.com> <373875FF.A6666D74@locke.ccil.org> Message-ID: <3.0.1.32.19990512112317.0076e78c@tiac.net> An external entity reference needs a declaration: If you want your application to "just know" about some entities which you have failed to define anywhere, I don't think that documents relying on that behavior would even be considered well-formed. How about putting: and the like into your document? >I'm trying to parse and index documents that contain several HTML-style >general entities ("©", "•", etc.), using Expat ("Version >19990307") as the parser. I want to be able to trap these entity strings >(they're not to be indexed, but they are to be included, untranslated, in >the document output). But, Expat exits with an XML_ERROR_UNDEFINED_ENTITY >error ("..undefined entity at line.."). Inspection of the Expat source >shows the following: -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlangdon at copeland.com Wed May 12 17:36:28 1999 From: jlangdon at copeland.com (Jeff Langdon) Date: Mon Jun 7 17:11:55 2004 Subject: Dynamic HTML/PDF's Message-ID: <8525676F.00556D4F.00@mail.copeland.com> Please excuse the non-XML question, but I have to start somewhere. As a developer I am learning all I can about XML, XSL, etc. and I greatly appreciate all the good information I get from these mailing lists, but my company will be living in the dark ages for some time to come, so my focus here is working with HTML and PDF's. I need to find a way to make a PDF (or similar technology ) dynamic. Example - When a client clicks on a hyperlink I want the PDF to come up with the ability to dynamically through a scripting language or some other technology append a gif or jpeg ( company logo ) to the document. I am using generic forms in conjunction with numerous company logos. Could someone point me in the right direction. Please feel free to contact me directly since this is not really an XML question - jlangdon@copeland.com TIA, Jeff Langdon Senior Web Developer The Copeland Companies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 12 17:57:45 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:11:55 2004 Subject: XLink: behavior must go! In-Reply-To: <373964B5.73572354@prescod.net> Message-ID: <199905121557.LAA07291@hesketh.net> At 06:23 AM 5/12/99 -0500, Paul Prescod wrote: >This probably isn't the best week to send this but you can't always choose >when inspiration (or religious fervor) will come to you. The message is >widely crossposted because it crosses disciplines but I would like to see >discussion be restricted to XML-DEV or offline. (I choose XML-DEV over >xlxp because more people are subscribed there right now. Per Paul's request, I'm responding to XML-Dev. Is there ever a good week for inspiration? I'd love to find one. Paul's message has lots and lots of parts to it. Rather than sending 35K replies back and forth, I'm going to try to focus on some parts I think make a good beginning. I'd also like to distill this down to a core proposal people can discuss. >I believe that the XLink behavioral attributes should be removed. >Theoretically they mix presentation and structure. This causes all kinds >of practical problems addressed below: I'm not yet with you completely on removal of these attributes, but I'll certainly agree that the many components of XLink that deal with behavior range from the extraordinarily vague to the excessively specific, without very much in the middle. >Also, XLink's behavior attribute is a car-wreck waiting to happen. What if >Microsoft and Netscape use it differently? Agreed, though I think train-wreck is a more appropriate scale. > Problem: complexity > >Let's radically simplify the XLink specification and *get it out the >door*. Taking behaviors out will help. Problem: Getting it out the door. I've been wanting to push (and use) XLink for the last two years. It's very hard to get people excited about something that has a vague draft that's over a year old. Getting the spec out the door will help sell XML as a general-purpose solution to a wide variety of problems that afflict webmasters every day. Simplifying it will ease that selling considerably. > Solution: > >Take all references to behavior and traversal out of the XLink spec. Move >it all into a pair of specification called "Extensions to XSL for Link >Rendering" and "Extensions to CSS for Link Rendering." I'd like to make this as concrete as possible. Does this mean that you'd be looking at something like the model below for describing extended links? (These come more or less from the XLink WD, minus the parts Paul doesn't like. I've renamed some of the role attributes to try and make things a bit clearer. myLinkContainer and myLinkLocator are placeholders, of course.) Style sheets would have to deal with the various roles and piece together appropriate behaviors. A key concern for me is making sure that CSS and XSL use a similar model for processing links and that that model can also be used by applications that wouldn't normally use style sheets. (The simple image map example on my web site is a very simple case, but there are a few thousand other possibilities.) Rather than going directly to implementation in CSS and XSL, I'd like to see an intermediate step describing what exactly is 'in' a link, and possible mechanisms for moving from raw sets of locators to traversable paths (including what might be on that pop-up menu or equivalent.) Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed May 12 18:02:56 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:11:55 2004 Subject: XLink: behavior must go! Message-ID: <3.0.32.19990512104722.007dd5e0@polaris.net> At 06:23 AM 5/12/1999 -0500, Paul Prescod wrote: [pretty convincing arguments about problems in XLink as specified to date] I've always thought of the XLink spec as a comprehensive blue-sky pastiche of wonderful, imperfectly-workable ideas, and figured that with time it would shake out to be, er, more perfectly workable. (And, granted, less blue-sky.) The "hints" in the spec, I reckoned, were there as Post-It(tm) reminders for authors of the next WD as much as for readers of the current one. It's been a looong time between WDs, though; if it would help accelerate the process then I'd be all for jettisoning the behavior-specific bits of the spec (or transferring responsibility for them to the style WGs). OTOH, transplanting the burden won't necessarily accelerate resolution of those Little Flaky Bits. Paul mentioned some problems inherent in transclusion of foreign structures, for example. That's the one LFB I'd be most interested in having and the one I'm least confident of ever obtaining, in anything like perfect form. (This isn't meant as a knock on the work of the Fragments WG by any means; it just seems impossible for them to resolve *all* the transclusion LFBs, e.g. partial nodes, ID clashes, etc.) (Paul didn't mention this, but I also worry greatly about the intellectual-property implications of auto/embed behavior, *especially* in the absence of default style/rendering. This strikes me as a nifty technological bauble with potentially far-reaching cultural impact.) ============================================================= John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jasr at im.se Wed May 12 18:34:39 1999 From: jasr at im.se (Serrat Jaime - jasr) Date: Mon Jun 7 17:11:55 2004 Subject: Dynamic HTML/PDF's Message-ID: <389DA7CB46CFD111A0D100600836AD65E66D57@msxmar1> Jeff wrote: >I need to find a way to make a PDF (or similar technology ) dynamic. I'm not certain it's your solution, but check out Adobe's page describing XFA. http://www.xfa.com/specifications.html XFA is a working draft specification submitted to the W3C by the JetForm company as an extension to handling XML documents and data as forms. JetForm has actually proposed two distinct documents: one describing a simple scripting language optimized for creating e-form centric logic and calculations, called XFA-Formcalc. The other, describes the open and extensible construction of secure forms with high fidelity composition, automated calculation and validation, pluggable user-interface components, and flexible data handling, called: XFA-Template. Good luck, -- jaime "jim" serrat Technical Manager of PDA08 - EDI Engine Office: +1 609-797-3227 Product Development Fax: +1 609-797-6660 Industri-Matematik Mobile: +1 609-315-3338 Five Greentree Centre Web: http://www.im.se Marlton, NJ 08053 Email: jasr@im.se > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990512/4b10d02d/attachment.htm From niko at cmsplatform.com Wed May 12 18:52:01 1999 From: niko at cmsplatform.com (Nik O) Date: Mon Jun 7 17:11:55 2004 Subject: Entities and Expat References: <8725676E.00610751.00@d53mta03h.boulder.ibm.com> <373875FF.A6666D74@locke.ccil.org> <005301be9be5$e16d3800$1a5e360a@tetondata.com> <37390768.AF79DAF8@pacbell.net> Message-ID: <004401be9c97$ad0a9820$1a5e360a@tetondata.com> Thank you both for your rapid response. I should have mentioned that i had previously tried to include entity declarations within my document (there is presently no DTD associated with the document). When i included the entity declaration at the beginning of the document (outside the root element), Expat returned XML_ERROR_INVALID_TOKEN ("not well-formed"). If the entity declaration was included within the root element, Expat returned XML_ERROR_SYNTAX ("syntax error"). Indeed, i double-checked this by copying the string from Joshua's email. Same results. Perhaps the real issue is Expat's handling of "" declarations in standalone documents? Or am i still missing something? My application is parsing XML documents that contain HTML entity references ("©", etc.), indexing the text, and building a full-text database comprised of HTML "documents". The app doesn't need to expand, translate, or index the entity strings -- it just needs a string length to keep the document's word offsets straight, and to copy the string to the output stream. I had hoped to do this in the DefaultHandler callback, but of course i'm never getting there. Joshua E. Smith wrote: > If you want your application to "just know" about some entities which you > have failed to define anywhere, I don't think that documents relying on > that behavior would even be considered well-formed. David Brownell wrote: > Expat doesn't read external parameter entities, including > "the" external subset, but it does understand that if it > doesn't come across one of those, all entities must be > defined through the internal subset... John Cowan wrote: > All you actually have to do is to ensure that the next character > (if not #, see above) is a NAMESTRT character, and that all characters > until ; are either NAME or NAMESTRT characters. There is no need (and > in fact it is forbidden) to look up the supposed entity name anywhere. The first two statements seem to contradict the third (what statement sparked my first message). I must admit i remain a little confused about the boundary between well-formed and valid XML documents when it comes to general entities. My opinion would be to agree with John Cowan's statement -- if an EntityRef is physically valid (see "[68]" below), why should the parser, or any other intermediate processor care whether the referenced entity 'Name' exists? However, when i went back to the XML spec, it seems that Joshua E. Smith is indeed correct that my document is *not* well-formed, and therefore Expat is processing it correctly. The following references and excerpts are from Tim Bray's truly excellent annotated XML 1.0 Specification (http://www.xml.com/axml/testaxml.htm or http://www.xml.com/axml/target.html to omit the explanation frame). I've added the text in curly braces (e.g. "{43}") to describe Tim's hyperlinks. ======= Begin spec excerpt ======= 4.3.2 Well-Formed Parsed Entities [snip] An internal general parsed entity is well-formed if its replacement text matches the production labeled content {43}. All internal parameter entities are well-formed by definition. ======= End spec excerpt ======= ======= Begin spec excerpt ======= [43] content ::= (element | CharData | Reference {67} | CDSect | PI | Comment)* ======= End spec excerpt ======= ======= Begin spec excerpt ======= [67] Reference ::= EntityRef | CharRef [68] EntityRef ::= '&' Name ';' [ WFC: Entity Declared ] [ VC: Entity Declared ] [ WFC: Parsed Entity ] [ WFC: No Recursion ] ======= End spec excerpt ======= ======= Begin spec excerpt ======= 4.1 Character and Entity References [snip] Well-Formedness Constraint: Entity Declared In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", the Name given in the entity reference must match that in an entity declaration, except that well-formed documents need not declare any of the following entities: amp, lt, gt, apos, quot. The declaration of a parameter entity must precede any reference to it. Similarly, the declaration of a general entity must precede any reference to it which appears in a default value in an attribute-list declaration. Note that if entities are declared in the external subset or in external parameter entities, a non-validating processor is not obligated to read and process their declarations; for such documents, the rule that an entity must be declared is a well-formedness constraint only if standalone='yes'. ======= End spec excerpt ======= According to the table in section "4.4 XML Processor Treatment of Entities and References", an "Internal General Entity" that is "Reference[d] in Content" is to be "Included". ======= Begin spec excerpt ======= 4.4.3 Included If Validating When an XML processor recognizes a reference to a parsed entity, in order to validate the document, the processor must include its replacement text. If the entity is external, and the processor is not attempting to validate the XML document, the processor may, but need not, include the entity's replacement text. If a non-validating parser does not include the replacement text, it must inform the application that it recognized, but did not read, the entity. ======= End spec excerpt ======= -Nik O, Content Mgmt Solutions, Jackson, Wyo. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 12 19:00:59 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:55 2004 Subject: Entities and Expat References: <8725676E.00610751.00@d53mta03h.boulder.ibm.com> <373875FF.A6666D74@locke.ccil.org> <005301be9be5$e16d3800$1a5e360a@tetondata.com> <37390768.AF79DAF8@pacbell.net> <004401be9c97$ad0a9820$1a5e360a@tetondata.com> Message-ID: <3739B4EB.2CE425EE@locke.ccil.org> Nik O wrote: > I should have mentioned that i had previously tried to include entity > declarations within my document (there is presently no DTD associated with > the document). That is your problem. You need to create a DTD internal subset declaration, like this: etc. etc. ]> That will cause the entity reference "æ" to expand to the string "æ", which seems to be what you want. > John Cowan wrote: > > All you actually have to do is to ensure that the next character > > (if not #, see above) is a NAMESTRT character, and that all characters > > until ; are either NAME or NAMESTRT characters. There is no need (and > > in fact it is forbidden) to look up the supposed entity name anywhere. I was talking about a different case: entity references within entity declarations, not entity references within the document instance itself. This is really only of concern to parser writers. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 at xmltree.com Wed May 12 19:22:14 1999 From: james at xmltree.com (james@xmlTree.com) Date: Mon Jun 7 17:11:55 2004 Subject: Getting the value of the xmlns attribute Message-ID: <00e501be9c9b$dd50b330$0500a8c0@fourleaf.com> Sorry if this is the inappropriate place to post this question. I've got some RDF data like Internet Alchemy http://alchemy.openjava.org/ Internet Alchemy - last published 7/May/1999 I want to get the value of the xmlns attribute, so I tried to use objSource.selectSingleNode("rdf:RDF/@xmlns"), which does not return an attribute object. The method call objSource.selectSingleNode("rdf:RDF/@xmlns:rdf") *does* return an attribute object. It seems that because xmlns is a reserved word, this particular method call does not return an attribute object. Is there a way around this? p.s. Using XMLDOM from Microsoft IE 5.00.2014.0216 Many thanks in advance, James Carlyle james@xmltree.com www.xmltree.com - directory of XML content on the web xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed May 12 19:31:04 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:56 2004 Subject: minOccur, maxOccur Message-ID: <8725676F.006013CA.00@d53mta03h.boulder.ibm.com> >> I dispute the usefulness of minOccur and maxOccur. I would like to hear >> about where people would use these features. I find that people often want >> them but can find a clearer way of expressing their document type when >> they are not available. > >Interesting statemen. How about an example. How would you define a schema >where can only contain and , each of which exactly one time? > That one is easy, and can be done via DTD now. It would be: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From niko at cmsplatform.com Wed May 12 20:06:31 1999 From: niko at cmsplatform.com (Nik O) Date: Mon Jun 7 17:11:56 2004 Subject: Entities and Expat References: <8725676E.00610751.00@d53mta03h.boulder.ibm.com> <373875FF.A6666D74@locke.ccil.org> <005301be9be5$e16d3800$1a5e360a@tetondata.com> <37390768.AF79DAF8@pacbell.net> <004401be9c97$ad0a9820$1a5e360a@tetondata.com> <3739B4EB.2CE425EE@locke.ccil.org> Message-ID: <006d01be9ca2$22c196e0$1a5e360a@tetondata.com> Thanks much for the clarification. Obviously, i need to go back to the remedial XML syntax class, since i was forgetting to wrap the "" declarations within a "" declarations and the root element start-tag are included in the first input file, and the root element end-tag is the last input file, with the untranslated content file(s) in between these wrapper files. I suppose an external DTD would be the preferred alternative, but i'm trying to avoid DTDs, for now (or at least until i pass that remedial class). -Nik O, Content Mgmt Solutions, Jackson, Wyo. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Wed May 12 21:14:51 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:11:56 2004 Subject: XLink: behavior must go! References: <199905121557.LAA07291@hesketh.net> Message-ID: <3739D18F.3DF4EF07@w3.org> "Simon St.Laurent" wrote: > >Let's radically simplify the XLink specification and *get it out the > >door*. Taking behaviors out will help. > > Problem: Getting it out the door. I've been wanting to push (and use) > XLink for the last two years. It's very hard to get people excited about > something that has a vague draft that's over a year old. Getting the spec > out the door will help sell XML as a general-purpose solution to a wide > variety of problems that afflict webmasters every day. Agreed. Actually, it narrowly missed being out the door for this weeks WWW8 conference. Expect drafts shortly. This was announced in the XML activity update in the W3C track today. -- Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed May 12 21:56:23 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:56 2004 Subject: Argh...Entities References: Message-ID: <3739D624.AB282D3A@prescod.net> Noah has given me some feedback on the schema-comments list that I would like to forward (with permission) and respond to. Noah_Mendelsohn/CAM/Lotus@lotus.com wrote: > > The schemas WG has given very serious consideration to the view that > validity constraints should be somehow separated from anything in the > schema that affects content. Entities do affect content and could be > eliminated or perhaps "put in a box" as you suggest. [by put in a box he means to make a separate specification that would handle them] > The more difficult case, I think, is default values for attributes. These > too affect content (and in the case of default values for namespace > attributes can affect the deeper meaning of the document structure.) > Anyway, we've heard strong opinions expressed that (1) default values for > attributes are an important feature of any replacement for DTDs and (2) > that it would be very cumbersome to define the default values somewhere > that is far removed from the declaration of the attribute itself. The > natural place to introduce a default does seem to be on the attribute > declaration. I agree, this does seem natural. Here are reasons it seems natural: a) people view the DTD document as documentation for the language b) DTD writers want to communicate to application writers that there is some specific default that makes the most sense c) DTD writers want to be able to change their mind about the specific default later. What if we rethought the attribute default mechanism in terms of these goals? Instead of having default attributes change the parse tree as seen in a DOM 1.0 tool, (i.e. at the lowest infoset) we can have them attach extra nodes to the infoset that the application gets by viewing the data through the schema. The necessity of this infoset is a given: how else will applications know their data types and so forth? In other words, attribute defaulting is a service provided by the schema engine to the application just like data type recognition and attribute value type recognition. It would NOT be a service provided to or by the parser (using the old fashioned definition of parser that did not include the entire universe). Probably defaulting would occur after namespace application (which wouldn't need it) but before (e.g.) XSL application (which would). If it makes it clearer, we can even stop referring to it as a default value and instead refer to it as a "suggested value." And note that you can build this as a SAX filter or DOM layer on top of XML 1.0 SAX or DOM. Text entities cannot really be rethought this way because XML 1.0 requires them to be resolved before anything else can proceed. Plus text entities are probably just not a good idea anyhow: we should be glad to let them die out. > So, depending on how you feel about that analysis of attribute values, > pandora's box is then open. I can see that the box is open but only a crack. If we think of the levels as: 1. physical 2. logical 3. DTD/schema-augmented logical Then default attributes can be considered to be at level 3. If we want to push them back into the parser (I advise against it) then we could call them level 2. But to influence level 1 from level 3 seems particularly gruesome and not backwards compatible. If we do it the "wrong way" then attribute defaulting is analogous to an ingrown toe-nail but text entity insertion is more like an ingrown toe. (sorry!) > The schema can afffect the contents of a > standalone=no document. Having, with regrets, crossed that bridge, does > that change the net tradeoff on entities? Maybe. The standalone=no > document is already potentially dependent on the schema for other reasons, > I.e. attribute defaults. Now the question is: be a proper superset of > DTD, including questionable features, or leave out entities? > > Anyway, these are some of the issues we wrestled with. You can see where > we landed this time. Thanks again for the feedback. > > Noah -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Diplomatic term: "Regret" Translation: To care, but not enough to condemn. ("We regret the loss of life in Sierra Leone. We have no intention to do anything to stop it, mind you, but we regret that it happened.") (Brills Content, Apr. 1999) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From reschke at medicaldataservice.de Wed May 12 23:51:56 1999 From: reschke at medicaldataservice.de (Julian Reschke) Date: Mon Jun 7 17:11:56 2004 Subject: minOccur, maxOccur In-Reply-To: <37390C59.60D2159D@prescod.net> Message-ID: <003401be9cc1$879a7360$cf00a8c0@nbreschke> > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Paul Prescod > Sent: Wednesday, May 12, 1999 7:07 AM > To: reschke@medicaldataservice.de; xml-dev > Subject: Re: minOccur, maxOccur > > > Julian Reschke wrote: > > > > Interesting statement. How about an example. How would you > define a schema > > where can only contain and , each of which exactly one time? > > I must not follow your question. The following seems to meet your > criteria: > > I think I don't understand your initial question then... Yes, you don't need minOccurs and maxOccurs if you have a DTD as well -- but that would be in addition to a Schema file. My understanding was that a Schema would be used instead of a DTD, and then these two attributes surely are useful. Could you please clarify a bit what you were trying to tell us :-) ? Regards, Julian xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 01:13:23 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:56 2004 Subject: What is W3C's official position on use of PI? Message-ID: <005f01be9ccd$46003500$bb96fea9@w21tp> I would like know exactly what W3C's position is on the use of Processing Instruction. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu May 13 01:39:20 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:11:56 2004 Subject: What is W3C's official position on use of PI? Message-ID: <3.0.32.19990512163835.011c52a0@pop.intergate.bc.ca> At 04:15 PM 5/12/99 -0700, Don Park wrote: >I would like know exactly what W3C's position is on the use of Processing >Instruction. I do not speak for W3C, but I can say with little fear of contradiction that consensus on this issue does not yet exist. Some people, as a matter of principle, regard PIs as problematic second-class syntax and would like simply to cease using them. Others see them as a perfectly respectable out-of-band signaling mechanism. Each time the idea of using PIs for some purpose has been proposed, lengthy and intense debate has ensued. In terms of W3C Recommendations, PIs occur in XML 1.0, where they are defined, and in DOM Level 1, which provides an API interface to them. There may be others but those are the ones I know about. -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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mjkoo at kistmail.kist.re.kr Thu May 13 02:12:38 1999 From: mjkoo at kistmail.kist.re.kr (Mi-Jeong Koo) Date: Mon Jun 7 17:11:56 2004 Subject: Parsing content with SAX API Message-ID: <373A1975.ABC6814B@kistmail.kist.re.kr> ... Rainmaker : John Grisham ... Is there any SAX API function to get the content, 'Rainmaker : John Grisham'? Thank you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 02:27:18 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:56 2004 Subject: What is W3C's official position on use of PI? References: <3.0.32.19990512163835.011c52a0@pop.intergate.bc.ca> Message-ID: <002101be9cd7$9989d000$bb96fea9@w21tp> > I do not speak for W3C, but I can say with little fear of contradiction > that consensus on this issue does not yet exist. Some people, as a matter > of principle, regard PIs as problematic second-class syntax and would like > simply to cease using them. Others see them as a perfectly respectable > out-of-band signaling mechanism. Each time the idea of using PIs for > some purpose has been proposed, lengthy and intense debate has ensued. Tim, Thanks for clearing that up. Do you what the folks who "regard PIs as problematic second-class syntax" recommend for first-class out-of-band signaling mechanism? I wouldn't mind giving up PI if there was an alternative. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu May 13 02:52:15 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:11:56 2004 Subject: What is W3C's official position on use of PI? Message-ID: <3.0.32.19990512174941.011de6b0@pop.intergate.bc.ca> At 05:29 PM 5/12/99 -0700, Don Park wrote: >Thanks for clearing that up. Do you what the folks who "regard PIs as >problematic second-class syntax" recommend for first-class out-of-band >signaling mechanism? You'd have to ask one of them. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu May 13 03:37:15 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:56 2004 Subject: What is W3C's official position on use of PI? References: <3.0.32.19990512163835.011c52a0@pop.intergate.bc.ca> <002101be9cd7$9989d000$bb96fea9@w21tp> Message-ID: <373A227F.96A1186B@prescod.net> Don Park wrote: > > Thanks for clearing that up. Do you what the folks who "regard PIs as > problematic second-class syntax" recommend for first-class out-of-band > signaling mechanism? I wouldn't mind giving up PI if there was an > alternative. Well, Liam Quin has been a constant critic of processing instructions. http://www.mulberrytech.com/xsl/xsl-list/archive/msg03388.html http://www.lists.ic.ac.uk/hypermail/xml-dev/9811/0203.html My response: http://www.mulberrytech.com/xsl/xsl-list/archive/msg03396.html As I said in that message, the important thing about processing instructions is that they are invisible to content models. If XML Schemas invented a way to make elements invisible to content models (like SGML's inclusion exceptions, but maybe only allowed at the top level) and a way to add these inclusions to existing schemas easily then processing instructions could be replaced by these "floating", element types. That would be neat. But if there are no floating element types then we still need processing instructions. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Diplomatic term: "Regret" Translation: To care, but not enough to condemn. ("We regret the loss of life in Sierra Leone. We have no intention to do anything to stop it, mind you, but we regret that it happened.") (Brill's Content, Apr. 1999) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu May 13 05:58:11 1999 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:11:56 2004 Subject: Argh...Entities In-Reply-To: <3739D624.AB282D3A@prescod.net> Message-ID: <199905130357.AA00472@archlute.apsdc.ksp.fujixerox.co.jp> Paul Prescod wrote: >Noah_Mendelsohn/CAM/Lotus@lotus.com wrote: >> So, depending on how you feel about that analysis of attribute values, >> pandora's box is then open. > >I can see that the box is open but only a crack. I agree with Paul. I personally would like to drop everything that affects information sets from the schema language. Hence, I oppose to information set contributions, archetypes, defaults, entities, notations, .... Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 06:16:17 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:56 2004 Subject: What is W3C's official position on use of PI? References: <3.0.32.19990512163835.011c52a0@pop.intergate.bc.ca> <002101be9cd7$9989d000$bb96fea9@w21tp> <373A227F.96A1186B@prescod.net> Message-ID: <004201be9cf7$984b9d20$7dcbfea9@w21tp> > As I said in that message, the important thing about processing > instructions is that they are invisible to content models. If XML Schemas > invented a way to make elements invisible to content models (like SGML's > inclusion exceptions, but maybe only allowed at the top level) and a way > to add these inclusions to existing schemas easily then processing > instructions could be replaced by these "floating", element types. That > would be neat. I entirely agree with your opinion. Liam's view is that of concern over misuse where I am more concerned with functionality. I believe XML community can benefit from a guideline for proper use of PI as well as some mechanism for registering PI target names. Meanwhile we need to encourage HTML browsers to recognize PI so that we do not lose this important feature of XML. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mjkoo at kistmail.kist.re.kr Thu May 13 06:52:04 1999 From: mjkoo at kistmail.kist.re.kr (Mi-Jeong Koo) Date: Mon Jun 7 17:11:56 2004 Subject: Parsing content with SAX API Message-ID: <373A5B08.C4987405@kistmail.kist.re.kr> ... Rainmaker : John Grisham ... Is there any SAX API function to get the content, 'Rainmaker : John Grisham'? Thank you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Thu May 13 10:14:57 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:11:56 2004 Subject: Parsing content with SAX API Message-ID: <01BE9D29.29081C90@grappa.ito.tu-darmstadt.de> Mi-Jeong Koo wrote: > .. > Rainmaker : John Grisham > .. > > > Is there any SAX API function to get the content, 'Rainmaker : John > Grisham'? The characters method in the DocumentHandler interface. Note that parsers are not required to return the entire content in one call -- they could make multiple, sequential calls and return it in pieces. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Thu May 13 10:36:37 1999 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:11:56 2004 Subject: XLink: behavior must go! Message-ID: <012801be9d1b$87ed3460$dac566c3@sgml.u-net.com> Paul Prescod wrote: >I believe that the XLink behavioral attributes should be removed. Theoretically they mix presentation and structure. This causes all kinds of practical problems addressed below: Behaviour *must* stay. What we need is some mechanism for passing through behaviour control properties from the instance to the XSLT. The behaviour attribute provides us with a standardized point which we can query from within XSLT to determine which types of behaviour a particular instance of an object should have. In fact the behaviour attribute should move from the XLink to XML standard, as xml:behaviour-control, but that is is bit too radical for people to bite off just yet. In the meantime it is vital that at least XLink provides us with a standardized mechanism for controlling instance behaviour. (Paul is right to say this is really a "hints" thing -but it is something more than a hint - it is a set of parameters that can be used to control behaviour where appropriate.) >We could go whole hog and specify exactly what they look like (e.g. popup menus, buttons, hotlinks, etc.) and provide options for styling them. But that would further violate a major tenet of the XML religion: the separation of presentation and structure. No we could not! In the first place XSL is not defining a GUI. In the second we could not begin to guess what the *user* requires. What if the user is blind? None of your suggested behaviours would be of the least use. What if the behaviour said "convert this instances of of invoices to euros before display" or "use the current exchange rate to express any prices in the linked document in the user's local currency"? What if the behaviour said "If this instance of the message is selected do not allow the user to select another of the listed options"? You cannot predefine the behaviour of all (or any) XML document instances - you can only provide an extensible mechanism that people can use to indicate what type of behaviour may be required and what controls should be used for this purpose within the XSL processor. >Take all references to behavior and traversal out of the XLink spec. Move it all into a pair of specification called "Extensions to XSL for Link Rendering" and "Extensions to CSS for Link Rendering." Again its a question of who is in control. We need to leave authors with the right to make choices without having to be stylesheet designers. One type of behaviour I would like to see is to be able to control which stylesheet should be associated with a particular instance when traversed via a particular linked document. As it stands authors have no control over the presentational style of a non-embedded instance. (This is a great agrument for auto-embed as it allows the display of the recalled data to be controlled by the local stylesheet.) We need a better mechanism for choice of stylesheet than those currently being shown. For example, I would like to be able to select the stylesheet used based on the language setting of the user's locale. How can I do this? We desparately need mechanisms to manage both link behaviour and the behaviour of stylesheets associated with linked documents. One attribute to do this, rather than a whole set of customizable ones that change from environment to environment is the only way we are going to get transportable interactive documents. Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From l-arcini at uniandes.edu.co Thu May 13 11:13:12 1999 From: l-arcini at uniandes.edu.co (F.A.A.) Date: Mon Jun 7 17:11:56 2004 Subject: XML spec in spanish Message-ID: <001e01be9d21$197915c0$0100000a@phoebe> Hi everyone, After reading again the XML 1.0 spec, taking careful notes (in spanish), I pretty much realized, this notes could be organized to help people if they had access to a spanish translation of the spec (you know, much like Tim did -thanks Tim-, only in spanish). Is there any spanish translation of the spec? in case there's not, I guess I'd be interested in doing it. You guys see the translation a useful effort for expanding the XML community into spanish-speaking countries or a waste of time? what do you think? Fabio Arciniegas A. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 12:12:52 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:57 2004 Subject: Parsing content with SAX API In-Reply-To: <373A1975.ABC6814B@kistmail.kist.re.kr> References: <373A1975.ABC6814B@kistmail.kist.re.kr> Message-ID: <14138.11402.978128.504906@localhost.localdomain> Mi-Jeong Koo writes: > ... > Rainmaker : John Grisham > ... > > > Is there any SAX API function to get the content, 'Rainmaker : John > Grisham'? Once you have created a class implementing DocumentHandler, instantiated it, and registered it with the Parser, and initiated the parse, then your handler will receive callbacks. Here's a simplified version: start document start element: "BOOK" characters: "Rainmaker : John Grisham" end element: "BOOK" end document Actually, a SAX parser is free to chunk up characters any which way, so you might end up with start document start element: "BOOK" characters: "Rainmaker" characters: " " characters: ":" characters: " " characters: "John" characters: " " characters: "Grisham" end element: "BOOK" end document Or even more extremely, one callback for each character. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 12:12:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:57 2004 Subject: What is W3C's official position on use of PI? In-Reply-To: <005f01be9ccd$46003500$bb96fea9@w21tp> References: <005f01be9ccd$46003500$bb96fea9@w21tp> Message-ID: <14138.11012.530967.639148@localhost.localdomain> Don Park writes: > I would like know exactly what W3C's position is on the use of > Processing Instruction. Perhaps we should start a W3C Should-People-Use-PIs Working Group, or even a PI Activity with several WGs (the PIs-In-Old-HTML-Browsers WG, the PIs-For-Stylesheets WG, etc.). Sorry -- Tim's reply is actually a bit more useful. This is really a question about people and their (varying) opinions, not about W3C policy. Here are the two ends of the spectrum: 1. PIs are probably too useful to drop altogether -- they allow you to do things like mark irregular revision boundaries, invent new declaration types, etc. 2. Level-three-browser compatibility is probably too important to drop altogether -- PIs are unlikely to show up in specs that might be used on HTML pages (Namespaces, RDF, Stylesheet linking, XHTML). 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Thu May 13 15:07:45 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:11:57 2004 Subject: Parsing content with SAX API Message-ID: <93CB64052F94D211BC5D0010A800133170EE79@wwmess3.bra01.icl.co.uk> > > Actually, a SAX parser is free to chunk up characters any which way, > so you might end up with [snip] > > Or even more extremely, one callback for each character. Or even more extremely, a few zero-length chunks thrown in for luck. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu May 13 15:22:11 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:57 2004 Subject: XLink: behavior must go! Message-ID: <002601be9d42$679cbc40$0b2e249b@fileroom.Synapse> Martin Bryan wrote: >Paul Prescod wrote: > >>I believe that the XLink behavioral attributes should be removed. >Theoretically they mix presentation and structure. This causes all kinds >of practical problems addressed below: > >Behaviour *must* stay. What we need is some mechanism for passing through >behaviour control properties from the instance to the XSLT. The behaviour >attribute provides us with a standardized point which we can query from >within XSLT to determine which types of behaviour a particular instance of >an object should have. In fact the behaviour attribute should move from the >XLink to XML standard, as xml:behaviour-control, but that is is bit too >radical for people to bite off just yet. In the meantime it is vital that at >least XLink provides us with a standardized mechanism for controlling >instance behaviour. (Paul is right to say this is really a "hints" >thing -but it is something more than a hint - it is a set of parameters that >can be used to control behaviour where appropriate.) > Is there anything within XLink itself that cannot be replaced by XSLT now that doc() and docref() have been defined? Does XLink not become something akin to a standard set of XSLT templates used for handling URI traversal? doc() and docref(), as well as unification with XPointer turn XSLT into a generalized graph transformation language. Could the XLink spec itself become an XSLT include file? Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Thu May 13 16:41:11 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:11:57 2004 Subject: XML spec in spanish Message-ID: <84285D7CF8E9D2119B1100805FD40F9F255266@MDYNYCMSX1> http://www.oasis-open.org/cover/xml.html is always a good place to check for this sort of thing. http://www.oasis-open.org/cover/xml.html#reference shows an existing translation of the XML spec in Spanish, although the link didn't work when I tried it. There is also a link to a local (www.oasis-open.org) copy which does work. The broken link mentions "Source from SGML-ESP." The list of XML mailing lists at IBM's XML website at http://www.software.ibm.com/xml/community/mailing-lists.html mentions SGML-ESP with the following description: "This XML listserv is meant to serve the Spanish-speaking community. Enviar un mensaje a sgml-esp-request@slug.ctv.es conel subject:subscribe. Para escribir a la lista escribir a sgml-esp@slug.ctv.es." That looks like a good way to get in touch with people working on this. buena suerte, Bob DuCharme www.snee.com/bob see www.snee.com/bob/xmlann for "XML: The Annotated Specification" from Prentice Hall. -----Original Message----- From: F.A.A. [mailto:l-arcini@uniandes.edu.co] Sent: Thursday, May 13, 1999 5:10 AM To: XML-dev Subject: XML spec in spanish Hi everyone, After reading again the XML 1.0 spec, taking careful notes (in spanish), I pretty much realized, this notes could be organized to help people if they had access to a spanish translation of the spec (you know, much like Tim did -thanks Tim-, only in spanish). Is there any spanish translation of the spec? in case there's not, I guess I'd be interested in doing it. You guys see the translation a useful effort for expanding the XML community into spanish-speaking countries or a waste of time? what do you think? Fabio Arciniegas A. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu May 13 16:46:15 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:11:57 2004 Subject: XLink: behavior must go! In-Reply-To: <002601be9d42$679cbc40$0b2e249b@fileroom.Synapse> Message-ID: <199905131445.KAA12757@hesketh.net> At 09:13 AM 5/13/99 -0400, Jonathan Borden wrote: > Is there anything within XLink itself that cannot be replaced by XSLT >now that doc() and docref() have been defined? Does XLink not become >something akin to a standard set of XSLT templates used for handling URI >traversal? doc() and docref(), as well as unification with XPointer turn >XSLT into a generalized graph transformation language. Could the XLink spec >itself become an XSLT include file? Er... just everything. One of the key points of XLink is that it is _not_ bonded to a particular style sheet language. XLink is useful in contexts where XSLT is either too much or too little, and provides common vocabulary that document developers can use to describe links whatever final processing the documents may receive. If your question is rephrased: "Is there anything within XLink itself that cannot be implemented by XSLT?" Then it might be received a little more kindly by those of us who work with XML in contexts where XSL (indeed style sheets, at times) is unnecessary. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nevansmu at fdgroup.co.uk Thu May 13 16:59:14 1999 From: nevansmu at fdgroup.co.uk (Neil Evans-Mudie) Date: Mon Jun 7 17:11:57 2004 Subject: XML-Dev: Getting the value of the xmlns attribute Message-ID: <01BE9D4B.AEACC9A0.nevansmu@fdgroup.co.uk> Greetings Mark & all u other VBXML'ers, PERSONAL INTRODUCTION - BIN IF NOT INTERESTED boy i'm glad to have this mailing list - i'm real excited that a specific list has been set up for VB & XML. Anyway i'll just introduce myself, then i'll go straight to the website 'projects area' and then contribute as much as i can to the mailing list. Hi, i'm Neil Evans-Mudie originally from the Isle Of Man now a resident of Sheffield, England (as in Steel and cutlery!!). I work for a software house called Fretwel-Downing Data Systems (http://www.fdgroup.co.uk). I'm interested in using XML within, what we call, the Further Education market To enable data exchange between our back office systems. I'm trying to do this with VB, MSXML.DLL, MTS, MSMQ and SQL-Server using shape extensions to ADO/SQL. I come from a Geographical Info. Systems and VB background (I used to teach GIS at Uni.). Anyway i'm pretty sporty and a generally jovial character (I think). So there u go - looking forward to participating in the VBXML community. Neil. > Hi James. > > Thanks for the promo... its all true!! Except that I am not a kiwi, I am from South Africa > and my wife and I are work-travelling around the place. This weekend we move to Australia. > > Hi Neil > > Go to our wbsite at http://www.vbxml.com and sign up for the email discussion lists. Read > the FAQ and so on. It's definitely where you need to be. > > But more importantly, check out our projects area - the XSL Tester one is excellent for you I > think. The code snippets in the Demo XML code area - the XML engine for call centers has > MASSIVE amounts of DOM code. > > Good luck! > Mark. > > > > Neil > > > > > firstly let me apologise for intruding on your time but i wondered if u may > > No problem! > > > > > can't work out how to populate the DOM tree from a dao or ado recordset - > > > could u suggest a way. > > No - I have never used ado etc. - I only use Allaire's Cold Fusion. I can recommend 2 > > resources - the book "XML-IE5" from Wrox (?27, ISBN 1-861001-57-6), and the (very active) > > user group VBXML at vbxml.com (run by a really keen and helpful NZer called Mark Wilson > > who is writing a book on VB and XML). They have quite a lot of sample code and are very > > keen to help active members. > > > > Best regards, > > James Carlyle > > > > > James, > > > > > > firstly let me apologise for intruding on your time but i wondered if u may > > > be able to help me. I noticed that this message invloved MS's DOM > > > (presumably MSXML.dll) - i've been trying to use the dll with little > > > success from vb (i'm a fairly novice vb'er and completely new to XML). i > > > can't work out how to populate the DOM tree from a dao or ado recordset - > > > could u suggest a way. > > > > > > Also once populated, how can i then add additional nodes and validate the > > > 'completed' tree against a DTD? > > > > > > Finally i'm going to export the xml as string to another application, which > > > i know i can create the xml string form the method DOMDocument.XML. I'll > > > pass this to message queue or other COM object, which the target can then > > > process in a predefined manner. > > > > > > I'd appreciate any pointers both general & specific which u could give me - > > > i've been on & off struggling with this for about 4 weeks and unfortunately > > > haven't receieved any guidance from general postings to any of the xml or > > > vb lists, or xml web sites i've found. > > > > > > Once again sorry to intrude on your private mailbox but, well, er, um, if > > > i've offended u please just bin the message!! > > > > > > TIA, best wishes, > > > > > > Neil. > > > > > > PS. it nice to see somebody else out there using MSXML.dll - that it in > > > itself gives me some belief. > > > > > > Neil Evans-Mudie > > > Developer, fretwell-downing group Ltd. > > > (nevansmu@fdgroup.co.uk; http://www.fdgroup.co.uk/) > > > [Snail-Mail: > > > fretwell-downing group Ltd, > > > Brincliffe House, 861 Ecclesall Road, Sheffield, S11 7AE, England. > > > Tel: +44 (0)114 281 6000; Fax: +44 (0)114 281 6001] > > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Thu May 13 17:15:59 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:11:57 2004 Subject: archetype refinement and architectural forms Message-ID: <84285D7CF8E9D2119B1100805FD40F9F255268@MDYNYCMSX1> It looks to me like the refinement of archetypes as described in the "XML Schema Part 1: Structures" document will make it possible to implement much of the intent behind architectural forms. Any comments? Bob DuCharme www.snee.com/bob "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 17:29:17 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:11:57 2004 Subject: What is W3C's official position on use of PI? References: <005f01be9ccd$46003500$bb96fea9@w21tp> <14138.11012.530967.639148@localhost.localdomain> Message-ID: <009c01be9d55$96de88e0$7dcbfea9@w21tp> > 2. Level-three-browser compatibility is probably too important to drop > altogether -- PIs are unlikely to show up in specs that might be > used on HTML pages (Namespaces, RDF, Stylesheet linking, XHTML). Level-three-browsers can be supported by filtering out PI from the server-side if the client can not handle PI. Real world problems like legacy browser incompatibility are best solved with real world solutions. Best, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wunder at infoseek.com Thu May 13 17:48:17 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:11:57 2004 Subject: XLink: behavior must go! In-Reply-To: <373964B5.73572354@prescod.net> Message-ID: <3.0.5.32.19990513083325.00c8fb80@corp> At 06:23 AM 5/12/99 -0500, Paul Prescod wrote: > >I believe that the XLink behavioral attributes should be removed. >Theoretically they mix presentation and structure. I agree that they mix presentation and structure, but I also feel that it is worthwhile to capture some common situations. That is, allow people to define link "roles", but start out with a few standard roles. This is analogous to including xml:lang in the XML spec. I'm concerned about XML being less useful than HTML because of a lack of common elements (conventions). For example, an XML author has no way to reliably give a web spider a title, description, or robot hints (follow/nofollow, index/noindex). Also, link roles could be meaningful to an indexing program -- transcluded text should be indexed with the source doc, -linked text shouldn't. I'm hunting down a copy of the PCTE rationale, since it has a nice description of the link roles in PCTE, and how they got to that design. Meanwhile, maybe I should write a NOTE proposing a PI analogous to the robots meta tag (). wunder -- Walter R. Underwood wunder@infoseek.com wunder@best.com (home) http://software.infoseek.com/cce/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mjkoo at kistmail.kist.re.kr Thu May 13 06:52:04 1999 From: mjkoo at kistmail.kist.re.kr (Mi-Jeong Koo) Date: Mon Jun 7 17:11:57 2004 Subject: Parsing content with SAX API Message-ID: <373A5B08.C4987405@kistmail.kist.re.kr> ... Rainmaker : John Grisham ... Is there any SAX API function to get the content, 'Rainmaker : John Grisham'? Thank you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Thu May 13 17:51:21 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:11:57 2004 Subject: Singletons in a DTD Message-ID: <3.0.1.32.19990513114639.00768410@tiac.net> I have an element which can contain 0 or more instances of some element types (call these collections), and 0 or 1 instances of others (call these singletons), and I don't want to contrain the order. If I have collections C1, C2, C3 and I have singletons S1, S2, S3 And I declare: (S1? , S2? , S3? , (C1 | C2 | C3)*) Then the singletons, if they appear, would have to be in that order and would have to be first. So that's not what I want. I suppose I could declare some combinatorics: ( S1? | S2? | S3? | (S1 , S2)? | (S2 , S1)? | (S1 , S3)? blah blah blah but I'd have to mix in the C1, C2, C3, etc., too, and I have about 8 singleton classes, so this would quickly get totally out of control. Am I missing something, or is what I want to describe not really practical in a DTD? I'm perfectly comfortable leaving the singletonness out of my DTD (my application will detect duplication errors anyway), if that's the only answer. But if there *is* a way to capture this without waiting for XSchema to be finished, I'd love to hear it! -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Thu May 13 10:14:57 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:11:57 2004 Subject: Parsing content with SAX API Message-ID: <01BE9D29.29081C90@grappa.ito.tu-darmstadt.de> Mi-Jeong Koo wrote: > .. > Rainmaker : John Grisham > .. > > > Is there any SAX API function to get the content, 'Rainmaker : John > Grisham'? The characters method in the DocumentHandler interface. Note that parsers are not required to return the entire content in one call -- they could make multiple, sequential calls and return it in pieces. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From l-arcini at uniandes.edu.co Thu May 13 11:13:12 1999 From: l-arcini at uniandes.edu.co (F.A.A.) Date: Mon Jun 7 17:11:57 2004 Subject: XML spec in spanish Message-ID: <001e01be9d21$197915c0$0100000a@phoebe> Hi everyone, After reading again the XML 1.0 spec, taking careful notes (in spanish), I pretty much realized, this notes could be organized to help people if they had access to a spanish translation of the spec (you know, much like Tim did -thanks Tim-, only in spanish). Is there any spanish translation of the spec? in case there's not, I guess I'd be interested in doing it. You guys see the translation a useful effort for expanding the XML community into spanish-speaking countries or a waste of time? what do you think? Fabio Arciniegas A. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 12:12:52 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:57 2004 Subject: Parsing content with SAX API In-Reply-To: <373A1975.ABC6814B@kistmail.kist.re.kr> References: <373A1975.ABC6814B@kistmail.kist.re.kr> Message-ID: <14138.11402.978128.504906@localhost.localdomain> Mi-Jeong Koo writes: > ... > Rainmaker : John Grisham > ... > > > Is there any SAX API function to get the content, 'Rainmaker : John > Grisham'? Once you have created a class implementing DocumentHandler, instantiated it, and registered it with the Parser, and initiated the parse, then your handler will receive callbacks. Here's a simplified version: start document start element: "BOOK" characters: "Rainmaker : John Grisham" end element: "BOOK" end document Actually, a SAX parser is free to chunk up characters any which way, so you might end up with start document start element: "BOOK" characters: "Rainmaker" characters: " " characters: ":" characters: " " characters: "John" characters: " " characters: "Grisham" end element: "BOOK" end document Or even more extremely, one callback for each character. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 12:12:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:58 2004 Subject: What is W3C's official position on use of PI? In-Reply-To: <005f01be9ccd$46003500$bb96fea9@w21tp> References: <005f01be9ccd$46003500$bb96fea9@w21tp> Message-ID: <14138.11012.530967.639148@localhost.localdomain> Don Park writes: > I would like know exactly what W3C's position is on the use of > Processing Instruction. Perhaps we should start a W3C Should-People-Use-PIs Working Group, or even a PI Activity with several WGs (the PIs-In-Old-HTML-Browsers WG, the PIs-For-Stylesheets WG, etc.). Sorry -- Tim's reply is actually a bit more useful. This is really a question about people and their (varying) opinions, not about W3C policy. Here are the two ends of the spectrum: 1. PIs are probably too useful to drop altogether -- they allow you to do things like mark irregular revision boundaries, invent new declaration types, etc. 2. Level-three-browser compatibility is probably too important to drop altogether -- PIs are unlikely to show up in specs that might be used on HTML pages (Namespaces, RDF, Stylesheet linking, XHTML). 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Thu May 13 10:36:37 1999 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:11:58 2004 Subject: XLink: behavior must go! Message-ID: <012801be9d1b$87ed3460$dac566c3@sgml.u-net.com> Paul Prescod wrote: >I believe that the XLink behavioral attributes should be removed. Theoretically they mix presentation and structure. This causes all kinds of practical problems addressed below: Behaviour *must* stay. What we need is some mechanism for passing through behaviour control properties from the instance to the XSLT. The behaviour attribute provides us with a standardized point which we can query from within XSLT to determine which types of behaviour a particular instance of an object should have. In fact the behaviour attribute should move from the XLink to XML standard, as xml:behaviour-control, but that is is bit too radical for people to bite off just yet. In the meantime it is vital that at least XLink provides us with a standardized mechanism for controlling instance behaviour. (Paul is right to say this is really a "hints" thing -but it is something more than a hint - it is a set of parameters that can be used to control behaviour where appropriate.) >We could go whole hog and specify exactly what they look like (e.g. popup menus, buttons, hotlinks, etc.) and provide options for styling them. But that would further violate a major tenet of the XML religion: the separation of presentation and structure. No we could not! In the first place XSL is not defining a GUI. In the second we could not begin to guess what the *user* requires. What if the user is blind? None of your suggested behaviours would be of the least use. What if the behaviour said "convert this instances of of invoices to euros before display" or "use the current exchange rate to express any prices in the linked document in the user's local currency"? What if the behaviour said "If this instance of the message is selected do not allow the user to select another of the listed options"? You cannot predefine the behaviour of all (or any) XML document instances - you can only provide an extensible mechanism that people can use to indicate what type of behaviour may be required and what controls should be used for this purpose within the XSL processor. >Take all references to behavior and traversal out of the XLink spec. Move it all into a pair of specification called "Extensions to XSL for Link Rendering" and "Extensions to CSS for Link Rendering." Again its a question of who is in control. We need to leave authors with the right to make choices without having to be stylesheet designers. One type of behaviour I would like to see is to be able to control which stylesheet should be associated with a particular instance when traversed via a particular linked document. As it stands authors have no control over the presentational style of a non-embedded instance. (This is a great agrument for auto-embed as it allows the display of the recalled data to be controlled by the local stylesheet.) We need a better mechanism for choice of stylesheet than those currently being shown. For example, I would like to be able to select the stylesheet used based on the language setting of the user's locale. How can I do this? We desparately need mechanisms to manage both link behaviour and the behaviour of stylesheets associated with linked documents. One attribute to do this, rather than a whole set of customizable ones that change from environment to environment is the only way we are going to get transportable interactive documents. Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Thu May 13 18:04:06 1999 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:11:58 2004 Subject: XLink: behavior must go! Message-ID: <012801be9d1b$87ed3460$dac566c3@sgml.u-net.com> Paul Prescod wrote: >I believe that the XLink behavioral attributes should be removed. Theoretically they mix presentation and structure. This causes all kinds of practical problems addressed below: Behaviour *must* stay. What we need is some mechanism for passing through behaviour control properties from the instance to the XSLT. The behaviour attribute provides us with a standardized point which we can query from within XSLT to determine which types of behaviour a particular instance of an object should have. In fact the behaviour attribute should move from the XLink to XML standard, as xml:behaviour-control, but that is is bit too radical for people to bite off just yet. In the meantime it is vital that at least XLink provides us with a standardized mechanism for controlling instance behaviour. (Paul is right to say this is really a "hints" thing -but it is something more than a hint - it is a set of parameters that can be used to control behaviour where appropriate.) >We could go whole hog and specify exactly what they look like (e.g. popup menus, buttons, hotlinks, etc.) and provide options for styling them. But that would further violate a major tenet of the XML religion: the separation of presentation and structure. No we could not! In the first place XSL is not defining a GUI. In the second we could not begin to guess what the *user* requires. What if the user is blind? None of your suggested behaviours would be of the least use. What if the behaviour said "convert this instances of of invoices to euros before display" or "use the current exchange rate to express any prices in the linked document in the user's local currency"? What if the behaviour said "If this instance of the message is selected do not allow the user to select another of the listed options"? You cannot predefine the behaviour of all (or any) XML document instances - you can only provide an extensible mechanism that people can use to indicate what type of behaviour may be required and what controls should be used for this purpose within the XSL processor. >Take all references to behavior and traversal out of the XLink spec. Move it all into a pair of specification called "Extensions to XSL for Link Rendering" and "Extensions to CSS for Link Rendering." Again its a question of who is in control. We need to leave authors with the right to make choices without having to be stylesheet designers. One type of behaviour I would like to see is to be able to control which stylesheet should be associated with a particular instance when traversed via a particular linked document. As it stands authors have no control over the presentational style of a non-embedded instance. (This is a great agrument for auto-embed as it allows the display of the recalled data to be controlled by the local stylesheet.) We need a better mechanism for choice of stylesheet than those currently being shown. For example, I would like to be able to select the stylesheet used based on the language setting of the user's locale. How can I do this? We desparately need mechanisms to manage both link behaviour and the behaviour of stylesheets associated with linked documents. One attribute to do this, rather than a whole set of customizable ones that change from environment to environment is the only way we are going to get transportable interactive documents. Martin Bryan XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nevansmu at fdgroup.co.uk Thu May 13 18:06:56 1999 From: nevansmu at fdgroup.co.uk (Neil Evans-Mudie) Date: Mon Jun 7 17:11:58 2004 Subject: Aplogies: wrong list!! Please delete immediately Message-ID: <01BE9D62.EF4EB060.nevansmu@fdgroup.co.uk> Aplogies to all at xml-dev this message was sent to the wrong list!! Sorry again (my contacts were set up incorrectly). Thanx Robert for informing me. On Thursday, May 13, 1999 5:06 PM, DuCharme, Robert [SMTP:DuCharmR@moodys.com] wrote: > Uhh, you sent this to the xml-dev list, but it's not a list for VB & > XML. http://www.vbxml.com/Joining/joining.htm shows that vbxml is a > different list from xml-dev. > > Bob DuCharme www.snee.com/bob snee.com> see www.snee.com/bob/xmlann for "XML: > The Annotated Specification" from Prentice Hall. > > -----Original Message----- > From: nevansmu@fdgroup.co.uk [mailto:nevansmu@fdgroup.co.uk] > Sent: Thursday, May 13, 1999 9:20 AM > To: XML-Dev (E-mail) > Subject: Re: XML-Dev: Getting the value of the xmlns attribute > > > Greetings Mark & all u other VBXML'ers, > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 18:45:01 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:11:58 2004 Subject: archetype refinement and architectural forms In-Reply-To: <84285D7CF8E9D2119B1100805FD40F9F255268@MDYNYCMSX1> References: <84285D7CF8E9D2119B1100805FD40F9F255268@MDYNYCMSX1> Message-ID: <14139.281.921006.222388@localhost.localdomain> DuCharme, Robert writes: > It looks to me like the refinement of archetypes as described in > the "XML Schema Part 1: Structures" document will make it possible > to implement much of the intent behind architectural forms. Any > comments? >From my first, quick skim, I think that there are a couple of problems with that approach: 1. It's very heavy-weight and processor-intensive, compared to simple Namespaces or AF processing. 2. There's no facility for multiple inheritance. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricker at xmls.com Thu May 13 18:51:21 1999 From: ricker at xmls.com (Jeffrey Ricker) Date: Mon Jun 7 17:11:58 2004 Subject: A milestone in XML In-Reply-To: <4.2.0.37.19990509153541.01b73ee0@mail.userland.com> References: <007601be9a6a$54bf8100$4d27fea9@w21tp> <4.2.0.37.19990509093952.01c59c60@mail.userland.com> Message-ID: <199905131650.MAA19795@mail.his.com> Dave, Why did Netscape feel it necessary to invent RSS rather than use CDF as Microsoft, DataChannel, PointCast, etc. do? What does RSS do that CDF does not? Is the difference so drastic that a new format is necessary, or could CDF be improved instead? I don't mean for this to sound like a jab. I am genuinely curious to know your purpose and reasoning. Jeffrey Ricker XMLSolutions At 03:36 PM 5/9/99 -0700, Dave Winer wrote: >RSS *is* interesting.. > >http://my.netscape.com/publish/help/quickstart.html > >It still needs to carry more info, but it's an excellent start. > >Dave > >At 03:21 PM 5/9/99 , Don Park wrote: >>Dave, >> >>RSS sounds interesting. Where can I find more information on it? A search >>of Netscape's developer site using "RSS" doesn't find anything. >> >>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/ and on >>CD-ROM/ISBN 981-02-3594-1 >>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >>(un)subscribe xml-dev >>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >>subscribe xml-dev-digest >>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 19:00:00 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:11:58 2004 Subject: FYI--off-topic--Notation Schemas proposal Message-ID: <003c01be9d59$fcc67fb0$1df96d8c@NT.JELLIFFE.COM.AU> For anyone who is interested, there is a draft-in-progress of my ideas for a good schema language. It allows you do things like * content models for attribute lists: to say element X can have attributes (id & (size & size-units)? & ( href | entityref)? ) * content models for attribute values, to say that attribute Y can have NMTOKENS ( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY | (SATURDAY? & SUNDAY?) ) * content models for IDREFS links, to say that element Z can have IDREFS to particular types of elements ( ( p | q | tbl ), (p, | q | tbl) In other words, it treats attribute lists, attribute value lists, & IDREF lists with the same strong typing that is available to elements. The foundation of my proposal is that everything should be modelled as a grammar: if the decision of whether to make something an attribute, an element or an element reference (IDREF) is completely arbitrary (from the information modeled), then why not allow strong typing on all them. It moves XML from being a strongly-yped tree language to being a strongly-typed graph language. It also allows people more freedom to structure their documents, for example to move to flat relational-style tables without giving up strong typing. This would make RDF more useful too. However, I gather some of this might be out of the scope of the XML Schema group. However, since apparantly XML 1.0 conformance was outside their scope too, apparantly (I am being naughty: they did an amazing job to pull together so many proposals and put it out on time...lets not forget that it is only a draft), perhaps they may be open to developing in other directions. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu May 13 19:07:49 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:11:58 2004 Subject: XLink: behavior must go! Message-ID: <006201be9d61$f3c33e00$0b2e249b@fileroom.Synapse> Simon St.Laurent : >At 09:13 AM 5/13/99 -0400, Jonathan Borden wrote: >> Is there anything within XLink itself that cannot be replaced by XSLT >>now that doc() and docref() have been defined? Does XLink not become >>something akin to a standard set of XSLT templates used for handling URI >>traversal? doc() and docref(), as well as unification with XPointer turn >>XSLT into a generalized graph transformation language. Could the XLink spec >>itself become an XSLT include file? > >Er... just everything. > >One of the key points of XLink is that it is _not_ bonded to a particular >style sheet language. XLink is useful in contexts where XSLT is either too >much or too little, and provides common vocabulary that document developers >can use to describe links whatever final processing the documents may receive. > >If your question is rephrased: > >"Is there anything within XLink itself that cannot be implemented by XSLT?" > >Then it might be received a little more kindly by those of us who work with >XML in contexts where XSL (indeed style sheets, at times) is unnecessary. > No intention to offend. You are correct, it seems to me that XLink can be implemented via XSLT now that XSLT includes doc() and docref(). There remains a distinction between the concept of XLink and the implementation. The concept of XLink does appear to be related to the concept of XPointer, both are specifications for graph traversal. My thought was that as it has been announced that the XPointer and XSL specs are to be combined that XLink might benefit from a similar integration. What I am struggling with is the question as to, if behaviors are removed from XLink, what concept does XLink contain beyond either a single URI or set of URIs? All of this, including bi-directional links etc, comes down to graph->graph transformation. It is unfortunate that this very important and general facility gets labeled a 'stylesheet' technology (not that I have anything against stylesheets. Since graph->graph transformation underlies a wide range of facilities, including RDF, a central and core definition of graph-graph transformation and traversal facilities greatly strengthens the ability of 'XML' to deliver on it's promises. XLink, like XPointer is a key element to graph traversal and for this reason these technologies should be grouped together and viewed as parts of a single larger picture. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 19:13:04 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:11:58 2004 Subject: Notation Schema proposal draft Message-ID: <005a01be9d5b$d23f4860$1df96d8c@NT.JELLIFFE.COM.AU> I forgot the URL for my proposal. http://www.ascc.net/~ricko/notation.htm 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From terje at in-progress.com Thu May 13 19:37:27 1999 From: terje at in-progress.com (Terje Norderhaug) Date: Mon Jun 7 17:11:58 2004 Subject: Singletons in a DTD Message-ID: At 8:46 AM 5/13/99, Joshua E. Smith wrote: >I have an element which can contain 0 or more instances of some element >types (call these collections), and 0 or 1 instances of others (call these >singletons), and I don't want to contrain the order. > >If I have collections C1, C2, C3 >and I have singletons S1, S2, S3 > >And I declare: > >(S1? , S2? , S3? , (C1 | C2 | C3)*) > >Then the singletons, if they appear, would have to be in that order and >would have to be first. So that's not what I want. > >I suppose I could declare some combinatorics: > >( S1? | S2? | S3? | (S1 , S2)? | (S2 , S1)? | (S1 , S3)? blah blah blah > >but I'd have to mix in the C1, C2, C3, etc., too, and I have about 8 >singleton classes, so this would quickly get totally out of control. > >Am I missing something, or is what I want to describe not really practical >in a DTD? I'm perfectly comfortable leaving the singletonness out of my >DTD (my application will detect duplication errors anyway), if that's the >only answer. But if there *is* a way to capture this without waiting for >XSchema to be finished, I'd love to hear it! The AND '&' connector in SGML covered this functionality, but isn't included in XML. It can thus easily be described in a DTD, just not an *XML* DTD. -- Terje | Media Design in*Progress Software for Mac Web Professionals at Take advantage of XML with Emile, the first XML editor for Mac. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From travis at betty.cnidr.org Thu May 13 20:23:24 1999 From: travis at betty.cnidr.org (Travis Walsh) Date: Mon Jun 7 17:11:58 2004 Subject: XML::Parser Message-ID: <011c01beb5c9$6cabb980$15b36d80@cnidr.org> I'm running XML:Parser 2.20 on linux. All of the newlines are stripped when I run a CharHandler. Should this be happening and how can I stop it? ********************** * K. Travis Walsh * MCNC / CNIDR * Programmer / Analyst * travis@mcnc.org ********************** My Quote of the day: Talk doesn't cook rice. -Chinese proverb xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu May 13 20:39:06 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:58 2004 Subject: Again wit da AND and Repetitions Message-ID: <87256770.006634D9.00@d53mta03h.boulder.ibm.com> I never really had any one say whether they thought that validation that included both AND connectors and M to N repetition for any of the connectors is feasible (meaning fast and compact and maintainable and verifiable in my opinion, but tell me if you disagree.) Does anyone believe that these can be done in less than brute force tree search times? Is any combination of trees with some nodes which are traditional DFAs make any sense? Are there any even theoretical discussions of such things out there anywhere for folks to study? Give that these are both stated goals of Schema, if they are not feasible that's an issue that should be discussed early. If they are feasible, then we can get on with it and not waste time arguing. I personally am not a big theoretical data structures person, or even a little one for that matter. I'm an object infrastructure person who just happens to be doing XML right now. So, from my perspective, I'm pretty concerned that the Schema spec, as stands, might require a doctoral thesis to implement a validator for that performs reasonably well. Am I just being paranoid and there is really a "XML Structural Validation With ANDs and NtoMs for Dummies" out there somewhere? If there is such a thing, could it be made to perform even within say 20% of the DFA based state machine of existing XML parsers? What are the feelings of some folks who implemented SGML validators? If you had to start with that and add NtoM repetition on top of that, where would that have taken you? Or did SGML already provide both of these things? If so, what was the general architecture used in some common ones? Why is the sky blue? Sorry for all the questions, but this is just an area where I don't have very much understanding and hope that there is some lingering SGML based wisdom in these areas that could be shared, or that perhaps some of you are big theoretical data structures folks who would like to expound on this subject for our enlightenment. TIA for any light shed. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu May 13 20:48:41 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:11:58 2004 Subject: No subject Message-ID: <87256770.00672902.00@d53mta03h.boulder.ibm.com> >What if we rethought the attribute default mechanism in terms of these >goals? Instead of having default attributes change the parse tree as seen >in a DOM 1.0 tool, (i.e. at the lowest infoset) we can have them attach >extra nodes to the infoset that the application gets by viewing the data >through the schema. The necessity of this infoset is a given: how else >will applications know their data types and so forth? > >In other words, attribute defaulting is a service provided by the schema >engine to the application just like data type recognition and attribute >value type recognition. It would NOT be a service provided to or by the >parser (using the old fashioned definition of parser that did not include >the entire universe). Probably defaulting would occur after namespace >application (which wouldn't need it) but before (e.g.) XSL application >(which would). > Hmmmm. Maybe I'm not fully understand you. But, if I am, this would be a serious problem with respect to performance. The parser really has to understand namespaces or you can never validate a stream based API, right? If the understanding of namespaces requires that it all happen after the fact, i.e. after its gone out the parser, then streaming protocols could not really be validated since the data would have to be accumulated until some part of the tree is built and can be validated, right? That would be kind of at odds to what makes streaming protocols useful. Or did I just totally miss the point? You *could* build it on top of SAX, but it would mean a very significant difference in performance. We can currently validate event output with a very small amount of overhead beyond the basic parsing overhead, because we understand such issues inside the parser and can apply the validation as the stream 'goes by'. If we had to give that up, though it would have other nice side effects, would be something to think hard about. Anything that makes XML perform noticebly worse is something to consider in its job as interchange language, right? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bryan.cooper at veritas.com Thu May 13 21:07:16 1999 From: bryan.cooper at veritas.com (Bryan Cooper) Date: Mon Jun 7 17:11:59 2004 Subject: XML validation In-Reply-To: <003c01be9d59$fcc67fb0$1df96d8c@NT.JELLIFFE.COM.AU> Message-ID: <4.1.19990513101336.00db53d0@pop.ncal.verio.com> Rick - I didnt see where to pickup your draft. Since this group is NOT XML-standards-body-only-need-apply, I thought I'd make a 2 cent point. SOMEWHERE in xmlland there is an effort to use XML tags syntax instead of DTD, and I just have to workaround with my own for now. Maybe that is getting completed. In any case, what I feel is that its EASIER for me to setup an XML validation thang than what I see as a separate syntax in the DTD world. PLUS it gets awfully difficult from an application approach to get really detailed rules e.g. arbitrary extensions to DTD for those cases where "if its tuesday and you are in belgium, you can speak three languages unless you are in a lambic beer brewery". To me, XML (or maybe xml) is helpful 'cause its readable e.g. intuitive - DTD's aint' folks and never will be.. So rather than worry about it, I create an application level XML tag and then place entries for each attribute for my own application. I am not trying to pursue STANDARDS. I am interested in STANDARDS when the parser folks can improve their interaction with my applications. A while ago I brought up EVENT handling which I feel is essential to getting more power from the parser but that met a big THUNK with the people on this group at that time. So, for my apps, after the XML parser has validated the entries via DTD, I can use a more granular application level XML approach. For example, to validate the XML entry and its several attributes, I have this 'validate' method hanging around for my application. At some point I could go back and build the DTD from this information and let the parser do the error checking, but this was faster for me to build into my application for right now than trying to grok the DTD stuff. And I don't see how the parser is going to handle the issues right now that more errors/rules brings to the table. I am using Python and the code to validate this was very short and easy to implement. Maybe 50 lines. I would see more benefit in using the parser if there was clearer interactions between the parser and the real world application. Most parsers take a document centric approach while I am working more data driven where I use bits of XML all through the processing of the application. So I want to be able to control just when this level of validation is done for example. BTW, can you find the INVALID XML on this page based on this syntax? I suspect other folks are doing something similar here to get things going: IMHO, this approach is more readable as well as more flexible than the DTD. Can someone point me to the status of using XML for this kind of validation is done? Again, if the PARSER's said they could do something more with the DTD than just complain when an error occurred, it would be more helpful to me. I know that the nascent XML editors need the DTDs so in the long term I'll have to go back and support that. ...bryan F. Bryan Cooper 707 823 7324 707 313 0355 fax VERITAS Software 707 321 3301 mobile Bryan.Cooper@veritas.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990513/ff1086e5/attachment.htm From jlatone at fantastic.com Thu May 13 21:13:43 1999 From: jlatone at fantastic.com (Joseph A. Latone) Date: Mon Jun 7 17:11:59 2004 Subject: Guidelines to describe an User Interface ? In-Reply-To: <37382930.D6F2952E@darmstadt.gmd.de> Message-ID: <000201be9d74$9c212e60$030a0a0a@cub> As well as a couple products http://www.viewsoft.com http://www.harmonia.com Joe > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Robb Shecter > Sent: Tuesday, May 11, 1999 5:57 AM > Cc: XML Developers' List > Subject: Re: Guidelines to describe an User Interface ? > > > Hi, > > You might also want to check out: > > http://www.bluestone.com/xml/XwingML/ > http://www.pierlou.com/prototype > http://cs.nyu.edu/phd_students/fuchs/ > > - Robb > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From terje at in-progress.com Thu May 13 21:54:22 1999 From: terje at in-progress.com (Terje Norderhaug) Date: Mon Jun 7 17:11:59 2004 Subject: Again wit da AND and Repetitions Message-ID: At 11:36 AM 5/13/99, roddey@us.ibm.com wrote: >I never really had any one say whether they thought that validation that >included both AND connectors and M to N repetition for any of the connectors is >feasible (meaning fast and compact and maintainable and verifiable in my >opinion, but tell me if you disagree.) > >Does anyone believe that these can be done in less than brute force tree search >times? XML requires deterministic content models. This allows validators to do their job without having to look more than one element ahead or do brute force tree searches. -- Terje | Media Design in*Progress Software for Mac Web Professionals at Take advantage of XML with Emile, the first XML editor for Mac. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Thu May 13 21:56:00 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:11:59 2004 Subject: Singletons in a DTD In-Reply-To: Message-ID: <3.0.1.32.19990513113709.009953a0@mail.accessone.com> Would (S1? | S2? | S3? | (C1 | C2 | C3)*) work? Dave LeBlanc At 10:40 AM 5/13/99 -0700, Terje Norderhaug wrote: >At 8:46 AM 5/13/99, Joshua E. Smith wrote: >>I have an element which can contain 0 or more instances of some element >>types (call these collections), and 0 or 1 instances of others (call these >>singletons), and I don't want to contrain the order. >> >>If I have collections C1, C2, C3 >>and I have singletons S1, S2, S3 >> >>And I declare: >> >>(S1? , S2? , S3? , (C1 | C2 | C3)*) >> >>Then the singletons, if they appear, would have to be in that order and >>would have to be first. So that's not what I want. >> >>I suppose I could declare some combinatorics: >> >>( S1? | S2? | S3? | (S1 , S2)? | (S2 , S1)? | (S1 , S3)? blah blah blah >> >>but I'd have to mix in the C1, C2, C3, etc., too, and I have about 8 >>singleton classes, so this would quickly get totally out of control. >> >>Am I missing something, or is what I want to describe not really practical >>in a DTD? I'm perfectly comfortable leaving the singletonness out of my >>DTD (my application will detect duplication errors anyway), if that's the >>only answer. But if there *is* a way to capture this without waiting for >>XSchema to be finished, I'd love to hear it! > >The AND '&' connector in SGML covered this functionality, but isn't >included in XML. It can thus easily be described in a DTD, just not an >*XML* DTD. > > >-- Terje | Media Design in*Progress > > Software for Mac Web Professionals at > Take advantage of XML with Emile, the first XML editor for Mac. > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 22:28:09 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:59 2004 Subject: XML::Parser In-Reply-To: <011c01beb5c9$6cabb980$15b36d80@cnidr.org> References: <011c01beb5c9$6cabb980$15b36d80@cnidr.org> Message-ID: * Travis Walsh | | I'm running XML:Parser 2.20 on linux. | | All of the newlines are stripped when I run a CharHandler. Should | this be happening and how can I stop it? If you mean then, yes, the XML recommendation requires it to be replaced with (except that pairs go to a single ). See section 2.11 in the XML recommendation for the details on this. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Thu May 13 22:30:39 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:59 2004 Subject: Again wit da AND and Repetitions References: <87256770.006634D9.00@d53mta03h.boulder.ibm.com> Message-ID: <373B3624.48F2287D@pacbell.net> roddey@us.ibm.com wrote: > > Does anyone believe that these can be done in less than brute force tree search > times? Since it can obviously be turned into a DFA, it can be as efficient as a DFA (linear time). Though compiling a content model into a DFA is not consistently cheap, and I wonder how many folk will care to implement it both correctly and efficiently. My issue is the wisdom of having such features. They're not necessary, and the particular sort of "feature creep" I see happening now with XML is a worry to me. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu May 13 22:40:36 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:11:59 2004 Subject: Again wit da AND and Repetitions References: <87256770.006634D9.00@d53mta03h.boulder.ibm.com> Message-ID: <373B38AD.CDDE6D69@locke.ccil.org> roddey@us.ibm.com wrote: > What are the feelings of some folks who implemented SGML validators? If you had > to start with that and add NtoM repetition on top of that, where would that have > taken you? Or did SGML already provide both of these things? If so, what was the > general architecture used in some common ones? Why is the sky blue? IIRC the canonical way of doing (A & B & C) is to transform it into (A | B | C)* and then do a post-check that each of A, B, C appears exactly once. As opposed to brute-force expansion into a DFA. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu May 13 22:54:20 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:11:59 2004 Subject: Again wit da AND and Repetitions In-Reply-To: <373B3624.48F2287D@pacbell.net> References: <87256770.006634D9.00@d53mta03h.boulder.ibm.com> Message-ID: <199905132053.QAA26618@hesketh.net> At 01:29 PM 5/13/99 -0700, David Brownell wrote: >My issue is the wisdom of having such features. They're not >necessary, and the particular sort of "feature creep" I see >happening now with XML is a worry to me. Someone posted a long time ago that XML would be best off if it shrank consistently from version to version rather than sprouting new features. I don't remember who it was, but I wish their wisdom would guide future XML development. Right now, it looks like we're aiming for a baroque period in XML. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Thu May 13 23:45:59 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:11:59 2004 Subject: XML::Parser References: <011c01beb5c9$6cabb980$15b36d80@cnidr.org> Message-ID: <373B47C0.2465DE36@pacbell.net> Lars Marius Garshol wrote: > > * Travis Walsh > | > | I'm running XML:Parser 2.20 on linux. > | > | All of the newlines are stripped when I run a CharHandler. Should > | this be happening and how can I stop it? > > If you mean then, yes, the XML recommendation requires it to be > replaced with (except that pairs go to a single ). > > See section 2.11 in the XML recommendation for the details on this. Careful. 2.11 applies to line ends: CR, CRLF, and LF are all mapped to a single LF. But if a CRLF constructed using character reference (as in your text above) won't be covered by 2.11 !! For example, see section 2.3.3 re attribute value normalization, which makes clear that you can emit a literal CRLF; and similarly 4.5 re construction of internal entity replacement texts. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 13 23:50:50 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:11:59 2004 Subject: Again wit da AND and Repetitions In-Reply-To: References: Message-ID: * roddey@us.ibm.com | | I never really had any one say whether they thought that validation | that included both AND connectors and M to N repetition for any of | the connectors is feasible (meaning fast and compact and | maintainable and verifiable in my opinion, but tell me if you | disagree.) | | Does anyone believe that these can be done in less than brute force | tree search times? I think so, yes. From skimming through the draft once and thinking a little about it I think it will cost noticeably more than normal validation, though. At least for my parser it seems that it will. My best idea so far is to create tracker objects that move through the content model as you parse the document. This is just a sketch in my head, though, and nothing is written or coded yet. (I'm currently working on support for datatypes and haven't gotten round to the structural schemas yet.) * Terje Norderhaug | | XML requires deterministic content models. This allows validators to | do their job without having to look more than one element ahead or | do brute force tree searches. Determinism doesn't have anything to do with it. You can still easily create deterministic finite state automata for XML content models (as described in DTDs, that is). Since the tags in XML remove any chances of ambiguity this doesn't cause any ambiguity in interpreting the markup. In fact, I need to add special code to my parser in order to warn about non-deterministic ones. In theory, you can do the same for what is described in the XML schemas specification, but in many cases you'll then be looking at a combinatorial explosion of automaton states. In fact, with DTDs like the XTEILITE DTD things can get pretty bad as it is. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri May 14 01:01:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:59 2004 Subject: XLink: behavior must go! References: <012801be9d1b$87ed3460$dac566c3@sgml.u-net.com> Message-ID: <373AE4A6.228BBEDB@prescod.net> Martin Bryan wrote: > > Behaviour *must* stay. Behaviour in general, yes. Behavior attributes in XLink? Not in my opinion. > What we need is some mechanism for passing through behaviour > control properties from the instance to the XSLT. XSLT already has features for retrieving attributes. We don't need to do anything special for behavior. From my minimalist point of view the only extensions we need for XSLT are the ability to recognize and traverse anchors and links and the ability to control flow between a linking template rule and an ordinary template rule. > The behaviour > attribute provides us with a standardized point which we can query from > within XSLT to determine which types of behaviour a particular > instance of an object should have. The XSLT is inherently tied to a document type. So why would we need to standardize the attribute name used for specifying behavior? There is no problem if you want to call it martin:behavior and I want to call it paul:behavior. In fact, that is good, because you can call it "popup_yes_or_no" and I can call it "javascript_command" depending on the semantics of our respective document types. The last thing we want is to have a single attribute called behavior where you put "yes-popup-it-up" and I put "this.popup()" and to have browsers trying to guess the semantics of the behavior attribute. We should either standardize it completely or not at all. > (Paul is right to say this is really a "hints" > thing -but it is something more than a hint - it is a set of parameters that > can be used to control behaviour where appropriate.) In most document types it is *not* appropriate for the author to control behavior directly at all for exactly the same reason that it is not appropriate for them to control presentation (which is really a kind of behavior anyhow). In the minority where it is appropriate you can either use adhoc mechanisms like those described above ("popup_yes_or_no") or even define standards built on top of XLink ("BehaviorLinks"). We have to be very careful what goes in which level. You want xml:behavior in XML. Someone in the XSL list wants xml:script. Typographers are going to want xml:font. All of these are specific to either a particular document type or maybe a set of document types and should be specified in higher layers. > No we could not! In the first place XSL is not defining a GUI. In what sense is XSL not defining a GUI? > In the second > we could not begin to guess what the *user* requires. What if the user is > blind? None of your suggested behaviours would be of the least use. That isn't true: popup menus are meaningful to blind people. But even so we could have other hotspot object types for other media. That's exactly why we have to move it into a stylesheet. > What if > the behaviour said "convert this instances of of invoices to > euros before display" or "use the current exchange rate to express any > prices in the linked document in the user's local currency"? What > if the behaviour said "If this instance of the message is selected do > not allow > the user to select another of the listed options"? XSL has extension mechanisms both in the XSL transformation and (I think) in the generated document. > Again its a question of who is in control. We need to leave > authors with the right to make choices without having to be > stylesheet designers. You sound like the people who tell me that XML sucks compared to Word because it takes control away from the author. Usually taking away control is the goal. Then you give back control in the stylesheet. That's the whole basis for descriptive markup. If, in some particular case, you need to put control right into the document type you do that by creating a stylesheet that puts the right level of control in the document. Nothing stops you from making a element type or a element type. Just don't put either in the core language (or linking language) please! > One attribute to do this, rather than a whole set of customizable > ones that change from environment to environment is the only way we are > going to get transportable interactive documents. You and I agree that various document types have differnet behavioral needs. We agree that there is no way that we can define everything that needs to be done in advance. I think that we agree that usually behavior should be defined in stylesheets, though there are a few cases where it should be defined inline. You demand that when it is inline it should always be expressed in the same attribute. I claim that this will interfere with the goal of extensibility and interoperability. It would be like requiring every XML document type to have a "para" element type. If we disagreed on the meaning and structure of paragraphs (which we inevitably will) then the common element type name is useless. Some people will be lulled into thinking we have interoperability but when we actually try to apply our stylesheets or programs to each others documents they would crash. Instead, we should all choose our own names for paragraphs and the mere act of making that choice will make clear that we are actually expecting our paragraph types to have different *content*. Same with the behavior attribute. We should only have common attributes if we can decide in advance what the structure of the content will be. Otherwise let's not present an illusion of interoperability. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri May 14 01:05:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:11:59 2004 Subject: PIs in xml:schema References: <3.0.32.19990512163835.011c52a0@pop.intergate.bc.ca> <002101be9cd7$9989d000$bb96fea9@w21tp> <373A227F.96A1186B@prescod.net> <004201be9cf7$984b9d20$7dcbfea9@w21tp> Message-ID: <373B1C30.5A93DF8C@prescod.net> Don Park wrote: > > I entirely agree with your opinion. Liam's view is that of concern over > misuse where I am more concerned with functionality. I believe XML > community can benefit from a guideline for proper use of PI as well as some > mechanism for registering PI target names. Meanwhile we need to encourage > HTML browsers to recognize PI so that we do not lose this important feature > of XML. Let me reiterate that in my mind the best way to handle this would be to allow these floating element types in XML schemas. So in a sense I am for the removal of PIs ... once they are properly replaced. I can think of an element-syntax replacement that would be far superior. Here is the beginning of a specification: The big problem with PIs is that they are not declared, namespace managed or internally structured (according to XML). Our replacement would have to allow a document to declare that it was using XHTML with "style binding inclusion extensions" or "xyz formatter page break extensions" or "zyx editor cursor position extensions". The fundamental characteristic of a floating element type is that an application that did not know about the floating element type could choose not to see elements of that type or their content. In this case the term "application" includes stylesheets and schemas. Further, it should be possible to identify a floating element type without reading the document's schema(s) -- or even reading the schema for the element type. As a very (very) rough strawperson proposal, lets say that we have a declaration: This syntax should be aligned with a) the NS spec, b) the xml:schema declaration syntax and c) the xml:schema ns/schema importation syntax. For now, we'll use this syntax. This declaration would say: a) elements in this namespace are floating elements b) they should conform to the referenced schema Floating elements would be invisible to the "main" schema and to each other. So conceptually a different instance of the schema processor would be required for each included schema. Some layer between SAX and a "float smart" application (including an XSL processor, XML Schema validator or DOM engine) would filter out floating elements that had not been specifically requested. You could register with the layer what floating elements you are interested in or simply ask for all of them. Stylesheets would register for the floating elements that they are interested in and only see those and no others. This is superior to PIs because today PIs mess up things like node-list-first...you might think that the title of a chapter would be its first node but not if there is a PI there! DOM-based applications would register recognized float schemas with the DOM-constructor (or ask for them all). Helper functions/methods would allow filtering at runtime. If we had all of this then I don't see why we would need the " Message-ID: <373B1DC1.7BA94F9C@prescod.net> Jonathan Borden wrote: > > Is there anything within XLink itself that cannot be replaced by XSLT > now that doc() and docref() have been defined? Does XLink not become > something akin to a standard set of XSLT templates used for handling URI > traversal? doc() and docref(), as well as unification with XPointer turn > XSLT into a generalized graph transformation language. Could the XLink spec > itself become an XSLT include file? Yes. I outlined the features that XSL would require in order to allow link recognition in the first message. It must be possible to ask the XSL processor whether an element is an anchor (not a link), what the other anchors are and what the properties of the linking element are. In other words the XSL processor must itself be able to recognize and traverse links. This really isn't a lot of work and I feel that it should go into XSLT version 1 but I suspect that the behavior attributes confused everybody (as they did me for a long time). Those attributes were well-intentioned but after a lot of thought I've come to the conclusion that they were a mistake. It took me more than a year to come to figure that out but I'm pretty confident now. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri May 14 02:04:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:00 2004 Subject: XLink: behavior must go! References: <3.0.5.32.19990513083325.00c8fb80@corp> Message-ID: <373B1E94.2F9B361D@prescod.net> Walter Underwood wrote: > > I agree that they mix presentation and structure, but I also > feel that it is worthwhile to capture some common situations. > That is, allow people to define link "roles", but start out > with a few standard roles. This is analogous to including > xml:lang in the XML spec. These are two very different things: link types and anchor roles are semantic, not behavioral. I have no problem with a few pre-defined roles though I can't think of many common ones. > I'm hunting down a copy of the PCTE rationale, since it has a > nice description of the link roles in PCTE, and how they got > to that design. Good idea. > Meanwhile, maybe I should write a NOTE proposing a PI analogous > to the robots meta tag (). Another good idea. Published layered conventions are better than "builtins". Too many builtins turn out to be not very useful "standalone" is a perfect example. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Fri May 14 02:55:34 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:12:00 2004 Subject: Singletons in a DTD In-Reply-To: <3.0.1.32.19990513113709.009953a0@mail.accessone.com> References: Message-ID: <3.0.1.32.19990513205127.0117db30@tiac.net> At 11:37 AM 5/13/99 -0700, David LeBlanc wrote: >Would (S1? | S2? | S3? | (C1 | C2 | C3)*) work? Nope. That would allow only one of S1, S2, or S3. I need to allow up to one of each, in any order. As was pointed out in a separate, but coincidentally related, thread, you'd have to put a * at the end of that, which suddenly loses singletonness. Alas. But I guess the & syntax from SGML is deceptively simple. I don't completely follow that other thread, but I gather it's hard to implement which is probably why they left it out of XML. -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From liamquin at interlog.com Fri May 14 03:03:32 1999 From: liamquin at interlog.com (Liam R. E. Quin) Date: Mon Jun 7 17:12:00 2004 Subject: What is W3C's official position on use of PI? In-Reply-To: <373A227F.96A1186B@prescod.net> Message-ID: On Wed, 12 May 1999, Paul Prescod wrote: Paul Prescod wrote: > Don Park wrote: > > Thanks for clearing that up. Do you what the folks who "regard PIs as > > problematic second-class syntax" recommend for first-class out-of-band > > signaling mechanism? I wouldn't mind giving up PI if there was an > > alternative. > > Well, Liam Quin has been a constant critic of processing instructions. Heh... I always wanted to be remembered for something :-) > http://www.mulberrytech.com/xsl/xsl-list/archive/msg03388.html > http://www.lists.ic.ac.uk/hypermail/xml-dev/9811/0203.html Well, if you read these -- especially the second -- you'll see that they are not arguments against processing instructions. The 2nd article argues against using a processing instruction to link a document to its style sheet in a way that was incompatible with the then current XLink draft, and also incompatible with the DOM. > [Paul's] response: > http://www.mulberrytech.com/xsl/xsl-list/archive/msg03396.html > > As I said in that message, the important thing about processing > instructions is that they are invisible to content models. Yes. This can be good and bad. There's been a tendency in the SGML world to use them like significant comments -- if you've ever seen a large document with scattered all over it, you'll know what I mean. The usual reaction is that people in such environments write scripts to remove all the processing instructions. > If XML Schemas > invented a way to make elements invisible to content models (like SGML's > inclusion exceptions, but maybe only allowed at the top level) and a way > to add these inclusions to existing schemas easily then processing > instructions could be replaced by these "floating", element types. That > would be neat. I agree, and in some ways this could be where namespaces go, I think. > But if there are no floating element types then we still need processing > instructions. Well, you don't need them in a formal sense, but I agree there there is very strong motivation for them :-) Lee -- Liam Quin, independent SGML/XML/Unix/perl consultant l i a m q u i n at i n t e r l o g dot c o 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri May 14 03:37:18 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:00 2004 Subject: auto/embed is not node transclusion References: <373964B5.73572354@prescod.net> <373AFD0D.B06C392E@nsc.com> Message-ID: <373B73F5.D1F11205@prescod.net> [hopefully of interest to the three lists referenced...] Rick Geimer wrote: > > While I agree in principle with the notion that it is generally a bad idea to > create markup that specifies a behavior, there are many real world examples > where this is the only practical thing to do. I agree. > I will use as an example the > exchange standard for the Semiconductor industry, ECIX (formerly known a > Pinnacles, or PCIS). > > ... > > For this to work, the standard had to specify a element with a > predefined behavior, i.e. take the contents of the element who's id matches > the reflection's idref and redisplay it inline at the location of the > reflection element...the same idea as show="embed" and actuate="auto", if I > understand XLINK correctly. I don't think you do understand XLink correctly. Many people make this mistake. I did for a long time myself. I presume that the semantic of the "reflection" element is node-level transclusion. In other words, applications (not just browsers) built on top of Pinnacles probably act as if that other element has been copied element for element, character for character, etc. XLink doesn't support that. XLink describes a data model that includes concepts of "anchor" and "link." It does not have a concept of either text-level or node-level transclusion. First let me define node-level transclusion: node level transclusion is a transformation from a source grove (DOM, information set, whatever) to a result grove (...) that creates a result where the result grove has some nodes replaced by nodes reference by those nodes. This would have well-defined implications for hypertext links, APIs, stylesheet languages and so forth. In other words, it would be *well-defined*. A few months ago I started defining a transclusion mechanism for XML but there is a problem with differentiation references to the pre- and post- transformation document. I'm not clear if the XML world is ready to accept the fact that this kind of hard problem requires an equivalent to the grove model to be solved. My impression is that the W3C is not properly constituted to handle abstractions instead of languages but the information set project provides partial evidence that this might not be the case. Now let demonstrate that XLink does not provide transclusion. First, it does not specify a data model for the result of a transformation. Second, the things it links to are not restricted to XML elements. In other words, XLink can embed JPEGs, MPEGs and other data that does not have a concept of nodes (unless we import the ISO concept of groves and property sets for them). Therefore we *cannot* in general interpret the grove mode in terms of a grove to grove transformation. You could argue that I am being a purist. Embedding PDFs or JPEGs would "probably" have the behavior of just *displaying* them inline but embedding an XML element would have the behavior of node-level transcluding it. Browsers would "probably" implement it compatibly. Are you comfortable with these probably's and with trusting the like-mindedness and good will of browser vendors? If so, let me ask a few questions: * what if someone does NOT want node-level transclusion but instead want XML documents and elements to get the same kind of figure-style transclusion that PDFs or graphics would get? * what does the input of an auto/embed transclusion look like from the stylesheet or DOM? * what does an idref-based hyperlink into the embedded document look like? What does it mean if the inclusion duplicates an ID? * how do you reference (from an XPointer) the reference-defining element instead of the referenced element in the result tree? * is the validity of the resulting document checked? is a valid referent of an XPointer that is restricted to pointing to *valid* documents of a particular type? * does user/embed mean that when you "invoke" the link the document structure changes? Should stylesheets be automatically reapplied? Does the DOM change? etc. I am not very confident of interoperable implementations by the major browser vendors. Personally, I feel that I would rather wait for a real transclusion mechanism even if it means I have to wait for a W3C grove model and addressing mechanism that can differentiate a reference to an input document from a reference to the result document. If you want to use a stylesheet to *render* auto/embed as node-level transclusion (and answer all of these questions in your stylesheet) then you certainly can. But the transformation you have chosen is not at all mandated by the XLink specification. Someone else could implement it differently and be just as right (or wrong) as you. So is half a standard better than none? Debatable. When it comes to linking, XLink does everything you need. Without behavior it is a beautifully small, simple and complete specification. > I don't think it would be appropriate for a standard to mandate a particular > stylesheet language along with the markup to make this work (though the only > way I have been able to get this to work with any XML tools today is with > XSL). Nor do I. I think we need real node-level transclusion desperately. I also think that it is a hard problem that must be solved properly after implementing the proper logical infrastructure. XLink doesn't do it and it probably wasn't meant to. Transclusion and linking are different. Their underlying data models are different. Linking is about describing a relationship between two nodes. The data model is "link", "locator", "anchor". Transclusion is about building a new grove from an old one. The data model is about "source tree" and "result tree." If XLink was meant to be interpreted as node-level transclusion then either the XLink or XPointer specification would mandate the meaning of a reference into a transclusion-expanded document. > If this > kind of link behavior can be specified in a standard way with XLINK, all the > better. I hope by now that I have demonstrated that it cannot be. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Fri May 14 07:51:41 1999 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:12:00 2004 Subject: XLink: behavior must go! Message-ID: <003701be9dcd$ade560e0$2ec566c3@sgml.u-net.com> Jonathon Borden wrote: > Is there anything within XLink itself that cannot be replaced by XSLT >now that doc() and docref() have been defined? Does XLink not become >something akin to a standard set of XSLT templates used for handling URI >traversal? doc() and docref(), as well as unification with XPointer turn >XSLT into a generalized graph transformation language. Could the XLink spec >itself become an XSLT include file? I expect that doc() and/or doc(ref) can be used to implement XLink, but not to specify what is to be linked to within the source document. You still need some generalized technique to identify when the included templates should be applied. (I still have problems with working out how docref() can be used to process the query part of an URL though!) Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 14 09:03:25 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:00 2004 Subject: Again wit da AND and Repetitions In-Reply-To: <373B38AD.CDDE6D69@locke.ccil.org> References: <87256770.006634D9.00@d53mta03h.boulder.ibm.com> <373B38AD.CDDE6D69@locke.ccil.org> Message-ID: * John Cowan | | IIRC the canonical way of doing (A & B & C) is to transform it into | (A | B | C)* and then do a post-check that each of A, B, C appears | exactly once. As opposed to brute-force expansion into a DFA. Hmmm. It sounds as if this could be extended to handle {n,m}A as well. Just transform it into A+ (or *, depending on n) and do a post-check that the number is correct. In fact, this solution looks relatively easy to implement. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri May 14 10:35:41 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:12:00 2004 Subject: A milestone in XML Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A18CF@eukbant101.ericsson.se> > -----Original Message----- > From: Jeffrey Ricker [SMTP:ricker@xmls.com] > > Dave, > Why did Netscape feel it necessary to invent RSS rather than use CDF as > Microsoft, DataChannel, PointCast, etc. do? > > Perhaps because CDF isn't XML? http://msdn.microsoft.com/workshop/delivery/channel/cdf1/cdf1.asp http://msdn.microsoft.com/workshop/delivery/cdf/reference/xml.asp Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri May 14 11:11:11 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:12:00 2004 Subject: Again wit da AND and Repetitions Message-ID: <93CB64052F94D211BC5D0010A800133170EE7B@wwmess3.bra01.icl.co.uk> > XML requires deterministic content models. This allows > validators to do their job without having to look more than one element ahead > or do brute force tree searches. It's not what XML requires that counts, it's what users require. What you're saying is that if you have an integrity constraint that XML parsers are congenitally incapable of enforcing, you had better implement it yourself, the hard way, in the application. I don't remember SQL ever adopting the view that the only integrity constraints you were allowed to specify were those that could be evaluated in linear time. In fact, the refusal to build implementation-based limitations into the language was one of the major reasons for the success of SQL. (In implementing GedML I discovered that the integrity constraints that I could specify in the DTD were such a pathetic subset of the total that I might as well do all the validation in the application and ignore the DTD capabilities entirely - especially as I had no way via the SAX API of knowing whether the parser had done any validation or not). 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Fri May 14 11:46:36 1999 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:12:00 2004 Subject: XLink: behavior must go! Message-ID: <012601be9dee$81cfa940$2ec566c3@sgml.u-net.com> Paul Prescod wrote: >You and I agree that various document types have differnet behavioral needs. We agree that there is no way that we can define everything that needs to be done in advance. I think that we agree that usually behavior should be defined in stylesheets, though there are a few cases where it should be defined inline. Not my words. I think that there are times when you want to be able to contol the behaviour inline, not define the behaviour inline. I want to provide a declarative property, not a procedural one. >You demand that when it is inline it should always be expressed in the same attribute. I claim that this will interfere with the goal of extensibility and interoperability. Only if we have a common attribute will we be able to share processing modules among applications. My goal is to be able to have processing modules that I can import into any XSL stylesheet that processes a document using XLinks to allow me to link from the request for data to my local (or external) databases, undertaking appropriate transformations to turn the data stored in the warehouse into the form that the author of the document wants it. While I can introduce your suggested martin:behaviour attributes into my DTD I cannot introduce them into someone elses DTD. If I am using an industry standard DTD that uses XLinks how can I control standardized processes that are known to work in my environment Saying I should just change stylesheets does not necessarily work as it depends on where control of stylesheet association takes place. At present we have not mechanism for local overrides of stylesheets. What I want is a mechanism that will allow me to control the working of imported sytlesheet modules on an instance by instance basis, without having to write special instances of stylesheets for each document instance. Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ldodds at ingenta.com Fri May 14 12:24:34 1999 From: ldodds at ingenta.com (Leigh Dodds) Date: Mon Jun 7 17:12:00 2004 Subject: Multiple(?) / Reuse of Parsers Message-ID: <000f01be9df3$db69a460$ab20268a@pc-lrd.bath.ac.uk> Hi, I'm currently working with an application that uses both DOM and SAX for parsing XML. The application creates a DOM representation of a document, and then uses the SAX api to parse a second document using the event driven interface. Currently I'm creating two parsers. One for the DOM representation, and one for the SAX parsing (SAXParser and DOMParser classes in XML4J). The latest version of this parser allows multiple parsers to be created (just downloading, so haven't tested it yet), but am I right in thinking that this isn't generally true for other parsers? Also, *should* I create a second parser when parsing the second document (through SAX), or can I reuse the first parser once the DOM representation has been created? I'm concerned there may be some 'gotchas'. I'm going to be reading the DOM representation based on the events from the SAX style parse. The 2.0.6. version of XML4J gives me a "InputSource stack out-of-sync" message at the moment - which I think may be because I'm creating two parsers which it doesn't support - hence the download of 2.0.9. which I'm about to try. Any thoughts, suggestions? Cheers, L. ================================================================== "Never Do With More, What Can Be Achieved With Less" ---William of Occam ================================================================== Leigh Dodds Eml: ldodds@ingenta.com ingenta ltd Tel: +44 1225 826619 BUCS Building, University of Bath Fax: +44 1225 826283 ================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Fri May 14 14:09:24 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:00 2004 Subject: Fw: XLink: behavior must go! Message-ID: <006c01be9e02$33294b20$5402a8c0@oren.capella.co.il> The Xlink thread is fascinating because it is a concrete manifestation of an abstract issue dealt in other threads (e.g. the OO/scripting thread). Viewed this way, I think the argument tends to Paul's side. XML is not a programming language; it is a data language. The "behavior" attribute doesn't sit well in a data language. Paul's alternative - allow attaching arbitrary attributes to an XLink, with application specific semantics - makes much more sense. Given the semantics of "behavior" is already application specific, why insist on a fixed name? This is only a way to ensure namespace problems. Much better to have "myapp:behavior"; this way you know the exact semantics of the attribute with no ambiguity, or know that you can't parse this specific attribute. Martin Bryan wrote: >Paul Prescod wrote: >>You and I agree that various document types have differnet behavioral >>needs. We agree that there is no way that we can define everything that >>needs to be done in advance. I think that we agree that usually behavior >>should be defined in stylesheets, though there are a few cases where it >>should be defined inline. Well, at least I agree :-) >Not my words. I think that there are times when you want to be able to >contol the behaviour inline, not define the behaviour inline. I want to >provide a declarative property, not a procedural one. Any attempt to "control the behavior inline" means "give an algorithm fot handling this link" and while this may be done decleratively, it is way out of scope for XML. >>You demand that when it is inline it should >>always be expressed in the same attribute. I claim that this will >>interfere with the goal of extensibility and interoperability. > >Only if we have a common attribute will we be able to share processing >modules among applications. My goal is to be able to have processing modules >that I can import into any XSL stylesheet that processes a document using >XLinks to allow me to link from the request for data to my local (or >external) databases, undertaking appropriate transformations to turn the >data stored in the warehouse into the form that the author of the document >wants it. Here's the core of the problem. XML is trying to hold a very long stick at both ends. On the one hand, we want to be able to define domain-specific tag sets and attributes; on the other hand we want universal clients to process them. Something has to give. The current solution is to require clients to process a well-know small set of standard XML languages (e.g., XSL FOs), and have someone provide an XSLT "stylesheet" (horrible name) to convert the input document into one of them. This allows XML itself to be domain-neutral, and still allow for universal clients. So far so good. What Martin is pushing for is making the "stylesheet" itself - or at least parts of it - universal. This is a misguided goal IMVHO. It is on par to requiring standard XML elements for "author", "title", "version", ... to ease document retreival. The way I see it, if XML is to define any form of predefined elements or attributes these had better be elements or attributes which are useful and _have the same semantics_ for each possible application. Otherwise, don't bother. >While I can introduce your suggested martin:behaviour attributes into my DTD >I cannot introduce them into someone elses DTD. Actually, someone else can refer to your "martin:behavior" attribute in his DTD (well, assuming namespace enabled DTDs but that's a separate issue). People could set standards for such attributes in particular domains - for example, "browser:behavior" as opposed to "vlsi:behavior" or "publishing:behavior" - assuming 'browser', 'vlsi' and 'publishing' refer to appropriate URIs, of course. Note I'm not enthused by "javascript:behavior", since it is inconsistent with the XML-as-data-language view. >If I am using an industry >standard DTD that uses XLinks how can I control standardized processes that >are known to work in my environment No, you can use an industry-standard DTD to good effect - it is just that the industry in question isn't "the XML industry"; instead it might be "the XML browsing industry", and the standard isn't "XML", it is "XML as used in browsers". There's simply no way a browser will be able to correctly handle links whose behavior is specific to vlsi design process, unless someone explicitly codes a stylesheet which explains how to do so. Having a fixed name would only make the life of the stylesheet writer that much more difficult - if not downright impossible. >Saying I should just change stylesheets does not necessarily work as it >depends on where control of stylesheet association takes place. At present >we have not mechanism for local overrides of stylesheets. What I want is a >mechanism that will allow me to control the working of imported sytlesheet >modules on an instance by instance basis, without having to write special >instances of stylesheets for each document instance. That's a valid concern, but it has little to do with the XLink proposal and the behavior attribute. Here CSS has an advantage over XSLT - it is much easier to provide overrides in CSS then it is in XSLT. Of course, if you are a member of the XML -> XSLT -> XML + CSS camp, then there's your (partial) solution... The way I see it, the code vs. data debate hasn't been settled yet. The current accepted technology, HTML, is a hybrid of both and therefore nobody likes it. XML is on the pure data side, but its success is yet to be seen. Java is on the code's side, and its success is also not clear (the Jini project, for example, demonstrates what this approach can achieve if seriously adopted). The ultimate test of both approaches is trying to use a document/object in a system it wasn't designed for. After all, there's no such thing as a "universal: client - it either displays on the screen, or activates speakers, or prints, or modifies databases, or something. The code approach is less suitable for adapting to unexpected applications. Given a pieces of java code which draws on the screen, it is very difficult to convert it to code reading text on the speakers or writing to a database record - unless it was designed with that in mind in the first place, of course. But the data approach is only slightly better; it keeps the data the same, but needs a new stylesheet per each application (for example, one for viewing on the screen and one for playing over speakers). How likely is it that people will bother to provide an aural stylesheet for their XML language? The best solution is to define standard languages/interfaces allowing the same data/code to be shared across applications. This works equally well for both approaches, but is very difficult to do. Hitting the right level of abstraction for combining domains (e.g., display and speech) is very difficult (hint: FOs are not the right level :-). Again, the data approach has a slight advantage here - since one only needs to specify the "data" and not the "behavior" specific to the application, it already starts more general. Which brings us back to why "behavior" must go :-) Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri May 14 15:41:32 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:00 2004 Subject: auto/embed is not node transclusion In-Reply-To: <373B73F5.D1F11205@prescod.net> Message-ID: <001c01be9e0e$50a25820$1b19da18@ne.mediaone.net> Paul Prescod wrote: > > Now let demonstrate that XLink does not provide transclusion. First, it > does not specify a data model for the result of a transformation. Second, > the things it links to are not restricted to XML elements. In other words, > XLink can embed JPEGs, MPEGs and other data that does not have a concept > of nodes (unless we import the ISO concept of groves and property sets for > them). Therefore we *cannot* in general interpret the grove mode in terms > of a grove to grove transformation. This is an excellent point. In XSLT 6.2.2 the issue of doc(uri) pointing to something other than an XML node is noted as an unresolved editorial point. > > You could argue that I am being a purist. Embedding PDFs or JPEGs would > "probably" have the behavior of just *displaying* them inline but > embedding an XML element would have the behavior of node-level > transcluding it. Browsers would "probably" implement it compatibly. Would links to binary resources have the same status as NOTATION's in terms of the XML information set? A set of notations could map to the returned content-type and a browser would deal with such a 'notation' in the same mechanism that a MIME content-type is dealt with (e.g. in-line, plug-in etc). > > I am not very confident of interoperable implementations by the major > browser vendors. Personally, I feel that I would rather wait for a real > transclusion mechanism even if it means I have to wait for a W3C grove > model and addressing mechanism that can differentiate a reference to an > input document from a reference to the result document. Or, we can adopt the ISO grove model once the XML property set/information set is defined. Is there any reason to reinvent the wheel in terms of groves? Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ldodds at ingenta.com Fri May 14 15:51:03 1999 From: ldodds at ingenta.com (Leigh Dodds) Date: Mon Jun 7 17:12:00 2004 Subject: Content model probs Message-ID: <000a01be9e10$abcf2fa0$ab20268a@pc-lrd.bath.ac.uk> Hi, I've being toying with a content model now and I think my brain must be overloaded because I can't think of the best way to format it so it'll parse. Basically I want to say that a tag should: 1. Contain #PCDATA, *OR* 2. an optional tag X followed by zero or more occurences of tag Y I had thought something like : (#PCDATA|(X?, Y*) but that doesn't seem to parse. At the moment I've had to settle on (#PCDATA|X|Y)* just so I can continue working, and manually check for the moment that I'm building documents which I consider legal. Any of you XML gurus got any suggestions? Thanks! L. p.s. A variation I'd also like to consider is changing the model such that 2. (above) becomes: 2. zero or more occurences of X, followed by zero or more occurences of Y. In this case X,Y can be interspersed. In the former, X *must* be before Y if its provided. ================================================================== "Never Do With More, What Can Be Achieved With Less" ---William of Occam ================================================================== Leigh Dodds Eml: ldodds@ingenta.com ingenta ltd Tel: +44 1225 826619 BUCS Building, University of Bath Fax: +44 1225 826283 ================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Fri May 14 16:05:43 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:12:00 2004 Subject: Content model probs In-Reply-To: Leigh Dodds's message of Fri, 14 May 1999 14:50:05 +0100 Message-ID: <199905141405.PAA05704@stevenson.cogsci.ed.ac.uk> > 1. Contain #PCDATA, *OR* > 2. an optional tag X followed by zero or more occurences of tag Y Can't be done. Content models that include #PCDATA and elements are restricted to the form (#PCDATA|x|y|...)*. > At the moment I've had to settle on (#PCDATA|X|Y)* Yes, that's the best you can do. If you want to do better, you will need to have two different element types for the two cases. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Fri May 14 16:17:32 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:00 2004 Subject: Again wit da AND and Repetitions Message-ID: <01BE9DF3.3509EFD0@cc398234-a.etntwn1.nj.home.com> John Cowan wrote: "IIRC the canonical way of doing (A & B & C) is to transform it into (A | B | C)* and then do a post-check that each of A, B, C appears exactly once. ..." It seems that this approach would require the parser to perform look ahead for the following content model: ( (A & B & C), C, C, C ) This content model would be transformed into: ( (A | B | C)*, C, C, C ) The transformed content model is non-deterministic. For example, the parser would have to look ahead when parsing the first C in the following input: C B A C C C The original content model is deterministic; the parser would not have to look ahead to determine that the first C (in C B A C C C) matches the (A & B & C) portion of the original content model. Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Fri May 14 18:52:09 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:01 2004 Subject: Multiple(?) / Reuse of Parsers References: <000f01be9df3$db69a460$ab20268a@pc-lrd.bath.ac.uk> Message-ID: <373C546B.346A0BE5@pacbell.net> As it says in the SAX spec for the "Parser" interface: SAX parsers are reusable but not re-entrant: the application may reuse a parser object (possibly with a different input source) once the first parse has completed successfully, but it may not invoke the parse() methods recursively within a parse. So, reusing the parser must be OK. Re should you be able to create more than one -- certainly. Complain to any parser vendor that doesn't let you do that; there's no reason to prevent that from being done, it's rather basic functionality. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 14 19:03:54 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:12:01 2004 Subject: XML validation Message-ID: <004701be9e23$b793bff0$2ff96d8c@NT.JELLIFFE.COM.AU> From: Bryan Cooper > In any case, what I feel is that its EASIER for me to setup an XML validation > thang than what I see as a separate syntax in the DTD world I am not particularly proposing a syntax: using semi-BNF things like XML content models or putting them in element syntax wasnt my point. (And, certainly, I am not saying that validation needs to be done at the XML processor, which is your other point.) My point is there are lots of other structures in an XML document which at the moment cannot be validated. Newbies ask a predictable set of questions: first "can I have required but in any order?" (e.g., SGML's &), then "can I specify that if I have a size attribute you must also specify a units attribute?". And in SGML people wished there was a way to constrain internal links to particular kinds of elements. I think these would be useful and inexpensive forms of validation to have (I think that was the point of your 50 lines of Python comment). If we already have validator code that checks a DOM NodeList (the element's contents), I don't know why it would be so difficult to have validators to check the NamedNodeMaps (attributes), and to check what is at the other end of an IDREF (or even an XLink for that matter). The XML Schema:Structures draft seems too conservative in this area: if it doesnt give substantial advantages over markup declarations I dont see the point: a little nicer improvement to content models for database support and an enormous increase in size. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sean at westcar.com Fri May 14 19:10:09 1999 From: sean at westcar.com (Sean Brown) Date: Mon Jun 7 17:12:01 2004 Subject: Icon Contest Results Message-ID: <3.0.6.32.19990514130946.00916620@mail.javanet.com> The results have been tabulated. Thanks to everyone involved! http://www.javanet.com/~sbrown/icons.html -Sean xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tconway at walldata.com Fri May 14 19:15:44 1999 From: tconway at walldata.com (tconway@walldata.com) Date: Mon Jun 7 17:12:01 2004 Subject: Content model probs Message-ID: You could define something like Message-ID: <3.0.1.32.19990514133735.0106a488@tiac.net> Ooooh, pretty! What's the intellectual property status of it? It strikes me that you might want to squeeze a TM on there someplace, and license it's use freely provided everything they are using it on is compliant/conformant to the spec (probably just well-formed, not necessarily valid, dontchathink?). Maybe someone over at Gnu will help you write the license, even. That way, the XML blunders in IE5 would prevent MS from using it until they get their act together. -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From streich at wpsi.com Fri May 14 20:03:46 1999 From: streich at wpsi.com (Robert Streich) Date: Mon Jun 7 17:12:01 2004 Subject: auto/embed is not node transclusion In-Reply-To: <373B73F5.D1F11205@prescod.net> Message-ID: <000501be9e34$21da5f80$de64a8c0@laptop-ros.wpsi.com> > First let me define node-level transclusion: node level transclusion is a > transformation from a source grove (DOM, information set, whatever) to a > result grove (...) that creates a result where the result grove has some > nodes replaced by nodes reference by those nodes. This would have > well-defined implications for hypertext links, APIs, stylesheet languages > and so forth. In other words, it would be *well-defined*. I think your definition here is wrong, Paul. "Transclusion" as described by Nelson would effectively link two groves. You can't copy the nodes into your own grove, you have to traverse to the grove that contains the transclusion and then traverse back at the end of it. The difference between transclusion and inclusion is that the context of the transcluded content is still retained. In Nelson's application model, transclusions opened a viewport that was nested inside your document. This way you could scroll above and below the transcluded content to see its original context. But I do agree with your original statement--auto/embed is not node transclusion. bob Robert Streich Work Process Systems, Inc. Houston, TX xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri May 14 20:42:30 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:01 2004 Subject: auto/embed is not node transclusion References: <000501be9e34$21da5f80$de64a8c0@laptop-ros.wpsi.com> Message-ID: <373C6D11.4ED384E7@locke.ccil.org> Robert Streich wrote: > In Nelson's application model, > transclusions opened a viewport that was nested inside your document. This > way you could scroll above and below the transcluded content to see its > original context. Sounds like the HTML 4.0 IFRAME element. AFAIK, IE 4.x and 5.x implement this, but no version of Netscape does yet. (Maybe Mozilla, I don't know.) You can see such a thing at http://www.ccil.org/~cowan/XML/RDF-made-easy.html , which transcludes Tim Bray's intro to RDF. If your browser doesn't grok IFRAME, you get a "Wouldn't it be nice if I could transclude here" message. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri May 14 20:45:01 1999 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:12:01 2004 Subject: auto/embed is not node transclusion In-Reply-To: Your message of "Fri, 14 May 1999 13:03:55 CDT." <000501be9e34$21da5f80$de64a8c0@laptop-ros.wpsi.com> Message-ID: <199905141842.UAA25024@chimay.loria.fr> Please, stop cross-posting... Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Marc.McDonald at Design-Intelligence.com Sat May 15 00:12:16 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:12:01 2004 Subject: Again wit da AND and Repetitions Message-ID: <4454C011BDE5D211B6C800609776E5400B6AB3@master.design-intelligence.com> > XML requires deterministic content models. This allows > validators to do their job without having to look more than one element ahead > or do brute force tree searches. The validator may not have to look more than 1 element ahead, but it does need to look elements behind or construct a tree representation for the pattern due to optional elements: With an input of elements c, d, e, f, h in element x. Marc B McDonald Principal Software Scientist Design Intelligence, Inc www.design-intelligence.com ---------- From: Kay Michael [SMTP:Michael.Kay@icl.com] Sent: Friday, May 14, 1999 2:11 AM To: xml-dev@ic.ac.uk Subject: RE: Again wit da AND and Repetitions > XML requires deterministic content models. This allows > validators to do their job without having to look more than one element ahead > or do brute force tree searches. It's not what XML requires that counts, it's what users require. What you're saying is that if you have an integrity constraint that XML parsers are congenitally incapable of enforcing, you had better implement it yourself, the hard way, in the application. I don't remember SQL ever adopting the view that the only integrity constraints you were allowed to specify were those that could be evaluated in linear time. In fact, the refusal to build implementation-based limitations into the language was one of the major reasons for the success of SQL. (In implementing GedML I discovered that the integrity constraints that I could specify in the DTD were such a pathetic subset of the total that I might as well do all the validation in the application and ignore the DTD capabilities entirely - especially as I had no way via the SAX API of knowing whether the parser had done any validation or not). 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Sat May 15 01:54:40 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:01 2004 Subject: Again wit da AND and Repetitions References: <4454C011BDE5D211B6C800609776E5400B6AB3@master.design-intelligence.com> Message-ID: <373CB780.AD87D279@pacbell.net> Marc.McDonald@Design-Intelligence.com wrote: > > > XML requires deterministic content models. This allows > > validators to do their job without having to look more > > than one element ahead > > or do brute force tree searches. > > The validator may not have to look more than 1 element ahead, but it does > need to look elements behind or construct a tree representation for the > pattern due to optional elements: > > > > > > With an input of elements c, d, e, f, h in element x. Actually, the content model for "x" is in error there, so any XML processor is allowed to report an error however rudely it chooses to do so. That content model is "ambigious". - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat May 15 02:12:50 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:12:01 2004 Subject: Again wit da AND and Repetitions Message-ID: <87256772.00010C7D.00@d53mta03h.boulder.ibm.com> >>Does anyone believe that these can be done in less than brute force tree search >>times? > >XML requires deterministic content models. This allows validators to do >their job without having to look more than one element ahead or do brute >force tree searches. > Actually it does not require deterministic models, it just allows you to check for them. And, I guess its not really what XML does or does not do that's in question here, its what the new upcoming schema spec proposes to do that's at issue. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat May 15 02:14:40 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:01 2004 Subject: Fw: XLink: behavior must go! References: <006c01be9e02$33294b20$5402a8c0@oren.capella.co.il> Message-ID: <373CB9E9.9CDFBFB0@prescod.net> Oren Ben-Kiki wrote: > > Note I'm not enthused by "javascript:behavior", > since it is inconsistent with the XML-as-data-language view. I am also not enthused by that idea. I am pandering^H^H^H^H^H^H^H^H demonstrating that the stylesheet-centric idea is still compatible with an ultimately flexible, inline behavioral definition. Whether that definition is compatible with good design is another question. > The way I see it, the code vs. data debate hasn't been settled yet. The > current accepted technology, HTML, is a hybrid of both and therefore nobody > likes it. XML is on the pure data side, but its success is yet to be seen. > Java is on the code's side, and its success is also not clear (the Jini > project, for example, demonstrates what this approach can achieve if > seriously adopted). Could you outline what you consider to be the successes of Jini? The idea of my light switch communicating with my refrigerator via migrating Java objects strikes me as kewl but highly brittle. The declarative part of an API specification leaves so much unsaid. I would feel much more comfortable if I heard that Jini was a set of APIs *and* data formats. > The ultimate test of both approaches is trying to use a document/object in a > system it wasn't designed for. > >... > > The code approach is less suitable for adapting to unexpected applications. Hey, doesn't that mean "we win?" According to you the migrating objects mechanism is "almost" as good as migrating data but "almost" only counts in horseshoes and hand grenades. Seriously: One virtue of migrating objects is that you can build data-based solutions on top of them. You just tell your migrant objects to stay put and send messages instead. This means that the two can actually work together pretty nicely. The light switch doesn't have to send an object to define its capabilities: it can send a message. But it may be too complex to define the GUI for the object completely declaratively (maybe XUL isn't enough) so you could send some code instead. My problem is that most people don't understand that there is a spectrum and a conflict here. So they often go straight for the programmatic solution without verifying that a declarative solution is impossible. They sense that the programmatic solution is more powerful but don't recognize the long-term costs (a perfect example: the recent (informal) proposal). This leads to abominations such as Postscript, Display Postscript, .bashrc's etc. The Unix community in particular is going to have to come to grips with the idea that more powerful is not necessarily the same as better. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat May 15 02:14:47 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:01 2004 Subject: XLink: behavior must go! References: <012601be9dee$81cfa940$2ec566c3@sgml.u-net.com> Message-ID: <373CBA12.E4DA7C78@prescod.net> Martin Bryan wrote: > > Not my words. I think that there are times when you want to be able to > contol the behaviour inline, not define the behaviour inline. I want to > provide a declarative property, not a procedural one. I think some people are going to want a little of each. I don't advise either one in general but maybe in some cases it makes sense. > >You demand that when it is inline it should > > always be expressed in the same attribute. I claim that this will > > interfere with the goal of extensibility and interoperability. > > Only if we have a common attribute will we be able to share processing > modules among applications. If you define common values for the attribute then I will be able to evaluate the usefulness of your idea. But if you are just talking about a common attribute name then I'll refer you back to my argument that this is worse than nothing because it encourags people to make incompatible documents and pretend that they are compatible by virtue of the attribute names. How do I map attribute values to real, honest to goodness behaviors in my browser? I'm not clear what your proposal is nor how it relates to the behavior attributes in XLink today. > My goal is to be able to have processing modules > that I can import into any XSL stylesheet that processes a document using > XLinks to allow me to link from the request for data to my local (or > external) databases, undertaking appropriate transformations to turn the > data stored in the warehouse into the form that the author of the document > wants it. So you want the features of the whole grove model and API and you think that a single standardized attribute name is going to give it to you? Nevertheless, fetching data out of your database is not a behavior problem. Transforming nodes is not, according to my terminology "behavior". It is addressing or "viewing" or even "rendering". In the "web model" the way to do this is to define a new form of URL: sql://[select * from blah]. Of course the URL model does not have a way to turn that into nodes. That's why I say you need the grove model. I guess the "web way" to do this is: http://www.mysite.com/cgi-bin/fetchdata?select * from blah > While I can introduce your suggested martin:behaviour attributes into my DTD > I cannot introduce them into someone elses DTD. If that's true then that's a problem with DTDs or XMLSchema's. It is generally useful to be able to subtype and extend other people's DTDs. Architectural forms allow it but so will XMLSchema. > If I am using an industry > standard DTD that uses XLinks how can I control standardized processes that > are known to work in my environment If you are talking about fetching data then you should use CGIs or groves. Its an addressing problem, not a behavior problem. > Saying I should just change stylesheets does not necessarily work as it > depends on where control of stylesheet association takes place. At present > we have not mechanism for local overrides of stylesheets. What I want is a > mechanism that will allow me to control the working of imported sytlesheet > modules on an instance by instance basis, without having to write special > instances of stylesheets for each document instance. Once again you are talking about a flaw in another part of the system. I don't quite understand your need but it seems far afield of a behavior attribute. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat May 15 02:21:34 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:01 2004 Subject: What is W3C's official position on use of PI? References: Message-ID: <373CBA2E.7225B353@prescod.net> "Liam R. E. Quin" wrote: > > Yes. This can be good and bad. There's been a tendency in the SGML > world to use them like significant comments -- if you've ever seen a > large document with scattered all over it, you'll know > what I mean. The usual reaction is that people in such environments > write scripts to remove all the processing instructions. I tend to consider the term "significant comment" an oxymoron in the text processing context. If something is flagged as data-model-invisible it should be data-model-invisible -- completely. Still, in my classes I've borrowed your idea and turned it around. I say that comments (the familiar concept) are a type of processing instruction designed for the processor called the "human brain." Other software should not expect to understand them and should ignore them. > I agree, and in some ways this could be where namespaces go, I think. Please see my recent proposal in another message. I think it formalizes that idea. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mscardin at us.oracle.com Sat May 15 06:17:12 1999 From: mscardin at us.oracle.com (Mark Scardina) Date: Mon Jun 7 17:12:01 2004 Subject: ANN: Oracle XML Parser for Java v1.0.1.3 - Maintenance Message-ID: <000001be9e89$c73d15d0$cd1e2382@us.oracle.com> The first maintenance release of the Oracle XML Parser for Java is available for download at http://technet.oracle.com/tech/xml. This is a bug-fix release. The following are included features and specs: Supports validation and non-validation modes Built-in Error Recovery until fatal error. Supports DTD Caching for improved performance. Supports W3C XML 1.0 Recommendation. Intergrated Document Object Model (DOM) Level 1.0 API Integrated SAX 1.0 API Supports W3C Proposed Recomendation for XML Namespaces Supports documents in the following encodings: UTF-8 BIG 5 UTF-16 GB2312 ISO-10646-UCS-2 EUC-JP ISO-10646-UCS-4 EUC-KR US-ASCII KOI8-R EBCDIC-CP-* ISO-2022-JP ISO-8859-1to -9 ISO-2022-KR Shift_JIS Support is available in the XML Forum on OTN to provide a collaborative area for bug reporting, technical support, and discussing other Oracle/XML issues. This forum will be used for external as well as internal beta testers. Mark V. Scardina Sr. Product Manager - Core and XML Development Server Technologies - Oracle Corporation Oracle XML News http://www.oracle.com/xml xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Sat May 15 12:25:22 1999 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:12:01 2004 Subject: XLink: behavior must go! Message-ID: <005701be9ebd$165c2e20$25c566c3@sgml.u-net.com> Oren Ben-Kiki wrote: >you can use an industry-standard DTD to good effect - it is just that the industry in question isn't "the XML industry"; instead it might be "the XML browsing industry", and the standard isn't "XML", it is "XML as used in browsers". There's simply no way a browser will be able to correctly handle links whose behavior is specific to vlsi design process, unless someone explicitly codes a stylesheet which explains how to do so. The problem I am trying to deal with is not related to "the XML industry" or "the XML browser industry" - instead it relates to a set of DTDs that share common-features which apply to a wide range of applications shared by a wide range of industries. If we are to develop sharable toolsets we need to develop sharable architectures. The key point is that I want, in the longer term, to replace the current practice of relentlessly copying data from one message to another (up to 10 times in some processes) with a process that allows linking to the original source of the data. The way this will be done will depend on the type of the data being linked to and on the local conditions for access to original documents. OK, I can define a generalized architecture that would be widely used for this purpose, and call it edi:behaviour, but as this is widely required by others why not also have it as a standard mechanism for passing link instance dependent information to the link processor? It should not be necessary to have individual stylesheets for individual instances of messages. It should not be necessary to redefine processes for each DTD that uses the shared information. We need to import standardized modules that will process standardized namespaces of elements in ways that depend on the conditions applying at the point at which the located data is to be retrieved from. Paul Prescod wrote: >So you want the features of the whole grove model and API and you think that a single standardized attribute name is going to give it to you? I have given up hope of getting an extensible grove model (note the key word at the beginning) or a proper API for managing the associations between XSLT and XML document instances (note that it is the instance I worry about, not its formal model). This is why I want to introduce, as a stop gap, a single architectural form that will apply to one class of objects in which I know from experience there is a particular problem. I would dearly love a better thought-out, long term solution based on proper architectural form definition, but in the meantime need to retain the stop-gap attribute to manage link processing. Don't throw out the bathwater until you know you have something to give the baby to drink. [They have just announced that they have cut the water supply to my house, which made me think of this variant of the metaphor!] Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Sat May 15 01:54:40 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:01 2004 Subject: Again wit da AND and Repetitions References: <4454C011BDE5D211B6C800609776E5400B6AB3@master.design-intelligence.com> Message-ID: <373CB780.AD87D279@pacbell.net> A non-text attachment was scrubbed... Name: not available Type: Size: 1602 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990515/1b07fccb/attachment.bat From dave at userland.com Sat May 15 16:08:13 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:12:02 2004 Subject: A milestone in XML In-Reply-To: <5F052F2A01FBD11184F00008C7A4A800022A18CF@eukbant101.ericss on.se> Message-ID: <4.2.0.37.19990515070125.01c95b90@mail.userland.com> I haven't answered this question because I don't know the answer. Who knows how anyone else thinks? Especially a big corporation that's just been acquired by an even bigger corporation? Anyway, from my POV, CDF is a dead horse. We did some work with it when it first came out, but it seemed fairly useless and never went anywhere that I could see. Beyond that, I have not got a clue what CDF was supposed to do that anyone wanted. RSS on the other hand is quite useful, and lots of people are getting on the RSS train, so of course we supported it enthusiastically. That's the big picture from where I sit. Dave At 01:36 AM 5/14/99 , Matthew Sergeant (EML) wrote: > > -----Original Message----- > > From: Jeffrey Ricker [SMTP:ricker@xmls.com] > > > > Dave, > > Why did Netscape feel it necessary to invent RSS rather than use CDF as > > Microsoft, DataChannel, PointCast, etc. do? > > > > > Perhaps because CDF isn't XML? > > http://msdn.microsoft.com/workshop/delivery/channel/cdf1/cdf1.asp > http://msdn.microsoft.com/workshop/delivery/cdf/reference/xml.asp > > Matt. > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on >CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Sat May 15 16:36:15 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:02 2004 Subject: A milestone in XML In-Reply-To: <4.2.0.37.19990515070125.01c95b90@mail.userland.com> Message-ID: Hi Dave, Hummmm, I understand that you have a very subjective view of it. Its OK, we can have subjective views as long as we don't state that they are objective :-) My own subjective opinion. Don't expect competing species to respect a common standard especially if a would be standard has been brought by the competitor. It just gives a clue that XML don't resolve the unity of languages. Contrary to that it encourage diversity and everybody can invent its own language. This is why, now just for channel or topic handling you have (just a few of what's out there) - CDF - RSS - RDF - topic maps In fact, what's marvelous about XML is that now each one can invent its own HTML :-) or its own meta data language. Seriously speaking, RSS is popular in the Netscape ecosystem and CDF in the Microsoft ecosystem. Which one is better? Its a question of: in which ecosystem you are. Never expect a Netscape specie to tell you that CDF is good and do not expect a Microsoft specie to tell you that RSS is good. Only some rare species living in both ecosystems can tell you that both do the job and in fact are about the same as long as you have the right interpreter to decode the language. And that the main perceive quality is dependant on the interpreter quality and how data is presented. And even o this subject, taste differ. And this is good. Its only a matter of ecosystem, taste and often a question of religion :-) My own religion tell me that I cannot use CDF or RSS because big money is reincarnated into these products :-)))) just kidding :-))) regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Dave Winer Sent: Saturday, May 15, 1999 10:04 AM To: xml-dev@ic.ac.uk Subject: RE: A milestone in XML I haven't answered this question because I don't know the answer. Who knows how anyone else thinks? Especially a big corporation that's just been acquired by an even bigger corporation? Anyway, from my POV, CDF is a dead horse. We did some work with it when it first came out, but it seemed fairly useless and never went anywhere that I could see. Beyond that, I have not got a clue what CDF was supposed to do that anyone wanted. RSS on the other hand is quite useful, and lots of people are getting on the RSS train, so of course we supported it enthusiastically. That's the big picture from where I sit. Dave At 01:36 AM 5/14/99 , Matthew Sergeant (EML) wrote: > > -----Original Message----- > > From: Jeffrey Ricker [SMTP:ricker@xmls.com] > > > > Dave, > > Why did Netscape feel it necessary to invent RSS rather than use CDF as > > Microsoft, DataChannel, PointCast, etc. do? > > > > > Perhaps because CDF isn't XML? > > http://msdn.microsoft.com/workshop/delivery/channel/cdf1/cdf1.asp > http://msdn.microsoft.com/workshop/delivery/cdf/reference/xml.asp > > Matt. > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on >CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sat May 15 20:19:21 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:02 2004 Subject: Again wit da AND and Repetitions In-Reply-To: <373CB780.AD87D279@pacbell.net> from "David Brownell" at May 14, 99 04:53:37 pm Message-ID: <199905151830.OAA29572@locke.ccil.org> Mark McDonald wrote: > > > > > > > > > > With an input of elements c, d, e, f, h in element x. And David Brownell replied: > Actually, the content model for "x" is in error there, so any > XML processor is allowed to report an error however rudely it > chooses to do so. That content model is "ambigious". I can only assume that both of you are suffering from brain farts. Any "x" that contains anything but an "a" or a "b" is obviously invalid. You are talking as if the above declarations were: Element declarations refer to lexically apparent objects (elements), not to mere groups of elements defined by pseudo-BNF. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat May 15 20:54:13 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:02 2004 Subject: auto/embed is not node transclusion References: <000501be9e34$21da5f80$de64a8c0@laptop-ros.wpsi.com> Message-ID: <373DC11D.951F775C@prescod.net> Robert Stretch wrote: > > The difference between transclusion and inclusion is that the context of the > transcluded content is still retained. In Nelson's application model, > transclusions opened a viewport that was nested inside your document. This > way you could scroll above and below the transcluded content to see its > original context. Thanks for point that out. I think that most people are more interested in the lower-level mechanism that we would call "node-level inclusion". Transclusion could (and arguably should) be built on top of inclusion. can be transformed into: -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jabuss at cessna.textron.com Sat May 15 21:59:06 1999 From: jabuss at cessna.textron.com (Buss, Jason A) Date: Mon Jun 7 17:12:02 2004 Subject: A milestone in XML Message-ID: > Wow... > > I guess this hadn't really occurred to me. This could get ugly quick. > Sure, browsers may support XML, but what if they build all these "extras" > based on their own DTD's into their development tools? RSS? CDF? They > may > throw all these features in, but have processing engines to handle all > these > special "extras" that may/may not work in eachother's browsers. Sounding > like DHTML all over again? Ugh...... > > Sure, they can do all this extra stuff at the chagrin of the development > and > standards communities, but when did that bother them in the past? They > could build all this "extra functionality" (read: proprietary) > functionality > into their browsers, the W3C group not give the "good developing seal of > approval" for XML, and where does it leave XML? Dead in the water. > > Maybe that would be a blessing in disguise... Maybe some rogue startup > could develop an open-source browser that embraces standards and is free > to > everyone (GNU? FSF?) and runs on all platforms and (at least attempts) to > support N'scape and IE's little "toys". Then if it wrestled enough market > share from the others, just start gradually "dumping" all those added > features, release by release. Of course, since I am dreaming, I would > like > a pony.... > > Anyway, standards are great, but only as great as their support in the > vendor world. We've gotten a lot of promises, but nothing written in > blood. > Hopefully, if we can get the general developers (webmasters, publishers) > to > start screaming as loud as the standards developers, PD software > developers, > and consultants, maybe they will listen. > > > Channels were a stupid idea anyway > > > good luck to all, > > -Jason > > > -----Original Message----- > > From: Didier PH Martin [SMTP:martind@netfolder.com > > > > Hummmm, I understand that you have a very subjective view of it. Its OK, > > we > > can have subjective views as long as we don't state that they are > > objective > > :-) > > > > My own subjective opinion. Don't expect competing species to respect a > > common standard especially if a would be standard has been brought by > the > > competitor. It just gives a clue that XML don't resolve the unity of > > languages. Contrary to that it encourage diversity and everybody can > > invent > > its own language. This is why, now just for channel or topic handling > you > > have (just a few of what's out there) > > - CDF > > - RSS > > - RDF > > - topic maps > > > > In fact, what's marvelous about XML is that now each one can invent its > > own > > HTML :-) or its own meta data language. > > > > Seriously speaking, RSS is popular in the Netscape ecosystem and CDF in > > the > > Microsoft ecosystem. Which one is better? Its a question of: in which > > ecosystem you are. Never expect a Netscape specie to tell you that CDF > is > > good and do not expect a Microsoft specie to tell you that RSS is good. > > Only > > some rare species living in both ecosystems can tell you that both do > the > > job and in fact are about the same as long as you have the right > > interpreter > > to decode the language. And that the main perceive quality is dependant > on > > the interpreter quality and how data is presented. And even o this > > subject, > > taste differ. And this is good. Its only a matter of ecosystem, taste > and > > often a question of religion :-) > > > > My own religion tell me that I cannot use CDF or RSS because big money > is > > reincarnated into these products :-)))) just kidding :-))) > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From terje at in-progress.com Sat May 15 22:03:33 1999 From: terje at in-progress.com (Terje Norderhaug) Date: Mon Jun 7 17:12:02 2004 Subject: Again wit da AND and Repetitions Message-ID: At 4:53 PM 5/14/99, David Brownell wrote: >Marc.McDonald@Design-Intelligence.com wrote: >> >> > XML requires deterministic content models. This allows >> > validators to do their job without having to look more >> > than one element ahead >> > or do brute force tree searches. >> >> The validator may not have to look more than 1 element ahead, but it does >> need to look elements behind or construct a tree representation for the >> pattern due to optional elements: >> >> >> >> >> >> With an input of elements c, d, e, f, h in element x. Not so, this isn't like BNF. The parser get the token for the start of the element 'x', making it use the content model for 'x' for further parsing. If the next token is a representation for the start of the 'a' element, it uses the content model for 'a' for further parsing. If the next token is an 'b', it uses the content model for the 'b' element for further parsing/validation. >Actually, the content model for "x" is in error there, so any >XML processor is allowed to report an error however rudely it >chooses to do so. That content model is "ambigious". What you had in mind is probably a declaration like this: However, this is ambigous as we won't know which sequence list we are in after parsing the start of a x element followed by a c element. It can be rewritten to a deterministic model though. -- Terje | Media Design in*Progress Software for Mac Web Professionals at Take advantage of XML with Emile, the first XML editor for Mac. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From terje at in-progress.com Sat May 15 22:17:34 1999 From: terje at in-progress.com (Terje Norderhaug) Date: Mon Jun 7 17:12:02 2004 Subject: Again wit da AND and Repetitions Message-ID: At 5:11 PM 5/14/99, roddey@us.ibm.com wrote: >>>Does anyone believe that these can be done in less than brute force tree >search >>>times? >> >>XML requires deterministic content models. This allows validators to do >>their job without having to look more than one element ahead or do brute >>force tree searches. > >Actually it does not require deterministic models, it just allows you to check >for them. And, I guess its not really what XML does or does not do that's in >question here, its what the new upcoming schema spec proposes to do that's at >issue. The XML 1.0 specification, 3.2.1 states that: "For compatability, it is an error if an element in the document can match more than one occurance of an element type in the content model". See also Appendix E to the specification, which describes in further detail what is meant by a deterministic and ambigous content model. It follows from the definition that a validating XML parser doesn't have to look ahead. This is important as it simplifies implementing validation. -- Terje | Media Design in*Progress Software for Mac Web Professionals at Take advantage of XML with Emile, the first XML editor for Mac. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From terje at in-progress.com Sat May 15 23:09:34 1999 From: terje at in-progress.com (Terje Norderhaug) Date: Mon Jun 7 17:12:02 2004 Subject: Again wit da AND and Repetitions / Singletons in a DTD Message-ID: At 5:51 PM 5/13/99, Joshua E. Smith wrote: >At 11:37 AM 5/13/99 -0700, David LeBlanc wrote: >>Would (S1? | S2? | S3? | (C1 | C2 | C3)*) work? > >Nope. That would allow only one of S1, S2, or S3. I need to allow up to >one of each, in any order. > >As was pointed out in a separate, but coincidentally related, thread, you'd >have to put a * at the end of that, which suddenly loses singletonness. Alas. > >But I guess the & syntax from SGML is deceptively simple. I don't >completely follow that other thread, but I gather it's hard to implement >which is probably why they left it out of XML. No, it is not particularly hard to implement support for the AND connector in a validating parser. However, the AND connector is redundant, as one can express the same using the other connectors (although not very elegant). For example, take the content model (A & B & C) expressing that we require the three elements in any order. Here is the XML equivalent content model: (A,((B,C)|(C,B))) | (B,((A,C)|(C,A))) | (C,((A,B)|(B,A))) Note that just permutating the elements in a sequence list is ambigous and thus not allowed: ((A,B,C)|(A,C,B)|(B,A,C)|(B,C,A)|(C,A,B)|(C,A,B)) A content model that uses AND connector can be converted into a proper XML content model using a simple algorithm. Thus, supporting the AND connector in an XML parser is at most as hard as writing the converter for the content model. This proves that supporting the AND connector isn't much harder than implementing the current connectors. However, there are better ways of implementing support for AND connectors than to convert AND content model into such tree structures. Simply make the parser keep track of which elements in the AND list have not yet been parsed. For each element encountered, remove its item from the list. Signal an error if the parser encounter an element not in the list of remainders, unless all of the remainding elements in the list are optional. Repeat until the list is empty or a parsed element is not in the list and all remainders are optional. This is how I implemented support for the AND connector in the validator of the Emile XML editor. We wanted to support the AND connector for backward compatability with HTML and other simple SGML document types. It allows Emile to load an HTML DTD into its XML authoring environment. The parser of course warns about that the AND connector isn't proper XML, but we think it is important to provide a bridge back to previous document formats for now. -- Terje Norderhaug President & Chief Technologist Media Design in*Progress San Diego, California Software for Mac Web Professionals at xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 15 23:33:50 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:02 2004 Subject: Again wit da AND and Repetitions / Singletons in a DTD In-Reply-To: References: Message-ID: * Terje Norderhaug | | For example, take the content model (A & B & C) expressing that we | require the three elements in any order. Here is the XML equivalent | content model: | | (A,((B,C)|(C,B))) | (B,((A,C)|(C,A))) | (C,((A,B)|(B,A))) The number of states here more or less follows n factorial, leaving the solution useless after 10 elements in a list or so. | [...] This proves that supporting the AND connector isn't much | harder than implementing the current connectors. Given infinitely long paper tapes, yes. :) | Simply make the parser keep track of which elements in the AND list | have not yet been parsed. For each element encountered, remove its | item from the list. [...] This is essentially the same solution that John Cowan mentioned earlier, and that I mused might be extended to cover the {m,n} modifier as well. However, I now see a potential problem with this in the presence of ambiguous content models. I've taken a different line with this compared to many of the others here, since I see no reason not to allow them (they cause no harm in XML). Furthermore, the recommendation only has a non-binding requirement that they be rejected. (I will warn about them, but that's another matter.) The problem is that if you generate a non-deterministic automaton from the weaker content model (A | B | ...)* and convert it to a deterministic one your deterministic states will be combinations of the non-d ones, which (I think) may mean that in some cases you won't know whether to enable the special & actions or not, since you don't know whether you're inside the & group or outside it. Does anyone know whether this really is a problem or not? --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 15 23:57:14 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:02 2004 Subject: Again wit da AND and Repetitions In-Reply-To: <01BE9DF3.3509EFD0@cc398234-a.etntwn1.nj.home.com> References: <01BE9DF3.3509EFD0@cc398234-a.etntwn1.nj.home.com> Message-ID: * John Cowan | | IIRC the canonical way of doing (A & B & C) is to transform it into | (A | B | C)* and then do a post-check that each of A, B, C appears | exactly once. ... * Robert C. Lyons | | It seems that this approach would require the parser to perform look ahead | for the following content model: | ( (A & B & C), C, C, C ) Nrgh. And I just posted a full page to say the same. Oh well. | This content model would be transformed into: ( (A | B | C)*, C, C, C ) | | The transformed content model is non-deterministic. [...] | | The original content model is deterministic; [...] Hmmm. As far as I can see this hints that if some other transformation were used this problem might be avoided. For example, ( ((A|B|C) , (A|B|C) , (A|B|C)), C, C, C ) does not have this problem. However, it does have the disagreeable property that it grows the content model by n squared, which will probably get intolerable somewhere around 200-300. Also, it gets you into trouble anyway if the original content model is ambiguous: ((A | B | C)*, (A & B & C), C, C, C) If you read one A you have no idea whether you're in the & group or not, regardless of how you transform it. Handling this latest content model seems like a real challenge to me. I think any viable approach will need to know when it reaches ((A | B | C)*, (A & B & C), C, C, C) ^ ^ 1 2 the states corresponding to 1 and 2 above, which as far as I can see effectively means resolving any ambiguities, which again seems to mean that lookaheads are required. (Or, alternatively, that you need to outlaw ambiguity in the original content model.) Please, someone, prove me wrong. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Sun May 16 00:08:08 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:02 2004 Subject: A milestone in XML In-Reply-To: <4.2.0.37.19990515070125.01c95b90@mail.userland.com> Message-ID: * Jeffrey Ricker | | Why did Netscape feel it necessary to invent RSS rather than use CDF | as Microsoft, DataChannel, PointCast, etc. do? When I first started looking at RSS I immediately noticed two things: a) it's incredibly simple (too simple, in fact) b) it's probably the most widely supported XML application so far, both in terms of software and content To me this smells like worse-is-better again, and I think that's a good answer to your question. I also think it's a useful lesson for the future. The success of most non-local XML applications is entirely dependent on their adoption by content providers, and previous experience seems to show that that very much depends on how easy it is to support. I would also conjecture that in most cases the software support depends on the content support. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sun May 16 00:45:02 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:12:02 2004 Subject: Again wit da AND and Repetitions / Singletons in a DTD Message-ID: <3.0.32.19990515154411.011dc8e0@pop.intergate.bc.ca> At 02:12 PM 5/15/99 -0700, Terje Norderhaug wrote: >No, it is not particularly hard to implement support for the AND connector >in a validating parser. In the first several generations of SGML parsing products, it was well-known that there were all sorts of bugs that were only observed when the & connector was being used. So the evidence doesn't support the claim above. This is exactly why it was left out of XML. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sun May 16 02:02:40 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:02 2004 Subject: John Cowan's comments on Structures draft Message-ID: <199905160014.UAA06714@locke.ccil.org> I want to thank the Schema WG for its hard work, and I realize that the following long list of comments can't be attended to right away, but I hope you are able to get to them all eventually (preferably by doing exactly what I want :-)). Note in clause 2.2: validation does not in fact contribute anything to the infoset. The things you mention (default attributes, attribute value normalization) are done by all processors whether validating or not, provided the relevant declarations appear in entities read by the processor. Non-validating processors are licensed not to read external entities, but not to ignore declarations in entities that they do read. elt-default: I think defaulted content is a fine idea. sic-elt-default: I agree with the "Preferred solution". namespace-declare (not speaking officially for infoset wg here): The trouble with making xmlns:foo attributes part of the infoset is that that locks in the name "foo", which is in effect a prefix and supposed to be changeable without affecting schema validity. I suggest you find a way to work around this problem. Clause 3.4.5: I associate myself fully with Paul Prescod's comments on removing the restrictions on mixed content: #PCDATA should be just a token, and whitespace where an element is expected simply doesn't affect validity. Definition of "full name" is very hard to understand. Please reword. Note in clause 3.4.9: I think any notion of implicit names is bogus. Please allow only explicit names. The "transclude" example: I don't think XLinks do transclusion, so a better name should be used. Clause 3.6: I associate myself with all others who denounce entity declarations in schemas, especially if they are allowed to satisfy otherwise unsatisfiable XML 1.0 entity references. Including them simply to superset DTDs perpetuates a design error made decades ago. Furthermore, nearly-well-formed XML is simply not XML, and XML WGs don't have any mandate for providing standards relating to non-XML. Clause 4.2: It seems strange to have an "export" element which exists (due to the default) primarily to declare what is *not* exported. Also, scattering individual export declarations through the schema in imitation of Java seems to me a mistake. I prefer the Common Lisp/Ada/ C++/etc. style where nothing is exported by default and where all *specific* objects to be exported are declared at the top of the schema. Clause 4.7: it would be useful to allow, at user option, schema processors to signal an error in case of a declaration conflict, instead of just ignoring all but the first. Conflicts may be the result of design errors rather than intentional overriding. Clause 4.8: the wording is bad here. "URI" means "URL or URN". If an URL is a string, so is an URI; if an URL is an abstract reference to what the string references, so is an URI. Calling a resolvable pointer an URL, and a potentially unresolvable one an URI, doesn't fit the facts. Clause 5: I propose that documentation be permitted as the first (optional) child element in every declaration, in the form of an "xhtml:body" element. XHTML, though not yet a Rec, is probably stable, and any instabilities reflect unintended discrepancies with HTML 4.0. Clause 6.1: The term "RUE" no longer appears in the Infoset-WD. Use "reference to unknown entity" instead. Better yet, demand that schema-validators must read all external entities, so that RUEs (by any name) are no longer an issue. I may have comments on the schema-schema or the schema-DTD later. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Sun May 16 10:32:24 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:03 2004 Subject: XLink: behavior must go! Message-ID: <012101be9f76$3bac2f90$5402a8c0@oren.capella.co.il> Paul Prescod wrote: >I wrote: >> The way I see it, the code vs. data debate hasn't been settled yet. The >> current accepted technology, HTML, is a hybrid of both and therefore nobody >> likes it. XML is on the pure data side, but its success is yet to be seen. >> Java is on the code's side, and its success is also not clear (the Jini >> project, for example, demonstrates what this approach can achieve if >> seriously adopted). > >Could you outline what you consider to be the successes of Jini? The idea >of my light switch communicating with my refrigerator via migrating Java >objects strikes me as kewl but highly brittle. The declarative part of an >API specification leaves so much unsaid. I would feel much more >comfortable if I heard that Jini was a set of APIs *and* data formats. I didn't say Jini had any successes yet :-) As to the potential, I'm less interested in the lightswitch talking to my refrigirator, as cool as that sounds. What I see in Jini is in the short term a way for practical zero (well, epsilon) administration for SOHO, and a way to do really neat things for mobile computing. In the long term, I simply love the idea of replacing the PCI bus with a 1000 ethernet micro hub. Instead of having a fat ugly box it is a hassle to upgrade, you have a small pile of cubes plugging into the network, which you can upgrade individually, just by plugging one out and plugging a new one in. USB and FireWire give some of this to an individual user; Jini can give it to a whole net. >> The ultimate test of both approaches is trying to use a document/object in a >> system it wasn't designed for. >> >>... >> >> The code approach is less suitable for adapting to unexpected applications. > >Hey, doesn't that mean "we win?" According to you the migrating objects >mechanism is "almost" as good as migrating data but "almost" only counts >in horseshoes and hand grenades. The code approach has one thing going for it - power. Consider an HTML page with embedded JavaScript. There's simply no way the same effect can be achieved with a pure data approach. We'll always have some of both. >Seriously: > >One virtue of migrating objects is that you can build data-based solutions >on top of them. You just tell your migrant objects to stay put and send >messages instead. You could make the reverse case - allow for migrating objects but wrap their API in terms of something like XML. Both approaches aren't exactly elegant. >My problem is that most people don't understand that there is a spectrum >and a conflict here. So they often go straight for the programmatic >solution without verifying that a declarative solution is impossible. They >sense that the programmatic solution is more powerful but don't recognize >the long-term costs (a perfect example: the recent (informal) >proposal). This leads to abominations such as Postscript, Display >Postscript, .bashrc's etc. First, it typically takes several years of experience with a programmatic approach before a good declerative approach can be formulated. The move from one to another is a sign of the maturity of the system. In fact you can view this in the evolution of programming languages themselves; much that was "programmatric" in older generations is "declerative" in newer ones. This shouldn't lead us into the trap of assuming that anything at all can be done "decleratively". A complex "declerative" language is worse then a simple "programmatic" one. For example, if printers used Prolog instead of PostScript (never mind the obvious inefficiencies), would that have made things better in any way? Hardly. As usual in these type of issues, what we'll see in the end is some sort of a hybrid system. Imagine an object oriented architecture with a clear seperation of data and code; data is specified in XML and code in Java or JavaScript, accessing the data via a DOM interface. The difference between it and HTML + JavaScript or simple migrating Java objects would be that the relationship between the code and the data would be much more clearly defined. Assuming that small issues of security, standard interfaces, standard and per-application libraries, version control, distribution etc. are resolved, such an architecture has the potential of being the ultimate "it". For example it could do anything Jini does, probably better. The role of the operating system would be reduced to offering the standard library. Network protocols would be reduced to a single one passing this sort of object. >The Unix community in particular is going to have to come to grips with >the idea that more powerful is not necessarily the same as better. Funny you should say that. UNIX has started with "almost everything is a file" approach and got pretty good results. Plan9 took it on to "really everything is a file" and got better results (technically). What I suggest above is similar in spirit to what may be called a PlanX approach - "everything is an XML document" - where the additional twist is "with some code attached", and "with a clear relationship between code and data". I don't see this as being against the UNIX spirit at all. Rather I see it as a natural evolution of its concepts. Not that I expect anything so clean and elegant to emerge from what humanity employs as a development process for its technology :-) Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Sun May 16 10:52:06 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:03 2004 Subject: XLink: behavior must go! Message-ID: <012601be9f78$fc60d950$5402a8c0@oren.capella.co.il> Martin Bryan wrote: >I wrote: >>you can use an industry-standard DTD to good effect - it is just that >the industry in question isn't "the XML industry"; instead it might be "the >XML browsing industry", and the standard isn't "XML", it is "XML as used in >browsers". There's simply no way a browser will be able to correctly handle >links whose behavior is specific to vlsi design process, unless someone >explicitly codes a stylesheet which explains how to do so. > >The problem I am trying to deal with is not related to "the XML industry" or >"the XML browser industry" - instead it relates to a set of DTDs that share >common-features which apply to a wide range of applications shared by a wide >range of industries. If we are to develop sharable toolsets we need to >develop sharable architectures. IMVHO, the problem is more with the lack of power in current DTDs. If it were possible to reuse DTD fragments, for example, containing the functionality you want, then the problem would have been solved. Moving the shared functionality directly into the XML standard works around this limitation, but I feel it is the wrong thing to do. >The key point is that I want, in the longer >term, to replace the current practice of relentlessly copying data from one >message to another (up to 10 times in some processes) with a process that >allows linking to the original source of the data. That's a good goal, I don't have any problem with it. >The way this will be done >will depend on the type of the data being linked to and on the local >conditions for access to original documents. OK, I can define a generalized >architecture that would be widely used for this purpose, and call it >edi:behaviour, but as this is widely required by others why not also have it >as a standard mechanism for passing link instance dependent information to >the link processor? If you can define a set of behaviors and make a good case that this set is applicable to the vast mojority of XML applications, they I'll gladly join you in lobbying for adding an 'xml:behavior' attribute to XLink with this set of values. In fact, I'm all for releasing XLink without a behavior attribute and creating a WG (or maybe placing it within the XLink WG mandate, whetever) dedicated to this attribute. IMVHO, we won't have a sensible notion of what to place in such an attribute until people will have some experience using XLink. Which means we'll have a year or so of 'my:behavior' and 'your:behavior'. After this year we'll see what is really common behavor, and release XLink 2.0 with 'xml:behavior' covering these cases. But even in this case, it should still be possible to add behaviors outside this set - 'my:behavior' will never disappear, even assuming the current specs. Actually, I can even accept 'behavior' as it stands today provided the specs say that this attribute is reserved, its valid set of values will be defined in a future version of the draft - effectively meaning that 'xml:behavior' has the priviliege of being called simply 'behavior'. Actually if there is one or two behaviors on which the WG could agree _today_, such as "include as an XML fragment within this document", then by all means release them in version 1.0. But release it! waiting another year for this issue to be resolved only harms the proposal. >It should not be necessary to have individual >stylesheets for individual instances of messages. >It should not be necessary >to redefine processes for each DTD that uses the shared information. Agreed; why do these follow from what Paul (and I) propose? >We need >to import standardized modules that will process standardized namespaces of >elements in ways that depend on the conditions applying at the point at >which the located data is to be retrieved from. The 'behavior' attribute as it is specified - or should I say, unspecified - today, does not give you this power. As long as it doesn't have a set of well-defined valid values, it is wores then useless. Have fun, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Sun May 16 11:02:38 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:03 2004 Subject: Icon Contest Results Message-ID: <015901be9f7a$7504fc00$5402a8c0@oren.capella.co.il> Nice (though not what I voted for :-). One suggestion, though. Suppose I use XSL to convert XML into XML + CSS. Which icon should be used, the XSL one or the CSS one? I'd rather there was an icon with both - how about using a magenta bar at the bottom, a combination of the CSS red and the XSL blue? Have fun, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Sat May 15 01:54:40 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:03 2004 Subject: Again wit da AND and Repetitions References: <4454C011BDE5D211B6C800609776E5400B6AB3@master.design-intelligence.com> Message-ID: <373CB780.AD87D279@pacbell.net> A non-text attachment was scrubbed... Name: not available Type: Size: 1602 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990515/1b07fccb/attachment-0001.bat From paul at prescod.net Sun May 16 16:05:25 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:03 2004 Subject: Content model probs References: <000a01be9e10$abcf2fa0$ab20268a@pc-lrd.bath.ac.uk> Message-ID: <373ECD73.B3134346@prescod.net> Leigh Dodds wrote: > > Basically I want to say that a tag should: > > 1. Contain #PCDATA, *OR* > 2. an optional tag X followed by zero or more occurences of tag Y > > I had thought something like : (#PCDATA|(X?, Y*) > but that doesn't seem to parse. This is disallowed in XML for historical reasons. In a recent message entitled "Mixed content considered harmful" (May 10), I proposed that this should change in the move to XML Schemas. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun May 16 16:31:54 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:12:03 2004 Subject: XML for Preferences Message-ID: <4.2.0.37.19990516071205.01c45100@mail.userland.com> We've come up with another excellent use for XML, to specify the interface for a web-based preference system. There are a lot of reasons why XML is the right choice here. First, it's understandable to people who write documentation. That means that the preferences wizard has a hope of being understandable to newcomers, since the system developer doesn't have to write the help text, and the work doesn't even need to be coordinated. The interactive part is just software, interpreting the content which is specified in XML. Also, you can render the same specification in a variety of different formats. For now, we're rendering as HTML, but it could just as easily be rendered in Flash, DHTML or as a Visual Basic "wizard". The concepts and the content are the same, but the engine running the content doesn't have to be. Further, if there were an agreement on how to specify preferences systems we could switch our deployment from Frontier to PHP or Zope or Oracle or Vignette, or whatever, and a lot of our content would just move with us by moving the preferences spec. In other words, this is an important place where a standard, defacto or standards-body-based, would enable growth and eliminate lock-in. ***Where we're at with this We have a running system at http://prefs.userland.com/. This is a live system, to access it you must be a member of userland.com, which is open to the public. If you're not a member, go to this page: http://logon.userland.com/, go thru the logon sequence, get the password via email, it should be self-explanatory. Sorry, there's no way to use this system without being a member. We won't do anything with your email address other than store it along with your password and preferences. ***Show me the XML! Now, there are two ways to see the XML spec behind this system. First you can directly access the XML page, thru this URL: http://prefs.userland.com/outline.xml Or you can see a screen shot of the editor: http://discuss.userland.com/msgReader$6316 Important point: Any XML editor can be used to edit this text. It does not have to be our outliner, which is a good XML editor. Any tool that can produce XML output will work fine. ***How to think of this It's a very lightweight thing. Any HTML coder can learn how to do this. It's not as powerful as Mozilla's XUL, but then it's a lot simpler than XUL. We looked at XUL before doing this, thinking perhaps that it would be a good starting point. We decided that it introduced a lot of unnecessary complexity for the people doing authoring, writers, explainers, users. We're doing this in the open. Maybe someone else wants to build on this idea? If so, please let me know. The spirit of XML is building on each others' work, that's why I keep telling you guys what we're doing. Keep diggin! Dave Winer UserLand 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun May 16 16:48:02 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:12:03 2004 Subject: A Milestone in XML Message-ID: <4.2.0.37.19990516074310.01c69450@mail.userland.com> >> a) it's incredibly simple (too simple, in fact) >> b) it's probably the most widely supported XML application so far,both in terms of software and content Both statements are true! That's why we're excited about RSS. It's a simple-enough beginning, and it has the backing of a portal, not just a company. That's where the rubber meets the road, AFAIK. RSS in fact is weaker than our own format, an example of which can be found here: http://news.userland.com/mostRecentScriptingNews.xml We've been able to build a great search engine off format, it's explained here: http://newssearch.userland.com/ Such a search engine is possible with RSS, and we will do it. It will be a very smart search engine because it will have human beings deciding what goes in it. So if you get to know an expert, and think he or she might know something about something you're interested in, just go to the search engine and ask. RSS, weak as it is from a technical standpoint, embodies a lot of the promise of XML. It's an excellent start. And it's proof that you don't have to grok all the computer science on the W3C site to be powerful with XML. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Sun May 16 20:57:09 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:03 2004 Subject: Again wit da AND and Repetitions References: <199905151830.OAA29572@locke.ccil.org> Message-ID: <373F14CA.58922DC6@pacbell.net> John Cowan wrote: > > Mark McDonald wrote: > > > > > > > > > > > > > > > > With an input of elements c, d, e, f, h in element x. > > And David Brownell replied: > > > Actually, the content model for "x" is in error there, so any > > XML processor is allowed to report an error however rudely it > > chooses to do so. That content model is "ambigious". > > I can only assume that both of you are suffering from brain farts. > Any "x" that contains anything but an "a" or a "b" is obviously > invalid. You are talking as if the above declarations were: > > > > > > Element declarations refer to lexically apparent objects (elements), > not to mere groups of elements defined by pseudo-BNF. Ah, yes ... I was reacting to the intent, not the exact wording! Thanks for catching that. There've been misstatements on this topic. The XML spec is clear that ambiguous content models are errors. What it does poorly is say exactly what that means; it basically boils down to a reality that documents better not have it, "or else". And any parser is free to do _whatever it wants_ when faced with such errors. - dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 qub.com Sun May 16 23:56:49 1999 From: paul at qub.com (Paul Tchistopolksii) Date: Mon Jun 7 17:12:03 2004 Subject: Announce. Some2XML alpha. Message-ID: <000f01be9fe7$54e04c00$7f02aace@g0f2n0> Hello. Available for download from http://www.pault.com Small perl script. The idea of Some2XML is to produce a well-formed XML documents from text files that already have some structure, even their original structure is not too much XML-alike. Rgds.Paul. paul@qub.com http://www.pault.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 17 00:23:51 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:12:03 2004 Subject: [Question] Re: XLink: behavior must go! In-Reply-To: <373CBA12.E4DA7C78@prescod.net> References: <012601be9dee$81cfa940$2ec566c3@sgml.u-net.com> Message-ID: <3.0.5.32.19990516182138.00b2c2b0@nexus.polaris.net> This thread's sort of calmed down in the last few days, but I've been wondering something. Would it be fair to say that the behavior attribute of an XLinking element is intended to function as a sort of localized (element-context-specific) PI -- a trigger to XLink-smart processors that is ignorable by others? If so, in what way is such an attribute more problematic than actual PIs? (Btw, as I said earlier, I agree with much of what Paul Prescod said in his opening post on the thread. This is just a matter of curiosity.) ========================================================== John E. Simpson | The secret of eternal youth simpson@polaris.net | is arrested development. http://www.flixml.org | -- Alice Roosevelt Longworth xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 17 01:30:06 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:03 2004 Subject: [Question] Re: XLink: behavior must go! References: <012601be9dee$81cfa940$2ec566c3@sgml.u-net.com> <3.0.5.32.19990516182138.00b2c2b0@nexus.polaris.net> Message-ID: <373F4F1F.C31962D5@prescod.net> "John E. Simpson" wrote: > > This thread's sort of calmed down in the last few days, but I've been > wondering something. > > Would it be fair to say that the behavior attribute of an XLinking element > is intended to function as a sort of localized (element-context-specific) > PI -- a trigger to XLink-smart processors that is ignorable by others? If > so, in what way is such an attribute more problematic than actual PIs? PIs have a rough namespace differentiation mechanism. You can look at a PI and know whether you handle it or not. (this mechanism should really be global and tied to "XML namespaces" but PIs are used infrequently enough that it should not be a problem) If a processor it sees how does the processor know which of the many programming language "plugins" it should be passed to? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Earth will soon support only survivor species -- dandelions, roaches, lizards, thistles, crows, rats. Not to mention 10 billion humans. - Planet of the Weeds, Harper's Magazine, October 1998 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon May 17 03:41:44 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:03 2004 Subject: [Question] Re: XLink: behavior must go! In-Reply-To: <373F4F1F.C31962D5@prescod.net> References: <012601be9dee$81cfa940$2ec566c3@sgml.u-net.com> <3.0.5.32.19990516182138.00b2c2b0@nexus.polaris.net> Message-ID: <4.0.1.19990516213553.01001560@207.211.141.31> At 06:05 PM 5/16/99 -0500, Paul Prescod wrote: >If a processor it sees how does the >processor know which of the many programming language "plugins" it should >be passed to? Hmm.... I didn't think it'd work quite like that. I figured BEHAVIOR would be an ordinary attribute - say, "popup" instead of "popup()", which the style sheet or other app-specific gizmo then converts to "popup()" as appropriate, knowing what the context was supposed to be. Sort of like a selector for CSS Action Sheets, if they get off the ground. I don't know if that would improve your opinion of BEHAVIOR any, but I can't say I find it as threatening as I would if I'd thought of it your way. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 17 04:37:34 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:12:03 2004 Subject: [Question] Re: XLink: behavior must go! In-Reply-To: <4.0.1.19990516213553.01001560@207.211.141.31> References: <373F4F1F.C31962D5@prescod.net> <012601be9dee$81cfa940$2ec566c3@sgml.u-net.com> <3.0.5.32.19990516182138.00b2c2b0@nexus.polaris.net> Message-ID: <3.0.5.32.19990516223717.007fb310@nexus.polaris.net> At 09:39 PM 05/16/1999 -0400, Simon St.Laurent wrote: >At 06:05 PM 5/16/99 -0500, Paul Prescod wrote: >>If a processor it sees how does the >>processor know which of the many programming language "plugins" it should >>be passed to? > >I figured BEHAVIOR would be an ordinary attribute - say, "popup" instead of >"popup()", which the style sheet or other app-specific gizmo then converts >to "popup()" as appropriate, knowing what the context was supposed to be. Aye. That's about what I was thinking, too. The XLink WD, such as it is, treats the behavior attribute rather gingerly. In 4.1.3 it says: A link author can also optionally use an attribute called behavior to communicate detailed instructions for traversal behavior. The contents, format, and meaning of this attribute are unconstrained. Later, in the intro to section 6 (Link Behavior), it says: In many cases, much finer control over the details of traversal behavior, of the type that existing hypertext software typically provides, will be desired. Such fine control of link behavior is outside the scope of this specification. However, the behavior attribute is provided as a standard place for authors to provide, and in which application software may look for, detailed behavioral instructions. And that's all it says about the behavior attribute. What seems to distinguish this from something like "behavior='popup'" -- with or without the parens -- is that the latter could be presumed to be fairly commonly desirable link behavior. I'm thinking that where a behavior attribute might really be useful would be something like: ...behavior="via:http://some.halfwaypoint.com/" whose meaning would be understood only by a special-purpose application that knows how the specified behavior inflects the meaning of the link. Any general-purpose application would simply treat the link in the "normal" way (whatever that turns out to be). And this kind of behavior -- like a page-break PI, and unlike (I think) the behavior specified in the show/actuate attributes -- wouldn't necessarily be best relegated to a style sheet or other external entity. It seems inherently "meaningful," and unable to be captured by any of the other XLinking attributes exactly because it is application-specific... not in an extension-to-XLink sense, but it its own right. But as usual, of course, this is like trying to read really grody entrails. ========================================================== John E. Simpson | The secret of eternal youth simpson@polaris.net | is arrested development. http://www.flixml.org | -- Alice Roosevelt Longworth xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Mon May 17 09:53:41 1999 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:12:03 2004 Subject: XLink: behavior must go! Message-ID: <009101bea03a$29f93da0$25c566c3@sgml.u-net.com> John E Simpson wrote >Would it be fair to say that the behavior attribute of an XLinking element is intended to function as a sort of localized (element-context-specific) PI -- a trigger to XLink-smart processors that is ignorable by others? If so, in what way is such an attribute more problematic than actual PIs? The key point about the behaviour attribute is that it is instance specific, rather than element-context-specific. (You can deal with all element-context-specific problems in the stylesheet; it is instance specific changes that are the difficult ones to control without passing some form of control parameter.) Oren Ben-Kiki wrote: >If you can define a set of behaviors and make a good case that this set is applicable to the vast mojority of XML applications, they I'll gladly join you in lobbying for adding an 'xml:behavior' attribute to XLink with this set of values. In fact, I'm all for releasing XLink without a behavior attribute and creating a WG (or maybe placing it within the XLink WG mandate, whetever) dedicated to this attribute. I do not believe that we are yet in a position to predefine the behaviours. These must be specified by particular industry groups, not by W3C. I am not convinced that the behaviours needed for the US Defense industry will be the same ones needed by the European healthcare industry (in fact I know they are different). Why should I seek to impose the requirements of one of these groups on the other? What is needed is a standard "point of reference" that people can know where to go for information. Suggestions like (made by Paul Prescod) are not what I had in mind - behaviour should not point to a procedure it should either pass parameters that can be used by procedures, e.g or better still, like namespace declarations, point to the source of the definition of the behaviour, e.g. . Note that the name of the parameter entity used to define behaviour is remote-resources-semantics.att - its the semantics we should be passing, not the calls. Note also the subtle change to the last example. Behaviour belongs on the locator rather than the link set. For simple links these are the same thing but for extended links this is not true. The key point is that for multiheaded links behaviour is controlled at link instance level. It is for multiheaded links that you need to control the behaviour of different members of the link set in different ways. Now to come to another point Ben made in response to my comments that: >It should not be necessary to have individual >stylesheets for individual instances of messages. >It should not be necessary >to redefine processes for each DTD that uses the shared information. Ben said: >Agreed; why do these follow from what Paul (and I) propose? I don't think they follow from what you have been saying, but they are something that has not been adequately thought through in the overall model of the XML family. Ben rightly suggested that we should used DTD fragments to define shareable resources. But how do you link sharable DTD fragments to sharable stylesheet fragments? How do you link stylesheets to local processes in a way that allow the local processes to be used with many different stylesheets, whenever a particular DTD fragment is invoked, and how do you provide user control over processes that are handled in multiple places. Remember that a multiheaded link is likely to be pointing to resources based on different servers, using different local processes to undertake business-related procedures that necessarily must be handled outside the stylesheet. I had said: >We need >to import standardized modules that will process standardized namespaces of >elements in ways that depend on the conditions applying at the point at >which the located data is to be retrieved from. Ben responded: >The 'behavior' attribute as it is specified - or should I say, unspecified - today, does not give you this power. As long as it doesn't have a set of well-defined valid values, it is wores then useless. I agree it is under-specified. I think it is too early (by 3-5 years rather than Ben's estimate of 1 year) to specify a decent set of acceptable procedures. I think the best we can do at present is to take the approach namespaces did - point to a resource that describes what is required and depend on the system having its own rules for resolving what that means. Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Mon May 17 11:38:22 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:04 2004 Subject: XLink: behavior must go! Message-ID: <007201bea048$9e4b0a40$5402a8c0@oren.capella.co.il> Martin Bryan wrote: >I wrote: > >>If you can define a set of behaviors and make a good case that this set is >applicable to the vast majority of XML applications, they I'll gladly join >you in lobbying for adding an 'xml:behavior' attribute to XLink with this >set of values. In fact, I'm all for releasing XLink without a behavior >attribute and creating a WG (or maybe placing it within the XLink WG >mandate, whetever) dedicated to this attribute. > >I do not believe that we are yet in a position to predefine the behaviours. >These must be specified by particular industry groups, not by W3C. That's also my position. >Suggestions like (made by Paul Prescod) are >not what I had in mind - behaviour should not point to a procedure it should >either pass parameters that can be used by procedures, e.g BEHAVIOR="popup"> or better still, like namespace declarations, point to the >source of the definition of the behaviour, e.g. BEHAVIOR="http://www.healthcare.org/xml/behaviours/popup_menu.xsl">. We are agreed on that as well. The question is, what is the best way to ensure this? We have several alternatives: 1. Leave 'behavior' unspecified and rely on people's common sense. 2. Make it a requirement that values to 'behavior' must be URIs. 3. Use XML namespace mechanism instead to qualify the attribute name, instead of its values. The spec now uses option (1), which I think is unsatisfactory. Let us at least have an editorial note recommending URI values! Paul (I presume) and myself would rather have option (3), as being more in tune with other XML standards (namespaces). But (2) also gets the job done. Given that (2) requires a very minor change to the spec as it stands (just adding a sentence or two), I guess it is the most practical one. If that's what it takes to get the spec out the door, so be it. >Now to come to another point Ben made in response to my comments that: >>It should not be necessary to have individual >>stylesheets for individual instances of messages. >>It should not be necessary >>to redefine processes for each DTD that uses the shared information. Urr... My first name is 'Oren' and the last one is 'Ben-Kiki'. 'Ben' is sort of a prefix (son-of) in Hebrew, but is a seperate word. Never fails to confuse English speakers used to middle names :-) Anyway, I said: >>Agreed; why do these follow from what Paul (and I) propose? >I don't think they follow from what you have been saying, but they are >something that has not been adequately thought through in the overall model >of the XML family. Ben rightly suggested that we should used DTD fragments >to define shareable resources. But how do you link sharable DTD fragments to >sharable stylesheet fragments? How do you link stylesheets to local >processes in a way that allow the local processes to be used with many >different stylesheets, whenever a particular DTD fragment is invoked, and >how do you provide user control over processes that are handled in multiple >places. Remember that a multiheaded link is likely to be pointing to >resources based on different servers, using different local processes to >undertake business-related procedures that necessarily must be handled >outside the stylesheet. Good questions! If I knew the answers, I'd probably be a W3C WG member instead of an outside kibitzer :-) BTW, I agree that these questions weren't thought completely through; however the WGs did invest time and effort in these directions - wo do have namespaces, for example. I would be happy if there was a WG which was dedicated to this issue, even if its output would be only a list of "recommended practices" explaining how exactly to use existing XML standards to achieve this effect. Since you've asked, I do have some notions as to how the above could be done. First, I think that some of these questions aren't quite the right ones. By this I mean that DTDs or XSchemas or whatever should be restricted to defining the structure of a valid XML document. Viewed this way it sharing DTD/XSchema fragments shouldn't be too hard. "All" you'd need to say is "and this element is as defined in the following DTD". Trivial issues such as namespace management are left as an excersize to the reader :-) Assuming this issue is resolved, there remains the question of how to share stylesheet fragments. Given that this is a completely separate issue, XSL already provides ways to do this. "All" you need to do is provide a "library module" stylesheets containing the templates for some functionality - transforming certain elements in certain ways. The ability to specify template modes and names is invaluable here; it ensures that these "modules" won't be invoked unless you explicitly activate them. Note that nothing stops you from providing a DTD/XSchema "fragment" and an associated XSL one, if you insist on tight coupling between the two. But you can also provide multiple XSL fragments for the same DTD/XSchema one, for separate styling/transformation goals. You could also provide XSL fragments which were applicable for a wide range of DTDs - consider for example the IE5 XSL stylesheet for viewing arbitrary XML documents. In short, I strongly feel that the assumption that a DTD "has" a stylesheet is wrong. As long as it is being considered, this issue will get nowhere. BTW, all this relies heavily on the XML namespace mechanism and the use of URIs, and otherwise builds on existing XML standard. However, these standards haven't been fully adjusted to namespaces yet. For example, there's at least one potential problem in XSL - AFAIK mode and template names can't be URIs, they must be simple names. I'll raise this issue in the XSL mailing list. A WG dedicated to this issue could go through all XML standards to ensure they match these scheme, and could make a better case for changing a particular standard if necessary. Another issue you mentioned is user control over this process. I think this ultimately falls in the domain of application designers. Almost by definition, end users will _not_ write CSS stylesheets or (shudder) XSLT stylesheets. They will expect to be able to select from a menu of predefined presentation options. It is an interesting question where these predefined options can be defined in an "application independent" manner. That's the only option which would guarantee users a freedom of presentation formats. However, as long as the W3C promotes the "single conversion" document processing model: "arbitrary data" + "stylesheet" -> "presentation format", there will be no application independent stylesheets. If you want them, there's no way around "arbitrary data" + "application dependent transformation" -> "universal semantics", then + "application independent stylesheet" -> "presentation format". The trick is defining the "universal semantics" language, of course. Currently the only candidate is HTML, and since it is a horrible universal semantics language you can't really write application independent stylesheets for it. It might be too late for the W3C to start developing such a language, anyway - not that they are even trying. Barring someone else doing it, there will be no application independent stylesheets. A pity, really. Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From philipnye at freenet.co.uk Mon May 17 11:41:56 1999 From: philipnye at freenet.co.uk (Philip Nye) Date: Mon Jun 7 17:12:04 2004 Subject: XML validation Message-ID: <00ab01bea04a$5c7443a0$298959c3@oemcomputer> > From: Bryan Cooper > The >XML Schema:Structures draft seems too conservative in this area: if it >doesnt give substantial advantages over markup declarations I dont see >the point: a little nicer improvement to content models for database >support and an enormous increase in size. I am quite new to XML and initially got quite excited about the XML Schema proposal. However, reading this list there seem to be two views of what schemas are for and I am not sure whether a schema is what I need. On the one hand are people who do not like the totally different syntax used in a DTD and would like to replace it with a schema which uses the same syntax as the rest of an XML document but otherwise does the same as a DTD. On the other hand there are those who want to do things a DTD cannot, such as object inheritance ( and ) or reintroduce the potentially useful but apparently tricky "&" connector. There is then the issue of backward compatibility between a schema and XML 1.0. Translating a schema based document to a DTD based one can be: possible, possible with loss of information, or just impossible. Some want one, while some want another. Is this a fair summary of the situation or have I got quite the wrong end of the stick? Philip Nye xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bd at internet-etc.com Mon May 17 11:46:45 1999 From: bd at internet-etc.com (Brandt Dainow) Date: Mon Jun 7 17:12:04 2004 Subject: Problems validating the W3C schema DTD's Message-ID: <001801bea049$6cd04d80$e282bc3e@p300> Hi - I'm playing about with the official DTD for schema's on the W3C's site http://www.w3.org/TR/xmlschema-1/. I' can't get the Microsoft XML parser in Internet Explorer 5 to validate it. It spits an error that attribute "xlmns" must be type #FIXED. Any comments? Brandt Dainow bd@internet-etc.com Internet Etc Ltd http://www.internet-etc.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 17 11:56:02 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:04 2004 Subject: [Question] Re: XLink: behavior must go! References: <012601be9dee$81cfa940$2ec566c3@sgml.u-net.com> <3.0.5.32.19990516182138.00b2c2b0@nexus.polaris.net> <4.0.1.19990516213553.01001560@207.211.141.31> Message-ID: <373FE315.2C8CF8B@prescod.net> "Simon St.Laurent" wrote: > > At 06:05 PM 5/16/99 -0500, Paul Prescod wrote: > >If a processor it sees how does the > >processor know which of the many programming language "plugins" it should > >be passed to? > > Hmm.... I didn't think it'd work quite like that. I'm trying to show the outer limits of what the current definition allows. > I figured BEHAVIOR would be an ordinary attribute - say, "popup" instead of > "popup()", which the style sheet or other app-specific gizmo then converts > to "popup()" as appropriate, knowing what the context was supposed to be. > Sort of like a selector for CSS Action Sheets, if they get off the ground. You probably know this already but: you can use any attribute as a selector. And if you use your own attribute name then you can namespace it to avoid accidental name/semantic clashes. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 17 11:58:43 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:04 2004 Subject: Overall XML Schema "structure" impressions Message-ID: <373FE0F4.9AE08B25@prescod.net> I am amazed that people from so wide a variety of backgrounds could so quickly come up with a relatively solid specification. If the schema spec were frozen today I would grumble about its imperfections but still choose it over DTDs. (not because its syntax is "more friendly" -- it isn't -- rather it is more robust and manageable) Clearly the group has so far limited its scope and ambition appropriately. As it is defined to be extensible we do not have to solve all of the problems in one go around. Presumably it will also interoperate with other schema languages that will be necessary for other data models (i.e. the linking graph, RDF) and for vertical markets. It is exciting to see the parts of the XML pantheon come together so coherently. I've made my specific reservations known separately but overall the common sense exhibited in the draft makes me feel confident that they will be dealt with. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 17 12:04:07 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:04 2004 Subject: Argh...Entities References: <199905130357.AA00472@archlute.apsdc.ksp.fujixerox.co.jp> Message-ID: <373FE415.DF506E52@prescod.net> MURATA Makoto wrote: > > I agree with Paul. I personally would like to drop everything that affects > information sets from the schema language. Hence, I oppose to information > set contributions, archetypes, defaults, entities, notations, .... I understand your goal but I think that that is too severe a constraint. The convenience of annotating the tree from the schema is just too large. Given a schema and a design for an application, the application designer can decide whether the application needs to be built on top of a schema processor or not. If it needs archetype, default, etc. then it must be, otherwise it does not need to be. Clearly language designers would have to start taking responsibility for performance. "If we depend on that then schema-less processing will be impossible. I think that it should always be possible to choose to see the same view that a schema-less processor would see. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Mon May 17 12:20:09 1999 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:12:04 2004 Subject: Argh...Entities In-Reply-To: <373FE415.DF506E52@prescod.net> Message-ID: <199905171019.AA00514@archlute.apsdc.ksp.fujixerox.co.jp> Paul Prescod wrote: > > I understand your goal but I think that that is too severe a constraint. I have been the only opponent. I am likely to lose. (; ;) > The convenience of annotating the tree from the schema is just too large. I agree with this observation, but my point is that information set contribution is ouside the scope of the schema validator. It should be left to application programs. By doing so, we can make the specification a lot simpler. Now that schemata are in the XML syntax, they can be parsed by XML processors. Thus, application programs can easily obtain additional information from schemata. We only have to allow XML schemata to have user-defined elements, which may be used by such application programs. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon May 17 15:03:30 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:04 2004 Subject: [Question] Re: XLink: behavior must go! In-Reply-To: <373FE315.2C8CF8B@prescod.net> References: <012601be9dee$81cfa940$2ec566c3@sgml.u-net.com> <3.0.5.32.19990516182138.00b2c2b0@nexus.polaris.net> <4.0.1.19990516213553.01001560@207.211.141.31> Message-ID: <199905171302.JAA08885@hesketh.net> At 04:36 AM 5/17/99 -0500, Paul Prescod wrote: >> I figured BEHAVIOR would be an ordinary attribute - say, "popup" instead of >> "popup()", which the style sheet or other app-specific gizmo then converts >> to "popup()" as appropriate, knowing what the context was supposed to be. >> Sort of like a selector for CSS Action Sheets, if they get off the ground. > >You probably know this already but: you can use any attribute as a >selector. And if you use your own attribute name then you can namespace it >to avoid accidental name/semantic clashes. Er... yes... but isn't XLink about providing a list of attributes we can use reliably with _any_ set of documents to build hypertexts? I _could_ create my own 'behavior'-like attribute, but knowing that everyone has access to the same behavior attribute at least provides me with the ability to perform selection on any XLink-conformant spec. I may not know what they mean, but at least I can test it and find out. I'm starting to wonder if it isn't time to wait and see what the next (supposedly soon) draft says. As John Simpson said, this is up there with entrail-interpretation. Not being an ancient Roman priest, I'm not very good at that. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Mon May 17 15:13:52 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:12:04 2004 Subject: XML for Preferences Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A18DA@eukbant101.ericsson.se> Looks interesting. You could extend this to store the prefs in XML also, by using the schema in my CGI::XMLForm module. It stores the form element names as XSL/XQL-like queries, and creates XML based on the form. For an online example see http://sergeant.org/cgi-bin/cvedit.pl (and do a view-source to see what's going on). Matt. -- http://come.to/fastnet Perl, XML, ASP, Database, mod_perl, High Performance Solutions perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)' It's Matt. See http://sergeant.org/notmatthew.txt > -----Original Message----- > From: Dave Winer [SMTP:dave@userland.com] > Sent: Sunday, May 16, 1999 3:28 PM > To: xml-dev@ic.ac.uk > Subject: XML for Preferences > > We've come up with another excellent use for XML, to specify the interface > for a web-based preference system. > > There are a lot of reasons why XML is the right choice here. First, it's > understandable to people who write documentation. That means that the > preferences wizard has a hope of being understandable to newcomers, since > the system developer doesn't have to write the help text, and the work > doesn't even need to be coordinated. The interactive part is just software, > interpreting the content which is specified in XML. > > Also, you can render the same specification in a variety of different > formats. For now, we're rendering as HTML, but it could just as easily be > rendered in Flash, DHTML or as a Visual Basic "wizard". The concepts and > the content are the same, but the engine running the content doesn't have > to be. > > Further, if there were an agreement on how to specify preferences systems > we could switch our deployment from Frontier to PHP or Zope or Oracle or > Vignette, or whatever, and a lot of our content would just move with us by > moving the preferences spec. > > In other words, this is an important place where a standard, defacto or > standards-body-based, would enable growth and eliminate lock-in. > > ***Where we're at with this > > We have a running system at http://prefs.userland.com/. This is a live > system, to access it you must be a member of userland.com, which is open to > the public. > > If you're not a member, go to this page: http://logon.userland.com/, go > thru the logon sequence, get the password via email, it should be > self-explanatory. > > Sorry, there's no way to use this system without being a member. We won't > do anything with your email address other than store it along with your > password and preferences. > > ***Show me the XML! > > Now, there are two ways to see the XML spec behind this system. First you > can directly access the XML page, thru this URL: > > http://prefs.userland.com/outline.xml > > Or you can see a screen shot of the editor: > > http://discuss.userland.com/msgReader$6316 > > Important point: Any XML editor can be used to edit this text. It does not > have to be our outliner, which is a good XML editor. Any tool that can > produce XML output will work fine. > > ***How to think of this > > It's a very lightweight thing. Any HTML coder can learn how to do this. > It's not as powerful as Mozilla's XUL, but then it's a lot simpler than > XUL. We looked at XUL before doing this, thinking perhaps that it would be > a good starting point. We decided that it introduced a lot of unnecessary > complexity for the people doing authoring, writers, explainers, users. > > We're doing this in the open. Maybe someone else wants to build on this > idea? If so, please let me know. The spirit of XML is building on each > others' work, that's why I keep telling you guys what we're doing. > > Keep diggin! > > Dave Winer > UserLand 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/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk> the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricker at xmls.com Mon May 17 16:18:39 1999 From: ricker at xmls.com (Jeffrey Ricker) Date: Mon Jun 7 17:12:04 2004 Subject: A milestone in XML In-Reply-To: <4.2.0.37.19990515070125.01c95b90@mail.userland.com> References: <5F052F2A01FBD11184F00008C7A4A800022A18CF@eukbant101.ericss on.se> Message-ID: <199905171417.KAA08380@mail.his.com> Sorry for the delay in response. Short vacation with the family. First things first: Of course CDF is XML. It is one of the very first uses of XML. You would be hard pressed to say I am in the Microsoft ecosystem, but lets give credit where its due. Yes, channels were overhyped and didn't go anywhere. (I personally believe the same fate awaits portals.) But look at the underlying purpose and capability of a CDF file. I designates a group of related files, describes them and tells you if and when they change. Now that's practical and it works. Are you going to tell me CDF is complicated? If you want complicated, look at ICE! But then realize that ICE is industrial strength content syndication, not intended for the pedestrian web page hacker. Climb under the hood of PointCast some time. It is very simple, make that practical, technology. CDF didn't meet all their needs, but they didn't throw the baby out with the bathwater. They didn't reinvent anything. They simply extended it. Isn't that what we did with HTML for the past few years? PS. Why do you call it a milestone, anyway? At 07:03 AM 5/15/99 -0700, Dave Winer wrote: >I haven't answered this question because I don't know the answer. Who knows >how anyone else thinks? Especially a big corporation that's just been >acquired by an even bigger corporation? Anyway, from my POV, CDF is a dead >horse. We did some work with it when it first came out, but it seemed >fairly useless and never went anywhere that I could see. Beyond that, I >have not got a clue what CDF was supposed to do that anyone wanted. RSS on >the other hand is quite useful, and lots of people are getting on the RSS >train, so of course we supported it enthusiastically. That's the big >picture from where I sit. Dave > > >At 01:36 AM 5/14/99 , Matthew Sergeant (EML) wrote: >> > -----Original Message----- >> > From: Jeffrey Ricker [SMTP:ricker@xmls.com] >> > >> > Dave, >> > Why did Netscape feel it necessary to invent RSS rather than use CDF as >> > Microsoft, DataChannel, PointCast, etc. do? >> > >> > >> Perhaps because CDF isn't XML? >> >> http://msdn.microsoft.com/workshop/delivery/channel/cdf1/cdf1.asp >> http://msdn.microsoft.com/workshop/delivery/cdf/reference/xml.asp >> >> Matt. >> >> >>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on >>CD-ROM/ISBN 981-02-3594-1 >>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >>(un)subscribe xml-dev >>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >>subscribe xml-dev-digest >>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 17 16:19:50 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:12:04 2004 Subject: XLink: behavior must go! In-Reply-To: <009101bea03a$29f93da0$25c566c3@sgml.u-net.com> Message-ID: <3.0.5.32.19990517101909.009e5370@nexus.polaris.net> At 08:35 AM 05/17/1999 +0100, Martin Bryan wrote: >[I] wrote > >>Would it be fair to say that the behavior attribute of an XLinking element >is intended to function as a sort of localized (element-context-specific) >PI -- a trigger to XLink-smart processors that is ignorable by others? If >so, in what way is such an attribute more problematic than actual PIs? > >The key point about the behaviour attribute is that it is instance specific, >rather than element-context-specific. (You can deal with all >element-context-specific problems in the stylesheet; it is instance specific >changes that are the difficult ones to control without passing some form of >control parameter.) Instance-specific? That sounds totally wrong to me, even given your own suggestion for the attribute's value (i.e., a URI). "Instance-specific" says to me, "true of this document instance," not "true of this element instance" -- the latter's what I meant when I said element-context-specific. In the latter case, a style sheet could *not* be used to establish behavior because there'd be no selector on the specific occurrence. It'd be like relegating href value assignment to a style sheet, no? The value to be used for a specific occurrence of that sort of behavior is not obtainable from the "meaning" of the tree structure at that point. Which value to use would be known to the author (human or otherwise), as a function of the "meaning" of that occurrence of that element, but unable to be communicated to a downstream application using other XLink (or style sheet selector) means. At 09:04 AM 05/17/1999 -0400, Simon St.Laurent wrote: >I'm starting to wonder if it isn't time to wait and see what the next >(supposedly soon) draft says. Yeah. I regret raising the question when I did... think I'll shut up now and see what the WG's come up with for ver. 2. ========================================================== John E. Simpson | The secret of eternal youth simpson@polaris.net | is arrested development. http://www.flixml.org | -- Alice Roosevelt Longworth xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 17 16:20:14 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:04 2004 Subject: Problems validating the W3C schema DTD's References: <001801bea049$6cd04d80$e282bc3e@p300> Message-ID: <37401F34.CA886D21@prescod.net> Brandt Dainow wrote: > > Hi - I'm playing about with the official DTD for schema's on the W3C's site > http://www.w3.org/TR/xmlschema-1/. I' can't get the Microsoft XML parser in > Internet Explorer 5 to validate it. It spits an error that attribute > "xlmns" must be type #FIXED. Any comments? That's an MSXML bug. Microsoft's namespace support is not that good. You could work around by just inserting the #FIXED. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 17 16:31:50 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:05 2004 Subject: Argh...Entities References: <199905171019.AA00514@archlute.apsdc.ksp.fujixerox.co.jp> Message-ID: <37401F82.5A13C62@prescod.net> MURATA Makoto wrote: > > Now that schemata are in the XML syntax, they can be parsed by XML processors. > Thus, application programs can easily obtain additional information from > schemata. We only have to allow XML schemata to have user-defined elements, > which may be used by such application programs. If a schema parses some date text to validate it then having the application do it again is inefficient and inconvenient. A schema could also use content model information to report breaks between content model chunks (if it "reported" non-terminals). This is incredibly convenient for application designers. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon May 17 16:47:55 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:05 2004 Subject: SGML lawyer questions Message-ID: <37402BFB.99EAEF77@locke.ccil.org> These are off-topic for this list, but SGML stuff shows up on occasion, so I figure I'll post them here rather than searching for an SGML list, especially as I know there are mavins here.... Consider the following two document instances in reference concrete syntax (the ### lines are not part of the documents): ### start here ### ]> this is text ### end here ### ### start here ### ]> this is text starting with 3 spaces ### end here ### My questions: 1) Are these documents valid? 2) What is the content of the TEXT element in each document? -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon May 17 16:49:17 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:05 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) In-Reply-To: <007201bea048$9e4b0a40$5402a8c0@oren.capella.co.il> Message-ID: <199905171448.KAA12461@hesketh.net> At 11:35 AM 5/17/99 +0200, Oren Ben-Kiki wrote: >We are agreed on that as well. The question is, what is the best way to >ensure this? We have several alternatives: > >1. Leave 'behavior' unspecified and rely on people's common sense. >2. Make it a requirement that values to 'behavior' must be URIs. >3. Use XML namespace mechanism instead to qualify the attribute name, >instead of its values. > >The spec now uses option (1), which I think is unsatisfactory. Let us at >least have an editorial note recommending URI values! Paul (I presume) and >myself would rather have option (3), as being more in tune with other XML >standards (namespaces). But (2) also gets the job done. Given that (2) >requires a very minor change to the spec as it stands (just adding a >sentence or two), I guess it is the most practical one. If that's what it >takes to get the spec out the door, so be it. How much more weight should we really be putting on URIs? We're going to need to be issuing directories of URIs and their meanings in different (Web, namespaces, now XLink) context if this keeps up. I realize that they're about the only mechanism for which large-scale unique registration is currently available, but wow, this could be genuinely ugly in a few years (even months!). Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Mon May 17 16:57:08 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:12:05 2004 Subject: A milestone in XML In-Reply-To: <199905171417.KAA08380@mail.his.com> References: <4.2.0.37.19990515070125.01c95b90@mail.userland.com> <5F052F2A01FBD11184F00008C7A4A800022A18CF@eukbant101.ericss on.se> Message-ID: <4.2.0.37.19990517074847.01d22c70@mail.userland.com> Thanks for reminding me of the flaw in CDF that RSS addresses. CDF asked you to name N pages on your site that should be watched for changes. RSS doesn't require that the pages be on your site, and further, it assumes that they could be different from day to day. This reflects what's actually happening in WebLand. Each story gets its own URL. That way when I go look for it two months from now it's still there. I remember programming CDF support in Frontier and realizing it had nothing to do with the kinds of sites people actually do. To me, that's why CDF didn't go anywhere. Why is RSS a milestone for XML? Because it's being so widely supported by webmasters of news oriented sites. Dave At 07:18 AM 5/17/99 , Jeffrey Ricker wrote: >Sorry for the delay in response. Short vacation with the family. > >First things first: Of course CDF is XML. It is one of the very first uses >of XML. > >You would be hard pressed to say I am in the Microsoft ecosystem, but lets >give credit where its due. Yes, channels were overhyped and didn't go >anywhere. (I personally believe the same fate awaits portals.) > >But look at the underlying purpose and capability of a CDF file. I >designates a group of related files, describes them and tells you if and >when they change. Now that's practical and it works. > >Are you going to tell me CDF is complicated? If you want complicated, look >at ICE! But then realize that ICE is industrial strength content >syndication, not intended for the pedestrian web page hacker. > >Climb under the hood of PointCast some time. It is very simple, make that >practical, technology. CDF didn't meet all their needs, but they didn't >throw the baby out with the bathwater. They didn't reinvent anything. They >simply extended it. Isn't that what we did with HTML for the past few years? > >PS. Why do you call it a milestone, anyway? > >At 07:03 AM 5/15/99 -0700, Dave Winer wrote: > >I haven't answered this question because I don't know the answer. Who knows > >how anyone else thinks? Especially a big corporation that's just been > >acquired by an even bigger corporation? Anyway, from my POV, CDF is a dead > >horse. We did some work with it when it first came out, but it seemed > >fairly useless and never went anywhere that I could see. Beyond that, I > >have not got a clue what CDF was supposed to do that anyone wanted. RSS on > >the other hand is quite useful, and lots of people are getting on the RSS > >train, so of course we supported it enthusiastically. That's the big > >picture from where I sit. Dave > > > > > >At 01:36 AM 5/14/99 , Matthew Sergeant (EML) wrote: > >> > -----Original Message----- > >> > From: Jeffrey Ricker [SMTP:ricker@xmls.com] > >> > > >> > Dave, > >> > Why did Netscape feel it necessary to invent RSS rather than use CDF as > >> > Microsoft, DataChannel, PointCast, etc. do? > >> > > >> > > >> Perhaps because CDF isn't XML? > >> > >> http://msdn.microsoft.com/workshop/delivery/channel/cdf1/cdf1.asp > >> http://msdn.microsoft.com/workshop/delivery/cdf/reference/xml.asp > >> > >> Matt. > >> > >> > >>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > >>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > >>CD-ROM/ISBN 981-02-3594-1 > >>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > >>(un)subscribe xml-dev > >>To subscribe to the digests, mailto:majordomo@ic.ac.uk the following >message; > >>subscribe xml-dev-digest > >>List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on >CD-ROM/ISBN 981-02-3594-1 > >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > >(un)subscribe xml-dev > >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > >subscribe xml-dev-digest > >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on >CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Mon May 17 17:09:03 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:12:05 2004 Subject: A milestone in XML Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A18DB@eukbant101.ericsson.se> > -----Original Message----- > From: Jeffrey Ricker [SMTP:ricker@xmls.com] > > Sorry for the delay in response. Short vacation with the family. > > First things first: Of course CDF is XML. It is one of the very first uses > of XML. > It used "MSXML" before XML 1.0 was released - hence it can't be parsed by an XML parser. The XML declaration is uppercase in every example of CDF I've seen. Including all on the MS web site. Therefore their CDF parser is categorically not an XML parser. They really should have made an effort to change this - it's been pointed out to them enough already, and the XML spec is over a year old. That's what I meant by CDF isn't XML, and I stand by that point. Point expat at the CDF examples and you get: not well-formed at line 1, column 5, byte 5 Matt. PS: What really worries me about the above practice (using something in such a widely used browser, based on a non-ratified-standard) is that in the future, all CDF parsers have to now deal with uppercase - that's bad and wrong, and it's going to happen again with XSL. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Mon May 17 17:59:24 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:05 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) Message-ID: <00d001bea07d$bd01cac0$5402a8c0@oren.capella.co.il> Simon St.Laurent wrote: >How much more weight should we really be putting on URIs? We're going to >need to be issuing directories of URIs and their meanings in different >(Web, namespaces, now XLink) context if this keeps up. I realize that >they're about the only mechanism for which large-scale unique registration >is currently available, but wow, this could be genuinely ugly in a few >years (even months!). It's genuinely ugly already :-) As you point out, don't really have a choice. The alternatives have been pretty thoroughly discussed in the SAX extensions naming threads a few months back, and all boil down to URIs or something else based on DNS. I haven't thought of the problem of the same URI used in different contexts (namespaces, XLink, maybe a name in XSLT). I think the recommended practice should be not to use the same URI in more then one context. I'd hesitate to make it an actual requirement, though, unless sufficient experience is gained. Another thing to keep in mind for version 2 of your favorite XML standard... Have fun, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From malliks at rocketmail.com Mon May 17 18:01:49 1999 From: malliks at rocketmail.com (Mallikarjuna Sangappa) Date: Mon Jun 7 17:12:05 2004 Subject: XML Document creation using SAX model Message-ID: <19990517154433.19520.rocketmail@web1.rocketmail.com> Hi, I am looking for an sample program for creating an XML Document using the SAX model. Any one out there who has tried creating one. Please let me know. Thanks in advance. CU, Malliks _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eisen at pobox.com Mon May 17 18:09:34 1999 From: eisen at pobox.com (Jonathan Eisenzopf) Date: Mon Jun 7 17:12:05 2004 Subject: Letting well-formedness slip: was A milestone in XML References: <5F052F2A01FBD11184F00008C7A4A800022A18DB@eukbant101.ericsson.se> Message-ID: <373FA463.AED793@pobox.com> "Matthew Sergeant (EML)" wrote: > > -----Original Message----- > > From: Jeffrey Ricker [SMTP:ricker@xmls.com] > > > > Sorry for the delay in response. Short vacation with the family. > > > > First things first: Of course CDF is XML. It is one of the very first uses > > of XML. > > > The XML declaration is uppercase in every example of CDF I've seen. Including all on the MS web site. Therefore their CDF parser is categorically not an XML parser. That's what I meant by CDF isn't XML, and I stand by that point. Of course, Matt's correct and I don't think we should back down on pressing the issue. It does beg the question, what to do with older parsers and XML files? Check the declaration before parsing or just ignore and let it fail? As long as it's not built into the parser one can easily handle the uppercase declarations. Jonathan. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rposton at austin.ibm.com Mon May 17 18:29:24 1999 From: rposton at austin.ibm.com (rposton@austin.ibm.com) Date: Mon Jun 7 17:12:05 2004 Subject: Any other good XML lists or newsletters? Message-ID: <199905171628.LAA26036@einstein.austin.ibm.com> This list is great for technical issues. But can anyone recommend another list or free newsletter that covers higher level issues such as XML trends, strategies, industry news on XML, analysis of XML market, etc.? I already know about the various XML web sites. thanks ________________________________ Rick Poston IBM RS/6000 Division; Austin, TX ________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon May 17 18:33:54 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:05 2004 Subject: Letting well-formedness slip: was A milestone in XML In-Reply-To: <373FA463.AED793@pobox.com> References: <5F052F2A01FBD11184F00008C7A4A800022A18DB@eukbant101.ericsson.se> Message-ID: <199905171632.MAA16574@hesketh.net> At 05:08 AM 5/17/99 +0000, Jonathan Eisenzopf wrote: [re: CDF] >Of course, Matt's correct and I don't think we should back >down on pressing the issue. It does beg the question, what >to do with older parsers and XML files? Check the declaration >before parsing or just ignore and let it fail? As long as it's >not built into the parser one can easily handle the uppercase >declarations. CDF isn't going to go anywhere further unless they clean up their code and become 'genuine' XML. A key part of XML's infrastructure is that any XML document should work in any XML parser, and the only parser I'm aware of that provides 'legacy' compatibility for CDF's approach is Microsoft's. (DataChannel may have inherited it.) Microsoft could post a simple CDF-fixer application, change their examples, push 'real' XML syntax for CDF. I haven't seen this yet, though I'd certainly welcome it. The point of XML is not to accomodate ideas Microsoft had while XML was still in development - the point of XML seems to be to create a format that different programs on different platforms can always read reliably. Accomodating Microsoft's 'goof' is a hassle for parser designers and application designers, and it seems much more reasonable for Microsoft to recommend that people change their CDF from the old format (which only works in MS-land) to 'true' XML, which will work in both MS-land and the rest of the XML universe. Pre-processing information that's supposed to be XML already before feeding it to the parser doesn't seem like an especially good use of resources, to say the least, and mangles the parser component architectures already in widespread use. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From spreitze at parc.xerox.com Mon May 17 18:40:12 1999 From: spreitze at parc.xerox.com (Mike Spreitzer) Date: Mon Jun 7 17:12:05 2004 Subject: RDF et IDL ? In-Reply-To: <199905111452.QAA18888@chimay.loria.fr> Message-ID: <001401bea083$dadc6770$1776020d@phobos.parc.xerox.com> > 1/ Could it be possible to do a mapping between an RDF schema > specification > and an IDL interface (a kind of rdftoidl) ? Looking for some > information... Well, if someone had (1) a mapping between RDF schemas and XML schemas, and (2) a mapping between XML schemas and IDL, those would give you what you want --- and two mappings that have many further uses themselves! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 17 18:47:18 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:05 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) In-Reply-To: <00d001bea07d$bd01cac0$5402a8c0@oren.capella.co.il> References: <00d001bea07d$bd01cac0$5402a8c0@oren.capella.co.il> Message-ID: <14144.18156.9708.23255@localhost.localdomain> Oren Ben-Kiki writes: > Simon St.Laurent wrote: > >How much more weight should we really be putting on URIs? We're going to > >need to be issuing directories of URIs and their meanings in different > >(Web, namespaces, now XLink) context if this keeps up. I realize that > >they're about the only mechanism for which large-scale unique registration > >is currently available, but wow, this could be genuinely ugly in a few > >years (even months!). > > It's genuinely ugly already :-) As you point out, don't really have a > choice. The alternatives have been pretty thoroughly discussed in the SAX > extensions naming threads a few months back, and all boil down to URIs or > something else based on DNS. One possible solution would be to define a new URL protocol that builds on HTTP URLs -- not as fancy as URNs, but they would build on something that exists and is well understood: hname://www.megginson.com/ns/ It's not enough simply to build on DNS, since many people have rights (however temporary) over part of a path but not over an entire host name, as is the case for my account on Sprynet: http://home.sprynet.com/sprynet/dmeggins/ In place of this, you could use hname://home.sprynet.com/sprynet/dmeggins/namespace/ (for example) to build on this tiny patch of Web real-estate that I rent. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 17 18:47:53 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:05 2004 Subject: XML Document creation using SAX model In-Reply-To: <19990517154433.19520.rocketmail@web1.rocketmail.com> References: <19990517154433.19520.rocketmail@web1.rocketmail.com> Message-ID: <14144.18364.800531.225821@localhost.localdomain> Mallikarjuna Sangappa writes: > I am looking for an sample program for creating an XML Document > using the SAX model. Any one out there who has tried creating > one. Please let me know. Thanks in advance. http://www.jclark.com/xml/XMLTest.java 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon May 17 18:49:22 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:06 2004 Subject: SGML lawyer questions References: <199905171520.RAA06254@brown.cs.uni-dortmund.de> Message-ID: <374047FD.FDF10172@locke.ccil.org> Stefan Mintert wrote: > > 1) Are these documents valid? > > 2) What is the content of the TEXT element in each document? > > Below is the answer from nsgmls. Please note that the files are read from > STDIN (I used ### to separate end of input from begin of output) Okay, so far so good. nsgmls doesn't think that leading blanks are part of the root element (i.e. the start-tag is inferred only when non-blank content is seen). Next question: why is this behavior the Right Thing? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 17 18:56:00 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:06 2004 Subject: Letting well-formedness slip: was A milestone in XML In-Reply-To: <373FA463.AED793@pobox.com> References: <5F052F2A01FBD11184F00008C7A4A800022A18DB@eukbant101.ericsson.se> <373FA463.AED793@pobox.com> Message-ID: <14144.18430.553499.259945@localhost.localdomain> Jonathan Eisenzopf writes: > Of course, Matt's correct and I don't think we should back down on > pressing the issue. It does beg the question, what to do with older > parsers and XML files? Check the declaration before parsing or just > ignore and let it fail? As long as it's not built into the parser > one can easily handle the uppercase declarations. (I'm not certain that it begs the question, but it certainly raises it.) Fortunately, there *are* no old versions of XML -- there's nothing but XML 1.0 out there, and the people in the W3C's XML Activity have (amazingly, for standards writers) resisted the very strong temptation to fiddle with it for well over a year, now. In other words, the problem is how to convert something that is *not* XML (such as CDF, HTML 4.0, TeX, RTF, etc.) to XML. Since CDF has strong similarities to XML, a little Perl might do the trick, but it is important to note that CDF is not XML, and since client-side push is a double-plus-ungood-stock-price-sinking-dirty-nasty word, I'd be surprised if anyone bothered to make it into XML now (people seldom enjoy maintaining their failures). Now, if there were an XML 1.1, an XML 2.0, etc., we'd have version-management problems: it is hard to build a market on a spec that is constantly changing. Fortunately, there's nothing out there but XML 1.0, and it turns out to be good enough, warts and all. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 17 19:02:23 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:12:06 2004 Subject: Any other good XML lists or newsletters? In-Reply-To: <199905171628.LAA26036@einstein.austin.ibm.com> Message-ID: <3.0.5.32.19990517130007.00b04a50@nexus.polaris.net> At 11:28 AM 05/17/1999 -0500, rposton@austin.ibm.com wrote: >But can anyone recommend another list or free newsletter >that covers higher level issues such as XML trends, >strategies, industry news on XML, analysis of XML market, etc.? Check out XML News, a free e-mail newsletter sponsored by Aeneid Corporation (with which I'm not affiliated). It's a weekly listing of pointers to news (breaking and otherwise) and features, on-line around the Web. To *subscribe* to XML News, email subscribe-xmlnews@aeneid.com To *unsubscribe* to XML News, email unsubscribe-xmlnews@aeneid.com To *contribute* to XML News, email xmlnews@aeneid.com ========================================================== John E. Simpson | The secret of eternal youth simpson@polaris.net | is arrested development. http://www.flixml.org | -- Alice Roosevelt Longworth xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 17 20:01:54 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:06 2004 Subject: RDF et IDL ? References: <001401bea083$dadc6770$1776020d@phobos.parc.xerox.com> Message-ID: <374053AF.3B79C793@prescod.net> Mike Spreitzer wrote: > > > 1/ Could it be possible to do a mapping between an RDF schema > > specification > > and an IDL interface (a kind of rdftoidl) ? Looking for some > > information... > > Well, if someone had (1) a mapping between RDF schemas and XML schemas, > and (2) a mapping between XML schemas and IDL, those would give you what > you want --- and two mappings that have many further uses themselves! I think that RDF schemas have a lot more in common with IDL than XML schemas do...concepts of nodes and properties, properties can be richly structured etc. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From malliks at rocketmail.com Mon May 17 20:09:35 1999 From: malliks at rocketmail.com (Mallikarjuna Sangappa) Date: Mon Jun 7 17:12:06 2004 Subject: Arguments to be passed to the program Message-ID: <19990517175209.16822.rocketmail@web1.rocketmail.com> Hi, Please let me know the actual arguments to be passed to the program with a sample command line. Thank U. CU, Malliks _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon May 17 20:24:24 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:12:06 2004 Subject: No subject Message-ID: <87256774.0064FC08.00@d53mta03h.boulder.ibm.com> >From: Lars Marius Garshol >Date: 14 May 1999 09:03:17 +0200 >Subject: Re: Again wit da AND and Repetitions > >* John Cowan >| >| IIRC the canonical way of doing (A & B & C) is to transform it into >| (A | B | C)* and then do a post-check that each of A, B, C appears >| exactly once. As opposed to brute-force expansion into a DFA. > >Hmmm. It sounds as if this could be extended to handle {n,m}A as well. >Just transform it into A+ (or *, depending on n) and do a post-check >that the number is correct. > >In fact, this solution looks relatively easy to implement. > I don't think it would work in the general sense, because you have lost the original semantics of the model when you convert it. You would need some way to 'attach' the original semantics onto particular states of the DFA. For instance, this model: ( (A{1..2},B,C,D?,E?) | (A{3..5},B,C,D,E)) If you converted this to: ((A+,B,C,D?,E?) | (A+,B,C,D,E)) And you got a content of: A,A,B,C,D,E what would you do to go back and check it? The original content model is pretty unambiguous. If you get one to two As, then D and E are optional. If you get 3 to 5 As, then D and E are not. But in the DFA, that would be pretty ambiguous, wouldn't it? How would you know which of them was the one that the DFA considered a match? How would you associate some end state (in the very interwoven set of states that a DFA would create for this model) with some auxillary data structure that you would use to go back and post check it? I admit I might be missing something here and didn't have a lot of time to think this argument out. I think I could have come up with a much worse scenario, but this one seems hard enough on the surface of it? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Mon May 17 20:31:22 1999 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:12:06 2004 Subject: RDF et IDL ? In-Reply-To: Your message of "Mon, 17 May 1999 09:39:37 PDT." <001401bea083$dadc6770$1776020d@phobos.parc.xerox.com> Message-ID: <199905171828.UAA01274@chimay.loria.fr> spreitze@parc.xerox.com said: ] Well, if someone had (1) a mapping between RDF schemas and XML ] schemas, and (2) a mapping between XML schemas and IDL, those would ] give you what you want --- and two mappings that have many further ] uses themselves! Gasp, no !... RDF and XML are not present at the same level. So u can not have: RDF <-> XML && XML <-> IDL then RDF <-> IDL Both RDF and IDL are used for describing class hierarchies, so i though that it should be intuitive to have a mapping between RDF and IDL. Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Mon May 17 20:39:45 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:12:06 2004 Subject: Problems validating the W3C schema DTD's Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF52D@RED-MSG-08> Brant Dainow wrote, regarding Microsoft's MSXML parser, "It spits an error that attribute 'xlmns' must be type #FIXED. Any comments?" The MSXML parser requires that any "xmlns" attribute declared in a DTD must be FIXED because, if you want to use the DTD to validate an instance, you must use exactly the same prefixes in the instance as were used in the DTD. Looking at the same point from another angle, DTDs do not treat namespace prefixes as symbolic intermediaries, but instead as ordinary characters in element and attribute names. As such, their binding is fixed by the author of the DTD, and any alteration of the binding in a document instance would produce an instance no longer described by that DTD. Presumably the work now underway in the W3C XML Schemas Activity will loosen this restriction. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon May 17 20:40:24 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:12:06 2004 Subject: Again wit da AND and Repetitions Message-ID: <87256774.0066624B.00@d53mta03h.boulder.ibm.com> >I don't remember SQL ever adopting the view that the only integrity >constraints you were allowed to specify were those that could be evaluated >in linear time. In fact, the refusal to build implementation-based >limitations into the language was one of the major reasons for the success >of SQL. > >(In implementing GedML I discovered that the integrity constraints that I >could specify in the DTD were such a pathetic subset of the total that I >might as well do all the validation in the application and ignore the DTD >capabilities entirely - especially as I had no way via the SAX API of >knowing whether the parser had done any validation or not). > I guess my argument though is that whatever you put in, its either too much or too little. Therefore, you should have a small, fast and compact set of built in constraints and provide for an escape mechanism for more complex constraints. I guess the argument against your argument would be that SQL is still an extremely limited mechanism. XML will be much more widely applicable and even if you made it ten times as large, complex, and piggy, you still won't handle a major fraction of the constraint requirements (in terms of structure and data typing) that the whole world will want, so some sort of layered escape mechanism is desirable no matter what you do. So why put in stuff that will be very heavy and for which everyone will pay when it still won't be enough? Keep the core fast and simple and applicable to what it was originally designed for, and push the heavy stuff out to the periphery or the application. I don't consider Schema to be the periphery, I consider it to be something that will become a core piece of the system, so everyone will pay for any pigginess in it. Just my opinion of course... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon May 17 20:48:23 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:12:06 2004 Subject: Again wit da AND and Repetitions Message-ID: <87256774.00670FBD.00@d53mta03h.boulder.ibm.com> From: terje@in-progress.com (Terje Norderhaug) Date: Sat, 15 May 1999 13:21:36 -0700 Subject: >>Actually it does not require deterministic models, it just allows you to check >>for them. And, I guess its not really what XML does or does not do that's in >>question here, its what the new upcoming schema spec proposes to do that's at >>issue. > >The XML 1.0 specification, 3.2.1 states that: > >"For compatability, it is an error if an element in the document can match >more than one occurance of an element type in the content model". > >See also Appendix E to the specification, which describes in further detail >what is meant by a deterministic and ambigous content model. > >It follows from the definition that a validating XML parser doesn't have to >look ahead. This is important as it simplifies implementing validation. > Sorry, I'd read too many things that day. I was reading deterministic and thinking ambiguous for some reason. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon May 17 20:51:51 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:12:06 2004 Subject: Again wit da AND and Repetitions / Singletons in a DTD Message-ID: <87256774.00677796.00@d53mta03h.boulder.ibm.com> >>But I guess the & syntax from SGML is deceptively simple. I don't >>completely follow that other thread, but I gather it's hard to implement >>which is probably why they left it out of XML. > >No, it is not particularly hard to implement support for the AND connector >in a validating parser. However, the AND connector is redundant, as one can >express the same using the other connectors (although not very elegant). > >For example, take the content model (A & B & C) expressing that we require >the three elements in any order. Here is the XML equivalent content model: [snip] >However, there are better ways of implementing support for AND connectors >than to convert AND content model into such tree structures. Simply make >the parser keep track of which elements in the AND list have not yet been >parsed. For each element encountered, remove its item from the list. Signal >an error if the parser encounter an element not in the list of remainders, >unless all of the remainding elements in the list are optional. Repeat >until the list is empty or a parsed element is not in the list and all >remainders are optional. > But that ignores the issue of what happens when an AND connector is embedded deeply with some very complex content model that is otherwise totally a straight XML type DFA! Do you then give up on doing a DFA for the entire content model when that happens? If not, then how do you do it? If you do, then its not terribly simple to do and its definitely not terribly quick. This gets back to my original question of how to deal with AND. Some of the suggestions do ok in simple situations, but are much harder if they must be generalized to deal with arbitrarily complex content models, which they must in the real world. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Mon May 17 20:54:35 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:12:06 2004 Subject: Non-XML documents to XML Converter? Message-ID: <37406619.D013F069@mitre.org> Anyone have a tool that converts a document that is formatted in a non-XML syntax into XML? I have tried Suli Ding's "Document to XML Converter" but it has so little documentation that I find it difficult to make heads or tails of it. /Roger xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 17 21:05:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:06 2004 Subject: SAX2: Alpha Documentation Message-ID: <14144.26397.60878.975165@localhost.localdomain> I've thrown together a quick-and-dirty SAX2 site at http://www.megginson.com/SAX/SAX2/ There is no code yet, but there's a little documentation and lists of interfaces, features, and properties, at least. I haven't included the new handler types yet, but they'll come along sooner or later (all of the infrastructure for them is in place). So far, this is very simple, and that simplicity appeals to me. This site is not yet linked from the main SAX page. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 17 21:13:07 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:06 2004 Subject: Non-XML documents to XML Converter? In-Reply-To: <37406619.D013F069@mitre.org> References: <37406619.D013F069@mitre.org> Message-ID: <14144.26717.620248.493022@localhost.localdomain> Roger L. Costello writes: > Anyone have a tool that converts a document that is formatted in a > non-XML syntax into XML? Perl -- it's hideously ugly, but most of the world uses it and it runs pretty fast (especially when pattern matching). Here's a ten-line Perl program that will convert most non-XML text files to XML (as long as they don't contain control characters): print "\n"; while (<>) { if (/[&<>]/) { s/&/\&\;/g; s//\>\;/g; } print; } print ""; 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Mon May 17 21:30:01 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:12:06 2004 Subject: Non-XML documents to XML Converter? Message-ID: <84285D7CF8E9D2119B1100805FD40F9F255280@MDYNYCMSX1> >Anyone have a tool that converts a document that is formatted in a >non-XML syntax into XML? I have tried Suli Ding's "Document to XML >Converter" but it has so little documentation that I find it difficult >to make heads or tails of it. /Roger "Non-XML syntax" is a pretty broad target. If a program is going to read non-XML input and then use XML markup to identify its structure in the output, it has to have some way of identifying the structure of the input. This means being specialized to read specific kinds of input. For example, Rick Geimer's RTF2XML (http://www.sesha.com/omlette/rtf2xml/) reads RTF and outputs XML. What kind of input do you have? Bob DuCharme www.snee.com/bob see www.snee.com/bob/xmlann for "XML: The Annotated Specification" from Prentice Hall. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon May 17 21:38:22 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:12:06 2004 Subject: Non-XML documents to XML Converter? Message-ID: <3.0.32.19990517123834.01219de0@pop.intergate.bc.ca> At 03:12 PM 5/17/99 -0400, David Megginson wrote: >Here's a ten-line Perl program that will convert most non-XML text >files to XML Has anyone told Jesse Berst? I smell an IPO coming... -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon May 17 21:47:46 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:06 2004 Subject: Problems validating the W3C schema DTD's References: <5BF896CAFE8DD111812400805F1991F708AAF52D@RED-MSG-08> Message-ID: <37406AB0.A27650A3@prescod.net> Andrew Layman wrote: > > The MSXML parser requires that any "xmlns" attribute declared in a DTD must > be FIXED because, if you want to use the DTD to validate an instance, you > must use exactly the same prefixes in the instance as were used in the DTD. Nevertheless the parser rejects documents that are valid both according to the XML and XML namespaces specification. > Looking at the same point from another angle, DTDs do not treat namespace > prefixes as symbolic intermediaries, but instead as ordinary characters in > element and attribute names. As such, their binding is fixed by the author > of the DTD, and any alteration of the binding in a document instance would > produce an instance no longer described by that DTD. When that occurs you can signal the error. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Mon May 17 22:01:41 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:06 2004 Subject: Non-XML documents to XML Converter? Message-ID: <01BEA07E.CD115060@cc398234-a.etntwn1.nj.home.com> Roger wrote: "Anyone have a tool that converts a document that is formatted in a non-XML syntax into XML?" Roger, XML Convert might be able to convert your non-XML document into XML. XML Convert can convert a wide range of flat files into XML. It uses a flat file schema to parse and validate the flat file and convert it into an XML document. You can download XML Convert for free at http://www.unidex.com/download.htm. Best regards, Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon May 17 22:53:44 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:06 2004 Subject: Parser2 considered harmful Message-ID: <374081AA.B4D33B56@locke.ccil.org> The [insert a certain W3 WG] folks have been deciding what to do about extending their interfaces xxx.Foo and xxx.Bar (not their real names) while adding a new level of their standard. They seem to have settled on just adding methods to the existing interfaces, a form of evolution which Java directly allows, and which works well in dynamic scripting languages (Javascript, Perl, etc.) COM implementations (which are not directly prescribed by the standard) will probably use Foo2, Bar2, and so on, because of special COM considerations, but that will not affect the standard, which will merely document at exactly what level (1, 2, etc.) a given property or method was added to the standard. I think that the use of Parser2 should be reconsidered in favor of just extending Parser. There are several arguments: 1) Either Parser2 inherits from Parser or it doesn't. If it doesn't (and underlying objects just implement both interfaces) then much casting must be done to get the right flavor to call a method on. This is very expensive in Java. If they do inherit, then you have the problem that Parser may be extended in several logically distinct ways, leading to interfaces Parser2A and Parser2B. The next generation will have to specify Parser3A, B, and C all inheriting from Parser2A *and* Parser2B, which causes a messy diamond-shaped inheritance graph. 2) Applications written to run against SAX1 Parser can be linked with SAX2 Parser with no issues. Applications written to run against SAX2 and linked with SAX1 parsers can run in degraded mode by catching a NoSuchMethodError or its equivalent when trying to use SAX2 features. With Parser2, the application would die with ClassNotFoundError. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon May 17 23:07:06 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:06 2004 Subject: Parser2 considered harmful In-Reply-To: <374081AA.B4D33B56@locke.ccil.org> References: <374081AA.B4D33B56@locke.ccil.org> Message-ID: <14144.33471.649589.158553@localhost.localdomain> John Cowan writes: > The [insert a certain W3 WG] folks have been deciding what to do > about extending their interfaces xxx.Foo and xxx.Bar (not their > real names) while adding a new level of their standard. > > They seem to have settled on just adding methods to the existing > interfaces, a form of evolution which Java directly allows, and > which works well in dynamic scripting languages (Javascript, Perl, > etc.) Yes, I believe that a similar point came up during our SAX-naming discussions earlier. > COM implementations (which are not directly prescribed by the > standard) will probably use Foo2, Bar2, and so on, because of > special COM considerations, but that will not affect the standard, > which will merely document at exactly what level (1, 2, etc.) a > given property or method was added to the standard. > > I think that the use of Parser2 should be reconsidered in favor of > just extending Parser. There are several arguments: > > 1) Either Parser2 inherits from Parser or it doesn't. If it > doesn't (and underlying objects just implement both interfaces) > then much casting must be done to get the right flavor to call a > method on. This is very expensive in Java. Actually, that wouldn't matter in any significant way, since the casting would have to be done only once for each document parsed (Parser is a top-level entry point). I wouldn't worry about what is or isn't expensive until we were dealing with code run repeatedly in a tight loop or for each parse event. > If they do inherit, then you have the problem that Parser may be > extended in several logically distinct ways, leading to interfaces > Parser2A and Parser2B. The next generation will have to specify > Parser3A, B, and C all inheriting from Parser2A *and* Parser2B, > which causes a messy diamond-shaped inheritance graph. That's the main reason for the shift to get/setFeature/Property -- while it screws around with type safety a little, it should eliminate (most) of the need for subclassing Parser2 any further. The main point is that, while XML itself is stable, what people want to do with XML is not -- if SAX is going to move forward, we need something open and extensible, so that some parsers can introduce and support new features without messing around with the Java class signatures. > 2) Applications written to run against SAX1 Parser can be linked with > SAX2 Parser with no issues. Applications written to run against SAX2 > and linked with SAX1 parsers can run in degraded mode by catching > a NoSuchMethodError or its equivalent when trying to use SAX2 > features. With Parser2, the application would die with > ClassNotFoundError. It's possible to test for the availability of a class in Java, if an application writer were worried about that -- what it really comes down to is the fact that you'll always have to use some kind of try {} catch {} statement if you're worried about whether SAX2 is available in your environment. All the best, and thanks for the comments, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Mon May 17 23:42:34 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:12:07 2004 Subject: Announcement: OmniMark is Free References: <3.0.1.32.19990511124821.013434c0@mail.accessone.com> <37389D38.C1678675@prescod.net> <3738C39C.76789562@nsc.com> <4.1.19990513100119.00c251a0@steptwo.com.au> <373CBA59.2A7832BC@prescod.net> <373F66A1.2CEFAF63@allette.com.au> <373FC334.BFAC2EFE@prescod.net> Message-ID: <37408D33.F990030@allette.com.au> [Cross posted to XSL and XML-Dev] If the major impediments to the adoption of OmniMark are cost and the fact that it's proprietary, this must surely change the equation for a few people. Maybe I'm biased, but I see this as one of the big announcements of the year. > OmniMark Technologies Corporation challenges Perl > Company announces OmniMark 5 programming language is free > > New Orleans, Louisiana - May 17, 1999 - OmniMark Technologies Corporation, > developer of the OmniMark? programming language, made several significant > product announcements at its OmniMark Developers Conference today. > > OmniMark president and CEO John McFadden announced the OmniMark programming > language is now free. The programming language has developed a strong > following since it was first introduced 10 years ago. > > A high level language, OmniMark is a clear alternative to Perl for > developing server-based web or network applications and CGI scripts without > having to make the leap to Java. > > "OmniMark programs are easier to write, read, and maintain," said John > McFadden. "OmniMark 5 combines a server safe network programming model with > an unmatched text processing language. Throw in its intuitive, integrated > approach to XML and you have a compelling combination." > > To make programming in OmniMark even easier, McFadden also announced the > release of the OmniMark Integrated Development Environment (IDE). This > powerful Windows-based environment includes an OmniMark-smart editor and > interactive debugger which lets developers write, analyze, and perfect > applications quickly and cost effectively. For example, the IDE can be used > to quickly develop and test CGI scripts interactively without invoking a web > server. OmniMark IDE can be purchased over the web for $995. > > A free, full-featured version of the OmniMark IDE, called OmniMark Home and > School, is available for personal and academic use. > > OmniMark already has a large following among Global 2000 companies who have > come to appreciate the robustness and ease of use of the language. Among the > attendees at this year's developers conference are representatives from > Boeing, IBM, Nokia Telecomunications, Airborne Express, and Underwriters > Laboratory. > > To find out more about obtaining free OmniMark software, visit their > website. > -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Marc.McDonald at Design-Intelligence.com Mon May 17 23:58:21 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:12:07 2004 Subject: Letting well-formedness slip: was A milestone in XML Message-ID: <4454C011BDE5D211B6C800609776E5400B6ADC@master.design-intelligence.com> I put an option in my parser for the pre 1.0 XML style since some of the XML examples on the net are in that style, the Shakespeare plays for instance. Marc B McDonald Principal Software Scientist Design Intelligence, Inc www.design-intelligence.com ---------- From: David Megginson [SMTP:david@megginson.com] Sent: Monday, May 17, 1999 9:55 AM To: XML Developers' List Subject: re: Letting well-formedness slip: was A milestone in XML Jonathan Eisenzopf writes: > Of course, Matt's correct and I don't think we should back down on > pressing the issue. It does beg the question, what to do with older > parsers and XML files? Check the declaration before parsing or just > ignore and let it fail? As long as it's not built into the parser > one can easily handle the uppercase declarations. (I'm not certain that it begs the question, but it certainly raises it.) Fortunately, there *are* no old versions of XML -- there's nothing but XML 1.0 out there, and the people in the W3C's XML Activity have (amazingly, for standards writers) resisted the very strong temptation to fiddle with it for well over a year, now. In other words, the problem is how to convert something that is *not* XML (such as CDF, HTML 4.0, TeX, RTF, etc.) to XML. Since CDF has strong similarities to XML, a little Perl might do the trick, but it is important to note that CDF is not XML, and since client-side push is a double-plus-ungood-stock-price-sinking-dirty-nasty word, I'd be surprised if anyone bothered to make it into XML now (people seldom enjoy maintaining their failures). Now, if there were an XML 1.1, an XML 2.0, etc., we'd have version-management problems: it is hard to build a market on a spec that is constantly changing. Fortunately, there's nothing out there but XML 1.0, and it turns out to be good enough, warts and all. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From deke at tallent.com Tue May 18 00:22:40 1999 From: deke at tallent.com (Deke Smith) Date: Mon Jun 7 17:12:07 2004 Subject: A milestone in XML Message-ID: <1285142778-61436514@server2.tallent.com> On 5/15/99 5:07 PM Lars Marius Garshol at larsga@ifi.uio.no said: >When I first started looking at RSS I immediately noticed two things: > > a) it's incredibly simple (too simple, in fact) > b) it's probably the most widely supported XML application so far, > both in terms of software and content > >To me this smells like worse-is-better again, and I think that's a >good answer to your question. Remember the Bauhuas mantra: "Form follows function." For what it is used for, a low stress way for self-published sites to expose their index, it is very appropriate. Especially since most of these self-published sites are produced by individuals who don't care to delve into intricacies of any standard. As someone who is chagrined to see large corporations carving the Internet up amongst theirselves I am excited to see tools that give a voice and audience to the "common people." We're talking big magic here. The dark side of this sort of empowerment can be seen in Columbine here in the US. The positive power can be seen in sites like B92 from Yugoslavia. It is good to let a spoon be a spoon and not a food processor. ----------------------------------------------------------------- Deke Smith Tallent Communications Group, Brentwood TN deke@tallent.com, 615-661-9878 "Eat, drink, and be merry, for tomorrow they may cancel your VISA." -Anon. ----------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Marc.McDonald at Design-Intelligence.com Tue May 18 00:28:17 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:12:07 2004 Subject: Again wit da AND and Repetitions Message-ID: <4454C011BDE5D211B6C800609776E5400B6ADD@master.design-intelligence.com> Steve Dahl pointed out my mental typo minutes after posting and I cleverly replied to him and not xml-dev. I meant the case later described: ((c,d,e,f,g) | (c,d,e,f,h)). >From reading appendix E of the XML spec, I put a lot more work into my pattern validator than needed. It does element lookbehind, rolling back to last alternative when pattern fails. The appendix is still a bit ambiguous since it mentions algorithms to reduce non-deterministic patterns to deterministic ones and doesn't say if such reductions are required. It seems rather arbitrary to allow (b,c,(e | f)) but not ((b,c,e) | (b,c,f)). A manual re-write is not possible when the 2 patterns may have been created by entity parameters: A technique commonly used to enable the reuse element definititions in a DTD. Marc B McDonald Principal Software Scientist Design Intelligence, Inc www.design-intelligence.com ---------- From: David Brownell [SMTP:david-b@pacbell.net] Sent: Sunday, May 16, 1999 11:56 AM To: John Cowan Cc: xml-dev@ic.ac.uk Subject: Re: Again wit da AND and Repetitions John Cowan wrote: > > Mark McDonald wrote: > > > > > > > > > > > > > > > > With an input of elements c, d, e, f, h in element x. > > And David Brownell replied: > > > Actually, the content model for "x" is in error there, so any > > XML processor is allowed to report an error however rudely it > > chooses to do so. That content model is "ambigious". > > I can only assume that both of you are suffering from brain farts. > Any "x" that contains anything but an "a" or a "b" is obviously > invalid. You are talking as if the above declarations were: > > > > > > Element declarations refer to lexically apparent objects (elements), > not to mere groups of elements defined by pseudo-BNF. Ah, yes ... I was reacting to the intent, not the exact wording! Thanks for catching that. There've been misstatements on this topic. The XML spec is clear that ambiguous content models are errors. What it does poorly is say exactly what that means; it basically boils down to a reality that documents better not have it, "or else". And any parser is free to do _whatever it wants_ when faced with such errors. - dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From terje at in-progress.com Tue May 18 04:25:38 1999 From: terje at in-progress.com (Terje Norderhaug) Date: Mon Jun 7 17:12:07 2004 Subject: Again wit da AND and Repetitions / Singletons in a DTD Message-ID: At 11:50 AM 5/17/99, roddey@us.ibm.com wrote: >>>But I guess the & syntax from SGML is deceptively simple. I don't >>>completely follow that other thread, but I gather it's hard to implement >>>which is probably why they left it out of XML. >> >>No, it is not particularly hard to implement support for the AND connector >>in a validating parser. However, the AND connector is redundant, as one can >>express the same using the other connectors (although not very elegant). >> >>For example, take the content model (A & B & C) expressing that we require >>the three elements in any order. Here is the XML equivalent content model: > > [snip] > >>However, there are better ways of implementing support for AND connectors >>than to convert AND content model into such tree structures. Simply make >>the parser keep track of which elements in the AND list have not yet been >>parsed. For each element encountered, remove its item from the list. Signal >>an error if the parser encounter an element not in the list of remainders, >>unless all of the remainding elements in the list are optional. Repeat >>until the list is empty or a parsed element is not in the list and all >>remainders are optional. > >But that ignores the issue of what happens when an AND connector is embedded >deeply with some very complex content model that is otherwise totally a >straight >XML type DFA! Do you then give up on doing a DFA for the entire content model >when that happens? If not, then how do you do it? If you do, then its not >terribly simple to do and its definitely not terribly quick. This gets back to >my original question of how to deal with AND. Please provide an example of such a complex content model that includes use of AND, simplified as much as possible while still demonstrating your point. -- Terje | Media Design in*Progress Software for Mac Web Professionals at Take advantage of XML with Emile, the first XML editor for Mac. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 18 05:16:33 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:12:07 2004 Subject: SAX2: Alpha Documentation Message-ID: <004201bea0dc$a72631a0$c8a8a8c0@thing1> David, Very, very nice. Bill > http://www.megginson.com/SAX/SAX2/ > So far, this is very simple, and that simplicity appeals to me. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Tue May 18 07:50:26 1999 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:12:07 2004 Subject: Argh...Entities Message-ID: <199905180549.AA00530@archlute.apsdc.ksp.fujixerox.co.jp> Paul Prescod wrote: > MURATA Makoto wrote: > > > > Now that schemata are in the XML syntax, they can be parsed by XML processors. > > Thus, application programs can easily obtain additional information from > > schemata. We only have to allow XML schemata to have user-defined elements, > > which may be used by such application programs. > > If a schema parses some date text to validate it then having the > application do it again is inefficient and inconvenient. A schema could > also use content model information to report breaks between content model > chunks (if it "reported" non-terminals). This is incredibly convenient for > application designers. On the other hand, we cannot use SAX and DOM as is. Existing XML infrastructure will not work any more. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at metalab.unc.edu Tue May 18 12:37:51 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:12:07 2004 Subject: Letting well-formedness slip: was A milestone in XML In-Reply-To: <4454C011BDE5D211B6C800609776E5400B6ADC@master.design-intelligence.com> Message-ID: Although most of Microsoft's CDF examples use the upper-case XML declaration, I've used the lower case version in my own work, and that seems to work just fine. When Microsoft first defined CDF, the then draft of XML was case-insensitive. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Java I/O (O'Reilly & Associates, 1999) | | http://metalab.unc.edu/javafaq/books/javaio/ | | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 18 12:38:51 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:12:07 2004 Subject: xmlns::#FIXED [Re: Problems validating the W3C schema DTD's] References: <5BF896CAFE8DD111812400805F1991F708AAF52D@RED-MSG-08> Message-ID: <3741434F.3ED189CA@mecomnet.de> the quoted statement regarding DTD's is not universal. it would be more accurate to describe the restriction as: "MSXML does not treat namespace prefixes as symbolic intermediaries, but instead as ordinary characters in element and attribute names." there is nothing keeping a parser from inferring xmlns binding scope and performing prefix expansion. while it is true that this requires that the document's content models be complete and consistent, this not more restrictive the presumptions entailed by a #FIXED constraint and permits the DTD-user much greater latitude. Andrew Layman wrote: > > The MSXML parser requires that any "xmlns" attribute declared in a DTD must > be FIXED because, if you want to use the DTD to validate an instance, you > must use exactly the same prefixes in the instance as were used in the DTD. > > Looking at the same point from another angle, DTDs do not treat namespace > prefixes as symbolic intermediaries, but instead as ordinary characters in > element and attribute names. As such, their binding is fixed by the author > of the DTD, and any alteration of the binding in a document instance would > produce an instance no longer described by that DTD. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Tue May 18 12:51:45 1999 From: costello at mitre.org (Roger L. Costello) Date: Mon Jun 7 17:12:07 2004 Subject: Non-XML documents to XML Converter? References: <01BEA07E.CD115060@cc398234-a.etntwn1.nj.home.com> Message-ID: <3741467A.97E39E0D@mitre.org> Thanks for all the responses to my message. I would like to clarify my original posting and present some thoughts on how this might relate to XSL. The documents that I am trying to convert to XML are slash-delimited. A double slash terminates a "set". A set is comprised of "fields". Here's a simple example: fruit/apple/red/macintosh// person/Roger/Boston /male/123-45-6789// Here I show two "sets". The second set extends over two lines. Each set is comprised of a number of fields. The first field in a set identifies the set type (it is the set identifier). I would like to convert this into an XML document that looks like this: apple red macintosh Roger Boston male 123-45-6789 The particular syntax here is not really important. The thing to note is that for a generic transformation engine to work you need to (1) supply it a description of the format of the document to be transformed. For this example, such info might be "slash-delimited, double slash terminated lines". (2) supply it the transformation rules. For example, rule: match="fruit" { field(2) field(3) field(4) } (3) and of course you need to supply it the actual document to be transformed. Interestingly, while driving in this morning I realized that this is what an XSL processor does. The only difference is that an XSL Processor has (1) hardcoded to use <...> as the delimiter. I think that it would be interesting to make an XSL Processor more generic such that you could "plug in" a format description document. Thus, the XSL Processor could transform not just XML documents, but any kind of documents. Comments? In any case, I will check out those URLs that people sent to me of conversion tools. Happy Tuesday! /Roger Robert C. Lyons wrote: > > Roger wrote: "Anyone have a tool that converts a document that is formatted in a > non-XML syntax into XML?" > > Roger, > > XML Convert might be able to convert your non-XML document into XML. > XML Convert can convert a wide range of flat files into XML. > It uses a flat file schema to parse and validate the flat file > and convert it into an XML document. > > You can download XML Convert for free at http://www.unidex.com/download.htm. > > Best regards, > > Bob > > ------ > Bob Lyons > EC Consultant > Unidex Inc. > 1-732-975-9877 > boblyons@unidex.com > http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Tue May 18 13:01:39 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:07 2004 Subject: Parser2 considered harmful Message-ID: John Cowan wrote, > If they do inherit, then you have the problem that > Parser may be extended in several logically distinct > ways, leading to interfaces Parser2A and Parser2B. > The next generation will have to specify Parser3A, B, > and C all inheriting from Parser2A *and* Parser2B, > which causes a messy diamond-shaped inheritance graph. It's not diamond inheritance per-se which is the problem, it's (as you point out) the potential for a combinatorial explosion of derived interfaces which is nasty. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Tue May 18 13:04:48 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:07 2004 Subject: Parser2 considered harmful Message-ID: David Megginson wrote, > That's the main reason for the shift to > get/setFeature/Property -- while it screws around with > type safety a little, it should eliminate (most) of > the need for subclassing Parser2 any further. Yes, but these new methods are a natural extension of the *core* functionality of the Parser interface. As such I'm with John Cowan that they should be merged into Parser. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From malliks at rocketmail.com Tue May 18 15:15:15 1999 From: malliks at rocketmail.com (Mallikarjuna Sangappa) Date: Mon Jun 7 17:12:07 2004 Subject: No subject Message-ID: <19990518125749.9270.rocketmail@web1.rocketmail.com> Hi David, Please give me sample command line parameters that has to be passed to XMLTest.java program to create an XML Document through SAX model. Thank You. CU, Malliks _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From malliks at rocketmail.com Tue May 18 15:15:58 1999 From: malliks at rocketmail.com (Mallikarjuna Sangappa) Date: Mon Jun 7 17:12:07 2004 Subject: Arguments to XMLTest.java Message-ID: <19990518125837.9565.rocketmail@web1.rocketmail.com> Hi David, Please give me sample command line parameters that has to be passed to XMLTest.java program to create an XML Document through SAX model. Thank You. CU, Malliks _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 18 15:29:32 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:07 2004 Subject: Parser2 considered harmful In-Reply-To: References: Message-ID: <14145.27307.754830.951254@localhost.localdomain> Miles Sabin writes: > It's not diamond inheritance per-se which is the > problem, it's (as you point out) the potential for a > combinatorial explosion of derived interfaces which is > nasty. Some concrete examples might be helpful -- I know that the get/setFeature/Property methods in Parser2 are not a silver bullet, but under what circumstances might people want to subclass Parser2 further in the future? 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 18 15:55:46 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:07 2004 Subject: No subject In-Reply-To: <19990518125749.9270.rocketmail@web1.rocketmail.com> References: <19990518125749.9270.rocketmail@web1.rocketmail.com> Message-ID: <14145.28935.484460.995658@localhost.localdomain> Mallikarjuna Sangappa writes: > Please give me sample command line parameters that > has to be passed to XMLTest.java program to create an > XML Document through SAX model. Thank You. Try compiling XMLTest.java, then typing java XMLTest You should see a message specifying the arguments expected. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 18 16:07:58 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:08 2004 Subject: XML Information Set WD Message-ID: <14145.29622.606052.509715@localhost.localdomain> I am happy to announce that the first XML Information Set Working Draft is now available from the W3C web site: http://www.w3.org/TR/xml-infoset Please send comments for the editors and Working Group to the address given in the WD. General discussion is, of course, welcome on any appropriate mailing list or newsgroup. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue May 18 16:37:08 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:08 2004 Subject: Non-XML documents to XML Converter? References: <01BEA07E.CD115060@cc398234-a.etntwn1.nj.home.com> <3741467A.97E39E0D@mitre.org> Message-ID: <374171F8.CEFA7040@prescod.net> "Roger L. Costello" wrote: > > Interestingly, while driving in this morning I realized that this is > what an XSL processor does. The only difference is that an XSL > Processor has (1) hardcoded to use <...> as the delimiter. > > I think that it would be interesting to make an XSL Processor more > generic such that you could "plug in" a format description document. > Thus, the XSL Processor could transform not just XML documents, but any > kind of documents. Comments? >From a formal languages point of view your "format description document" is a grammar and grammar construction is not very easy. I mean your particular non-XML syntax is easy but what about the C++ grammar? I don't think that there is any grammar-based parsing tool that can both handle the full generality of context free languages and have high performance. :( Another way to approach it is to abandon the grammar and just embed the parsing logic directly in some computer program. This is typically what Perl, Python and Omnimark programmers do. (though there are formal parser packages for Perl and Python) For your simple language either mechanism would be easy. In fact it looks like about a fifteen line Python program to me. Here's the start of one that optimizes readability over performance: from string import split from fileinput import FileInput data = FileInput().read() records = split( data, "//" ) counter = 0 for record in recordstrings: counter = counter+1 parts = split( record, "/" ) if parts[0]=="fruit": print ""%(counter, parts[0]) ... elif parts[0]=="...": ... You can see how the "parsing" logic is spread through the program. In this case that doesn't matter much because the language is so simple. As an aside: your document type is a little odd. I don't think it is intuitive or convenient to give every message a unique generic identifier ("tagname"). The whole point of the generic identifier is that it should identify a *genre* -- i.e. all messages, or all fruit messages, etc. On the other hand, you've got something called "setid" which seems to me to be the right place for an element-unique identifier -- but you seem to have put the generic identifier there! -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Tue May 18 16:54:49 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:08 2004 Subject: Parser2 considered harmful Message-ID: David Megginson wrote, > Miles Sabin writes: > > It's not diamond inheritance per-se which is the > > problem, it's (as you point out) the potential for a > > combinatorial explosion of derived interfaces which is > > nasty. > > Some concrete examples might be helpful -- I know that > the get/setFeature/Property methods in Parser2 are not a > silver bullet, but under what circumstances might people > want to subclass Parser2 further in the future? Err ... no, that's not what I meant. getProperty() deals with things quite nicely. It's an example of something Erich Gamma calls the 'Extension Objects Pattern'. See, http://www.cs.wustl.edu/~schmidt/PLoP-96/gamma.txt (only an abstract I'm afraid). My point was more along the lines of getProperty() etc. are (or, at least, will be) core Parser functionality, and that they should, if possible, be defined in the main Parser interface, rather than relegated to an auxilliary extension interface. The various discussions on the DOM IG seem to have come to the conclusion that augmenting interfaces in this way isn't problematic in Java, and that it's the cleanest and most comprehensible solution to the interface evolution problem. The biggest problem with the Parser2 route is that it interacts badly with ParserFactory. ParserFactory's methods return Parsers, so if getProperty() is defined on Parser2 I have to cast before I can call it, and that's ugly, particularly since the cast might fail. ParserFactory can't be modified so that it's methods return Parser2s without breaking signature compatability with SAX1, but we can add the new methods directly to Parser without causing any problems. Actually, this probably needs a bit of clarification. I guess a rejoinder might be: doesn't this break compatibility with parsers which only implement the current Parser interface? Ie. with a current parser, wouldn't the effect of, Parser p = ParserFactory.makeParser(); p.setProperty ("http://xml.org/sax/properties/dtd-handler", myDTDHandler); be to throw a NoSuchMethodException? In fact this doesn't need to happen, because the SAX2 ParserFactory could do something like this, public static Parser makeParser() { Parser p; // Original stuff elided try { p.getProperty("dummy"); // we get here if we're SAX2 compatible ... return p; } catch(NoSuchMethodException ex) { // ... we get here if we're not. return new SAX1ParserAdapter(p); } } Where SAX1ParserAdapter is defined as follows, class SAX1ParserAdapter implements Parser { private Parser itsBaseParser; private DocumentHandler itsDocumentHandler = null; private DTDHandler itsDTDHandler = null; private EntityResolver itsEntityResolver = null; private ErrorHandler itsErrorHandler = null; private Locale itsLocale = null; public SAX1ParserAdapter(Parser baseParser) { itsBaseParser = baseParser; } public void setDocumentHandler (DocumentHandler handler) { // cache locally ... itsDocumentHandler = handler; // forward to underlying SAX1 parser ... itsBaseParser.setDocumentHandler(handler); } // etc. for for other Parser methods that can be // safely forwarded to a SAX1 parser. public void setFeature (String featureId, boolean state) { // throw relevant exceptions } public boolean getFeature(String featureId) { // return SAX1 compatible results or throw // relevant exceptions } public void setProperty (String propertyId, Object value) { // call SAX1 Parser.setXXXHandler() methods // where appropriate (and cache locally), or // throw relevant exceptions. } public Object getProperty(String propertyId) { // return locally cached handlers where // appropriate, or throw relevant exceptions. } } This should work with all possible combinations of SAX parsers, and SAX client applications. Case 1: SAX1 parser, SAX1 client No problem, it's the current situation. Case 2: SAX1 parser, SAX2 client No problem, dealt with by adapter as above. SAX2 client can use SAX2 methods without casting and without having to worry about NoSuchMethodExceptions. Case 3: SAX2 parser, SAX1 client No problem, SAX2 interfaces are backwards compatible. Case 4: SAX2 parser, SAX2 client. No problem. As in case 2, the SAX2 client can use SAX2 methods without casting and without having to worry about NoSuchMethodExceptions. Note that this assumes that a SAX2 client can only be built against SAX2 interfaces and classes (which is fine because that's guaranteed), and that a SAX2 client will be able to ensure that the SAX2 ParserFactory is on its classpath at runtime (which shouldn't be a problem). Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From begeddov at jfinity.com Tue May 18 17:04:47 1999 From: begeddov at jfinity.com (Gabe Beged-Dov) Date: Mon Jun 7 17:12:08 2004 Subject: SAX2 and Acceptor/Connector Message-ID: <3741720E.E5F06EA3@jfinity.com> It seems to me that all of the new functionality in SAX2 can be described as create time negotiation between the consumer of XML parsing services and the provider. Once this negotiation has completed, the steady state usage of the parser is done via the same interfaces as in SAX1. There is a design pattern that addresses similar issues called the Acceptor/Connector pattern (http://www.cs.wustl.edu/~`schmidt/Acc-Con.ps.gz). I'm sure that you can come up with some use case that will seem to require you to modify the parser feature set on the fly in the middle of a parse but I'm equally sure that it would not outweigh the myriad benefits of applying the Acceptor/Connector pattern. An additional benefit of this approach is that the steady state interfaces can continue to be SAX1 and not impact the existing code base. This relates to the Parser2 thread. Cordially from Corvallis, Gabe Beged-Dov xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue May 18 17:08:01 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:08 2004 Subject: Argh...Entities References: <199905180549.AA00530@archlute.apsdc.ksp.fujixerox.co.jp> Message-ID: <37417799.5C1E7945@prescod.net> MURATA Makoto wrote: > > On the other hand, we cannot use SAX and DOM as is. As is? No. But we can build on them. We have to build on them to make schema parsers anyhow. And if a particular application does not need the extended schema information then it can work directly with the SAX 1 or DOM level 1. > Existing XML infrastructure will not work any more. We're just talking about a layer on top. XLink doesn't invalidate XML 1.0. It just means you need another layer of tools to get the full meaning of a document. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dante at mstirling.gsfc.nasa.gov Tue May 18 17:33:23 1999 From: dante at mstirling.gsfc.nasa.gov (Dante Lee) Date: Mon Jun 7 17:12:08 2004 Subject: unsubscribe Message-ID: unsubscribe Dante M. Lee Code 588 NASA/GSFC Greenbelt MD 20771 Voice = 301-521-1077 Bldg = 23 Rm = W415 Email = dante@mstirling.gsfc.nasa.gov dante4@hotmail.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue May 18 18:19:01 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:08 2004 Subject: Argh...Entities In-Reply-To: <37417799.5C1E7945@prescod.net> References: <199905180549.AA00530@archlute.apsdc.ksp.fujixerox.co.jp> Message-ID: <199905181618.MAA29286@hesketh.net> At 09:22 AM 5/18/99 -0500, Paul Prescod wrote: >MURATA Makoto wrote: >> >> On the other hand, we cannot use SAX and DOM as is. > >As is? No. But we can build on them. We have to build on them to make >schema parsers anyhow. We _can_ build on them - but I have concerns that the (significantly larger and more complex) schema processing is going to get lumped in with the current XML 1.0 mechanism and give us bloated parsers that are difficult to control. I'd love to see the schema spec people describe in some fairly scandalous detail how exactly schemas should interact with XML 1.0 documents - and make sure that all schema-compliant docs are 1.0-compliant. I've made some proposals in my Layered Model article (http://www.simonstl.com/articles/layering/layered.htm) and XML Processing Description Language (XPDL - http://purl.oclc.org/NET/xpdl ). I'd like to see the schema WG and supporting groups make the connections between the various layers. >And if a particular application does not need the extended schema >information then it can work directly with the SAX 1 or DOM level 1. So we hope. >> Existing XML infrastructure will not work any more. > >We're just talking about a layer on top. XLink doesn't invalidate XML 1.0. >It just means you need another layer of tools to get the full meaning of a >document. As noted above, however, we need to make sure that the layering of those tools is well understood and that layers do not interfere with each other. I don't think we're nearly there yet. Simon St.Laurent XML: A Primer / Building XML Applications (June) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jhoward at requisite.com Tue May 18 18:34:34 1999 From: jhoward at requisite.com (Jerry Howard) Date: Mon Jun 7 17:12:08 2004 Subject: XML-Data Reduced (XDR) Message-ID: <37419650.81A1731B@requisite.com> I've seen several announcements about Microsoft's Biztalk initiative being XML based and references to "XML-Data Reduced (XDR)". Does anyone have pointers to more information on this? Here's the blurp from a press release announcement from last week: > XML-Data Reduced (XDR), the preferred syntax for BizTalk, in the next > version of cXML - XDR is an alternative to the Data Type Definitions > (DTDs) that are outlined in the Extensible Markup Language standard and > provides a richer way to define XML documents. a URL for the whole artcile is at: http://corp.ariba.com/News/AribaArchive/biztalk.htm Jerry xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Tue May 18 19:24:52 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:12:08 2004 Subject: XML-Data Reduced (XDR) Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF541@RED-MSG-08> "XML-Data Reduced" (XDR) refers to a trimmed and improved version of the XML-Data schema syntax. The original XML-Data submission can be found at http://www.w3.org/TR/1998/NOTE-XML-data/ . Information on XML-Data Reduced is at http://msdn.microsoft.com/xml/XMLGuide/schema-overview.asp . xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Tue May 18 21:00:55 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:12:08 2004 Subject: XML-Data Reduced (XDR) Message-ID: <01BEA171.39E073E0@grappa.ito.tu-darmstadt.de> > I've seen several announcements about Microsoft's Biztalk initiative > being XML based and references to "XML-Data Reduced (XDR)". Does anyone > have pointers to more information on this? See http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Tue May 18 21:04:53 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:08 2004 Subject: XML-Data Reduced (XDR) [External Data Representation] References: <5BF896CAFE8DD111812400805F1991F708AAF541@RED-MSG-08> Message-ID: <3741B970.179B5696@pacbell.net> Andrew Layman wrote: > > "XML-Data Reduced" (XDR) refers to a trimmed and improved version of the > XML-Data schema syntax. The original XML-Data submission can be found at > http://www.w3.org/TR/1998/NOTE-XML-data/ . Information on XML-Data Reduced > is at http://msdn.microsoft.com/xml/XMLGuide/schema-overview.asp . It'd be useful to use an acronym that's not already taken ... XDR has been defined for several years now. It's an IETF draft standard, in fact, and is in widespread use throughout the Internet. ftp://ftp.isi.edu/in-notes/rfc1832.txt Since Microsoft's proposal has substantial overlap with the original XDR in terms of functionality (basic machine data types), I think it's clear that confusion will be happening. One way to reduce the confusion would be for Microsoft to put a reference to that IETF document, and suggest that people use terminology such as "Microsoft XDR" to disambiguate between the two. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcheek at NetVendor.com Tue May 18 21:41:33 1999 From: mcheek at NetVendor.com (Mark Cheek) Date: Mon Jun 7 17:12:08 2004 Subject: XML chaos Message-ID: first, to state the obvious.. i am an XML newbie. i have been all over the web researching the tools, API's and specs out there - but a few questions remain. i am a c++ contractor assigned to read and write XML documents using java. our questions: is SAX supposed to be a plug-in API for this purpose.. or, should we be using one of the Sun or IBM products? the SAX is an event-based parser - but is the Sun product tree-based? i guess what we are asking is: what is the 1) simplest XML reader/writer java product out there and 2) the most efficient? we've noticed the Sun product beats IBM in the benchmarks, but we're wondering if we need the Sun product or could we just drop SAX into our product and read/write our XML documents immediately.....????? sorry for the convoluted rambling, -mc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 18 22:02:06 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:08 2004 Subject: XML chaos References: Message-ID: <3741C6D7.31FB1261@locke.ccil.org> Mark Cheek wrote: > our questions: is SAX supposed to be a plug-in API for this > purpose.. or, should we be using one of the Sun or IBM products? SAX is a parser API, not a parser. Most parsers supply this API. Unless you need a tree model of the document, you can write your code around the SAX API and then plug in any parser you want, such as Sun's, IBM's, Aelfred (www.microstar.com), XP (www.jclark.com) or whatever. Some parsers such as Sun's and IBM's also provide the DOM API, which is tree-based, if that's more useful to your application. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed May 19 03:03:32 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:08 2004 Subject: XML-Data Reduced (XDR) [External Data Representation] References: <5BF896CAFE8DD111812400805F1991F708AAF541@RED-MSG-08> <3741B970.179B5696@pacbell.net> Message-ID: <374201AD.70734B1@prescod.net> Andrew Layman wrote: > > "XML-Data Reduced" (XDR) refers to a trimmed and improved version of the > XML-Data schema syntax. The original XML-Data submission can be found at > http://www.w3.org/TR/1998/NOTE-XML-data/ . Information on XML-Data Reduced > is at http://msdn.microsoft.com/xml/XMLGuide/schema-overview.asp . "The XML Schema implementation that ships with Internet Explorer 5 is based primarily upon the XML-Data Note , posted by the W3C in January 1998, and the Document Content Description note. XML Schemas in Internet Explorer 5 provide support for the subset of XML-Data that coincides directly with the functionality expressed in DCD, albeit in a slightly different XML grammar." "The XML Schema implementation provided with Internet Explorer 5 focuses on syntactic schemas, without support for inheritance or other object-oriented design features." Ah, well then. That clears things up. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco The dress code in Las Cruces New Mexico has been tightened [to] target Gothic clothing, such as dark trench coats. "It is not a witch hunt" Superintendent Jesse L. Gozales said. "It is for the safety of the kids in our schools." - Associated Press, May 16 1999 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jp at ncfocus.com Wed May 19 03:19:22 1999 From: jp at ncfocus.com (JP Morgenthal) Date: Mon Jun 7 17:12:08 2004 Subject: SAX2 Message-ID: David, Am I correct in believing that there are still no parser interfaces for being notified or allowed to see the actual prolog definitions of the XML Document? During the course of delivering my Java & XML Training course, I have been asked many times by attendees "Will SAX give me the DTD declarations?". It seems to me that the next version of SAX should provide this information. It seems important to those that are building more generic software to run against XML Documents. Comments??? Regards, JP ********************************************** JP Morgenthal CEO & Director of Research NC.Focus P: 516-792-0997 F: 516-792-0996 E: jp@ncfocus.com W: www.ncfocus.com ******************************************** xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From machida at vtt.co.jp Wed May 19 05:01:19 1999 From: machida at vtt.co.jp (Akihiko Machida) Date: Mon Jun 7 17:12:09 2004 Subject: unsubscribe References: Message-ID: <37422940.D46CF4BB@vtt.co.jp> unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 qub.com Wed May 19 06:59:04 1999 From: paul at qub.com (Paul Tchistopolksii) Date: Mon Jun 7 17:12:09 2004 Subject: How to disable validation. Message-ID: <000e01bea1b4$a59d7ea0$85d4d6cf@g0f2n0> Hello. I have a question about DTD's. Here is the (simplified) situation. Let's consider that we have company A processing XML documents of some kind ( A-documents), validating those documents with some DTD ( let's call it A.DTD ). Company B does the same validation-based processing with their B-documents. The only difference between A-documents and B-documents is that A-documents have element that is specific to company A and B-documents have element specific to company B - the rest of elements and attributes are the same for both companies. Now our companies decided to exchange their documents. As a solution they may write XSL stylesheets, or ( maybe) use entities to remove A1 elemets and B1 elements. I see no other ways to workaround this situation and both are a bit complicated. The problem here is to hide some part of XML document from the validation process. If company B could say in B.DTD something like: And company A would add to A.DTD That will allow both companies to do whatever they like inside their elements ( A1 and B1 would become attributes, for example ) and easily exchange the documents without any ( even simple ) XSL-based ( or not XSL-based ) filtering. I'm sure there is some answer to this "how to hide some part of XML document from validation?" I'l appreciate if you'l provide me with any URL that may be related to this problem. Thank you. Rgds.Paul. paul@pault.com http://www.pault.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mjkoo at kistmail.kist.re.kr Wed May 19 07:54:26 1999 From: mjkoo at kistmail.kist.re.kr (Mi-Jeong Koo) Date: Mon Jun 7 17:12:09 2004 Subject: DTD editor using SAX(Project X) Message-ID: <37425247.2E6749FC@kistmail.kist.re.kr> Hi~ all. I'd like to make a DTD editor using SAX(SUN's Project X). Is there any class of SAX? Thank you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From machida at vtt.co.jp Wed May 19 08:07:26 1999 From: machida at vtt.co.jp (Akihiko Machida) Date: Mon Jun 7 17:12:09 2004 Subject: unsubscribe Message-ID: <37425504.7AFF7BDC@vtt.co.jp> unsubscribe ? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Wed May 19 09:15:37 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:12:09 2004 Subject: How to disable validation. Message-ID: <01BEA1D7.D9269EA0@grappa.ito.tu-darmstadt.de> Paul Tchistopolksii wrote: > The only difference between A-documents and > B-documents is that A-documents have > element that is specific to company A > and B-documents have element specific > to company B - the rest of elements and > attributes are the same for both companies. > > Now our companies decided to exchange > their documents. As a solution they may write > XSL stylesheets, or ( maybe) use entities > to remove A1 elemets and B1 elements. > I see no other ways to workaround this > situation and both are a bit complicated. > > The problem here is to hide some part of > XML document from the validation process. You could do write a single DTD with the following: and then have each company define their company-specific elements in company-specific DTDs, which would be included through the internal subset. This is open to abuse, though, as a valid document could contain any elements, not just the intended, company-specific elements, in the COMPANY_SPECIFIC element. However, if the documents are machine generated, this is not a problem. (By the way, EMPTY and ANY(THING) are valid only in content model definitions, not attributes.) -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Wed May 19 11:50:00 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:09 2004 Subject: SAX2 and XSLT processors Message-ID: <025501bea1dc$929ef2c0$5402a8c0@oren.capella.co.il> I have raised this issue before, and somehow it didn't get very far. But I feel that a standard API for XSLT processors , in the spirit of SAX, would be very helpful. One interesting way for doing it would be to build upon the SAX2 extension mechanism, providing a standard SAX2 feature called http://xml.org/sax/features/xslt-transformation and a write only property it uses, called http://xml.org/sax/properties/xslt-stylesheet which takes an InputSource value. I like this approach since it meshes well with the SAX2 framework. Given that XSLT processor writers will need to adapt their code to SAX2 anyway, using this opportunity to get a standard API to such processors seems like a good idea. The amount of work required seems pretty small, at least for an XSLT processor which is already built on top of a SAX parser and produces SAX events as the results - these are the only ones which should be integrated into this framework, anyway. There remains the question of how to obtain a SAX2 parser supporting XSLT - say for example I have both XP and XT in my system, I'd expect XP to be the default SAX parser. However this is an open question in the current SAX2 interface for all extensions, not just for XSLT, so we can wait until it gets resolved in general. David Megginson has started writing the SAX2 documentation, listing standard features and properties (see http://www.megginson.com/SAX/SAX2/). How about adding this feature there? Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 12:26:23 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:09 2004 Subject: SAX2 In-Reply-To: References: Message-ID: <14146.37156.674912.714490@localhost.localdomain> JP Morgenthal writes: > Am I correct in believing that there are still no parser interfaces > for being notified or allowed to see the actual prolog definitions > of the XML Document? I apologize for the confusion. The final version of SAX2 will probably contain some (optional) interfaces for DTD information and lexical information. SAX2 is designed so that people can invent any handler types they want and register them using setProperty(); we're working on finalizing that infrastructure first, then we'll provide a couple of recommended core handler types. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arthur.rother at ovidius.com Wed May 19 12:56:50 1999 From: arthur.rother at ovidius.com (Arthur Rother) Date: Mon Jun 7 17:12:09 2004 Subject: question: where is the colon in processing instruction names Message-ID: <4.1.19990519123944.03d10f10@bodoni.ovidius.local> Hello, In one of the XML-DEV posted messages it says, that colons are not allowed in processing instruction names. The XML parser in IE5 does not allow colons in processing names. But I could not find anything in http://www.w3.org/TR/REC-xml#sec-pi The question is, is it allowed, and if not, why? This is probably discussed allready, but I could not find more as the one message mentioned. Thanks, Arthur Rother xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paxamr at unix.ccc.nottingham.ac.uk Wed May 19 14:02:10 1999 From: paxamr at unix.ccc.nottingham.ac.uk (adam moore) Date: Mon Jun 7 17:12:09 2004 Subject: Announce: xml-mol mail list In-Reply-To: <4.1.19990519123944.03d10f10@bodoni.ovidius.local> Message-ID: xml-mol mail list: scope and interests xml-mol is a mail-list for the discussion of issues concerning the implementation of XML-based biological and chemical applications and data with particular reference to sequences and structure. Specific fields of interest include (non-exhaustive list): - Parsing legacy data into XML - Document Object Model (DOM) handling of bioData - Developing open frameworks for XML-aware bio applications xml-mol mail list: FAQ (Frequently asked questions) 1. How do I (un)subscribe? To (un)subscribe to the list send an email with the text '(un)subscribe xml-mol' in the body to majordomo@ala.vsms.nottingham.ac.uk 2. Can I read old messages to this list? A full archive of the list is available at: http://ala.vsms.nottingham.ac.uk/biodom/xml-mol/ 3. What biological data should I discuss here? Any of it! The list scope particularily focuses on molecules, but one of the great things about working in an emerging field is the wide variety of uses / applications that become available every day. Please let us know if you have one! 4. What programming language should I use / discuss here? There are no restrictions on discussing language specific issues, but bear in mind that expertise and interest will vary, and there are some lanaguage-specific mail-lists. Currently there are XML applications being written in (at least) perl, java, C, C++ and python. 5 Why is the FAQ so short? Because the list is so new! Additions will be made over time. Please let me know of any changes you would like made FAQ maintainer: Adam Moore Adam Moore Virtual School of Molecular Sciences School of Pharmaceutical Science, University of Nottingham http://www.vsms.nottingham.ac.uk/vsms/ Personal Page:http://www.ccc.nottingham.ac.uk/~paxamr/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 15:39:45 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:09 2004 Subject: question: where is the colon in processing instruction names In-Reply-To: <4.1.19990519123944.03d10f10@bodoni.ovidius.local> References: <4.1.19990519123944.03d10f10@bodoni.ovidius.local> Message-ID: <14146.48716.615518.315963@localhost.localdomain> Arthur Rother writes: > In one of the XML-DEV posted messages it says, that colons > are not allowed in processing instruction names. Colons are not allowed in PI names *for namespace processing*; they certainly are allowed in XML 1.0. > The XML parser in IE5 does not allow colons in processing > names. If it is meant to be XML 1.0 conformant, it should allow colons when you are not performing namespace processing (though it's probably a good idea not to use them anyway). Others may correct me, but I don't think that a conformant processor is allowed to reject well-formed XML (expect, perhaps, if the processing is performing validation and the document is not valid). Namespaces cannot change this, since XML 1.0 is an independent standard. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at metalab.unc.edu Wed May 19 15:55:59 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:12:09 2004 Subject: Announcement: OmniMark is Free In-Reply-To: <37408D33.F990030@allette.com.au> References: <3.0.1.32.19990511124821.013434c0@mail.accessone.com> <37389D38.C1678675@prescod.net> <3738C39C.76789562@nsc.com> <4.1.19990513100119.00c251a0@steptwo.com.au> <373CBA59.2A7832BC@prescod.net> <373F66A1.2CEFAF63@allette.com.au> <373FC334.BFAC2EFE@prescod.net> Message-ID: At 7:42 AM +1000 5/18/99, Marcus Carr wrote: >[Cross posted to XSL and XML-Dev] > >If the major impediments to the adoption of OmniMark are cost and the fact >that >it's proprietary, this must surely change the equation for a few people. Maybe >I'm biased, but I see this as one of the big announcements of the year. > Neaar as I can tell from the Web site this is still $995 payware. I see no option of any free download of anything anywhere. What am I missing? +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Java I/O (O'Reilly & Associates, 1999) | | http://metalab.unc.edu/javafaq/books/javaio/ | | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed May 19 16:55:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:09 2004 Subject: Announcement: OmniMark is Free References: <3.0.1.32.19990511124821.013434c0@mail.accessone.com> <37389D38.C1678675@prescod.net> <3738C39C.76789562@nsc.com> <4.1.19990513100119.00c251a0@steptwo.com.au> <373CBA59.2A7832BC@prescod.net> <373F66A1.2CEFAF63@allette.com.au> <373FC334.BFAC2EFE@prescod.net> Message-ID: <3742CBC7.A8CE05D9@prescod.net> Elliotte Rusty Harold wrote: > > Neaar as I can tell from the Web site this is still $995 payware. I see no > option of any free download of anything anywhere. What am I missing? You can get it from their home page. Go to http://www.omnimark.com . Click on the "free software" link and then on "get it now." -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "It's only a movie. People should get a life." - George Lucas (http://www.nypost.com/news/9025.htm) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 16:58:44 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:10 2004 Subject: question: where is the colon in processing instruction names References: <4.1.19990519123944.03d10f10@bodoni.ovidius.local> Message-ID: <3742D16A.AB3F7C1E@locke.ccil.org> Arthur Rother wrote: > The question is, is [colon in PI targets] allowed, and if not, why? > This is probably discussed allready, but I could not find > more as the one message mentioned. Not allowed, because colons are allowed only in element and attribute names. There is a note near the end of XML-Namespaces explaining this. (Of course they are allowed in vanilla XML 1.0 without namespaces, but they are discouraged, unless you are experimenting with a namespace mechanism other than XML-Namespaces.) The mechanism for mapping PI targets to URIs is a notation declaration, as explained in XML-Rec. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 17:21:52 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation Message-ID: <14146.54445.466530.585391@localhost.localdomain> (I'd like to hear from as many people as possible on this issue.) For SAX2, we need to add at least four methods to the SAX 1.0 Parser interface: public void setFeature (String featureId, boolean state) throws SAXException; public boolean getFeature (String featureId) throws SAXException; public void setProperty (String propertyId, Object value) throws SAXException; public Object getProperty (String propertyId) throws SAXException; There are three ways of doing this: 1. Create a new interface, org.xml.sax.Parser2, that extends org.xml.sax.Parser. PRO: - provides nice, two-way compatibility - easy to write adapters for existing SAX 1.0 drivers. CON: - subclassing always leads to crime (see the GOF book for copious warnings). 2. Add the methods to org.xml.sax.Parser, and require applications to catch NoSuchMethodException when using the new methods, in case they're concerned about what version they're dealing with. PRO: - doesn't limit options for subclassing in the future CON: - very difficult to write adapters for existing SAX 1.0 drivers (slower acceptance and implementation of SAX2) - can cause unexpected behaviour at deployment time, unless the application designer knows to catch NoSuchMethodException 3. Create a separate interface org.xml.sax.ParserProps (or something like that), and require SAX2 drivers to implement both interfaces. PRO: - easy to writer adapters for existing SAX 1.0 drivers - fewer nasty deployment surprises CON: - will require lots of casting - conceptually ugly Please, comment, comment, comment! I'm not smart enough to figure this out myself. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jabuss at cessna.textron.com Wed May 19 17:22:16 1999 From: jabuss at cessna.textron.com (Buss, Jason A) Date: Mon Jun 7 17:12:10 2004 Subject: FW: Announcement: OmniMark is Free Message-ID: > -----Original Message----- > From: Buss, Jason A > Sent: Wednesday, May 19, 1999 9:34 AM > To: 'Elliotte Rusty Harold' > Subject: RE: Announcement: OmniMark is Free > > I believe the IDE is the $995 payware, but the source code for the > Omnimark5 processing engine itself is free. > > (ie, the command line functionality is still there. Using a GUI to build > .xom files is gonna cost you. Unless you are using for home or education) > > Now I can expand all my Omnimark4LE stuff. But it may still take me some > serious effort to need much more than 200 actions. > > -----Original Message----- > From: Elliotte Rusty Harold [SMTP:elharo@metalab.unc.edu] > Sent: Wednesday, May 19, 1999 8:52 AM > To: XML-Dev Mailing list > Subject: Re: Announcement: OmniMark is Free > > At 7:42 AM +1000 5/18/99, Marcus Carr wrote: > >[Cross posted to XSL and XML-Dev] > > > >If the major impediments to the adoption of OmniMark are cost and the > fact > >that > >it's proprietary, this must surely change the equation for a few people. > Maybe > >I'm biased, but I see this as one of the big announcements of the year. > > > > Neaar as I can tell from the Web site this is still $995 payware. I see > no > option of any free download of anything anywhere. What am I missing? > > > +-----------------------+------------------------+-------------------+ > | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | > +-----------------------+------------------------+-------------------+ > | Java I/O (O'Reilly & Associates, 1999) | > | http://metalab.unc.edu/javafaq/books/javaio/ | > | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | > +----------------------------------+---------------------------------+ > | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | > | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | > +----------------------------------+---------------------------------+ > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 17:25:47 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 and XSLT processors In-Reply-To: <025501bea1dc$929ef2c0$5402a8c0@oren.capella.co.il> References: <025501bea1dc$929ef2c0$5402a8c0@oren.capella.co.il> Message-ID: <14146.54998.168258.57554@localhost.localdomain> Oren Ben-Kiki writes: > One interesting way for doing it would be to build upon the SAX2 > extension mechanism, providing a standard SAX2 feature called > http://xml.org/sax/features/xslt-transformation and a write only > property it uses, called > http://xml.org/sax/properties/xslt-stylesheet which takes an > InputSource value. I think that it's a great approach, but the feature and property probably don't belong in the core, for two reasons: 1. XSL is not yet a recommendation; and 2. there are many other specs, such as RDF, XML Linking, and XML Schemas, that could fairly claim equal treatment. That said, there is no reason at all that someone couldn't define such a feature and property outside of the SAX2 core list and let the market decide. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Viraf.Bankwalla at trw.com Wed May 19 17:26:40 1999 From: Viraf.Bankwalla at trw.com (Viraf Bankwalla) Date: Mon Jun 7 17:12:10 2004 Subject: Need help modeling a taxonomy in XML Message-ID: Hi, I would appreciate help / direction / references in determining whether XML is appropiate, and how to go about designing / implementing a solution to the following problem. I am trying to represent a taxonomy using XML. The taxonomy is 5 levels deep and each level may have several thousand terms. Multiple views of the taxonomy will be available to the user - for example : View 1 View 2 ========= ========= L1-a L3-a +-L2-a +-L2-a +-L3-a | +-L1-a +-L2-b | +-L1-b +-L2-d View 1 above shows the prefered path to the term. View 2 shows a user selected term and it's parents. As the nodes are multi-axial the path to each of the root(s) are shown. The application also needs to be able to query the taxonony for terms. The solution is currently implemented using a relational database. How would one go about modeling this in XML and what tools are available to search / manage the taxonomy. When I initially looked at the problem it looked ideal for XML, however after having discovered that the nodes are multi-axial I'm not sure if XML or a relational database is the best solution. Any help would be useful. Thanks. - vi xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 17:29:08 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 and Acceptor/Connector In-Reply-To: <3741720E.E5F06EA3@jfinity.com> References: <3741720E.E5F06EA3@jfinity.com> Message-ID: <14146.55299.616360.737473@localhost.localdomain> Gabe Beged-Dov writes: > It seems to me that all of the new functionality in SAX2 can be > described as create time negotiation between the consumer of XML > parsing services and the provider. Almost -- right now, I cannot imagine any properties being written during parse time, but certainly people may want to read them, as is the case with the following two properties: http://xml.org/sax/properties/dom-node http://xml.org/sax/properties/xml-string (For anyone coming in late, you can read preliminary SAX2 documentation at http://www.megginson.com/SAX/SAX2/). 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arkin at trendline.co.il Wed May 19 17:42:00 1999 From: arkin at trendline.co.il (Arkin) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation References: <14146.54445.466530.585391@localhost.localdomain> Message-ID: <3742D92F.AFB80E65@trendline.co.il> Empty adpater class called ParserProp and an extended interface called ParserEx. The application will create a ParserProp instance by passing it a reference to Parser. The application will then try to set a feature or a property. If Parser implements ParserEx, it would work nicely. If Parser does not implement ParserEx (an old version), then ParserProp will throw an exception. Thus: ParserProp prop; prop = new ParserProp( myParser ); try { prop.setFeature( "xyz" ); } catch ( SAXException except ) { // Do something about it, or do nothing about it. } Arkin David Megginson wrote: > > (I'd like to hear from as many people as possible on this issue.) > > For SAX2, we need to add at least four methods to the SAX 1.0 Parser > interface: > > public void setFeature (String featureId, boolean state) > throws SAXException; > > public boolean getFeature (String featureId) > throws SAXException; > > public void setProperty (String propertyId, Object value) > throws SAXException; > > public Object getProperty (String propertyId) > throws SAXException; > > There are three ways of doing this: > > 1. Create a new interface, org.xml.sax.Parser2, that extends > org.xml.sax.Parser. > > PRO: - provides nice, two-way compatibility > - easy to write adapters for existing SAX 1.0 drivers. > CON: - subclassing always leads to crime (see the GOF book for > copious warnings). > > 2. Add the methods to org.xml.sax.Parser, and require applications to > catch NoSuchMethodException when using the new methods, in case > they're concerned about what version they're dealing with. > > PRO: - doesn't limit options for subclassing in the future > CON: - very difficult to write adapters for existing SAX 1.0 > drivers (slower acceptance and implementation of SAX2) > - can cause unexpected behaviour at deployment time, unless > the application designer knows to catch > NoSuchMethodException > > 3. Create a separate interface org.xml.sax.ParserProps (or something > like that), and require SAX2 drivers to implement both interfaces. > > PRO: - easy to writer adapters for existing SAX 1.0 drivers > - fewer nasty deployment surprises > CON: - will require lots of casting > - conceptually ugly > > Please, comment, comment, comment! I'm not smart enough to figure this > out myself. > > 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/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbona18 at campus.mor.itesm.mx Wed May 19 17:44:15 1999 From: cbona18 at campus.mor.itesm.mx (Ing. Cesar Bonavides M.) Date: Mon Jun 7 17:12:10 2004 Subject: &anytype; to RTF converter. Need help! Message-ID: Hy everyone! First of all, I'd like to thank everyone 'cause your helping comments and hints and tips. Well, I think this answer is not to out of context. I'd like to know if there is a converter from: TeX, or LaTex, or PostScript or PDF to RTF. I know there's something out there, but I don't have time to find it out. I appreciate your invaluable help. Thanx in advance. Cesar PS. Hope you understood this mexican's english! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arkin at trendline.co.il Wed May 19 17:53:25 1999 From: arkin at trendline.co.il (Arkin) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 and XSLT processors References: <025501bea1dc$929ef2c0$5402a8c0@oren.capella.co.il> <14146.54998.168258.57554@localhost.localdomain> Message-ID: <3742DBEC.5633CD86@trendline.co.il> I have been requested to implement this feature in an XML library more than once, both by XSL users and for other related external documents (XSP, DCP, whatever). I think it could and should be done in a very generic manner, allowing the application to specify one or more external documents using the same PI mechanism and the parser would respond by placing them (or reporting them) through the properties. By scope these references should be one per document and always appear above the root element. Feature: http://xml.org/sax/features/xsl-transform If true the parser sould attempt to apply XSL transformation and return the results, if XSL is supported. Property: http://xml.org/sax/property/xsl-stylesheet Read and write. If set before the parser is started, will introduce the PI directive using the supplied system identifier into the document name, if no such PI already exists. When read, will use either the one supplied in the document or the one supplied in the property (whichever comes last) and return a system identifier. EntityResolver can be used to get the InputStream. In addition, I think the following could be useful: Property: http://xml.org/sax/property/document-base Read and write. Provide a URL for resolving all relative URLs appearing in the document (stylesheet, external entities, etc). Could be used to supply a fake base URL when the document is parsed from memory. Could be used to return the base URL when the document is parsed from a real URL, e.g. for the purpose of locating an external stylesheet. Arkin David Megginson wrote: > > Oren Ben-Kiki writes: > > > One interesting way for doing it would be to build upon the SAX2 > > extension mechanism, providing a standard SAX2 feature called > > http://xml.org/sax/features/xslt-transformation and a write only > > property it uses, called > > http://xml.org/sax/properties/xslt-stylesheet which takes an > > InputSource value. > > I think that it's a great approach, but the feature and property > probably don't belong in the core, for two reasons: > > 1. XSL is not yet a recommendation; and > 2. there are many other specs, such as RDF, XML Linking, and XML > Schemas, that could fairly claim equal treatment. > > That said, there is no reason at all that someone couldn't define such > a feature and property outside of the SAX2 core list and let the > market decide. > > 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/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 18:26:09 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation Message-ID: <3.0.32.19990519092328.009abab0@pop.intergate.bc.ca> At 11:20 AM 5/19/99 -0400, David Megginson wrote: >2. Add the methods to org.xml.sax.Parser, and require applications to > catch NoSuchMethodException when using the new methods, in case > they're concerned about what version they're dealing with. > > PRO: - doesn't limit options for subclassing in the future > CON: - very difficult to write adapters for existing SAX 1.0 > drivers (slower acceptance and implementation of SAX2) > - can cause unexpected behaviour at deployment time, unless > the application designer knows to catch > NoSuchMethodException Still, this seems the right thing to do. SAX has been successful, but of all its eventual users, 95% haven't started or even heard of it yet. Face the legacy-code issue and deal with it and just make SAX as good as possible for the long haul. -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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srnm at yahoo.com Wed May 19 18:28:50 1999 From: srnm at yahoo.com (Steven Marcus) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation Message-ID: <19990519163047.29359.rocketmail@send205.yahoomail.com> Hello, How about using a "marker" interface? A marker interface defines no methods. Marker interfaces allow you to check for new functionality and use the new functionality without casting. Java uses marker interfaces to signal the following capabilities: Cloneable, Serializable et al. So for SAX2: 1) add the new APIs to the org.xml.sax.Parser class 2) create a new empty interface possibly called Parser2, or better SAX2 3) SAX2 compliant-parsers will implement the new marker interface as well as all the methods in org.xml.sax.Parser If you care to use the new SAX2 methods and are not sure that the parser implements them, just check for the marker interface in your code. Something like if (!(parser instanceof SAX2)) throw new RuntimeException("need a SAX2-compliant parser"); // otherwise use the parser as normal Catching NoSuchMethodExceptions is very "ugly" (at least in Java) and I suggest that any solution that requires this is lacking ... Thanks! Steven Marcus --- David Megginson wrote: > (I'd like to hear from as many people as possible on this > issue.) > > For SAX2, we need to add at least four methods to the SAX 1.0 > Parser > interface: > > public void setFeature (String featureId, boolean state) > throws SAXException; > > public boolean getFeature (String featureId) > throws SAXException; > > public void setProperty (String propertyId, Object value) > throws SAXException; > > public Object getProperty (String propertyId) > throws SAXException; > > There are three ways of doing this: > > 1. Create a new interface, org.xml.sax.Parser2, that extends > org.xml.sax.Parser. > > PRO: - provides nice, two-way compatibility > - easy to write adapters for existing SAX 1.0 drivers. > CON: - subclassing always leads to crime (see the GOF book > for > copious warnings). > > 2. Add the methods to org.xml.sax.Parser, and require > applications to > catch NoSuchMethodException when using the new methods, in > case > they're concerned about what version they're dealing with. > > PRO: - doesn't limit options for subclassing in the future > CON: - very difficult to write adapters for existing SAX > 1.0 > drivers (slower acceptance and implementation of > SAX2) > - can cause unexpected behaviour at deployment time, > unless > the application designer knows to catch > NoSuchMethodException > > 3. Create a separate interface org.xml.sax.ParserProps (or > something > like that), and require SAX2 drivers to implement both > interfaces. > > PRO: - easy to writer adapters for existing SAX 1.0 drivers > - fewer nasty deployment surprises > CON: - will require lots of casting > - conceptually ugly > > Please, comment, comment, comment! I'm not smart enough to > figure this > out myself. > > > 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/ and > on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following > message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > _____________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed May 19 18:32:21 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation Message-ID: <93CB64052F94D211BC5D0010A800133170EE91@wwmess3.bra01.icl.co.uk> I'd go for an amalgam of (1) and (3): define a new interface Parser2 that is forwards-compatible from Parser but *doesn't* extend it. Give the supplier the choice of implementing either or both interfaces (in the same or different classes). The user decides which interface he's going to use and selects a product that supplies it. This makes it difficult to write a client application that will work directly with either interface, but the availability of adapters (in both directions) should mean this isn't a problem. The fact that Parser2 doesn't extend Parser will ensure that the old Parser interface eventually falls into disuse. Mike Kay > > 1. Create a new interface, org.xml.sax.Parser2, that extends > org.xml.sax.Parser. > > 3. Create a separate interface org.xml.sax.ParserProps (or something > like that), and require SAX2 drivers to implement both interfaces. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Wed May 19 18:37:48 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation Message-ID: Err ... I might be losing my sanity here, but I _thought_ I'd posted a description of a technique that allows us to have the best of all worlds (forwards and backwards compatibility with new methods added to Parser, and no ugly casting or catching of NoSuchMethodErrors) in my last contribution to the 'Parser2 considered harmful' thread, http://www.lists.ic.ac.uk/hypermail/xml-dev/9905/0425.html Didn't it propagate? Didn't it make sense? I'd be happy to elaborate if it wasn't all that clear. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 20:51:38 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:10 2004 Subject: Namespace separators Message-ID: <37430808.9517BF11@locke.ccil.org> I foresee problems with the SAX2 namespace feature. In particular, defaulting to a null separator means that some universal names become confusible. Thus url="http://me.net/foobar" name="scope" url="http://me.net/foobars" name="cope" look the same. In addition, allowing users to specify random separators will lead to trouble, because people will not be aware of which separators are safe and which are not. The safe separators (those which cannot appear in an XML name or in an URI) are space, <, >, #, ", {, }, |, \, ^, ~, [, ], and `. Also various non-ASCII characters (no non-ASCII character can appear as such in an URI). If we *must* support multiple namespace characters, then we should make the property read-only, leaving the choice up to parser writers rather than application programmers. Parser writers have some chance of being aware of the issue. (The DOM folks are leaning toward "{URL}name" format, BTW, although I am attempting to persuade them that a leading character is not needed.) -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 22:11:45 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:12:10 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation In-Reply-To: <14146.54445.466530.585391@localhost.localdomain> Message-ID: <000d01bea234$00bf78e0$6535fea9@w21tp> > 2. Add the methods to org.xml.sax.Parser, and require applications to > catch NoSuchMethodException when using the new methods, in case > they're concerned about what version they're dealing with. > > PRO: - doesn't limit options for subclassing in the future > CON: - very difficult to write adapters for existing SAX 1.0 > drivers (slower acceptance and implementation of SAX2) > - can cause unexpected behaviour at deployment time, unless > the application designer knows to catch > NoSuchMethodException David, I prefer #2 combined with a helper class to ease some of the pain. If the client supports SAX2 only, then they can invoke Parser directly. If the client supports both SAX and SAX2, then they can invoke the static helper methods in the helper class which handles things like NoSuchMethodException. They should be passing an instance of the parser to the static helper methods. Comment? 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Wed May 19 22:24:08 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:11 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation Message-ID: A quick follow up to my last post ... I did a sanity check on the mechanism I descibed earlier and it looks as though there's a problem. It works perfectly as described for Sun JDK1.2.1 (with the exception that the error to catch is AbstractMethodError rather than NoSuchMethodError). Sadly it fails for Sun JDK 1.1.8 (the only other I've got handy at the mo'). The problem is that the older JDK won't allow the instantiation of a class which implements an older version an interface when a newer version of that interface is present on the classpath: new throws an IncompatibleClassChangeError (as a result of a failure during classloading I presume). By comparison JDK1.2.1 allows the instantiation, and throws AbstractMethodErrors if methods from the newer interface are called on the old class. The upshot is that with JDK1.1.8 you wouldn't be able to create an instance of a SAX1 parser in the presence of the SAX2 interfaces, which means that my adapter approach can't get off the ground. As far as I can see JDK1.2.1 is following the JLS here, and JDK1.1.8 (and possibly earlier) is in error. The fact that it's JDK1.1.Xs fault doesn't help all that much tho'. I'll report it as a bug and see what feedback I get from Sun. If anyone's want's a peek at the code for the test cases to make sure I'm not missing something obvious, please let me know. Assuming this is a genuine problem I have to pick one of Davids options. I'd have to go along with Tim and back option (2). Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 22:35:08 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:11 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation References: <000d01bea234$00bf78e0$6535fea9@w21tp> Message-ID: <37432008.17CEC5@locke.ccil.org> Don Park wrote: > If the client supports SAX2 only, then they can invoke Parser directly. > If the client supports both SAX and SAX2, then they can invoke the static > helper methods in the helper class which handles things like > NoSuchMethodException. > > They should be passing an instance of the parser to the static helper > methods. By using a dynamic helper class, the rest of the application doesn't need to know or care if this is a SAX2 or SAX1 parser. See Miles's and my messages on the subject. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 23:08:50 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:11 2004 Subject: SAX2: Namespace separators In-Reply-To: <37430808.9517BF11@locke.ccil.org> References: <37430808.9517BF11@locke.ccil.org> Message-ID: <14147.10109.851665.626283@localhost.localdomain> John Cowan writes: > I foresee problems with the SAX2 namespace feature. In particular, > defaulting to a null separator means that some universal names > become confusible. Thus > > url="http://me.net/foobar" name="scope" > url="http://me.net/foobars" name="cope" Agreed. I arbitrarily chose to default to the null separator for two reasons: 1. because RDF does it, and it's the only Recommendation that has anything to say about the specifics of concatenation; and 2. to stay out of any religious wars against which character should be used as the separator. The RDF concatenation does lead to nasty problems, as John suggests. I could live with [space], if everyone promises not to flame me (it's one character that's virtually guaranteed not to be allowed in XML names in any future version of the spec). 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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-b at pacbell.net Wed May 19 23:11:17 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:11 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation References: <14146.54445.466530.585391@localhost.localdomain> Message-ID: <37432898.A48ED78A@pacbell.net> David Megginson wrote: > > 1. Create a new interface, org.xml.sax.Parser2, that extends > org.xml.sax.Parser. > > PRO: - provides nice, two-way compatibility > - easy to write adapters for existing SAX 1.0 drivers. > CON: - subclassing always leads to crime (see the GOF book for > copious warnings). Actually, strike that "con" -- this isn't subclassing, it's instead "subtyping", since Parser is an interface not a class. Inheriting interfaces can't cause the crimes you'd get by relying on parent class implementation artifacts! My preference is clearly for #1 ... it's the standard way to evolve existing interfaces in Java and most other interface oriented frameworks. > 2. Add the methods to org.xml.sax.Parser, and require applications to > catch NoSuchMethodException when using the new methods, in case > they're concerned about what version they're dealing with. As Miles recently noted, this depends on everyone upgrading to conform to the Java 2 standard. (I recall the internal discussions at the time. This was a conscious change in behavior; JDK 1.1 and 1.0 are now viewed as being in error.) While desirable, it's not a thing I see happening very quickly ... particularly in embedded systems which conform to the JDK 1.1 behavior!! The motivation for changing this depended on ease of evolution in the specific case where interface definers have strong control over all implementations of the interface ... which clearly is not the case with SAX!! (Note that this change removes one of the incentives to use abstract base classes inappropriately!) > 3. Create a separate interface org.xml.sax.ParserProps (or something > like that), and require SAX2 drivers to implement both interfaces. The primary difference between this and #1 is that this defines another interface, and I don't see a benefit to that. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 23:14:11 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:11 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation In-Reply-To: <37432898.A48ED78A@pacbell.net> References: <14146.54445.466530.585391@localhost.localdomain> <37432898.A48ED78A@pacbell.net> Message-ID: <14147.10478.956663.81236@localhost.localdomain> David Brownell writes: > Inheriting interfaces can't cause the crimes you'd get by relying > on parent class implementation artifacts! No, but it can still lead to the crime of obfuscation. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jabuss at cessna.textron.com Wed May 19 23:20:38 1999 From: jabuss at cessna.textron.com (Buss, Jason A) Date: Mon Jun 7 17:12:11 2004 Subject: Announcement: OmniMark is Free Message-ID: The download for the IDE includes the source code for Omnimark5. I believe you just elect not to install the IDE using the Web Object Packager thingy.... Unfortunately, something is up with Omnimark's server (possibly low bandwidth) but my downloads from that server are running less then 1K over a T1 frame. The darn thing either locks up and times out, or corrupts the file when it downloads. Hopefully next week I will be able to download it. -Jason > -----Original Message----- > From: Elliotte Rusty Harold [SMTP:elharo@metalab.unc.edu] > Sent: Wednesday, May 19, 1999 11:33 AM > To: Buss, Jason A > Subject: RE: Announcement: OmniMark is Free > > >I believe the IDE is the $995 payware, but the source code for the > Omnimark5 > >processing engine itself is free. > > > > They say the source code is free, but where is it? What's the URL? I can't > find it and no URL is given in the press release. If it's on their web > site > somewhere it's pretty well hidden. It looks like vaporware to me. > > > +-----------------------+------------------------+-------------------+ > | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | > +-----------------------+------------------------+-------------------+ > | Java I/O (O'Reilly & Associates, 1999) | > | http://metalab.unc.edu/javafaq/books/javaio/ | > | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | > +----------------------------------+---------------------------------+ > | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | > | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | > +----------------------------------+---------------------------------+ > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 19 23:34:11 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:12:11 2004 Subject: SAX2: Namespace separators Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF563@RED-MSG-08> RDF concatenates a namespace's URI plus a local name to form a new URI by simple concatenation, with no intervening separator, true enough, but RDF also imposes a rule that all namespace URIs must end in "/" so that no ambiguity is possible. I think there are two lessons to take from this: 1. It is desirable, perhaps essential for RDF compatibility, that the composition of a namespace's URI plus a local name itself be a URI or URI reference. 2. Careful choice of rules for either naming namespaces or for picking separator characters allows us to avoid ambiguity. Proposals to never have a separator either lead to ambiguity or to imposing restrictions on namespaces. These, therefore, either fail the ambiguity test or fail in the face of many namespace URIs that are legal per the namespaces spec. That is not good. I have seen the following rule proposed, and it appears both robust and compatible with RDF: To compose a namespace's URI plus a local name into a new string that is a URI reference, concatenate the strings directly if the URI ends in "/" or "?", else concatenate the strings but separate them with a "#". xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From BFersch at aol.com Wed May 19 23:52:00 1999 From: BFersch at aol.com (BFersch@aol.com) Date: Mon Jun 7 17:12:11 2004 Subject: Announcement: OmniMark is Free Message-ID: jason: Glad to know that it is not just me that is unable to download the software. Question: why announce it if they can't handle the traffic? 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 20 00:05:41 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:11 2004 Subject: none In-Reply-To: <87256774.0064FC08.00@d53mta03h.boulder.ibm.com> References: <87256774.0064FC08.00@d53mta03h.boulder.ibm.com> Message-ID: * roddey@us.ibm.com | | The original content model is pretty unambiguous. If you get one to | two As, then D and E are optional. If you get 3 to 5 As, then D and | E are not. But in the DFA, that would be pretty ambiguous, wouldn't | it? You're quite right, my suggested transformation could inject ambiguity into a content model that did not originally have it, and this does make it appear much less attractive. I haven't had time to think it through, but it might be possible to contrive a solution that in the case of merged foo{m,n} groups would choose different exits depending on the actual number of foos. Or it may be too difficult to actually be much of a gain. --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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Thu May 20 01:19:57 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:12:11 2004 Subject: &anytype; to RTF converter. Need help! In-Reply-To: Message-ID: <4.1.19990520091624.00bf31c0@mail.steptwo.com.au> At 01:40 20/05/1999 , Ing. Cesar Bonavides M. wrote: | Hy everyone! | | First of all, I'd like to thank everyone 'cause your helping comments and | hints and tips. | | Well, I think this answer is not to out of context. | | I'd like to know if there is a converter from: | | TeX, or LaTex, or PostScript or PDF to RTF. | | I know there's something out there, but I don't have time to find it out. | | I appreciate your invaluable help. | | Thanx in advance. | | Cesar Cesar, You've picked some difficult formats to convert. TeX and LaTex should be convertable using Perl or Omnimark. Not too hard, but a bit of work. Postscript and PDF are very, very hard formats to work with, and I don't know of any easy way of dealing with them. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 20 02:54:27 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:11 2004 Subject: SAX2: Namespace separators In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAF563@RED-MSG-08> References: <5BF896CAFE8DD111812400805F1991F708AAF563@RED-MSG-08> Message-ID: <14147.23196.678787.820378@localhost.localdomain> Andrew Layman writes: > RDF concatenates a namespace's URI plus a local name to form a new > URI by simple concatenation, with no intervening separator, true > enough, but RDF also imposes a rule that all namespace URIs must > end in "/" so that no ambiguity is possible. I cannot find any such constraint in the REC, but I might have missed it; in any case, the Namespace URI for RDF itself, "http://www.w3.org/1999/02/22-rdf-syntax-ns#", does not follow that rule. > I have seen the following rule proposed, and it appears both robust > and compatible with RDF: > > To compose a namespace's URI plus a local name into a new string > that is a URI reference, concatenate the strings directly if the > URI ends in "/" or "?", else concatenate the strings but separate > them with a "#". That's an interesting suggestion, but I don't think that it's compatible with the Namespaces REC. As far as I understand Namespaces in XML, and have (potentially) distinct element names, and it would be wrong for a generic processor to lose the distinction (though an application might choose to do so). 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From begeddov at jfinity.com Thu May 20 03:01:33 1999 From: begeddov at jfinity.com (Gabe Beged-Dov) Date: Mon Jun 7 17:12:11 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation References: <14146.54445.466530.585391@localhost.localdomain> <37432898.A48ED78A@pacbell.net> Message-ID: <37434F39.8BC2D38B@jfinity.com> David Brownell wrote: > > 3. Create a separate interface org.xml.sax.ParserProps (or something > > like that), and require SAX2 drivers to implement both interfaces. > > The primary difference between this and #1 is that this defines another > interface, and I don't see a benefit to that. A separate interface for create time negotiation of steady state capabilities provides both API and implementation efficiency. Again, I would refer you to Doug Schmidts excellent coverage of this design pattern (albiet in a different domain, i.e. network transports). This can also be thought of as a smart factory that actually does capability matching as opposed to just providing a trivial implementation indirection. The idea that you can do this by first creating the default parser and then negotiating thru its interface, and then under the covers creating a different parser that matches the agreed capabilities just doesn't seem that appealing. Cordially from Corvallis, Gabe Beged-Dov xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From niko at cmsplatform.com Thu May 20 03:22:32 1999 From: niko at cmsplatform.com (Nik O) Date: Mon Jun 7 17:12:11 2004 Subject: &anytype; to RTF converter. Need help! Message-ID: <015001bea25e$cc643f60$1a5e360a@tetondata.com> A good source for TeX/LaTeX tools and info is http://www.tug.org. Select the "CTAN" link, then use the "Search the Catalogue For a Keyword" feature, searching for "RTF". You'll find several TeX-to-RTF tools listed. The direct URL is: http://tug.ctan.org/cgi-bin/cataloguesearch.pl?preferredCTAN=ctan.tug.org%2F tex-archive&CATSTRING=RTF. And Cesar, mi amigo, your English is sooo much better than mi Espanol (yes, i know it's mis-spelled, but i'm sending plain-text). So, no worries, eh? -Nik O, Content Mgmt Solutions, Jackson, Wyo. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Thu May 20 04:14:28 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:12:11 2004 Subject: &anytype; to RTF converter. Need help! References: <4.1.19990520091624.00bf31c0@mail.steptwo.com.au> Message-ID: <37436C30.8E8E67A1@allette.com.au> Cesar wrote: > I'd like to know if there is a converter from: > TeX, or LaTex, or PostScript or PDF to RTF. > I know there's something out there, but I don't have time to find it out. I've had some luck using something called la2mif, that converts TeX to Maker Interchange Format that can be read into FrameMaker and saved to RTF. It did a surprisingly good job on equations, though I'm not sure how much would be retained during the conversion to RTF. For details, try http://www.mekon.co.uk. With small documents (on one page), you can Select all --> copy PDF data from Acrobat and paste it into FrameMaker. Again, it's a kludge and you may have problems with character sets, but it will at least get the data into a textual format. Please don't judge me based on these methods - I feel cheap and dirty as it is... -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From branjan at wipinfo.soft.net Thu May 20 06:09:17 1999 From: branjan at wipinfo.soft.net (Balaji Ranjan) Date: Mon Jun 7 17:12:11 2004 Subject: how to save dom Message-ID: hi , i want to know how to save a dom in memory to disk using IBMParser for java thanks in advance Balaji Ranjan The ability to learn an ability from scratch is the ability u need to suceed. --Anonymous xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Thu May 20 10:39:42 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:12 2004 Subject: SAX2 and XSLT processors Message-ID: <038101bea29b$eaec5520$5402a8c0@oren.capella.co.il> David Megginson wrote: >Oren Ben-Kiki writes: > > > One interesting way for doing it would be to build upon the SAX2 > > extension mechanism, providing a standard SAX2 feature called > > http://xml.org/sax/features/xslt-transformation and a write only > > property it uses, called > > http://xml.org/sax/properties/xslt-stylesheet which takes an > > InputSource value. > >I think that it's a great approach, but the feature and property >probably don't belong in the core, for two reasons: That depends on what you mean by "belonging in the core". Certainly a SAX processor isn't required to implement the feature. >1. XSL is not yet a recommendation; and It will be, soon, or so we hope; let's assume for the sake of discussion its August and a final draft is out. >2. there are many other specs, such as RDF, XML Linking, and XML > Schemas, that could fairly claim equal treatment. I perfectly agree that the same problem exists for all relevant W3C recommendations. IMVHO, it is wrong to specify such features using http://my.own.company/... URIs. It would be very much in the spirit of SAX to specify them under http://xml.org/... instead. That is, I feel that _all_ features necessary for implementing XML standards (be they from the W3C or from anywhere else) do "belong in the core". How about the following solution: Reserve the http://xml.org/sax/features/w3.org/ and http://xml.org/sax/properties/w3.org/ base URIs for specifying features and properties for implementing features and properties for implementing W3C XML recommendations. These prefixes would be followed by the internal part of the URI the W3C uses the recommendation - for example, "XSL/Transform/1.0" - and then followed by a sub-feature of a property name, if necessary. For XSL, we'd get http://xml.org/sax/features/w3.org/XSL/Transform/1.0 and http://xml.org/sax/properties/w3.org/XSL/Transform/1.0/stylesheet. Similar features and properties would be defined for RDF, XLink, XSchema, etc. If in the future some other organization - "std.makers.org" - contributes relevant standards, we'll define http://xml.org/sax/features/org.makers.std/..., etc. This way "standard" features would have "standard" names. >That said, there is no reason at all that someone couldn't define such >a feature and property outside of the SAX2 core list and let the >market decide. I can't see "someone" other then w3.org or xml.org being able to pull this off. For example, I'm perfectly willing to contribute the URIs http://com.publishare/sax/features/xsl-transformation/1.0 and http://com.publishare/sax/features/xsl-transformation/1.0/stylesheet for specifying XSL transformations and specifying an InputSource for loading the stylesheet. What's the chance that implementers will wrap their XSL processor this way? Consider that "http://publishare.com" is a URI controlled by my company, and therefore refers to a particular product ("PubliShare", not released yet) which happens to use XSL. We'd certainly enjoy the resulting publicity within the XML community, but the chances that Microsoft (or IBM, or Sun, or any other company for that matter) will provide its XSL processor using these URIs is pretty slim. If, on the other hand, we (XML developers) accept SAX2 and within it a way to specify all standard XML recommendations, under a neutral name such as "xml.org", there's a pretty good chance that implementers will bother complying. Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 20 11:48:23 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:12:12 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) Message-ID: <03fd01bea2a6$19f351c0$6f6167cb@james.harvestroad.com.au> >One possible solution would be to define a new URL protocol that >builds on HTTP URLs -- not as fancy as URNs, but they would build on >something that exists and is well understood: > > hname://www.megginson.com/ns/ I suggested this to TimBL at WWW8 but he didn't buy it. My argument went something like this: 1. Namespace URIs don't have to point to anything retrievable, they are just unique identifiers 2. Some URI schemes might not be web-retrievable (eg "isbn:1-23456-789-0") 3. Some URI schemes *are* web-retrievable (eg http://www.megginson.com/ns/) 4. So namespaces URIs *can* point to something, though, such as a human-readable description of the namespace, if they use a URI scheme that is web-retrievable. 5. If this is done, how does one distinguish referencing the namespace from referencing the file describing the namespace 6. My suggestion: come up with a new URI scheme that has the same scheme-specific syntax as an http URI but that is only intended as a unique identifier. TimBL suggested there wasn't a distinction to be made (as did Rohit Khare who cited Roy Fielding's PhD thesis). I'm still not convinced. Comments? 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 20 12:31:50 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:12 2004 Subject: SAX2 and XSLT processors In-Reply-To: <038101bea29b$eaec5520$5402a8c0@oren.capella.co.il> References: <038101bea29b$eaec5520$5402a8c0@oren.capella.co.il> Message-ID: <14147.58249.513922.226496@localhost.localdomain> Oren Ben-Kiki writes: > I perfectly agree that the same problem exists for all relevant W3C > recommendations. IMVHO, it is wrong to specify such features using > http://my.own.company/... URIs. It would be very much in the spirit > of SAX to specify them under http://xml.org/... instead. The trouble is that we've created a centralized registry bottleneck -- a single person has to approve every new feature and property name to avoid name collision. Except for a few core SAX2 features and properties (and there may already be too many), I think that there are great advantages to letting the market decide what to use, and then (slowly) migrating feature names into the core if there's great enough demand. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Thu May 20 13:19:49 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:12 2004 Subject: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation Message-ID: David Brownell wrote, > David Megginson wrote, > > 2. Add the methods to org.xml.sax.Parser, and > > require applications to catch NoSuchMethodException > > when using the new methods, in case they're > > concerned about what version they're dealing with. > > As Miles recently noted, this depends on everyone > upgrading to conform to the Java 2 standard. Actually, no it doesn't. If everyone upgraded to Java 2 then by adopting my proposed mechanism we'd have a flawless backwards and forwards compatible migration path. Given that the Java 2 requirement isn't acceptable, then option (2) depends on us being willing to put up with a (hopefully short) migration period during which there will be interoperability problems with combinations of SAX2 clients and SAX1 parsers. I think that's a price worth paying, given that SAX is still quite a young API ... we should get it right _now_ while there's still time. And getting it right means making sure that the API is as simple and comprehensible as possible, which is what option (2) offers. The getProperty() mechanism should ensure that this problem is much less likely to come up again soon. I'm pretty sure that this is what Tim meant. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Thu May 20 15:36:38 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:12:12 2004 Subject: SAX2 and XSLT processors Message-ID: <01d501bea2c4$f6142e40$5402a8c0@oren.capella.co.il> David Megginson wrote: >I wrote: > > I perfectly agree that the same problem exists for all relevant W3C > > recommendations. IMVHO, it is wrong to specify such features using > > http://my.own.company/... URIs. It would be very much in the spirit > > of SAX to specify them under http://xml.org/... instead. > >The trouble is that we've created a centralized registry bottleneck -- >a single person has to approve every new feature and property name to >avoid name collision. And that's what we wanted to avoid in the first place... Point taken. But it seems inevitable for the particular case of W3C standard features. >Except for a few core SAX2 features and properties (and there may >already be too many), I think that there are great advantages to >letting the market decide what to use, and then (slowly) migrating >feature names into the core if there's great enough demand. I agree with this as far as "new" features are concerned, since whoever introduces the new feature presumably also specifies the feature and property names. Not to mention that being a "new" feature, nobody would be forced to use it. It makes for a wonderful way for the industry to evolve SAX and XML, instead of standard organizations. That said... W3C features are different in two important respects. First, these are features one _must_ use to comply with "official standards". There's much less of a "market decision" whether to use them or not. Second, the people defining the standards did not bother to specify matching SAX2 features and properties. And yet, we need a universal name for each such feature. The solution might be to lobby the W3C to provide these names. Can anyone from the W3C comment on the likelihood of this? Assuming that it won't happen, "we" will have no choice but to appoint someone to act as a proxy to the W3C for the purpose of defining these names - with an emphasis on "one". This "one" should be acceptable to most developers, otherwise he'll be ignored. For better or worse, our only candidate at the moment is whoever controls "xml.org". Does anyone have an alternative? BTW, I checked and there's an registered "xsl.org" URI, maybe they'd like to do this instead? If we don't do this, then what should a SAX2 parser implementer wishing to provide a W3C feature do, exactly? Invent his own name and properties for it? That would mean that switching SAX2 parser implementations would become much harder then switching SAX parser implementations. "You are in a maze of standard W3C SAX2 features, all different" :-) That wasn't the idea. I appreciate the goal of keeping the SAX2 "core" small, though I'm still not clear what distinguishes features in the "core" - is it the fact they are specified using the "xml.org" URI? A parser may still choose not to implement them, for example. If the idea is that "if you implement this _standard_ feature, this is the way you must do it so others will be able to use it", then W3C features do belong in this set. If this set is large that's because XML complex, which isn't something SAX can solve. Let us just be glad we aren't dealing with SGML :-) At any rate, if you still feel uncomfortable with the W3C features, how about packaging them in a separate group - a "W3C" feature set, say, which would be independent of the "core" feature set, but would still be under the control of xml.org? That would mesh well with the naming scheme I proposed - that is, "core" features would be under "xml.org/features", but "W3C" features would be under "xml.org/features/w3.org". I'd be interested with what XSLT processor implementers have to say on this. Would you consider packaging the processor as a SAX2 parser? If so, what feature names would you use or would like to use? Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 May 20 16:34:06 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:12 2004 Subject: SAX2 and XSLT processors In-Reply-To: <01d501bea2c4$f6142e40$5402a8c0@oren.capella.co.il> References: <01d501bea2c4$f6142e40$5402a8c0@oren