From Alice.Portillo at PSS.Boeing.com Sat Aug 1 00:15:37 1998 From: Alice.Portillo at PSS.Boeing.com (Portillo, Christina) Date: Mon Jun 7 17:03:20 2004 Subject: White Space Message-ID: In reading 2.10 Whitespace I don't come away with a clear picture what whitespace is and isn't being passed on through the processor to an application. Can someone clarify this for me? Question 1: "In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines, denoted by the nonterminal S in this specification) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document." Although insignificant white space was not intended for inclusion does it all get passed through the processor anyway? Question 2: "An XML processor must always pass all characters in a document that are not markup through to the application." Is the white space added "to set apart the markup for greater readability" considered markup? Does it get passed through the processor? Question 3: "A validating XML processor must also inform the application which of these characters constitute white space appearing in element content." Do I understand correctly, that although the application is informed of this white space in element content, all this white space is still passed on? Christina Portillo Product Definition and Image Technology The Boeing Company Phone: 425.237.3351 PO Box 3707 M/S 6H-AF Fax: 425.237.3428 Seattle, WA 98124-2207 christina.portillo@boeing.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Aug 1 01:09:14 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:20 2004 Subject: White Space Message-ID: <3.0.32.19980731160714.00c529f0@207.34.179.21> At 03:15 PM 7/31/98 -0700, Portillo, Christina wrote: >In reading 2.10 Whitespace I don't come away with a clear picture what >whitespace is and isn't being passed on through the processor to an >application. Can someone clarify this for me? All white space in the document, regardless of where it appears, must be passed through to the application under all circumstances. One twist on this - line-end sequences (CR, LF, CRLF) are all normalized to a single LF. You might want to take a look at the annotated spec at xml.com >Question 3: > "A validating XML processor must also inform the application >which of these characters constitute white space appearing in element >content." > >Do I understand correctly, that although the application is informed of >this white space in element content, all this white space is still >passed on? Yes. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shin at comeng.chungnam.ac.kr Sat Aug 1 03:43:15 1998 From: shin at comeng.chungnam.ac.kr (Dongwook Shin) Date: Mon Jun 7 17:03:20 2004 Subject: Looking for a partner in commercializing an efficient IR engine for SGML/XML data Message-ID: <35C2717D.70F697D4@comeng.chungnam.ac.kr> Hello, I am looking for a partner in commercializing an efficient information retrirval engine for SGML/XML data we have developed recently. The engine employs BUS (Bottom Up Scheme) technique that I devised, by which indexing overhead can be minimized. The basic idea of BUS is that indexing is performed only at the lowest levels of the document structure, while retrieval at a higher level can be done at run time by gathering index information made at the lowest levels. From an experiment, the index overhead amounts to 30 percent of the source documents tagged in SGML and the retrieval time is fast as well. BUS allows the element search and retrieval at any level in the document structure including: (1) nested structural search (searching elements that are ancestors of another elements) (2) content search (3) element traversal at an arbitrary level (4) retrieval of the elements in documents corresponding to a specific element in a DTD As for the BUS technique, we demonstrated as well as published a technical paper in the Digital Libraries '98. The response of the demonstration was so good. If you have an interest, you can test it with a JDK 1.1.5 enabled browser in http://savage.comeng.chungnam.ac.kr/~sgml In this site, you can download a technical paper as well as test the demo system. Any inquiry about the system or cooperation is welcome to: E-mail : shin@comeng.chungnam.ac.kr FAX: +82-42-822-4997 Postal mail: Dongwook Shin, Professor Department of Computer Engineering, Chungnam National University 220 Kung-Dong, Yusong-Gu 305-764 Republic of Korea Thanks for your reading Dongwook Shin -- Dongwook Shin Department of Computer Engineering, Chungnam National University, Korea E-mail: shin@comeng.chungnam.ac.kr FAX: +82-42-822-4997 URL: http://savage.comeng.chungnam.ac.kr/~shin/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmodre at edu.uni-klu.ac.at Sat Aug 1 10:31:13 1998 From: jmodre at edu.uni-klu.ac.at (Juergen Modre) Date: Mon Jun 7 17:03:20 2004 Subject: xml parser toolkits for "legacy" environment? References: <35c22d344f40004@laurel.kp.org> Message-ID: <35C2D12F.8F0BFC36@edu.uni-klu.ac.at> Biron,Paul V wrote: > Is anyone out there working on tools that would allow someone who is > confined to "legacy" environments (COBOL, FORTRAN, etc. for programming > languages and MUMPS, OS/400, MVS, etc. for operating systems) to use > XML? You can e.g. use the free "XML Generator" from DataChannel (www.datachannel.com) to translate legacy data to XML. "The DataChannel XML Generator lets you translate data from arbritary sources to XML. Starting from delimited text files, you can XML-enable ANY application" Hope this helps & all the best Juergen ------------------------------------------------------------------- JUERGEN MODRE | Phone: +43 4214 2320 Reisdorf 6 | Mobile: +43 664 233 22 22 A-9371 Brueckl | E-mail: jmodre@edu.uni-klu.ac.at Austria (Europe) | WWW: http://www.edu.uni-klu.ac.at/~jmodre ------------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eriblair at mediom.qc.ca Sat Aug 1 18:56:45 1998 From: eriblair at mediom.qc.ca (Eric Riblair) Date: Mon Jun 7 17:03:20 2004 Subject: HELP ME PLEASE ... ERROR LOADING MESSAGES FROM MSXML applet. Message-ID: <3.0.1.32.19980801125939.0090f5e0@mediom.qc.ca> "When" I'd try to load an xmldso applet in an IE4.01 for Mac ... I had a response like this: ---------------------------------------------------------------------------- ---------------------------------------- "An...Error" loading class: com.ms.com.ComSuccessException java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.xml.dso.XMLRowsetProvider java.lang.ClassNotFoundException: com.ms.osp.OLEDBSimpleProvider Error loading class: com.ms.com.ComSuccessException java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.xml.dso.XMLRowsetProvider java.lang.ClassNotFoundException: com.ms.osp.OLEDBSimpleProvider java.lang.ClassNotFoundException: com.ms.xml.dso.XMLRowsetProvider at com/ms/vm/loader/URLClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Cla ss; (URLClassLoader.java:0:0x28) at java/lang/ClassLoader.loadClassInternal(Ljava/lang/String;Z)Ljava/lang/Class ; (ClassLoader.java:0:0x1f) at com/ms/xml/dso/SchemaNode.createElement(Z)V (XMLDSO.java:0:0x0) at com/ms/xml/dso/SchemaNode.setRow(Lcom/ms/xml/util/Name;)Lcom/ms/xml/dso/Sche maNode; (XMLDSO.java:0:0xc) at com/ms/xml/dso/XMLDSO.generateSchema(Lcom/ms/xml/om/Element;Lcom/ms/xml/dso/ SchemaNode;)V (XMLDSO.java:0:0x32) at com/ms/xml/dso/XMLDSO.updateSchema()V (XMLDSO.java:0:0x6a) at com/ms/xml/dso/XMLDSO.init()V (XMLDSO.java:0:0xf0) at com/ms/jam/AppletPanel.doAppletInit()V (AppletPanel.java:0:0x35) at com/ms/jam/AppletPanel.doAppletStateChange(I)V (AppletPanel.java:0:0x2f) at com/ms/jam/AppletViewerPanel.runApplet()V (AppletViewerPanel.java:0:0xba) at com/ms/jam/JAMAppletViewer.run()V (JAMAppletViewer.java:0:0x7) at java/lang/Thread.run()V (Thread.java:0:0x10) Does that mean anything to someone in this list ... Thanks for any help, Eric xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlapp at webmethods.com Sat Aug 1 19:15:31 1998 From: jlapp at webmethods.com (Joe Lapp) Date: Mon Jun 7 17:03:20 2004 Subject: White Space In-Reply-To: <3.0.32.19980731160714.00c529f0@207.34.179.21> Message-ID: <199808011715.NAA06738@bag-1.mail.digex.net> At 04:07 PM 7/31/1998 -0700, Tim Bray wrote: >All white space in the document, regardless of where it appears, must >be passed through to the application under all circumstances. One >twist on this - line-end sequences (CR, LF, CRLF) are all normalized >to a single LF. You must be referring only to content. Per (3.3), whitespace in attribute values is also subject to normalization. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Aug 1 20:05:00 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:20 2004 Subject: LISTRIVIA (was Re: HELP ME PLEASE ...) In-Reply-To: <3.0.1.32.19980801125939.0090f5e0@mediom.qc.ca> Message-ID: <3.0.1.16.19980801190510.84f75c5c@pop3.demon.co.uk> At 12:59 01/08/98 -0400, Eric Riblair re-posted [... stack trace/error-log deleted ...] Please do not repost messages - and certainly not at near-daily intervals. There is a large readership of this list and if you don't get help from your first message, reposting isn't going to help (it will simply annoy most people). Two points: - you have crossposted to 3 other lists both times. This is regarded as poor etiquette and makes it even less likely that you will get help from either list. - it is extremely difficult to diagnose many problems over the 'Net. Unless it's immediately obvious what is wrong (i.e. it's a common mistake or someone has seen it already) it probably depends on your precise environment. P. We sympathise with these types of problem - we all have them. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Sat Aug 1 21:39:20 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:03:20 2004 Subject: XML Developers' Conference, August 20-21 Message-ID: <199808011936.MAA26741@boethius.eng.sun.com> A two-day technical conference for XML, XSL, and XLL developers will be held Thursday and Friday, August 20 and 21, in Montreal, Canada. Cosponsored by the Graphic Communications Association (GCA) and the Organization for the Advancement of Structured Information Standards (OASIS), the XML Developers' Conference extends the highly successful series of "XML Developers' Days," which began at the International World Wide Web conference in 1997 and became an independent biannual event last August. Like the previous events, this UnConference(tm) resists the bigger-is-better trend of recent years and maintains the concept of a focused, single-track event featuring just the very best presentations from the cream of XML geekdom. This is a conference by developers, for developers, in a locale noted for its French-Canadian culture, great food, and low prices. If you come wearing a suit we won't actually turn you away, but we don't need your business so badly that we're willing to lower the level of discourse. This time the presentations include up-to-the-minute in-depth briefings on XML support from Microsoft, Netscape, and Sun; demonstrations of XML/XSL software; XML applications for RDF and SMIL; and presentations on XML schemas, XLink, architectural forms processing, and the use of XML in knowledge management. The presenters include six members of the W3C XML Working Group that produced the XML specification, and the conference is led by Jon Bosak, Chairman of the W3C XML WG. See the complete conference schedule at http://www.gca.org/conf/xmldev98/ The XML Developers' Conference immediately follows the GCA Metastructures 1998 Conference in the same location, Le Centre Sheraton in Montreal, August 18-19. The Metastructures Conference is the premiere annual event for those interested in the technical side of XML-based information management, including use of the emerging XLL specification for advanced hyperlinking. For complete information on the Metastructures Conference, see http://www.gca.org/conf/meta98/ A special rate is available for those wishing to attend both conferences. The Metastructures Conference is preceded on August 17 by a day of tutorials on architectural forms, XML, XSL, XLL, DSSSL, and SMIL, so if you're not up to attending the XML Developers' Conference right now, you will be after taking the appropriate tutorial! If you are seriously interested in the XML family of standards, here's your chance to get the very latest news on industry support for XML technologies, hear from the people at the center of this next-generation infrastructure for the Web, and share information and opinions with people like yourself at the forefront of the XML movement. Be there! ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems 901 San Antonio Road, MPK17-101, Palo Alto, California 94303 ISO/IEC JTC1/SC34/WG4::NCITS V1::OASIS::W3C XML WG::W3C XSL WG ---------------------------------------------------------------------- It is earlier than we think. -- Vannevar Bush ---------------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eric at w3.org Sun Aug 2 07:09:11 1998 From: eric at w3.org (Eric Prud'hommeaux) Date: Mon Jun 7 17:03:20 2004 Subject: SAX: ignorable whitespace question Message-ID: Should "abcd#20$20efgh" be reported as: characters("abcd#20#20efgh") characters("abcd#20efgh") characters("abcd") ignorableWhitespace(#20#20) characters("efgh") characters("abcd") ignorableWhitespace(#20) characters("efgh") Also, is there a more appropriate forum for this sort of question? -eric xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Aug 2 11:03:11 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:20 2004 Subject: SAX: ignorable whitespace question In-Reply-To: Message-ID: <3.0.1.16.19980802100323.7a2fc5b2@pop3.demon.co.uk> At 01:08 02/08/98 -0400, Eric Prud'hommeaux wrote: >Should "abcd#20$20efgh" be reported as: > characters("abcd#20#20efgh") > characters("abcd#20efgh") > characters("abcd") ignorableWhitespace(#20#20) characters("efgh") > characters("abcd") ignorableWhitespace(#20) characters("efgh") I suspect that your question isn't sufficiently clearly phrased for a clear answer. SAX needs to be read in conjunction with the XML RECommendation. The concept of ignorable whitespace depends on what DTD information is provided. > >Also, is there a more appropriate forum for this sort of question? XML-DEV (not DML) is where most people who are interested in SAX will look to discuss it at present. As SAX becomes more integrated into XML tools then there may well be introductory tutorials on how to use SAX and what SAX does and does not do. In the present case I suspect you should (a) read the SAX documentation carefully (b) write some simple test code to find out exactly what some common SAX implementations *do*. Create some test documents with and without DTDs and feed them to SAX running under your test code. If you then find the results appear to violate the documentation, or vary between implementations, I am sure people would be interested and make useful comments. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Aug 2 11:25:14 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:21 2004 Subject: SAX: ignorable whitespace question In-Reply-To: Message-ID: <3.0.1.16.19980802102459.7a2fe062@pop3.demon.co.uk> I proably confused you with my previous answer... I was replying to your question about which forum to ask questions on. At 01:08 02/08/98 -0400, Eric Prud'hommeaux wrote: >Should "abcd#20$20efgh" be reported as: Assuming this is in element content (e.g. abcd efgh and means "abcd efgh", then it is passed without change, using characters(). Ignorable whitespace occurs between elements and not inside character strings. XML (unlike HTML) does not normalise character content and all characters that are not markup are passed to the application. Ignorable whitespace is a device that SAX provides to help the application decide what action it may be able to take. If you are writing a SAX-based application you will need to understand this concept. P Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eric at w3.org Sun Aug 2 18:40:21 1998 From: eric at w3.org (Eric Prud'hommeaux) Date: Mon Jun 7 17:03:21 2004 Subject: SAX: ignorable whitespace question In-Reply-To: <3.0.1.16.19980802102459.7a2fe062@pop3.demon.co.uk> Message-ID: On Sun, 2 Aug 1998, Peter Murray-Rust wrote: > XML (unlike HTML) does not normalise character content > and all characters that are not markup are passed to the application. > Ignorable whitespace is a device that SAX provides to help the application > decide what action it may be able to take. If you are writing a SAX-based > application you will need to understand this concept. Oops, I was reading the XML spec without casting away a couple of HTML assuptions. Thank you. I'm writing a parser (in perl) now and wasn't sure I should take the actions of Microstar's SAX driver as gospel. Admittedly, I've been lazy about testing other implementations, but I was hoping for an authoritative answer rather than an empirical study. I've also crawled around Microstar's and Megginson's web spaces looking for the SAX spec or at least a whitepaper. Do you have a pointer? > At 01:08 02/08/98 -0400, Eric Prud'hommeaux wrote: > >Should "abcd#20$20efgh" be reported as: > > Assuming this is in element content (e.g. abcd efgh > and means "abcd efgh", then it is passed without change, using > characters(). Ignorable whitespace occurs between elements and not inside > character strings. In that regard, it would seem that text is handled differently from system identifiers and attribute values. How about leading and trailing whitespace, or tags with just whitespace? For example, is "some text\r\n\t" reported completely as characters and not split into characters("some text") and ignorable("\r\n\t")? Is the whitespace in "\n \n" ignorable? I also assume from the XML spec that SAX is acting in the role of XML processor and must translate \r's so it would really be characters(" some text\n\t"). Current (apparently overzealous) algorythm: ##### # reportText - break up ignorable whitespace from characters sub reportText { my $self = shift; my $characters = shift; # fold \r\n and \r into \n - XML:2.11 $characters =~ s/\r\n/\n/g; $characters =~ tr/\r/\n/g; if ($characters =~ m/\A(\s+)/) { # leading ignorables $self->ignorableWhitespace($&); $characters = $'; } while ($characters =~ m/(\s{2,})/) { # nested ignorables $self->characters($`) if ($` ne ''); $self->ignorableWhitespace($&) if ($& ne ''); $characters = $'; } if ($characters =~ m/(\s+)\Z/) { # trailing ignorables $self->characters($`) if ($` ne ''); $self->ignorableWhitespace($&) if ($& ne ''); } } Algorythm Lite: sub reportText { my $self = shift; my $characters = shift; # fold \r\n and \r into \n - XML:2.11 $characters =~ s/\r\n/\n/g; $characters =~ tr/\r/\n/g; if ($characters =~ m/\S/) { # any non-white space? $self->characters($characters); } else { $self->ignorableWhitespace($&); } } -eric xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Aug 2 20:03:41 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:21 2004 Subject: XSchema: email problems Message-ID: If anyone attempted to send me private email regarding XSchema on Friday, Saturday, or this morning, please resend it to simonstl@ibm.net. The Microsoft Network appears to be losing most of my messages; some test messages I sent bounced, while others disappeared without a trace. I'll have a new primary address in about a month anyway. Thanks for your cooperation and your help, Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Mon Aug 3 04:12:05 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:21 2004 Subject: SAX: ignorable whitespace question In-Reply-To: Message-ID: <199808030215.AA01867@murata.apsdc.ksp.fujixerox.co.jp> On Sun, 2 Aug 1998, Peter Murray-Rust wrote: > XML (unlike HTML) does not normalise character content > and all characters that are not markup are passed to the application. > Ignorable whitespace is a device that SAX provides to help the application > decide what action it may be able to take. If you are writing a SAX-based > application you will need to understand this concept. I think that CR, LF, or CR+LF are always normalized into LF. Eric Prud'hommeaux wrote: > In that regard, it would seem that text is handled differently from > system identifiers and attribute values. As for attribute values, we do have different normalization. As for systems identifiers, I do not understand your point. > How about leading and trailing whitespace, or tags with just > whitespace? For example, is "some text\r\n\t" reported > completely as characters and not split into characters("some text") > and ignorable("\r\n\t")? Right. They are not split. >Is the whitespace in "\n \n" > ignorable? If 1) the DTD is available, 2) the element type t1 has an element content, and 3) an XML processor uses the DTD to distinguish element content and mixed content, then the whitespace in is ignorable. >I also assume from the XML spec that SAX is acting in the > role of XML processor and must translate \r's so it would really be > characters(" some text\n\t"). Quite. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bock at informatik.uni-bremen.de Mon Aug 3 10:48:21 1998 From: bock at informatik.uni-bremen.de (Matthias Bock) Date: Mon Jun 7 17:03:21 2004 Subject: xml-dev Digest V1 #62 In-Reply-To: owner-xml-dev-digest@ic.ac.uk's message of "Tue, 14 Jul 1998 02:00:11 +0100" References: Message-ID: <1phfzue9jv.fsf@lenina.informatik.uni-bremen.de> bla -- Dipl. inform. Matthias Bock Chrystal Software http://www.chrystal.com tel: 0421 4366093 fax: 0421 4366083 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Joel.Jeffery at drake.co.uk Mon Aug 3 16:01:21 1998 From: Joel.Jeffery at drake.co.uk (Joel Jeffery) Date: Mon Jun 7 17:03:21 2004 Subject: Open Software Description (OSD) and Microsoft Internet Compondent Download (MSICD) DTD Files Message-ID: Hi. I'm having severe difficulties trying to track down these two files. They're not where they should be: http://www.microsoft.com/standards/osd/osd.dtd http://www.microsoft.com/standards/osd/msicd.dtd I apologise if I'm mailing the wrong group, but I've been banging my head against the wall trying to uncover some decent documentation for OSD and MSCID, but the key bits (the dtds) are nowhere to be found. Many thanks in advance, joel xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 3 16:41:20 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:03:21 2004 Subject: Open Software Description (OSD) and Microsoft Internet Compondent Download (MSICD) DTD Files Message-ID: <3.0.32.19980803103519.0069855c@polaris.net> At 03:01 PM 8/3/98 +0100, Joel Jeffery wrote: >I'm having severe difficulties trying to track down these two files. >They're not where they should be: >http://www.microsoft.com/standards/osd/osd.dtd Now at: http://www.eu.microsoft.com/standards/osd/default.asp#appa >http://www.microsoft.com/standards/osd/msicd.dtd Don't know about this one; sorry. John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wchang at nist.gov Mon Aug 3 17:51:07 1998 From: wchang at nist.gov (Wo Chang, x3439) Date: Mon Jun 7 17:03:21 2004 Subject: What SAXDOM drivers available ? Message-ID: <199808031549.LAA02141@pion.ncsl.nist.gov> Can anyone tells me what other SAXDOM (or FREEDOM) drivers available other than MSXML and AElfred? Thanks in advanced! --Wo xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jctsai at fedex.com Mon Aug 3 18:52:53 1998 From: jctsai at fedex.com (January Tsai) Date: Mon Jun 7 17:03:21 2004 Subject: What SAXDOM drivers available ? Message-ID: <199808031652.AA29175@gateway.fedex.com> Try www.sil.org/sgml/sgml.html and go to XML tools and applications. There are lots of free XML parsers: DXP from DataChannel, Alpha from IBM, ... -jt Can anyone tells me what other SAXDOM (or FREEDOM) drivers available other than MSXML and AElfred? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 3 19:30:23 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:21 2004 Subject: Non-Validating XML Parsers: Requirements Message-ID: <35C5F396.5DAE140F@locke.ccil.org> (There is nothing official about this: it is what I glean from reading the XML recommendation plus applying reason and common sense.) NVP = non-validating conforming parser(s). Other capitalized terms are used as in RFC 2119. 1. An NVP MUST check the document entity for well-formedness and report any violations. 2. An NVP MAY check external entities (including the external DTD subset, external parsed entities, and external parameter entities) for well-formedness, and if it does so, MUST report any violations. 3. An NVP MUST process certain attribute list and entity declarations, and use them to normalize attribute values, include the replacement text of internal entities, and supply default attribute values. 4. An NVP MAY process attribute list and entity declarations that appear in external entities (including the external DTD subset and external parameter entities). 5. An NVP MUST NOT process attribute list and entity declarations that logically follow references to any parameter entities that have not been read by the NVP. As usual, everything in the external DTD subset logically follows everything in the internal DTD subset. 6. An NVP MAY NOT signal an error if a reference is made to an undeclared entity, if the entity was declared in some external entity. 7. An NVP MAY NOT signal an error if a reference is made to an unparsed entity, if the entity was declared in some external entity. 8. An NVP MAY NOT signal an error if an entity refers to itself directly or indirectly, if either the entity or some other part of the entity circle was declared in some external entity. 9. An NVP MAY NOT signal an error if a reference to an external entity is made in an attribute value, if the entity was declared in some external entity. 10. An NVP MAY NOT signal an error if a reference to an entity (other than a parameter entity) is made within the DTD, if the entity was declared in some external entity. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Aug 3 19:32:00 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:21 2004 Subject: Non-Validating XML Parsers: Requirements Message-ID: <35C5F3A7.9B560726@locke.ccil.org> (There is nothing official about this: it is what I glean from reading the XML recommendation plus applying reason and common sense.) NVP = non-validating conforming parser(s). Other capitalized terms are used as in RFC 2119. 1. An NVP MUST check the document entity for well-formedness and report any violations. 2. An NVP MAY check external entities (including the external DTD subset, external parsed entities, and external parameter entities) for well-formedness, and if it does so, MUST report any violations. 3. An NVP MUST process certain attribute list and entity declarations, and use them to normalize attribute values, include the replacement text of internal entities, and supply default attribute values. 4. An NVP MAY process attribute list and entity declarations that appear in external entities (including the external DTD subset and external parameter entities). 5. An NVP MUST NOT process attribute list and entity declarations that logically follow references to any parameter entities that have not been read by the NVP. As usual, everything in the external DTD subset logically follows everything in the internal DTD subset. 6. An NVP MAY NOT signal an error if a reference is made to an undeclared entity, if the entity was declared in some external entity. 7. An NVP MAY NOT signal an error if a reference is made to an unparsed entity, if the entity was declared in some external entity. 8. An NVP MAY NOT signal an error if an entity refers to itself directly or indirectly, if either the entity or some other part of the entity circle was declared in some external entity. 9. An NVP MAY NOT signal an error if a reference to an external entity is made in an attribute value, if the entity was declared in some external entity. 10. An NVP MAY NOT signal an error if a reference to an entity (other than a parameter entity) is made within the DTD, if the entity was declared in some external entity. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Aug 3 19:35:50 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:21 2004 Subject: XCatalog revised Message-ID: <35C5F4BE.8B5C0018@locke.ccil.org> See http://www.ccil.org/~cowan/XML/XCatalog.html for the current version of XCatalog. The next version will hopefully be an Internet-Draft with full references. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Mon Aug 3 19:36:03 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:21 2004 Subject: API versioning in SAX Message-ID: <5030300023653242000002L022*@MHS> "No, because even parsers that support level 1 (the current level) may vary in their behavior, because non-validating parsers can produce different things (expand external parsed entities or not, understand ATTLISTs or not, etc.) If your application depends on these things, you need to be able to check whether the parser you are using does so. And I do believe that people will replace parsers, as smaller/faster/ better ones come out, in their applications. A major impetus of Java is to avoid monolithic apps where the user is stuck with the app exactly as packaged." Just to play the devil's advocate, are you sure you are not creating a technical solution to what everyone is more likely to solve with a non-technical one? If I'm the administrator of my server or my workstation, and I see a new SAX driver out there, wouldn't I just read the README before I even downloaded it to make sure that its capable of doing what my current does (plus more maybe?) I doubt very seriously I'd just download new drivers and try them until one fails to fail, ya know? And, even if I did, the fact that it fails to fail on the 3 apps I have now, doesn't mean it supports what I want to support on app #4, so I'm going to just read the docs and see what it supports most likely. Also, once I know what the SAX driver can do, and know that it does what I need, why would I want my application playing "20 Questions" every time I run it, when I know what the answer is going to be every time? Why waste the time, when the kind of situation that you envision might not even happen very often? Have you really checked and seen how likely people are to blindly use new XML driver software in such as way as to create the problem you've presented to be solved? ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Aug 3 19:51:14 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:21 2004 Subject: API versioning in SAX References: <5030300023653242000002L022*@MHS> Message-ID: <35C5F86E.533B915F@locke.ccil.org> Dean Roddey scripsit: > If I'm the administrator of my server or my workstation, and > I see a new SAX driver out there, wouldn't I just read the README before I even > downloaded it to make sure that its capable of doing what my current does (plus > more maybe?) The trouble is that these are subtle features. See the post I just sent out, riddled with MUSTs and MAY NOTs. Of the 10 items mentioned, compliant non-validating parsers can vary in 7 of them, which means there are something like 2^7 classes of non-interchangeable (but still compliant) parsers. The docs may not even be specific on these points. Any SAX app that depends on any of those 7 features better have some way of checking whether or not the SAX parser supports them, or else uniformly rely on none of them. > And, even if I did, the fact that it fails to > fail on the 3 apps I have now, doesn't mean it supports what I want to support > on app #4, so I'm going to just read the docs and see what it supports most > likely. I think this point is a red herring. Different SAX apps, due to their different requirements, may need different parsers. It's either some such inquiry mechanism as this, or else have every app keep a list of "certified" parsers, and have each app writer spend time certifying every old and new parser. > Also, once I know what the SAX driver can do, and know that it does what I > need, why would I want my application playing "20 Questions" every time I run > it, when I know what the answer is going to be every time? Why waste the time, > when the kind of situation that you envision might not even happen very often? It's a cheap check. Call a getFeatures method, get an int back, AND it with the feature bits you need, and do a numeric = comparison to make sure they're all set. That's it. Then when you change SAX parsers in future, your app will either work, or will break early with an "Insufficiently flavorful SAX parser" error. > Have you really checked and seen how likely people are to blindly use new XML > driver software in such as way as to create the problem you've presented to be > solved? How can I? The whole area is so new.... -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Mon Aug 3 19:54:13 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:03:21 2004 Subject: Non-Validating XML Parsers: Requirements Message-ID: <000801bdbf07$dc6c4000$1e09e391@mhklaptop.bra01.icl.co.uk> >Other capitalized terms are used as in RFC 2119. ...>6. An NVP MAY NOT signal an error if ... I don't know offhand what RFC 2119 says on the matter, and I haven't got time to look, but any set of rules that includes the term "may not" is liable to be misinterpreted by half its audience. When I am reviewing specifications, "may not" always gets a thumbs down. I don't much like "may" either. Everything is permitted unless the specification prohibits it, a sentence whose main verb is "may" therefore says nothing. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Mon Aug 3 20:00:00 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:03:21 2004 Subject: API versioning in SAX Message-ID: <000f01bdbf08$d031a540$1e09e391@mhklaptop.bra01.icl.co.uk> If I'm the administrator of my server or my workstation, and I see a new SAX driver out there, wouldn't I just read the README ... That's surely the whole point. The guy who writes the application and the guy who chooses the parser are not the same person, so the former wants to check at run-time that the latter hasn't screwed him up. Incidentally, the thing that's most likely to go wrong when you switch parsers, in my experience, is that character data is split up differently. Every time I use SAX, I forget that the parser is allowed to hand me data one character at a time if it chooses. Perhaps someone should write a SAX parser that does just that, so I can test that my application would cope with it. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Mon Aug 3 20:42:19 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:21 2004 Subject: API versioning in SAX Message-ID: On Mon, 3 Aug 1998, Michael Kay wrote: > the parser is allowed to hand me data one character at a > time if it chooses. Perhaps someone should write a SAX > parser that does just that, so I can test that my > application would cope with it. My as yet unreleased HXP parser could do that. It is a production grammer based parser. On the lowest level it throws start and stop events for each production in the XML spec. It does this right down to the type of character. This means that the data event for each character is thrown separately. I naturally planned on buffering these in my SAX driver, but if it isn't that much trouble, I'll build in a mode to do this. :-) --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From colds at nwlink.com Mon Aug 3 21:38:17 1998 From: colds at nwlink.com (Chris Olds) Date: Mon Jun 7 17:03:21 2004 Subject: Do you understand XML namspaces? Message-ID: <008d01bdbf16$16475040$dc59fcc6@albert.salsa.walldata.com> Not so fast - there is a new Working Draft out, and when they said the previous version "may be updated, replaced or obsoleted", they weren't kidding! http://www.w3.org/TR/WD-xml-names was updated yesterday (August 2nd). /cco "I'd explain it to you, but I don't understand it yet!" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Aug 3 21:43:18 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:21 2004 Subject: Non-Validating XML Parsers: Requirements References: <000801bdbf07$dc6c4000$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <35C612C4.E5210DF5@locke.ccil.org> Michael Kay wrote: > I don't know offhand what RFC 2119 says on the matter, and I > haven't got time to look, but any set of rules that includes > the term "may not" is liable to be misinterpreted by half > its audience. When I am reviewing specifications, "may not" > always gets a thumbs down. *sigh* I do wish people wouldn't review things without reading them. I happen to agree with you about MAY NOT, but that's what RFC 2119 says. The RFC is about 600 words long, BTW, and here's a link: http://www.isi.edu/in-notes/rfc2119.txt . > I don't much like "may" either. Everything is permitted > unless the specification prohibits it, a sentence whose main > verb is "may" therefore says nothing. *Everything*? So if a specification for a C compiler doesn't *say* that compiling a strictly conforming program does *not* make demons fly out of your nose, then the compiler is allowed to do that? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Mon Aug 3 21:46:28 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:22 2004 Subject: Non-Validating XML Parsers: Requirements In-Reply-To: <35C5F396.5DAE140F@locke.ccil.org> Message-ID: On Mon, 3 Aug 1998, John Cowan wrote: > (There is nothing official about this: it is what I glean from > reading the XML recommendation plus applying reason and common sense.) > NVP = non-validating conforming parser(s). Other capitalized terms > are used as in RFC 2119. I am in the middle of implementing all this stuff in my HXP parser right now and have been groveling through the spec sorting out many of these issues, so this is very helpfull. > 1. An NVP MUST check the document entity for well-formedness and > report any violations. Meaning, it MUST check ALL the well formedness constraints, and MAY check validity constraints. > 3. An NVP MUST process certain attribute list and entity declarations, > and use them to normalize attribute values, include the replacement > text of internal entities, and supply default attribute values. default attribute values...mmm...that is what I am coding today :-) If an attribute is REQUIRED or IMPLIED, an NVP doesn't have to touch it or deal with it at all. Otherwise an NVP must check if there is a value for an attribute and if not, include the default value. If the attribute is FIXED, an NVP is not required to check if the instance value matches the declared value because that is a validity constraint. This means that if you supply an instance value for a FIXED attribute, where that instance differs from the declared fixed value, that an NVP MAY (if it supports the Fixed Attribute Default VC) or MAY NOT supply the correct declared value for this attribute. > 5. An NVP MUST NOT process attribute list and entity declarations that > logically follow references to any parameter entities that have not > been read by the NVP. As usual, everything in the external > DTD subset logically follows everything in the internal DTD subset. Feed the following document to an NVP which doesn't read any external entities: ]> A &yy; B &zz; C What should it print out? Currently HXP sees the reference to %xx; while processing yy, realizes this has not been read, and from that moment on will no longer process any entity declarations, including those of yy and zz. It then throws a not well formed exception in Test content because &yy; has not been declared. When I feed this to AElfred (file.ent doesn't actually exist), it gives me "A 3 B 1 3 4 C", which I think must be a bug. XP throws an exception "parameter entity reference in entity value in internal subset", which means that it processed the declaration (correctly?), the thing here is the table in section 4.4 of the spec says that PE's are not recognized in content, so I thought XP would have passed right over this? --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 3 22:00:00 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:22 2004 Subject: Do you understand XML namspaces? In-Reply-To: Your message of "Mon, 03 Aug 1998 12:36:57 PDT." <008d01bdbf16$16475040$dc59fcc6@albert.salsa.walldata.com> Message-ID: <199808031958.VAA21008@chimay.loria.fr> colds@nwlink.com said: ] http://www.w3.org/TR/WD-xml-names was updated yesterday (August 2nd). Just one thing to say : GASP !!! WD-xml-names-19980802 said: ] The namespace prefix, unless it is xml or xmlns, must have been ] declared in a namespace declaration. Hum !!! And what about the following example (15 lines after within the WD) : ...strange. The XML NS for html is declared after Message-ID: <35C61A96.1DE8E8D7@locke.ccil.org> Chris Hubick wrote: > Meaning, it MUST check ALL the well formedness constraints, and > MAY check validity constraints. Correct. > default attribute values...mmm...that is what I am coding today > :-) If an attribute is REQUIRED or IMPLIED, an NVP doesn't have to touch > it or deal with it at all. Otherwise an NVP must check if there is a > value for an attribute and if not, include the default value. If the > attribute is FIXED, an NVP is not required to check if the instance value > matches the declared value because that is a validity constraint. So far so good. > This means that if you supply an instance value for a FIXED attribute, > where that instance differs from the declared fixed value, that an NVP > MAY (if it supports the Fixed Attribute Default VC) or MAY NOT supply the > correct declared value for this attribute. That's not clear. It is an error for the document to supply a value other than the FIXED one, so the parser may return the FIXED value, or the application's value, or make demons fly out of your nose. (See previous posting, or comp.std.c++). > > 5. An NVP MUST NOT process attribute list and entity declarations that > > logically follow references to any parameter entities that have not > > been read by the NVP. As usual, everything in the external > > DTD subset logically follows everything in the internal DTD subset. > > Feed the following document to an NVP which doesn't read any external > entities: > > > > > ]> > A &yy; B &zz; C This document is not WF, and every parser should detect it (but some do not), to wit: parameter entity references in the internal subset can only come between declarations, not within one. See clause 2.8, the WF constraint called "PEs in Internal Subset". If you move the DTD into the external subset, then the result is unclear to me. I suspect that any parser that reads the external subset is compelled to read external parameter entities as well, so that the result is A 2 [whatever] 3 B 1 2 [whatever] 3 4 C > When I feed this to AElfred (file.ent doesn't > actually exist), it gives me "A 3 B 1 3 4 C", which I think must be > a bug. It's a bug in that Aelfred should throw an error. > XP throws an exception "parameter entity reference in entity value > in internal subset", which means that it processed the declaration > (correctly?) That is the correct action. > the thing here is the table in section 4.4 of the spec > says that PE's are not recognized in content, so I thought XP would have > passed right over this? Entity values are not the same thing as "content", which means literally the stuff within elements. Parameter entity references are allowed within (internal) entity values, general or parameter, but only if the entities in question are defined within the external subset. See clause 4.4.5. (Note that the following example is in error: "&YN;" should read "%YN;".) The table in 4.4 repays careful study. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bandar at WellsFargo.COM Mon Aug 3 22:22:16 1998 From: bandar at WellsFargo.COM (bandar@WellsFargo.COM) Date: Mon Jun 7 17:03:22 2004 Subject: unsubscribe Message-ID: <695ED9BA149FD1118C6C0001FA7E6AF3D60A48@xcem-casfo-03.wellsfargo.com> unsubscribe me -----Original Message----- From: Michael Kay [mailto:M.H.Kay@eng.icl.co.uk] Sent: Monday, August 03, 1998 10:55 AM To: John Cowan; XML Dev Subject: Re: Non-Validating XML Parsers: Requirements >Other capitalized terms are used as in RFC 2119. ...>6. An NVP MAY NOT signal an error if ... I don't know offhand what RFC 2119 says on the matter, and I haven't got time to look, but any set of rules that includes the term "may not" is liable to be misinterpreted by half its audience. When I am reviewing specifications, "may not" always gets a thumbs down. I don't much like "may" either. Everything is permitted unless the specification prohibits it, a sentence whose main verb is "may" therefore says nothing. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Mon Aug 3 22:39:14 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:03:22 2004 Subject: Revised namespaces draft available Message-ID: <199808032036.NAA27212@boethius.eng.sun.com> A major revision of the namespaces draft is now publicly available at http://www.w3.org/TR/WD-xml-names This draft incorporates a new attribute-based syntax for namespace declarations as well as new mechanisms for defaulting and scoping. The XML Working Group actively solicits feedback from early implementors of the revised draft and has set up a special mailing list to gather input for an editorial team that will review early implementation experiences. See the section titled "Status of this Document" near the beginning of the WD for details. Jon Bosak Chairman, W3C XML WG xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 3 22:59:23 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:22 2004 Subject: Non-Validating XML Parsers: Requirements Message-ID: <3.0.32.19980803135751.00bfebe0@207.34.179.21> At 01:29 PM 8/3/98 -0400, John Cowan wrote: >(There is nothing official about this: it is what I glean from >reading the XML recommendation plus applying reason and common sense.) >NVP = non-validating conforming parser(s). Other capitalized terms >are used as in RFC 2119. FWIW, I agree with John's write-up, except that the phrase MAY NOT is kind of misleading. The spec says that an NVP may fail to detect certain kinds of entity-related sins in the case that the entity was declared where the processor wasn't looking and wasn't required to look... the phrase MAY NOT suggests that the processor is forbidden to do certain things. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Mon Aug 3 23:07:15 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:22 2004 Subject: Non-Validating XML Parsers: Requirements In-Reply-To: <35C61A96.1DE8E8D7@locke.ccil.org> Message-ID: On Mon, 3 Aug 1998, John Cowan wrote: > > This means that if you supply an instance value for a FIXED attribute, > > where that instance differs from the declared fixed value, that an NVP > > MAY (if it supports the Fixed Attribute Default VC) or MAY NOT supply the > > correct declared value for this attribute. > > That's not clear. It is an error for the document to supply a value > other than the FIXED one, so the parser may return the FIXED value, > or the application's value, or make demons fly out of your nose. > (See previous posting, or comp.std.c++). Yes, it should throw an error if it understands the validity constraint, but if it doesn't the behaviour is undeterminded. > > > > > > > > > ]> > > A &yy; B &zz; C > > This document is not WF, and every parser should detect it (but > some do not), to wit: parameter entity references in the internal > subset can only come between declarations, not within one. > See clause 2.8, the WF constraint called "PEs in Internal Subset". I thought this document was well formed, I read "PEs in Internal Subset" to mean that you can't have stuff like: but you can have: '> %xx; ]> because the grammer doesn't allow the PEReferences where they occur in the first example (within declarations): [48] cp ::= (Name | choice | seq) ('?' | '*' | '+')? but it does in the second (where declarations occur): [28] doctypedecl ::= ' Message-ID: <3.0.1.16.19980803231152.2197b826@pop3.demon.co.uk> At 19:01 03/08/98 +0100, Michael Kay wrote: >If I'm the administrator of my server or my workstation, and >I see a new SAX driver out there, wouldn't I just read the >README ... > >That's surely the whole point. The guy who writes the >application and the guy who chooses the parser are not the >same person, so the former wants to check at run-time that >the latter hasn't screwed him up. The current JUMBO2 has an option to load any SAX-based parser from a menu button, so you can experiment in a fairly interactive manner. At this stage of the game I'd suggest that application writers try more than one parser to make sure that consistent results are being generated from SAX. And if different parsers give different results it might be worth reporting those here in case the authors were unaware. In any case a systematic comparison of any such differences between parsers would be a public service :-) P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 4 00:45:21 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:22 2004 Subject: Revised namespaces draft available In-Reply-To: <199808032036.NAA27212@boethius.eng.sun.com> Message-ID: <3.0.1.16.19980803233224.2197a11c@pop3.demon.co.uk> At 13:36 03/08/98 -0700, Jon Bosak wrote: >A major revision of the namespaces draft is now publicly available at > > http://www.w3.org/TR/WD-xml-names > >This draft incorporates a new attribute-based syntax for namespace >declarations as well as new mechanisms for defaulting and scoping. >The XML Working Group actively solicits feedback from early >implementors of the revised draft and has set up a special mailing >list to gather input for an editorial team that will review early >implementation experiences. See the section titled "Status of this >Document" near the beginning of the WD for details. > >Jon Bosak >Chairman, W3C XML WG Many thanks for posting this, Jon, I have been privileged to observe process by which this spec was produced and when it was near completion made an offer to the XML-WG that XML-DEV might be able to assist in informally helping early implementations of the spec. I append what I wrote (about a week ago]: ---------------------------------------------------------------------------- ------ The XML-WG is releasing the next draft of XML-names and as this is of particular interest to XML-DEV members, I'll try to set the scene. As you will recall, XML-DEV has no formal standing in the W3C process but unofficially its presence has been of value to the process. I suggested on the XML-SIG list that XML-DEV could have a useful role to play in helping the active development of namespace implementations and received broad agreement to post this message. [NOTE: the W3C has a number of Activities, of which XML is one (others are DOM, RDF, P3P, MathML, etc.). Each has a chair and editorial board/team and/or WGs which produce WDs, and PRs. The XML-WG also oversees the XML-names development (which is central to several other activities). The XML-WG has chosen to have a SIG of about 100 members to which many problems are referred for discussion. The deliberations of the XML-WG and XML-SIG are confidential to W3C members and invited experts (which includes me and several other members of XML-DEV).] The XML-WG, XML-SIG and other W3C groups have spent (literally) thousands of e-mails discussing XML-names. It has turned out to be much more challenging than was originally anticipated. I have been privileged to see some of these discussions and I believe the people involved have shown great commitment and technical ability. Fairly recently it was decided to address the whole namespace problem (not just the deliberately limited version of 1998-05). The questions of scoping, global attributes and many other features have been very challenging but are now included in the draft. I ask you to take on trust that what is presented is the product of a huge amount of labour by committed people. You may feel that it could have been done otherwise, but I suggest that we don't pursue those thoughts but try to make the current draft work. I am very confident that *a* good solution has been reached. With this tool we shall be able to do some remarkable things. When/if we hit problems the WG will pick them up, and will take a view as to whether the spec needs any revision. There will be no need (or point) in lobbying them. As with other XML-DEV activities we are doing this as an experiment and because it's worth doing. It may or may not lead to protocols, software or other resources. It will almost certainly be a good idea to start small and expand, just as with SAX and XSchema. I'd suggest that we might: - collate experience from those who have actually implemented namespaces (somewhere in the 1997..1998-05 period). For example I discovered while browsing XML4J today that it has considerable namespace support, and I'm sure there are other tools (I'm happy to make the latest JUMBO2 available shortly - it has a simple namespace approach). - collate DTDs which have been developed to be namespace-aware. These will be essential for testing systems later. Examples of (I think) single-namespace DTDs include: - XSchema - MathML - IBTWSH - XML-data (if simplified to primitives) we can appeal for other examples (for example, I'd be happy to contribute VHG.dtd) - collect documents which adhere to these DTDs. As you can see I am assuming that DTDs (or schemas) are likely to be important for namespaces. I think we should be wary of addressing "well-formed tag soup" at this stage - that can come later, if at all. The issues that we'll need to consider include: - how can we manage prefixed and non-prefixed versions of a DTD? With and without validation. - how can we combine more than one DTD? With and without validation. There are also questions of the interfaces to namespace-aware: - elements - attributes - PIs In particular the XML and XLL specs define a number of XML:* attributes. At what stage should these be processed? Should there be a special module for processing xml-reserved elements (if any) and attributes? At what stage should software need to know the identity of the prefix, the URI, etc. Should we define a Name class/interface? These are challenging enough. Beyond that we have the questions of scoping - how to implement it, what its semantics are, how to treat default and global scopes. I'd suggest we take a day or two to think about this before commenting, and that we may be wise to take the simplest issues first. It won't help if our discussion is so broad that we get lost. This is an issue of great interest to W3C members and non-members alike. Offers of help will be extremely welcome, but don't be disappointed if other solutions or groups appear to be more appropriate for a particular problem. P. I am really looking forward to seeing this move forward. It will require patience and forbearance. We are moving into an area where semantics and ontology are important and this is why it is so tough, but exciting. In essence we are developing the first global mechanism for supporting ontology and if we can crack that we can do anything... ------------------------------------------------------------------------------ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 4 00:45:57 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:22 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 6 Message-ID: After an hour with the namespace draft, this is where I'm at. If I'm wildly dead wrong, as is often the case when I'm dealing with namespaces, please let me know. The FIXED declaration for the xmlns attribute and the removal of prefixes from subelements appear to be the main issues. I could change the attribute to xmlns:XSC and return the prefixes if that seems preferable. (I'm planning on overriding it again in the Doc element, and allowing others to override it in the More element, if that's helpful. Let me know! Being wrong can be fun too. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.0 XSchema Syntax This section describes the XSchema document syntax. The XSchema document is an XML document containing a single XSchema element in which information describing the schema is nested. The XSchema element must be preceded by an XML declaration and may be preceded by other declarations, comments, and processing instructions. 2.1 The XSchema Element The XSchema element is the root element for all XSchema documents. The declaration for the XSchema element is: The XSchema element contains other elements describing the XSchema and building a schema. These elements are described in later sections of this specification. The XSchema element may also contain other XSchema elements nested inside of it. This nesting of XSchema elements improves reusability of XSchemas by allowing the combination of multiple XSchemas inside of a single XSchema framework. It also allows finer-grained control over documentation for subsections of an XSchema. The XSchema element's attributes include information about the namespace used by XSchema, the version of the XSchema specification used, and information about the type of documents described by the XSchema. The XSchema namespace is fixed with the xmlns attribute to correspond with the 8/2/98 working draft of Namespaces in XML. Information about the XSchema specification version used to create this XSchema, contained in the Version attribute, is critical to proper handling of documents should the specification be updated in the future. This specification is identified as version 1.0. Future major and minor versions of the XSchema specification should identify themselves differently. No provision is made at this time for nesting XSchemas using different versions of the specification under a parent XSchema element. The MimeType and FileExtension attributes are used to provide a suggested MIME (Multipurpose Internet Mail Extensions) Content-type and file extension for documents created using a particular XSchema. Applications may use this information to identify XML document types. A document library that generates XML documents dynamically could assign file extensions and MIME types based on the XSchema used. Applications using this information should use the values stored in the first XSchema encountered during processing. For instance, if an XSchema includes another nested XSchema, the values for the MimeType and FileExtension attributes of the root XSchema should be used. By default, most XML documents are assumed to have a MIME type of application/xml, as described in "XML Media Types" by E.J. Whitehead and Murata Makoto. Developers who need different MIME types for documents created using particular XSchemas may register other MIME types with the IETF, as described in RFC 1590, or use the 'x-' prefix syntax for subtypes, as described in RFC 1521. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 4 01:49:06 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:22 2004 Subject: XSchema question Message-ID: <016701bdbf38$09bee0a0$2ee044c6@arcot-main> Does XSchema handle 'redefinition' of schema either entirely or partially? I would like to see each XLF log source redefine their schema from time to time to reflect changes. XSchema can handle this, it would be great. Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Tue Aug 4 01:52:09 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:22 2004 Subject: External DTD Grammar Message-ID: The following is an attempt to construct BNF productions for XML in the internal and external DTD subsets. These productions should reflect what can occur in an XML file before any processing has occured. Basically I am trying to figure out, in a well formed XML document, what can an XML processor encounter while parsing any given section/production of document. So I just went through the productions and added PEReferences wherever one might occur (all over the place). I think the whitespace appended to PE's when included (sec 4.4.8) helps make this a little easier. As I understand it, a parser does NOT have to deal with: %endecls; % example 'test'> This is not well formed, right? (please say yes) How do other parsers deal with this? A PEReference preprocessor? A preprocessor is hard, because what your preprocessing depends on the results of the actual processing that would occur after the preprocessor finished. The following represent productions in the XML specification which need to be changed to meet this goal. I don't really know what I am doing here, I just threw this together in 5 minutes and I am doing it to generate feedback. So am I completely off my rocker? Help and guidance much appreciated, thanks! ---------------------- Internal DTD Subset: [9] EntityValue ::= '"' ([^%&"] | Reference)* '"' | "'" ([^%&'] | Reference)* "'" External DTD subset: [9] EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"' | "'" ([^%&'] | PEReference | Reference)* "'" [10] AttValue ::= '"' ([^<&"] | Reference | PEReference)* '"' | "'" ([^<&'] | Reference | PEReference)* "'" [45] elementdecl ::= '' [46] contentspec ::= 'EMPTY' | 'ANY' | Mixed | children | PEReference [47] children ::= (choice | seq | PEReference) ('?' | '*' | '+')? [48] cp ::= (Name | choice | seq | PEReference) ('?' | '*' | '+')? [52] AttlistDecl ::= '' [53] AttDef ::= S (Name | PEReference) S AttType S DefaultDecl [54] AttType ::= StringType | TokenizedType | EnumeratedType | PEReference [55] StringType ::= 'CDATA' | PEReference [56] TokenizedType ::= 'ID' | 'IDREF' | 'IDREFS' | 'ENTITY' | 'ENTITIES' | 'NMTOKEN' | NMTOKENS' | PEReference [57] EnumeratedType ::= NotationType | Enumeration | PEReference [58] NotationType ::= ('NOTATION' | PEReference) S '(' S? (Name | PEReference) (S? '|' S? (Name | PEReference))* S? ')' [59] Enumeration ::= '(' S? (Nmtoken | PEReference) (S? '|' S? (Nmtoken | PEReference))* S? ')' [60] DefaultDecl ::= '#REQUIRED' | '#IMPLIED' | PEReference | (('#FIXED' S)? AttValue) [71] GEDecl ::= '' [72] PEDecl ::= '' [73] EntityDef ::= EntityValue | PEReference | (ExternalID NDataDecl?) [74] PEDef ::= EntityValue | ExternalID | PEReference [75] ExternalID ::= ('SYSTEM' | PEReference) S (SystemLiteral | PEReference) | ('PUBLIC' | PEReference) S (PubidLiteral | PEReference) S (SystemLiteral | PEReference) [76] NDataDecl ::= S ('NDATA' | PEReference) S (Name | PEReference) [82] NotationDecl ::= '' [83] PublicID ::= ('PUBLIC' | PEReference) S (PubidLiteral | PEReference) --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 4 04:13:57 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:22 2004 Subject: Model group ambiguities In-Reply-To: <000401bdba4f$a583c160$e46118cb@caleb> Message-ID: <199808040217.AA01880@murata.apsdc.ksp.fujixerox.co.jp> James K. Tauber wrote: > My understanding was that SGML content models have to be deterministic to > start with in order to avoid problems with automatic reduction to DFAs > because of and groups, etc. Prof. Anne Brugemann-Klein strongly believes that this restriction is an extremely bad idea. I would strongly recommend full support of non-deterministic content models. Otherwise, DTD transformation will become impossible, since translated DTD's cannot always be captured by deterministic content models. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amitr at abinfosys.com Tue Aug 4 04:52:20 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:03:22 2004 Subject: Where and how to place XSL processor for formatting of ASP form handler generated XML response? Message-ID: <00b101bdbf53$2c1b0140$0101a8c0@server.abinfosys.com> Hello, ENVIRONMENT :- * Scripting Environment :- ASP * Client Briowser :- IE 4.01 * XSL processor :- MSXSL * Web Server :- IIS 4.0 * Database Server :- SQL Server 6.5 1) Where do I place the MSXSL(XSL processor) for it to trap a response (an XML steam) generated by an ASP form handler after form submission? 2) What scripting event and code would I use with the MSXSL to trap the XML response from the form handler? SCENARIO DESCRIPTION :- * I have a default.asp file which will generate a FORM for user input. * On Submission an ASP form handler = test.asp is invoked. Code snippet for default.asp is :- From jjc at jclark.com Tue Aug 4 07:53:12 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:23 2004 Subject: Namespaces in 20 lines Message-ID: <35C69EB5.B4462AD0@jclark.com> At first glance the new namespace draft might appear rather complicated, but actually it is really easy to implement. Assuming you have a non-namespace-aware XML tree, here's all it takes to implement basic namespace processing in Java (albeit inefficiently and with incomplete enforcement of namespace constraints): /** * Expands an element type or attribute name (according to the * value of the isAttribute argument) using the * namespace declarations in effect for the specified element. * For a non-global attribute or for an unqualified element type * name or for a name starting with "xml:", returns the name * unchanged. Otherwise returns an expanded name consisting * of the namespace URI followed by a + * character followed by the local part. Returns null if the name * cannot be expanded because a namespace prefix is not declared. */ String expandName(String name, Element element, boolean isAttribute) { // The index of the colon character in the name. int colonIndex = name.indexOf(':'); // The name of the attribute that declares the namespace prefix. String declAttName; if (colonIndex == -1) { // Default namespace applies only to element type names. if (isAttribute) return name; declAttName = "xmlns"; } else { String prefix = name.substring(0, colonIndex); // "xml:" is special if (prefix.equals("xml")) return name; declAttName = "xmlns:" + prefix; } for (; element != null; element = element.getParent()) { String ns = element.getAttributeValue(declAttName); if (ns != null) { // Handle special meaning of xmlns="" if (ns.length() == 0 && colonIndex == -1) return name; return ns + '+' + name.substring(colonIndex + 1); } } return null; } James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Aug 4 10:16:34 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:23 2004 Subject: API versioning in SAX Message-ID: <199808040814.KAA27809@berlin.dvs1.tu-darmstadt.de> > Just to play the devil's advocate, are you sure you are not creating a > technical solution to what everyone is more likely to solve with a > non-technical one? If I'm the administrator of my server or my workstation, and > I see a new SAX driver out there, wouldn't I just read the README before I even > downloaded it to make sure that its capable of doing what my current does (plus > more maybe?) I doubt very seriously I'd just download new drivers and try them > until one fails to fail, ya know? And, even if I did, the fact that it fails to > fail on the 3 apps I have now, doesn't mean it supports what I want to support > on app #4, so I'm going to just read the docs and see what it supports most > likely. Generic, third party applications built on top of SAX are pretty much expected to work with all SAX parsers -- that's the whole point of having a standard interface. An example of this kind of application is a spreadsheet (Excel, Quattro Pro, Lotus 1-2-3, etc.) that uses a SAX parser to read data from an XML file. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Aug 4 10:40:45 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:23 2004 Subject: Namespace Comments Message-ID: <002a01bdbf82$4cd6ef50$2ee044c6@arcot-main> I have read the latest namespace spec. While I am sure that a lot considerations and discussions have gone into the spec, I am compelled to ask why something like the following was not chosen? Cheaper by the Dozen 1568491379

This is a funny book!

If attribute-based namespace declaration is the only way to go, why not use a simple word like 'namespace' instead of 'xmlns' so that its purpose is clear to the reader? If 'namespace' is too common, people can qualify it with 'xml' like this 'xml:namespace'? Why not consider changing the name of the standard to something shorter? Saving of 4 characters does seem quite worth the use of obscure word like 'xmlns' for something as common as namespace. Best wishes, Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Aug 4 10:43:37 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:23 2004 Subject: XSchema question Message-ID: <199808040838.KAA27837@berlin.dvs1.tu-darmstadt.de> > Does XSchema handle 'redefinition' of schema either entirely or partially? > I would like to see each XLF log source redefine their schema from time to > time to reflect changes. XSchema can handle this, it would be great. I'm not sure I understand the question. Do you mean, can you change your content models and so on and have XSchema automatically resolve the differences based on which version of the file you're reading and which version of the XSchema you're using? If so, XSchema doesn't handle this, but it's an interesting idea. I think that architectural forms do handle this. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Tue Aug 4 11:00:50 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:23 2004 Subject: Namespace Comments References: <002a01bdbf82$4cd6ef50$2ee044c6@arcot-main> Message-ID: <35C6CA76.38929FF0@jclark.com> Don Park wrote: > > I have read the latest namespace spec. While I am sure that a lot > considerations and discussions have gone into the spec, I am compelled to > ask why something like the following was not chosen? [element based solution deleted] Because it was felt undesirable that namespace processing should change the structure of the element tree. > If attribute-based namespace declaration is the only way to go, why not use > a simple word like 'namespace' instead of 'xmlns' so that its purpose is > clear to the reader? Only names beginning with "xml" (any case) are reserved by the XML spec. > If 'namespace' is too common, people can qualify it with 'xml' like this > 'xml:namespace'? Using 'xml:namespace' would mean that a namespace 'foo' was declared using xml:namespace:foo="..." which looks very strange to me. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Tue Aug 4 11:06:03 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:23 2004 Subject: Namespaces ! Message-ID: <199808040904.LAA22283@chimay.loria.fr> I read the last specification of the XML Namespaces this night. To tell the truth it disturbed me somewhat ! * Namespace Constraint: Prefix Declared The WD says: "The namespace prefix, unless it is xml or xmlns, must have been declared in a namespace declaration. The namespace prefixes xml and xmlns are reserved, and considered to have been implicitly declared." 1/ The example following this definition uses a NS declared after its use : "" I am not sure that attribute-based is the best way for declaring NS. Why not have preserved the old specification for the declarations of XML Namespaces (using PI) ? And use something like : ... Create another reserved name (xmlns) weighs down the XML notation and opens the door to already encountered problems (remenber HTML!). Each one (Microsoft, Netscape, Sun, ...) will arrive with its own reserved name and one will fall down in the same problems as with HTML ( vs for example). We should have only one reserved name : "xml" !!! 2/ There is a redundancy of information. A simple prefix is enough to specify the namespace used : Cheaper by the Dozen 1568491379 ... Should be : Cheaper by the Dozen 1568491379 ... This makes also XML document not easily readable. 3/ Implementation. If i understand the new WD, it's possible to have everywhere within the document (in each Element start tag) a Namespace declaration. Hum, i agree with James Clark that it is easy to implement but we have to provide for each Element object an 'xmlns' attribute and make inherited each one of its descendants. Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Tue Aug 4 11:13:37 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:23 2004 Subject: API versioning in SAX In-Reply-To: "Michael Kay"'s message of "Mon, 3 Aug 1998 19:01:59 +0100" References: <000f01bdbf08$d031a540$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: Michael> Michael Kay => In article => <000f01bdbf08$d031a540$1e09e391@mhklaptop.bra01.icl.co.uk>, Michael => wrote: Michael> Every time I use SAX, I forget that the parser is allowed to Michael> hand me data one character at a time if it chooses. Perhaps Michael> someone should write a SAX parser that does just that, so I Michael> can test that my application would cope with it. You could write a SAX filter that accepts input from the parser of the moment, and delivers it a character at a time. It should be fairly trivial given the filter interface recently posted here. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 4 11:23:22 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:23 2004 Subject: Namespace Comments Message-ID: <003d01bdbf88$3f6fa220$2ee044c6@arcot-main> James, >Because it was felt undesirable that namespace processing should change >the structure of the element tree. Hmm. Namespace nodes would indeed look funny in a document displayed as a tree. I suppose the Namespace WG does not consider having extraneous attributes as change to the structure of the document. What about having to change DTDs to use the namespace? Isn't that a bit harsh? >Only names beginning with "xml" (any case) are reserved by the XML spec. Could we not reserve "namespace" as well? It seems quite restricting that only the XML spec itself can reserve names. > xml:namespace:foo="..." > >which looks very strange to me. How silly of me. Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Tue Aug 4 11:26:50 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:03:23 2004 Subject: Non-Validating XML Parsers: Requirements Message-ID: <003401bdbf8a$69bfa000$1e09e391@mhklaptop.bra01.icl.co.uk> >*sigh* I do wish people wouldn't review things without reading >them. I happen to agree with you about MAY NOT, but that's >what RFC 2119 says. The RFC is about 600 words long, BTW, and >here's a link: http://www.isi.edu/in-notes/rfc2119.txt . Thanks for the reference. I've read it now. I'm relieved to discover it does not recommend or assign a meaning to the phrase "MAY NOT". Wherever "MAY NOT" appears in a (so-called) spec, it either means "MUST NOT" or it means "MAY OR MAY NOT", which is a synonym for "MAY", and which, as I remarked earlier, is formally equivalent to omitting the sentence. > >> I don't much like "may" either. Everything is permitted >> unless the specification prohibits it, a sentence whose main >> verb is "may" therefore says nothing. > >*Everything*? So if a specification for a C compiler doesn't >*say* that compiling a strictly conforming program does *not* >make demons fly out of your nose, then the compiler is allowed >to do that? Absolutely. It might not succeed in the market, but it would conform to the spec. (As did an early Algol68 compiler I once used whose only error message was " is not a program". Which, come to think of it, is not that far removed from the behaviour of some XML parsers I have used...) Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Aug 4 11:30:47 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:23 2004 Subject: XSchema question Message-ID: <005601bdbf89$2fd3db00$2ee044c6@arcot-main> >> Does XSchema handle 'redefinition' of schema either entirely or partially? >> I would like to see each XLF log source redefine their schema from time to >> time to reflect changes. XSchema can handle this, it would be great. > >I'm not sure I understand the question. Do you mean, can you change your >content models and so on and have XSchema automatically resolve the differences >based on which version of the file you're reading and which version of the >XSchema you're using? If so, XSchema doesn't handle this, but it's an >interesting idea. I think that architectural forms do handle this. No. If I defined an element named FOO with attribute named BAR, can I 1. Redefine FOO's containment rules. 2. Redefine FOO's attribute list. 3. Change BAR's default value. If XSchema does not do it, maybe we should define another standard that does this (XSchizo? ). Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Aug 4 11:42:20 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:23 2004 Subject: Namespaces ! Message-ID: <006b01bdbf8a$e3e57620$2ee044c6@arcot-main> > > ... Another solution is: ... Parsing of PI data is a lot simpler this way. Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Tue Aug 4 11:52:38 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:03:24 2004 Subject: External DTD Grammar In-Reply-To: Chris Hubick's message of Mon, 3 Aug 1998 16:47:33 +0000 (GMT) Message-ID: <199808040952.KAA11060@stevenson.cogsci.ed.ac.uk> > > %endecls; % example 'test'> > > This is not well formed, right? (please say yes) It's well-formed but not valid (see production [29]). So non-validating processors don't have to detect the error. (Of course a n-v parser that doesn't read the external subset can't detect errors in it - that's why it isn't a WF constraint - but there are n-v parsers that do read it.) My parser (RXP / LT-XML) relies on the fact that since PEs have spaces inserted around them, they can only start and finish in places where whitespace would be legal. PEs are pushed and popped during whitespace processing. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Tue Aug 4 12:03:53 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:24 2004 Subject: Namespaces ! References: <199808040904.LAA22283@chimay.loria.fr> Message-ID: <35C6D75E.5E845CE9@jclark.com> Patrice Bonhomme wrote: > 1/ The example following this definition uses a NS declared after its use : > "" This is allowed. The spec should be clearer about this. > I am not sure that attribute-based is the best way for declaring NS. Why > not have preserved the old specification for the declarations of XML > Namespaces (using PI) ? This has been discussed an exhaustive length in the WG. If you are a W3C member, you can go read the archives. I don't think it is profitable to rehash the discussion in this forum. > Create another reserved name (xmlns) The XML Recommendation already reserves xmlns and indeed all names beginning with "xml". > weighs down the XML notation and > opens the door to already encountered problems (remenber HTML!). Each one > (Microsoft, Netscape, Sun, ...) will arrive with its own reserved name and one > will fall down in the same problems as with HTML ( vs for > example). Only names beginning with "xml" (any case) are reserved and they are reserved for use only by future versions of XML. > We should have only one reserved name : "xml" !!! > > 2/ There is a redundancy of information. > > A simple prefix is enough to specify the namespace used : > > > Cheaper by the Dozen > 1568491379 ... > > Should be : > > > Cheaper by the Dozen > > 1568491379 ... > > This makes also XML document not easily readable. Where is the "isbn:" prefix declared? How would that allow global attributes with different namespaces? You are wasting your time suggesting alternative designs. Read the "Status of this document" section: "the Working Group intends to keep the features [the draft] describes functionally unchanged unless problems are discovered during early implementation work". > 3/ Implementation. > > If i understand the new WD, it's possible to have everywhere within the > document (in each Element start tag) a Namespace declaration. Hum, i agree > with James Clark that it is easy to implement but we have to provide for each > Element object an 'xmlns' attribute and make inherited each one of its > descendants. You have to be able to find the inherited value of namespace declaring attributes; this is no different from what you already have to do for xml:lang and xml:space. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Tue Aug 4 12:06:06 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:24 2004 Subject: Namespace Comments References: <003d01bdbf88$3f6fa220$2ee044c6@arcot-main> Message-ID: <35C6D948.A60A61B5@jclark.com> Don Park wrote: > > James, > > >Because it was felt undesirable that namespace processing should change > >the structure of the element tree. > > Hmm. Namespace nodes would indeed look funny in a document displayed as a > tree. I suppose the Namespace WG does not consider having extraneous > attributes as change to the structure of the document. Additional attributes do change the document but they are much less likely to cause problems than additional container elements; they also cause fewer problems for validation. > What about having to change DTDs to use the namespace? Isn't that a bit > harsh? Any non-namespace aware validation facility is bound to be sub-optimal with namespaces. If you have only a single namespace, you can make a valid document use namespaces just by changing the internal subset: ]> ... > >Only names beginning with "xml" (any case) are reserved by the XML spec. > > Could we not reserve "namespace" as well? It seems quite restricting that > only the XML spec itself can reserve names. The namespace facility is intended eventually to become part of XML proper, and can thus only make use of names already reserved by XML 1.0. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Tue Aug 4 12:14:08 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:03:24 2004 Subject: Non-Validating XML Parsers: Requirements In-Reply-To: Chris Hubick's message of Mon, 3 Aug 1998 14:02:32 +0000 (GMT) Message-ID: <199808041013.LAA11523@stevenson.cogsci.ed.ac.uk> > This would mean that the grammer has PE > references in places that are not allowed in the internal subset, Yes; a document must satisfy the grammar rules and the constraints. > suggesting those are only valid in the external subset, yet the > grammer leaves them out in many places where they are allowed in the > external subset! Earlier drafts of the standard attempted to indicate where paramater entities could occur by special syntax in the grammar rules. This made them very hard to read. I think that to do this right would need two grammars; one for the unexpanded source and one for the result after expansion. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mahr at 135.kef.co.il Tue Aug 4 12:22:15 1998 From: mahr at 135.kef.co.il (Eric Mahr) Date: Mon Jun 7 17:03:24 2004 Subject: unsubscribe References: <199808041013.LAA11523@stevenson.cogsci.ed.ac.uk> Message-ID: <35C6EC30.73F1E68E@135.kef.co.il> unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Tue Aug 4 12:41:13 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:24 2004 Subject: Namespaces ! In-Reply-To: <35C6D75E.5E845CE9@jclark.com> Message-ID: <199808041044.AA01890@murata.apsdc.ksp.fujixerox.co.jp> James Clark wrote: > You have to be able to find the inherited value of namespace declaring > attributes; this is no different from what you already have to do for > xml:lang and xml:space. We can ban inheritance of xml:lang and xml:space when prefixes differ. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Tue Aug 4 12:51:46 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:24 2004 Subject: Namespaces in 20 lines In-Reply-To: <35C69EB5.B4462AD0@jclark.com> Message-ID: <199808041055.AA01891@murata.apsdc.ksp.fujixerox.co.jp> James Clark wrote: > At first glance the new namespace draft might appear rather complicated, > but actually it is really easy to implement. Assuming you have a > non-namespace-aware XML tree, here's all it takes to implement basic > namespace processing in Java (albeit inefficiently and with incomplete > enforcement of namespace constraints): I also think that parsing and detection of namespaces are easy. I feel that almost all of the proposals can quite easily allows these two. I am very much interested in feedback from those applications which *modify* namespace-aware XML trees. What happens if namespace declarations are added or deleted? Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From aheitor at ef.pt Tue Aug 4 13:11:32 1998 From: aheitor at ef.pt (Ana Heitor) Date: Mon Jun 7 17:03:24 2004 Subject: convert xml to HTML. In-Reply-To: <35C69EB5.B4462AD0@jclark.com> Message-ID: Hi, someone can tell me how is possibel convert xml to HTML. I don't want run one application in the command line like xsl of microsoft. thanks AH xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 4 13:27:41 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:24 2004 Subject: Do you understand XML namespaces? In-Reply-To: <199808031958.VAA21008@chimay.loria.fr> References: Message-ID: <3.0.1.16.19980804121352.3b37e610@pop3.demon.co.uk> At 21:58 03/08/98 +0200, Patrice Bonhomme wrote: > >colds@nwlink.com said: >] http://www.w3.org/TR/WD-xml-names was updated yesterday (August 2nd). > >Just one thing to say : GASP !!! I hope this is a gasp of excitement. > > >WD-xml-names-19980802 said: >] The namespace prefix, unless it is xml or xmlns, must have been >] declared in a namespace declaration. > >Hum !!! And what about the following example (15 lines after within the WD) : > > > >...strange. The XML NS for html is declared after >Pat. I think there will be a number of things that XML-DEVers will find 'strange'. I suggest that (a) you take time to read and re-read the draft and try to work out a few examples (b) if, after careful re-reading, you feel something is unclearly (or incorrectly) drafted, mail xml-names-issues@w3.org [1]. The use of 'after' in your query suggest that you have interpreted the draft differently from the editors and that possibly some re-wording could help. Since your concern is including in this mail - copied to xml-names-issues - you needn't resend it :-) (c) if you feel the design of the draft is wrong/unworkable on minor points again mail the editorial team. (d) if you wish to be any early implementer of the draft please make [modular] suggestions on this list. I suspect we shall benefit from separating out the various issues in the draft rather than trying to come up with a monolithic solution. P. [1] I am assuming this is a simple e-mail rather than a subscribed list. If not, could precise details be given [otherwise you may be sent may 'subscribe' messages]. Are the contents of these mails public? Otherwise you may get many hundred similar messages? I have copied this message to xml-names-issues to see what happens - please forgive the crossposting. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From CallaghanN at NPRI70.NPT.NUWC.NAVY.MIL Tue Aug 4 13:52:06 1998 From: CallaghanN at NPRI70.NPT.NUWC.NAVY.MIL (Callaghan Nancy NUWCDIVNPT) Date: Mon Jun 7 17:03:24 2004 Subject: unsubscribe Message-ID: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 4 15:03:31 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:24 2004 Subject: XSchema question Message-ID: Don Park wrote: >Does XSchema handle 'redefinition' of schema either entirely or partially? >I would like to see each XLF log source redefine their schema from time to >time to reflect changes. XSchema can handle this, it would be great. I'm not totally sure how the log file would need to change its schema. If you mean that an admin went through and changed settings on the things to be logged, it shouldn't be a problem. If you mean something else, I'm not really sure. XSchema should be as flexible as DTDs, content-model wise, and you might be able to create a program that actually modified the XSchema whenever you felt like it more easily than you could modify an equivalent DTD. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 4 15:23:30 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:24 2004 Subject: Namespaces ! Message-ID: James Clark: >You have to be able to find the inherited value of namespace declaring >attributes; this is no different from what you already have to do for >xml:lang and xml:space. I hate to say this, but I didn't hear peals of joy surrounding xml:lang and xml:space processing. Indeed, XML-Dev was pretty well covered in complaints about inheritance of attributes and the fun it creates for both event-based parsers and tools that extract subsections of documents (XPointers, for instance.) Just because it's already there doesn't mean it was a delightful idea in the first place. Since James also wrote "You are wasting your time suggesting alternative designs," I'll stick to implementation and documentation. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 4 15:23:35 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:25 2004 Subject: XSchema question Message-ID: The joys of out-of-sequence email... Don Park wants to: >If I defined an element named FOO with attribute named BAR, can I >1. Redefine FOO's containment rules. >2. Redefine FOO's attribute list. >3. Change BAR's default value. > >If XSchema does not do it, maybe we should define another standard that does >this (XSchizo? ). It might be tricky; you'd need to read in the XSchema, modify it, and spit it back out. Since XSchemas use XML instance syntax, doing this shouldn't be too hard; it's a matter of walking the tree to the information you want (not the straight XML element tree, but reasonably close) making the change, and resaving the schema. You'd need one schema copy per instance of the application that was prone to this behavior, so multiple copies of the same application wouldn't trip over each other's changes. XSchizo could just be a program that reads in XSchemas, accepts edits through a simple API, and spits 'em back out. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Aug 4 15:29:44 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:25 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 6 Message-ID: <199808041318.PAA28715@berlin.dvs1.tu-darmstadt.de> > After an hour with the namespace draft, this is where I'm at. If I'm wildly > dead wrong, as is often the case when I'm dealing with namespaces, please let > me know. The FIXED declaration for the xmlns attribute and the removal of > prefixes from subelements appear to be the main issues. I could change the > attribute to xmlns:XSC and return the prefixes if that seems preferable. (I'm > planning on overriding it again in the Doc element, and allowing others to > override it in the More element, if that's helpful. > > [stuff snipped] > > 2.1 The XSchema Element > > The XSchema element is the root element for all XSchema documents. The > declaration for the XSchema element is: > > Choice | Sequence | Mixed | Ref | Notation | XSchema)*)> > xmlns CDATA #FIXED "http://www.purl.org/NET/XSchema/v1" > Version CDATA #FIXED "1.0" > MimeType CDATA "application/xml" > FileExtension CDATA "xml" > id ID #IMPLIED> > > [more stuff snipped] > > The XSchema namespace is fixed with the xmlns attribute to correspond with the > 8/2/98 working draft of Namespaces in XML. I think this is the right way to go. We might want to add a note to the spec that, if the XSchema DTD is external and someone is using a non-validating parser, they should add the following declaration to the internal DTD to ensure the correct namespace is used for XSchema elements: Just to make sure, you are overriding the default in the Doc element to use the IBTWSH URI and in the More element to set the default to null. (We can't really do anything else with More because we don't know what namespace URI or prefix people will use.) We should also recommend that people include these attribute declarations in their internal subset when the XSchema DTD is external and they are using a non-validating parser. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Aug 4 15:35:58 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:25 2004 Subject: Namespaces ! Message-ID: <199808041330.PAA28825@berlin.dvs1.tu-darmstadt.de> Patrice Bonhomme wrote: > 3/ Implementation. > > If i understand the new WD, it's possible to have everywhere within the > document (in each Element start tag) a Namespace declaration. Hum, i agree > with James Clark that it is easy to implement but we have to provide for each > Element object an 'xmlns' attribute and make inherited each one of its > descendants. Actually, DTD designers can't provide an xmlns attribute for each element in the way I think you mean. This is because the attribute name itself carries instance-specific information (the instance-specific prefix), which the DTD designer can't know ahead of time. Thus, if an instance wants to use a different prefix, it must declare its own attribute in the internal subset: --OR-- --OR-- (In the last case, the instance must actually use the attribute on the appropriate element.) If no DTD is being used, the instance author simply adds the xmlns attribute of their choice to the element of their choice. This is not really different from the old spec, except for more flexibility in the scoping of namespace prefixes. If you (as an instance author) want to duplicate the old PI, just add your prefix attribute to the root element. If you want more limited scope, add it to the appropriate nested element. The other (minor) advantage of the new spec is that (depending on the parser used and where the DTD resides), the namespace prefix can be declared by in the DTD, which means that instance authors do not need to remember to include the PI. One last thing to remember is that most people are not going to spend a lot of time changing prefixes anyway. There is simply no point. The DTD designer designs a DTD and assigns a prefix to be used for the new elements (or sets a default namespace, which is the most sensible thing). If the DTD designer then uses elements from another namespace, he/she/it checks for collisions with existing prefixes and assigns a new prefix accordingly. The instance author then just uses the prefixes already in the DTD and spends their time creating instance files (which the understand) instead of changing prefixes (which they don't). (Beware not to assume any magic about namespaces. I used to imagine that they would automatically merge XML files and their corresponding DTDs. While it is certainly possible to build the software to do this, using namespaces to resolve collisions, it is not (yet) a common operation. Most people are going to create documents from fixed DTDs in which all namespace collisions have already been resolved by hand.) -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Aug 4 15:48:24 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:25 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 6 Message-ID: <199808041341.PAA28838@berlin.dvs1.tu-darmstadt.de> > Just to make sure, you are overriding the default in the Doc element to use the > IBTWSH URI and in the More element to set the default to null. (We can't really > do anything else with More because we don't know what namespace URI or prefix > people will use.) We should also recommend that people include these attribute > declarations in their internal subset when the XSchema DTD is external and they > are using a non-validating parser. Oops. I just realized you can't do this. Namespace attributes apply to the element where they occur and all children. Thus, the following declaration places the Doc element in the IBTWSH namespace, which is a validity violation of the XSchema DTD. There doesn't seem to be a way that we can say we want all elements beneath (but not including) the Doc element to be in the IBTWSH namespace. Instead, the instance will need to either use a prefix (which we can declare in Doc) or change the default in all elements directly beneath Doc. Same applies to More. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 4 16:25:56 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:25 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 6 Message-ID: Ron Bourret writes: >There doesn't seem to be a way that we can say we want all elements >beneath (but not including) the Doc element to be in the IBTWSH namespace. >Instead, the instance will need to either use a prefix (which we can >declare in Doc) or change the default in all elements directly beneath >Doc. Same applies to More. Looks like we're back to the XSC: prefix, just to stay out of the way of this. That way Doc can declare the IBTWSH null namespace and More the same without stomping on themselves. Reasonable? Initial implementatoins are such fun... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 4 16:36:24 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:25 2004 Subject: External DTD Grammar In-Reply-To: Message-ID: <3.0.1.16.19980804153547.37e7f3fa@pop3.demon.co.uk> At 16:47 03/08/98 +0000, Chris Hubick wrote: > >The following is an attempt to construct BNF productions for XML in the >internal and external DTD subsets. These productions should reflect what [...] >I don't really know what I am doing here, I just threw this together in >5 minutes and I am doing it to generate feedback. > >So am I completely off my rocker? I can't help with the technical details but can reassure you (at least for your sanity) that PEs were a difficult problem when the spec was being created - you'll see some discussion on XML-DEV about a year ago or earlier. The current solution clarified the situation a lot. So I'd be surprised if it was seriously broken. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 16:46:21 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:25 2004 Subject: Namespace Comments References: <002a01bdbf82$4cd6ef50$2ee044c6@arcot-main> Message-ID: <35C71E9C.47B8178F@locke.ccil.org> Don Park wrote: > Why not consider changing the name of the standard to > something shorter? How's that? "XML" is too long for you? You want it to be called just "XM"? ("X" is already taken.) > Saving of 4 characters does seem quite worth the use of obscure word like > 'xmlns' for something as common as namespace. "xml-namespace" might do what you wanted (without using more than one colon), but those of us who type XML directly would not be pleased. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 16:51:54 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:25 2004 Subject: Namespaces ! References: <199808040904.LAA22283@chimay.loria.fr> Message-ID: <35C71FD5.64A0CB7C@locke.ccil.org> Patrice Bonhomme wrote: > The WD says: "The namespace prefix, unless it is xml or xmlns, must have been > declared in a namespace declaration. The namespace prefixes xml and xmlns are > reserved, and considered to have been implicitly declared." > > 1/ The example following this definition uses a NS declared after its use : > "" The draft also says, "The namespace declaration is considered to apply to the element where it is specified and to all elements within the content of that element, unless overridden [...]." That's "to the element", not just to its content. The GI of an element is part of it, so the example is conformant. > We should have only one reserved name : "xml" !!! All names beginning "xml" or "XML" or "xML" or whatever are already reserved. > > Cheaper by the Dozen > > 1568491379 ... That won't work. What *is* the "isbn" namespace? You haven't specified its URI 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 4 17:38:30 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:25 2004 Subject: convert xml to HTML. In-Reply-To: References: <35C69EB5.B4462AD0@jclark.com> Message-ID: <3.0.1.16.19980804155158.404fc0f2@pop3.demon.co.uk> At 10:29 04/08/98 +0100, Ana Heitor wrote: >Hi, > >someone can tell me how is possibel convert xml to HTML. >I don't want run one application in the command line like xsl of >microsoft. Hi Ana, This is a common question - (PeterF - is it on the FAQ?). Because you (or anyone) can design any elements in XML you like there cannot be a standard way of converting XML to HTML. For example: This is a I found yesterday What does FOO mean? Should you set it as a section? What is a BAR? The most common approach will be to design a stylesheet (XSL) which describes how FOO and BAR should be rendered. This stylesheet can drive an HTML-aware XSL processor to output HTML. Different stylesheets can give different results. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 4 17:38:36 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:25 2004 Subject: Namespaces ! In-Reply-To: <199808041330.PAA28825@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980804163721.0887b750@pop3.demon.co.uk> At 15:30 04/08/98 +0200, Ron Bourret wrote: [...] >This is not really different from the old spec, except for more flexibility in >the scoping of namespace prefixes. If you (as an instance author) want to >duplicate the old PI, just add your prefix attribute to the root element. If >you want more limited scope, add it to the appropriate nested element. The >other (minor) advantage of the new spec is that (depending on the parser used >and where the DTD resides), the namespace prefix can be declared by in the DTD, >which means that instance authors do not need to remember to include the PI. > [...] > >(Beware not to assume any magic about namespaces. I used to imagine that they >would automatically merge XML files and their corresponding DTDs. While it is >certainly possible to build the software to do this, using namespaces to resolve >collisions, it is not (yet) a common operation. Most people are going to create >documents from fixed DTDs in which all namespace collisions have already been >resolved by hand.) > I think Ron has described this very well. I sympathise very much with people who have found the new spec comes as a shock. As JamesC has already mentioned the XML-WG spent a lot of time addressing some of the questions that many of you naturally want to ask. Although we are only at day+1 I think the discussion so far has been very constructive and suggests we can start discussing implementation. Let me suggest the following premises: A: Since Namespaces will be fitted to a future version of XML (and by implication all XML-related drafts - XLL, XSL, etc.) all syntactic processing should occur in the parser or SAX interface where possible. In other words we want to remove as much burden from the application. B: Much of the current namespace spec is about minimisation. The prefix acts as a minimisation device. Scoping acts as a minimisation device. The SAX interface can expand minimised parts of a document to full UniversalNames (however held). The actual syntax of minimisation should be irrelevant to the application, i.e.: which prefix was used whether a namespace was default or not whether a prefix was implicit through scope (The only reason for the application receiving the prefix would be that it wished to be able to transform the document using the same prefix). This is similar to the question as to whether and carry different semantics. The WG has decided they do not. I would hope that the following documents are effectively equivalent:

This is a hyperlink.

This is a hyperlink. This is a hyperlink. but that: This is a hyperlink. is different (because in 6.3 HREF and HTML:CLASS have different namespaces). C: Software that provides specific processing for a namespace (e.g. MathML, CML) has to have access to the ns as a hardcoded string. This is because the namespaces extend beyond the document. Thus jumbo.cml.MoleculeNode may need to search for elements in the document which have a universal name containing ns="urn:www.xml-cml.org". Thus MoleculeNode might search its children to see it there were any elements with universal name "urn:www.xml-cml.org,ATOM". It has to distinguish this from ATOM provided by another namespace - e.g. in computing. D: FWIW I have been hacking namespaces into JUMBO2 and seem to require two classes: Namespace (one for each distinct xmlns in the document) UniversalName (One for each distinct elementType and each distinct attribute) If SAX can (a) process the minimisation completely and (b) return Namespaces for the document and (c) return a universal name for each Element and Attribute then I think I shall be very happy. From what various people have said it seems fairly straightforward. E: Authoring and transformation is more of a problem. I would suggest that UniversalName carried its prefix in case the application wanted to re-emit it. I suspect that any editing software would work with UniversalNames (although the screen might display minimised names). This means that only when the document comes to be written need one look to see if minimisation and scoping was valuable. Of course this might make some transformed documents more difficult for humans to read - e.g. they might have no minimisation or it might be applied completely throughout the document. But we have taken this view in SAX - that comments are thrown away and that other minimisation details are lost (e.g. whether an attribute was supplied in the document or the DTD). So I think I can live with it. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 4 20:12:50 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:25 2004 Subject: xml-names-issues@w3.org Message-ID: <3.0.1.16.19980804191307.0a0f8a08@pop3.demon.co.uk> I don't think I'm revealing anything secret by noting that mail to the above address is hypermailed at: http://lists.w3.org/Archives/Public/xml-names-issues/1998JulSep P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 20:15:55 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:25 2004 Subject: Non-Validating XML Parsers: Requirements References: <003401bdbf8a$69bfa000$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <35C74FC1.71BA3E61@locke.ccil.org> Michael Kay wrote: > Thanks for the reference. I've read it now. I'm relieved to > discover it does not recommend or assign a meaning to the > phrase "MAY NOT". You are correct. Mea culpa. > Wherever "MAY NOT" appears in a (so-called) spec, it either > means "MUST NOT" or it means "MAY OR MAY NOT", which is a > synonym for "MAY", and which, as I remarked earlier, is > formally equivalent to omitting the sentence. I meant the latter: MAY or may not. > > > >> I don't much like "may" either. Everything is permitted > >> unless the specification prohibits it, a sentence whose > main > >> verb is "may" therefore says nothing. [snip my earlier, flippant response] Seriously, though, what I wrote was not really a spec, but a clarification of an existing spec. In that case, MAY is useful, for it expresses behavior on which the client cannot depend, but which may be provided. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 4 20:32:48 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:26 2004 Subject: Namespaces and URNs Message-ID: <3.0.1.16.19980804193226.3befc11c@pop3.demon.co.uk> I would appreciate guidance from people knowledgeable in URN syntax and use. (A) The NS draft gives an example as xmlns='urn:loc.govs:books' but a private correspondent tells me than URNs should be of the form urn:scheme:something - so unless loc.gov is a scheme there appear to be differences of opinion. (B). I would greatly value consistency in the use of standard URNs. The only way we can implement interoperability is if everyone uses the same URN to refer to a namespace. Since the URN need not represent a real WWW resource there is very little check on whether a URN is fictitious. The draft shows an example of this problem. HTML is referenced mainly through the string: http://www.w3.org/TR/REC-html40 This seems fine to me, but later (5, box 6) it is referenced by: urn:w3-org-ns:HTML Are these equivalent? If so, there must be a central registry of synonyms somewhere. And, if so, it places a great burden on implementers who must search the WWW for all possible equivalences. I would *much* prefer that the whole world used exactly the same string for the namespace for HTML4.0. Experience with HTML has not helped the cause of unique identifiers for DTDs. I suspect that there are zillions of different (F)PIs in the HTML DOCTYPE statements round the world. And - unless I'm told different - I suspect no software actually processed them. So we are going into an era where we have to convince authors that NS URNs are critically important - they can't just guess and hope. I'd like to suggest that people who really know post the authoritative URNs for common DTDs/schemas. And that we all stick to using the correct one in all our examples. Among the ones we shall need in many namespace examples are: HTML (including version) IBTWSH XSchema MathML (a useful example) DublinCore RDF XML-Data Having developed 2 DTDs (CML and VHG) I need to know how to prepare URNs for them. It seems clear that anyone wishing to create a DTD which can be used for Namespaces has to buy/borrow a domain name. (I suppose they could buy an FPI instead, but since I already have domain names I'd prefer to stick with those). P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 20:35:02 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:26 2004 Subject: Non-Validating XML Parsers: Requirements References: Message-ID: <35C753E9.15579A6E@locke.ccil.org> Chris Hubick wrote: > I thought this document was well formed, I read "PEs in Internal > Subset" to mean that you can't have stuff like: > > > > but you can have: > > '> > %xx; > ]> > > but looking at the EntityValue production: > > [9] EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"' > | "'" ([^%&'] | PEReference | Reference)* "'" > > It allows a PEReference in an entity value, and thus I thought it was well > formed. Good point. I think there is a genuine conflict here. But I read clause 4.5 (allowing PE references in entity values) in conjunction with the WF constraint "PEs in Internal Subset", and I believe that internal entity declarations within the internal subset may not contain PEs in the entity value. Can we get a more authoritative or more knowledgeable commentator? > [T]he supplied grammer was for the internal subset, and knew I didn't have > to worry about the external in the first round because I didn't want to > validate. The supplied DTD grammar is actually for either subset *after* PE references have been expanded and conditional sections removed appropriately. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 20:41:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:26 2004 Subject: External DTD Grammar References: Message-ID: <35C755C3.93F5E403@locke.ccil.org> Chris Hubick wrote: > > %endecls; % example 'test'> > > This is not well formed, right? (please say yes) Unfortunately, it appears to be WF, because clause 4.3.2 says that every internal PE is WF by definition, and a markup declaration is not one of the things mentioned in that clause that cannot begin in one entity and end in another. If endecls were an external entity, the text would not be WF. > How do other parsers deal with this? A PEReference preprocessor? A > preprocessor is hard, because what your preprocessing depends on the > results of the actual processing that would occur after the preprocessor > finished. Why so? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 4 20:47:11 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:26 2004 Subject: Namespaces and URNs Message-ID: Peter Murray-Rust writes: >Having developed 2 DTDs (CML and VHG) I need to know how to prepare URNs >for them. It seems clear that anyone wishing to create a DTD which can be >used for Namespaces has to buy/borrow a domain name. (I suppose they could >buy an FPI instead, but since I already have domain names I'd prefer to >stick with those). Have to agree with this one completely. The PURL space is pretty handy (info at http://www.purl.org, thanks to Dan Brickley again for pointing it out), but tends to be pretty long. I can use ISBN's as well, but since there's no catalog for these things and no requirement that it point anyplace, I have a hard time feeling that these identifiers are reliable and/or meaningful. I realize they don't have to be "reliable" or meaningful; I just wish they were given some kind of meaning I could use to find out more about a particular namespace. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 20:47:13 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:26 2004 Subject: Non-Validating XML Parsers: Requirements References: <35C5F396.5DAE140F@locke.ccil.org> <35C63C5A.C352CAB5@Eng.Sun.COM> Message-ID: <35C75713.4C5BA1D7@locke.ccil.org> David Brownell wrote: > - Validating Parsers > > - Nonvalidating Parsers that read external definitions > > - Nonvalidating Parsers that don't read those definitions > > Point being that as section 5.2 makes clear, some WF errors will > not be reported by the third category of parser, but must be > reported by the other two. I think, however, that NVPs may read some external entities (the DTD external subset, say) but not others (like the content of external general entities). > That'd be "SHALL NOT" ... but I think that a parser which > has read the external DTD entities MUST report as a WF error > such problems. See the XML specification in section 5.2, which > is explicit that this is a WF error AND that it's not consistently > reported. No, it means "MAY fail to" or "MAY or may not". > > 7. An NVP MAY NOT signal an error if a reference is made to an > > unparsed entity, if the entity was declared in some external entity. > > As above -- this is a "MUST" if the parser reads external entities. > and a "MUST NOT" elsewhere. Unless it reads some e.e.s but not others. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 20:53:37 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:26 2004 Subject: Revised namespaces draft available References: <3.0.1.16.19980803233224.2197a11c@pop3.demon.co.uk> Message-ID: <35C75868.1AB525FD@locke.ccil.org> Peter Murray-Rust wrote: > - collate experience from those who have actually implemented namespaces > (somewhere in the 1997..1998-05 period). For example I discovered while > browsing XML4J today that it has considerable namespace support, and I'm > sure there are other tools (I'm happy to make the latest JUMBO2 available > shortly - it has a simple namespace approach). Well, as author of NamespaceFilter (which now bites the dust), I suppose I count as a namespace implementor. I foresee no difficulties in rewriting my code to meet the new draft (and at the same time adding general support for inherited attributes, which I had wanted to do as a ParserFilter anyway). The new version will be less efficient, since every startElement event will have to have its attributes searched to see if a new xmlns:* attribute appears. I would point out that people who use default or FIXED values of xmlns:* attributes would be well advised to put them in the internal subset, since non-validating parsers may not see them otherwise. > - IBTWSH IBTWSH is non-namespace rather than single-namespace. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 21:10:32 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:26 2004 Subject: Namespaces ! References: <199808041536.RAA23101@chimay.loria.fr> Message-ID: <35C75C95.9E003C6D@locke.ccil.org> Patrice Bonhomme wrote: > cowan@locke.ccil.org said: > ] The draft also says, "The namespace declaration is considered to apply > ] to the element where it is specified and to all elements within the > ] content of that element, unless overridden [...]." > > If the draft says it..... It sounds strange. My parser reads a tag name > (prefix+local) of an Element and has to wait for the namespace declaration to > qualified this name. For me, it is as if we put the Element Declaration > within the open tag of this Element, unthinkable. Not much of a problem, really, at least for SAX-style parsers that return the GI and the attribute map at the same time. > cowan@locke.ccil.org said: > ] All names beginning "xml" or "XML" or "xML" or whatever are already > ] reserved. > > I agree. But 'xmlns' is not xml! But "xmlns" *begins* with the string "xml", which is what is reserved. *Any* name beginning with those three letters is reserved, like "xml-foo" or "xml:bogus" or "xmlxml". > It is a detail. I'd use : > The trouble is that PIs don't nest within the element structure, and the whole point of the new draft (IMHO) is to localize prefix definitions so they are not just document-global. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Tue Aug 4 21:13:19 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:26 2004 Subject: External DTD Grammar In-Reply-To: <35C755C3.93F5E403@locke.ccil.org> Message-ID: On Tue, 4 Aug 1998, John Cowan wrote: > > How do other parsers deal with this? A PEReference preprocessor? A > > preprocessor is hard, because what your preprocessing depends on the > > results of the actual processing that would occur after the preprocessor > > finished. > > Why so? Because you can use a PEReferences to form a PEDecl, and you need to have processed a PEDecl before a PEReference to it can be processed. So I can't just scroll (unidirectionally) through a whole document just processing PEReferences, because I need to have processed the PEDecl's for those first, and I cant just scroll through processing PEDecl's, because they could be created using PEReferences. All I am saying is that this is hard, not easy. --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 4 21:18:05 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:26 2004 Subject: Namespaces ! References: <3.0.1.16.19980804163721.0887b750@pop3.demon.co.uk> Message-ID: <35C75E33.9CB71067@locke.ccil.org> Peter Murray-Rust wrote: > D: FWIW I have been hacking namespaces into JUMBO2 and seem to require two > classes: > Namespace (one for each distinct xmlns in the document) > UniversalName (One for each distinct elementType and each distinct attribute) Okay. Do we really need UniversalName as a *class*, or is it sufficient (as I continue to believe) to represent it as a String, possibly interned? If the latter, then my ParserFilter approach will work fine, returning all element names in the universal form of URI + delimiter + localPart (where URI can be null), and all attribute names in the form URI + delimiter + localPart for global attributes, and URI + delimiter + elementLocalPart + delimiter + localPart for local attributes. > If SAX can (a) process the minimisation completely and (b) return > Namespaces for the document and (c) return a universal name for each > Element and Attribute then I think I shall be very happy. From what various > people have said it seems fairly straightforward. Using my ParserFilter approach, of course, no parsers need to change at all to support namespaces: it becomes an *application* issue, but supported by a *universal* piece of machinery. Ditto with inherited attributes generally. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Tue Aug 4 21:20:41 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:26 2004 Subject: SAX - External Entities In-Reply-To: <35C75713.4C5BA1D7@locke.ccil.org> Message-ID: On Tue, 4 Aug 1998, John Cowan wrote: > > > 7. An NVP MAY NOT signal an error if a reference is made to an > > > unparsed entity, if the entity was declared in some external entity. > > > > As above -- this is a "MUST" if the parser reads external entities. > > and a "MUST NOT" elsewhere. > > Unless it reads some e.e.s but not others. Hmm, this made me think about SAX. Earlier this year I was looking for a way to tell a SAX parser not to process external entities for a browsing application. David Megginson told me just to return an XMLSource for an empty string from the entity handler. It is however becoming obvious to me that it could be important for the parser to know that it is skipping an external entity as opposed to that entity being empty, such as the case above. It makes me wonder if using an empty XMLSource to skip entities is a good way to do it. --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Tue Aug 4 21:34:08 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:27 2004 Subject: Non-Validating XML Parsers: Requirements In-Reply-To: <35C753E9.15579A6E@locke.ccil.org> Message-ID: On Tue, 4 Aug 1998, John Cowan wrote: > > [T]he supplied grammer was for the internal subset, and knew I didn't have > > to worry about the external in the first round because I didn't want to > > validate. > > The supplied DTD grammar is actually for either subset *after* PE > references have been expanded and conditional sections removed > appropriately. Then, as I asked in May: http://www.lists.ic.ac.uk/hypermail/xml-dev/9805/0085.html but never got an answer to: [9] EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"' | "'" ([^%&'] | PEReference | Reference)* "'" If this is the DTD grammar AFTER PE inclusion, how can there be PEReferences ??? --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From docjah at wizvax.net Tue Aug 4 21:34:19 1998 From: docjah at wizvax.net (Dave Geoghegan) Date: Mon Jun 7 17:03:27 2004 Subject: Looking for a good XSL processor Message-ID: <35C76115.A829B5B@wizvax.net> Hi, I'm looking for a good XSL processor. I've tried docproc and it seems to be the architecture I'm after but it's support for CSS in it's rules is very limited. Any other XSL processors I should try (besides MSXML) Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 21:43:15 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:27 2004 Subject: External DTD Grammar References: Message-ID: <35C7640C.1FFD2496@locke.ccil.org> Chris Hubick wrote: > Because you can use a PEReferences to form a PEDecl, and you > need to have processed a PEDecl before a PEReference to it can be > processed. So I can't just scroll (unidirectionally) through a whole > document just processing PEReferences, because I need to have processed > the PEDecl's for those first, and I cant just scroll through processing > PEDecl's, because they could be created using PEReferences. All I am > saying is that this is hard, not easy. This lends itself perfectly to the standard approach for preprocessors like the C preprocessor, but is even simpler because there are no macro arguments and no recursions. The only requirement is that no PE be used before it is defined, which is guaranteed by the WFC and VC named "Entity Declared". A lower "lexical" level detects PE references, looks up the replacement text in a table, and returns it instead. Replacement texts can't contain PE references (PE declarations can, but the references are resolved at entity declaration time), so it isn't even necessary to push back the replacement text onto the input stream. A higher "syntactic" level processes PE declarations (from which PE references have already been removed) and enters the replacement text in the lookup table used by the lower level. Everything not a PE declaration is sent to the output stream. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 22:14:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:27 2004 Subject: Non-Validating XML Parsers: Requirements References: <35C5F396.5DAE140F@locke.ccil.org> <35C63C5A.C352CAB5@Eng.Sun.COM> <35C75713.4C5BA1D7@locke.ccil.org> <35C76325.C9526B9A@Eng.Sun.COM> Message-ID: <35C76B86.63560471@locke.ccil.org> David Brownell wrote: > In any case, that's what I meant. Declarations gate this issue, > not content, except that the issue won't come up if an undeclared > entity is never referenced ! If by "external declaration" you mean "declaration appearing in an external entity" (as opposed to "declaration *of* an external entity") then yes. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 4 22:31:33 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:27 2004 Subject: Namespaces and URNs References: <3.0.1.16.19980804193226.3befc11c@pop3.demon.co.uk> Message-ID: <35C76F92.55B85CDE@locke.ccil.org> Peter Murray-Rust wrote: > (A) The NS draft gives an example as > xmlns='urn:loc.govs:books' > but a private correspondent tells me than URNs should be of the form > urn:scheme:something - so unless loc.gov is a scheme there appear to be > differences of opinion. Your correspondent is correct per RFC 2141 (http://www.isi.edu/in-notes/rfc2141.txt) but no particular schemes (there called NIDs, Namespace Identifiers) are defined there or elsewhere in the RFCs. So "loc.gov" could be a scheme name, although if it were I at least would expect that the "something" would be a Library of Congress call number, not something vague like "books". RFC 1737 says vaguely that ISBNs, ISO public identifiers (what are those, please?) and UPC product codes "seem to satisfy the functional requirements" of URNs. The only publicly available Internet-Draft that actually proposes an URN scheme proposes "ietf", for RFCs, minutes of IETF working groups, and so on. > Are these equivalent? If so, there must be a central registry of synonyms > somewhere. And, if so, it places a great burden on implementers who must > search the WWW for all possible equivalences. I would *much* prefer that > the whole world used exactly the same string for the namespace for HTML4.0. Efforts are underway to help with URN resolution, but nothing is set up yet. > Having developed 2 DTDs (CML and VHG) I need to know how to prepare URNs > for them. It seems clear that anyone wishing to create a DTD which can be > used for Namespaces has to buy/borrow a domain name. (I suppose they could > buy an FPI instead, but since I already have domain names I'd prefer to > stick with those). For the moment, the best hope is to use URLs and try to make sure they are as persistent as possible, either using PURLs or some informal scheme. After all, Java package names are in effect URNs for packages, and the existing scheme works well enough: most people have at least an email address they can use. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Tue Aug 4 23:06:37 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:03:27 2004 Subject: Namespaces and URNs In-Reply-To: <35C76F92.55B85CDE@locke.ccil.org> References: <3.0.1.16.19980804193226.3befc11c@pop3.demon.co.uk> Message-ID: <3.0.5.32.19980804160357.0087d1a0@postoffice.swbell.net> At 04:31 PM 8/4/98 -0400, John Cowan wrote: >RFC 1737 says vaguely that ISBNs, ISO public identifiers (what are >those, please?) and UPC product codes "seem to satisfy the functional >requirements" of URNs. ISO public identifiers are a form of universal name designed to meet the requirements of SGML documents to be able to reference storage objects without referencing system-specific locations. They are formally defined in ISO 8879 (the SGML standard) and in ISO 9070, which defines various registration authorities for public IDs (of which the ISBN is one). The SGML standard does not define how public IDs are to be resolved into system IDs--that is left up to particular systems. The SGML Open (now OASIS) entity catalog mechanism provides a way to do this resolution. It is supported by most SGML tools, including SP and its derivitives (and I presume, EXPAT, but I haven't tried it). Public IDs predate the Internet and are independent of any type of system, rather than being specific to a particular access method or networking infrastructure. Note that there is nothing magical about public IDs or URNs that distinguishes them from system IDs or URLs except the expectations that they generate: if you claim that something is a URN then there is an expectation that the name will be persistent. If you claim that something is a system ID, then there is no expectation that the name will be persistent. However, whether you call it a URN or URL (or a public ID or a system ID), it is up to the owner of the *name* to ensure that it is persistent. Thus, URLs can be just as persistent as URNs, but nobody expects them to be. URN resolution is always presumably indirect (because persistence cannot be ensured in the general case without some form of indirection), but URLs can be just as indirect, so from an implementation standpoint, there's no useful difference between URNs and URLs. SGML made the distinction between "public" IDs and "system" IDs based on the idea that some things would be "published" and thereby made public, so you would need a way to name them that wasn't in terms of any particular storage system. However, it turns out that without an infrastructure for publishing things, the distinction between public and non-public doesn't make much sense. However, the distinction between "can expect it to be persistent" and "can't expect it to be persistent" is a useful one. In particular, the requirement to support URNs forces you to put some sort of indirection mechanism in place, something you can get by without doing for URLs. The problem, of course, is that some people do need the names they own to be persistent and therefore are forced to build (or buy, like PURLs), the infrastructure to manage name persistence. SGML assumed that data objects would move between different types of systems and therefore had to have some system-independent way of referring to things. The Web *is* a storage system and therefore doesn't need system-independent storage identifiers. This is a subtle but important distinction: if your data only operates on the Web, then URLs are all you need, but if your data operates in a number of environments (or may be moved from one environment to another over its lifetime), then URLs are just one of an infinite number of system-specific addressing methods that you need to protect your data from by using system-independent names in your data and providing mappings of the moment as part of your data management infrastructure. In my opinion, the Internet should provide a persistent name infrastructure anagous to (but more general than) DNS so that each server doesn't have to provide its own way to manage persistent names. And I don't want to have to pay for it on a per-name basis--I want it to be an infrastructure whose cost is borne by the community at large, just the way the rest of the Internet infrastructure is. Note that it is the job of the owner of the resource to ensure that the resource is persistent, not that all of the names that might refer to it are persistent (although there is a general supposition that the owner of the resource might also maintain a name for the resource). In other words, the owner of a name for a resource and the owner of the resource itself may not be the same entity. Cheers, Eliot --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Tue Aug 4 23:12:40 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:27 2004 Subject: API versioning in SAX Message-ID: <5030300023696246000002L062*@MHS> >> If I'm the administrator of my server or my workstation, and >> I see a new SAX driver out there, wouldn't I just read the README before I even >> downloaded it to make sure that its capable of doing what my current does (plus >> more maybe?) > The trouble is that these are subtle features. See the post I just > sent out, riddled with MUSTs and MAY NOTs. Of the 10 items mentioned, > compliant non-validating parsers can vary in 7 of them, which means > there are something like 2^7 classes of non-interchangeable (but still > compliant) parsers. The docs may not even be specific on these points. Hmmm. Ok I'm going to play the "Very Cynical Devil's Advocate" here and ask the obvious question of "Is a spec that allows 2^7'th conforming variations really a spec?" If one assumes the normal progression of things as such widely used specs are evolved in the presence of evolutionary baggage and intsalled base, wouldn't we likely get up into Saganesque numbers of possible conforming variations in the not too distant future? Having worked in a previous life on a large medical software system which was kind of like the "configurable system from hell" 8-), this type of scheme always scares me. As the number of possible optional configurations expands, even if one can confirm that driver X supports your needed features, the likelihood that use of subset Y of optional features in a particular input file can cause unexpected, unintended, and/or intertwined consequences that the writers of the driver just cannot reasonably foresee (or at least reasonably maintain in a coherent manner as they move their code along in time with developer turnover etc...) Anyway, I'm not expecting the W3C to go back to the grindstone just because of my concerns, but I think they are legitimate concerns. It would serve everyone's best interests (IMHO) to have a very tight specification in which there are very few optional reactions to the same circumstances. Given what is riding on XML (the future of the net?), and given that interoperability is a key issue that needs to be addressed on the internet, it would seem that a loose spec is somewhat at odds with the long term goal? The questions being asked here in this forum are somewhat indicative of a confusing specification, and we are supposed to be the smart ones Just my opinion of course, and I'm widely known to be kinda stoopid :-) ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com "Two buttocks always make friction" - African 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 4 23:15:33 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:27 2004 Subject: Namespace Comments References: <002a01bdbf82$4cd6ef50$2ee044c6@arcot-main> <35C6CA76.38929FF0@jclark.com> Message-ID: <35C7960E.5C986D94@mecomnet.de> James Clark wrote: > > Using 'xml:namespace' would mean that a namespace 'foo' was declared > using > > xml:namespace:foo="..." > > which looks very strange to me. as an alternative, xml:namespace=":" would look "normal", would eliminate the xmlns "namespace", and would avoid the anomaly of having the prefix value itself encoded as a name. as i would prsume that this rather mundane option must have been eliminated in the deliberation process, i ask whether there is some intended advantage to the proposed prefix binding mechanism? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 4 23:59:08 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:27 2004 Subject: Revised namespaces draft available In-Reply-To: <35C75868.1AB525FD@locke.ccil.org> References: <3.0.1.16.19980803233224.2197a11c@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980804212235.0bc7e67c@pop3.demon.co.uk> At 14:52 04/08/98 -0400, John Cowan wrote: >Peter Murray-Rust wrote: > >> - collate experience from those who have actually implemented namespaces >> (somewhere in the 1997..1998-05 period). For example I discovered while >> browsing XML4J today that it has considerable namespace support, and I'm >> sure there are other tools (I'm happy to make the latest JUMBO2 available >> shortly - it has a simple namespace approach). > >Well, as author of NamespaceFilter (which now bites the dust), I suppose Lots of things bite the dust - chunks of JUMBO2 have as well and I suspect XML4J. >I count as a namespace implementor. I foresee no difficulties in >rewriting my code to meet the new draft (and at the same time adding >general support for inherited attributes, which I had wanted to do >as a ParserFilter anyway). The new version will be less efficient, >since every startElement event will have to have its attributes >searched to see if a new xmlns:* attribute appears. Since namespaces are so fundamental I think it's very important that we outline the various ways forward. AIUI your filter sits on top of SAX whereas I suspect others (including at least myself privately) want SAX to do as much as possible. We don't want these to be incompatible. > >I would point out that people who use default or FIXED values of >xmlns:* attributes would be well advised to put them in the >internal subset, since non-validating parsers may not see them >otherwise. This isn't much fun. It would be a very easy mistake to make. Can we package the NS stuff in a single file and do something like: %namespace1; %namespace2; ]> This makes sure it gets included. You can also include namespace1.ent in the external subset - it will get ignored if already declared in the internal subset. > > >> - IBTWSH > >IBTWSH is non-namespace rather than single-namespace. My point was that if I use it in (say) VHG - as I intend to - it has to acquire a namespace. Thus: XYZZY A magic word unless you intend that it should always have the null namespace xmlns="". I wouldn't think that a good idea. P. > >-- >John Cowan http://www.ccil.org/~cowan cowan@ccil.org > You tollerday donsk? N. You tolkatiff scowegian? Nn. > You spigotty anglease? Nnn. You phonio saxo? Nnnn. > Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 5 00:00:52 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:27 2004 Subject: Namespaces ! In-Reply-To: <35C75E33.9CB71067@locke.ccil.org> References: <3.0.1.16.19980804163721.0887b750@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980804210236.0bc799c4@pop3.demon.co.uk> At 15:17 04/08/98 -0400, John Cowan wrote: > >Okay. Do we really need UniversalName as a *class*, or is it sufficient >(as I continue to believe) to represent it as a String, possibly >interned? If the latter, then my ParserFilter approach will work >fine, returning all element names in the universal form of >URI + delimiter + localPart (where URI can be null), and all >attribute names in the form URI + delimiter + localPart for >global attributes, and URI + delimiter + elementLocalPart + delimiter >+ localPart for local attributes. I think that UniversalName should carry the prefix in case the application wants it. I also have a getNamespace() associated with it. > >> If SAX can (a) process the minimisation completely and (b) return >> Namespaces for the document and (c) return a universal name for each >> Element and Attribute then I think I shall be very happy. From what various >> people have said it seems fairly straightforward. > >Using my ParserFilter approach, of course, no parsers need to change >at all to support namespaces: it becomes an *application* issue, >but supported by a *universal* piece of machinery. Ditto with >inherited attributes generally. I deliberately didn't look at this, because I was aware that the new NS draft was coming up and I had to be very careful what I said. Enough people have been thinking about namespaces that I hope we can make rapid progress in how to implement them. Personally I want SAX to sort them all out for me :-) P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Aug 5 01:44:01 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:27 2004 Subject: Namespaces/XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 6 Message-ID: Two ideas I _really_ like, though I'm not 100% sure of their acceptability. First, from John Cowan: > xmlns:XSC CDATA #FIXED "(XSchema URI)" > xmlns CDATA #FIXED "(XSchema URI)"> > >thus making either XSC or null a valid prefix for XSchema. Then >all XSchema elements are declared in the DTD with no colons except >XSC:Doc and XSC:More, which have ATTLIST declarations thus: > > xmlns CDATA #FIXED ""> > xmlns CDATA ""> > >and likewise for XSC:More. Then within the XSC:Doc and XSC:More >elements there is no default prefix, which is what IBTWSH wants. >XSC:More users can override this with an explicit xmlns attribute. Basically, the point of this is to allow XSchema declarations to use the default namespace, while still allowing the components under Doc and More to have 'freedom of namespace' or somesuch. (I'll probably make XSC:Doc implied, not fixed.) Is this practice acceptable? The XSC prefix will have to be used on both XSC:Doc and XSC:More because they assign the default namespace to something other than the XSchema identifier. I don't see any reason the same URN can't be used twice, and end up equivalent. If it's kosher, it's going in. ---------------------------- The second provides for more flexible prefix handling within XSchemas, and will have a direct impact on Section 3.0 more than 2.0. The second idea, for avoiding namespace collisions within XSchema, comes from Peter Murray-Rust: > > > > ]> > >... > > > > AttValue="&foo; URI"/> > > >That allows a single change in the XSchema definition file to percolate >through the whole file. I actually think this is cleaner and more powerful >than PEs for maintenance. This works to some extent, allowing the XSchema designer to change the prefix, but it still requires changes in the XSchema and not just in the document instance. There are other fun things we could do, like adding an attribute to XSC:XSchema elements that identifies the namespace in which they live via the URN (forget the prefix), but I'm really not sure what's best here. All suggestions, public or private, are welcome. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Aug 5 02:54:07 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:27 2004 Subject: XSchema question Message-ID: <01ba01bdc00a$47ef8f50$2ee044c6@arcot-main> >It might be tricky; you'd need to read in the XSchema, modify it, and spit it >back out. Since XSchemas use XML instance syntax, doing this shouldn't be too >hard; it's a matter of walking the tree to the information you want (not the >straight XML element tree, but reasonably close) making the change, and >resaving the schema. You'd need one schema copy per instance of the >application that was prone to this behavior, so multiple copies of the same >application wouldn't trip over each other's changes I am afraid there isn't any XSchema file to modify because XSchema is 'inline'. Inline metadata is potentially very important in applications such as XLF where each log producer could introduce their own schema (talk about going schizo!) and update them as needed. For example, if a TV station streams out its programming as a single XML stream, it would have to update its schema for each show. Anyway, it is clear to me at this point that XSchema does not address 'dynamic-schema' and 'inline-schema'. Thanks for the comments. Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Aug 5 04:07:50 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:28 2004 Subject: namespaces in dtd's Message-ID: <35C7DAC8.BE1EC6B4@mecomnet.de> what is the intended encoding for a namespace declaration in a dtd. is the "declaration before use" rule intended to apply here? will the norm be that at least the xmlns:? attribute declaration always appears before the respective element declaration? will one attribute be expected per element (whether as a norm in the internal subset, or not) in order to declare a default uri and bind the prefix? will the choice of the elements which are afforded xmlns attributes in effect specify the 'relative' root elements? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Aug 5 04:16:09 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:28 2004 Subject: Namespace Comments References: <002a01bdbf82$4cd6ef50$2ee044c6@arcot-main> <35C6CA76.38929FF0@jclark.com> <35C7960E.5C986D94@mecomnet.de> <35C78497.645D203D@Eng.Sun.COM> Message-ID: <35C7DCB3.9653A068@mecomnet.de> David Brownell wrote: > > james anderson wrote: > > > > as an alternative, > > > > xml:namespace=":" > >... > > Consider: > > > > > > > Basically, many namespaces defined in one element. > that's just a sugaring problem: xml:namespace="='' prefix>='' ..." (whereby the ':' in my initial query was ill advised) the processing necessary to pick out arbitrarily named attributes is sufficiently complex, that unary values cannot, in themselves, be an advantage. other reasons? wait a minute ... one 'advantage' which comes to mind is that the disjoint attributes allow one to factor the declarations across physical entities and/or time. ? is that an advantage or a disadvantage? are "people" really intending that (beyond binding of default namespaces on the fly - during decoding) the after-the-fact binding/re-binding of an attribute value have the effect of changing the namespace of a name and thereby, among other effects, from the perspective of a "dom-based processor", the 'type' of an already decoded element? i've wondered, in the past, whether 'universal' names were really intended denote stable types across documents, since although the name itself may be stable, the side-effects of decoding two successive documents might well yield two different element declarations. using attributes to bind prefixes takes this a step further. is it intended that a processor simply tolerate bindings which leave an element in an "unserializable" form? should it constrain attribute bindings so that namespace bindings are somehow protected? are the xmlns:? bindings to be treated as the property of the parser/serializer whereby the latter is permitted to treat current values hints only? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Wed Aug 5 04:26:42 1998 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:03:28 2004 Subject: Namespaces and URNs Message-ID: > -----Original Message----- > From: Peter Murray-Rust [mailto:peter@ursus.demon.co.uk] > Sent: Tuesday, August 04, 1998 12:32 PM > To: xml-dev@ic.ac.uk > Subject: Namespaces and URNs > > > I would appreciate guidance from people knowledgeable in URN > syntax and use. > > (A) The NS draft gives an example as > xmlns='urn:loc.govs:books' > but a private correspondent tells me than URNs should be of the form > urn:scheme:something - so unless loc.gov is a scheme there > appear to be > differences of opinion. Note that the examples in the namespace paper are intended to be just that -- hypothetical examples. That doesn't mean that the URNs used in the examples have actually been registered -- they certainly have not. However, this example does have a problem -- the period in "loc.govs" is not allowed per the productions in http://www.isi.edu/in-notes/rfc2141.txt. The example ought to at least be syntactically conformant. I have already pointed this out, and will ensure it gets fixed before the spec goes to PR. > > (B). I would greatly value consistency in the use of standard > URNs. The > only way we can implement interoperability is if everyone > uses the same URN > to refer to a namespace. Since the URN need not represent a real WWW > resource there is very little check on whether a URN is fictitious. > The draft shows an example of this problem. HTML is > referenced mainly > through the string: > http://www.w3.org/TR/REC-html40 > This seems fine to me, but later (5, box 6) it is referenced by: > urn:w3-org-ns:HTML > > Are these equivalent? If so, there must be a central registry > of synonyms > somewhere. And, if so, it places a great burden on > implementers who must > search the WWW for all possible equivalences. I would *much* > prefer that > the whole world used exactly the same string for the > namespace for HTML4.0. Again, the examples are meant to be examples, and need not be consistent among themselves. As John Cowan pointed out URNs, if and when they are widely supported, are clearly the best solution for the persistent unique names of XML namespaces. Unfortunately, URNs don't really exist yet, and in interim URLs or other URIs can be used. > > Experience with HTML has not helped the cause of unique > identifiers for > DTDs. I suspect that there are zillions of different (F)PIs > in the HTML > DOCTYPE statements round the world. And - unless I'm told > different - I > suspect no software actually processed them. So we are going > into an era > where we have to convince authors that NS URNs are critically > important - > they can't just guess and hope. > > I'd like to suggest that people who really know post > the authoritative > URNs for common DTDs/schemas. And that we all stick to using > the correct > one in all our examples. Among the ones we shall need in many > namespace > examples are: > HTML (including version) > IBTWSH > XSchema > MathML (a useful example) > DublinCore > RDF > XML-Data I think you're confusing URNs with URI schemas. All URNs use one schema: "URN". This list you show above would indicate that you're interested in defining standard URNs for some popular namespaces. While this isn't a bad idea, I think it will ultimately be hopeless to take on the task of tracking all interesting namespaces. The namespace spec must allow for the use of namespaces without requiring each individual namespace be registered prior to use. This may mean piggy-backing on existing uniquefying mechanisms such as Internet Domain names, which would argue for the use of URLs in interim. This doesn't mean that some of the more popular and widely used namespaces shouldn't use URNs. There is a procedure described in http://www.ietf.org/internet-drafts/draft-ietf-urn-nid-req-03.txt for registration of URN namespace ID (the "NID" in the RFC2141 productions) might be registered. Unfortunately, the current draft starts out by saying: 'For the purposes of this document, an "IANA-like" entity is assumed to exist.' I take this as an indication that the IANA itself has not actually taken up this task, and that no other organization has stepped forward to do so. > > Having developed 2 DTDs (CML and VHG) I need to know how to > prepare URNs > for them. It seems clear that anyone wishing to create a DTD > which can be > used for Namespaces has to buy/borrow a domain name. (I > suppose they could > buy an FPI instead, but since I already have domain names I'd > prefer to > stick with those). > > P. Well, you could try to be the first on your block to register a URN, if you could find who to register it with. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Wed Aug 5 05:24:25 1998 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:03:28 2004 Subject: Namespace Comments Message-ID: Mr. Anderson -- To answer the first of your many questions: Yes, a syntax virtually identical to yours, that allowed multiple namespace declarations in a single attribute was considered. The resulting syntactic problems swayed the WG away from that approach. (Some of the issues -- you now need an internal quoting mechanism, or a careful proscription on the legal characters in a URI, in order to allow proper separation of the pairs. It gets even messier to come up with a syntax to declare the default prefix.) I couldn't understand most of the rest of your questions. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 5 08:15:03 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:28 2004 Subject: Deterministic behavior in processors Message-ID: <3.0.32.19980804231436.00a831a0@207.34.179.21> At 02:00 PM 8/4/98 -0400, Dean Roddey wrote: >Hmmm. Ok I'm going to play the "Very Cynical Devil's Advocate" here and ask the >obvious question of "Is a spec that allows 2^7'th conforming variations really >a spec?" ... >It would serve >everyone's best interests (IMHO) to have a very tight specification in which >there are very few optional reactions to the same circumstances. Basically I think this concern is reasonable, and the fact that the behavior of a NVP is non-deterministic has bothered not a few people in the XML process; there's even an appendix in the spec that talks about this. As a registered minimalist, it never really bothered me, because I have always thought that external entities were pretty bogus outside the authoring arena anyhow, and anybody who sends anything across the wire had better either: (a) guarantee no external entities, or (b) potentially have external entities AND specify use of a validating processor In both of these scenarios the behavior is completely deterministic. I think that anyone who sends XML across the wire and uses external entities and does not specify a validating processor has rocks in their head and deserves what they get. One extrapolation from this argument is that external entities are bogus and shouldn't have made it into XML. I believe this, but only about 48% of the time. Another extrapolation is that we should decree that NVP's *never* read external entities. But in the authoring situation, having an NVP be potentially able to read something like &chap1; &chap2; is handy enough that it seems senseless to rule it out just because it opens the door to really stupid behavior, viz. sending external entities over the wire without specifying a validating processor. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Aug 5 08:25:20 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:28 2004 Subject: Namespaces and URNs Message-ID: <3.0.32.19980804232628.00a86fd8@207.34.179.21> At 07:32 PM 8/4/98, Peter Murray-Rust wrote: >(A) The NS draft gives an example as > xmlns='urn:loc.govs:books' >but a private correspondent tells me than URNs should be of the form Hmm, while in fact URN's are still mostly a hypothetical animal, our examples should exhibit correct URN syntax, which that one doesn't, so it needs to be fixed. >Are these equivalent? If so, there must be a central registry of synonyms >somewhere. There is little chance of this happening. Basically, the reason namespaces exist is to allow software to recognize & process particular chunks of markup. Thus, if the W3C were to declare that for HTML4 as the W3C defines it, the canonical URI is to be "[hint hint, Dan]", then I would expect that a lot of HTML processors, such as those built in Redmond and Mountain view, would gear their software to recognize that namespace and do so right now. Since there is no hope of a central registry of everything, basically namespace URIs will I expect be established via a messy market-driven mechanism whereby certain classes of software converge around certain canonical URIs and agree that this means HTML, that means RDF, the other means CML, and so on. I would expect that people who promulgate useful vocabularies ought at the same time to publish a canonical namespace URI, and I expect that the chances of that URI being bought-into by other software would be a function of (a) how useful the vocabulary is, and (b) how much the group publishing the URI is trusted not to abuse the namespace I.e. Peter, you ought, in the near future, to publish a canonical URI for CML. It doesn't need to be a URN; in fact, in the near-term, I would be nervous about using URNs since they are (relatively speaking) poorly understood and not widely implemented [pause for obligatory flaming from URN fans]. The W3C ought to publish some canonical URI for HTML and for SMIL and XML and CSS and a bunch of other things. Microsoft *did*, to their credit, publish a canonical URI for XML-data. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 5 08:27:29 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:28 2004 Subject: XSchema question In-Reply-To: <01ba01bdc00a$47ef8f50$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980805072622.35a74952@pop3.demon.co.uk> At 17:41 04/08/98 -0700, Don Park wrote: [...] > >Anyway, it is clear to me at this point that XSchema does not address >'dynamic-schema' and 'inline-schema'. Actually I think it does - although I may people aren't going to be comfortable with the former - rather like self-modifying code. If I understand you you want to have a schema/DTD that changes dynamically with time, driven by the contents of the (changing) document. This is not common in traditional SGML where the DTD is used to constrain documents to a pre-conceived format. Your approach is to review the contents of the log file and change the DTD/schema to reflect them. It isn't common to generate DTDs from documents but there is a tool called FRED from OCLC which apparently does this. Of course a human could also do it. XSchemas can be 'inline' in that being an XML document they can be included (using the entity mechanism: ]> &myschema; ... rest of log file ... This includes the content of the myschema.xml file, so it's part of the tree. It cannot be dynamic. If you want it dynamic you could use something like: ... rest of log file ... We haven't yet defined the syntax or mechanism whereby an XSchema gets 'used' and you are welcome to devise your own. So the second syntax would allow you to link to the (dynamically updated) myschema.xml file at arbitrary intervals. The file could change in the meantime. If this is what you want to do you'll probably have to write your own system for managing it because I guess it's not commonly done in SGML. P> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 5 08:44:33 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:28 2004 Subject: Namespaces and URNs In-Reply-To: Message-ID: <3.0.1.16.19980805074423.35a7b450@pop3.demon.co.uk> At 19:25 04/08/98 -0700, Charles Frankston wrote: > >Note that the examples in the namespace paper are intended to be just that >-- hypothetical examples. That doesn't mean that the URNs used in the >examples have actually been registered -- they certainly have not. However, Thanks. Understood. [...] >Again, the examples are meant to be examples, and need not be consistent >among themselves. As John Cowan pointed out URNs, if and when they are >widely supported, are clearly the best solution for the persistent unique >names of XML namespaces. Unfortunately, URNs don't really exist yet, and in >interim URLs or other URIs can be used. I had assumed that the widespread use of urn: in XML-related drafts meant that it was a usable approach. I have kept hearing that URNs aren't quite ready - sounds like we are still some way away. > [...] > >I think you're confusing URNs with URI schemas. All URNs use one schema: >"URN". This list you show above would indicate that you're interested in >defining standard URNs for some popular namespaces. While this isn't a bad >idea, I think it will ultimately be hopeless to take on the task of tracking >all interesting namespaces. The namespace spec must allow for the use of I wasn't planning to track all of them. I was suggesting that *during the prototyping of XML-names tools* we were publicly consistent. Thus is someone writes a namespace tool to deal with HTML4.0 there needs to be a way for them to communicate exactly what version of HTML is meant. And we all have to use the same string. Because that string is the only point of having namespaces which extend beyond the document. So if we are serious about making namespaces work we need to start using the same strings to refer to the same namespace. I agree that that means that DTD owners/maintainers need to be involved. Since most of the common DTDs are within the remit of the W3C, they should be thinking of how to identify them in namespaces. If they want to use FPIs, fine. But they should make it clear which the FPIs *are* and use them consistently. If they want to use URLs instead - fine. But they shouldn't encourage the use of both simultaneously. [...] >> >> Having developed 2 DTDs (CML and VHG) I need to know how to >> prepare URNs >> for them. It seems clear that anyone wishing to create a DTD >> which can be >> used for Namespaces has to buy/borrow a domain name. (I >> suppose they could >> buy an FPI instead, but since I already have domain names I'd >> prefer to >> stick with those). >> >> P. > >Well, you could try to be the first on your block to register a URN, if you >could find who to register it with. Doesn't sound very hopeful. My best strategy appears to by to put a large notice on the CML web-site saying: "The namespace URL (or should that be URI?) for referring to CML1.0 should be: 'http://www.xml-cml.org/xmlns/cml10'. This is the only appropriate string to use as an xmlns attribute value to identify CML1.0. Anyone writing software to process CML documents should use this string to identify whether the author intends to map the namespace onto CML1.0. No other string should be used to identify CML1.0 in an XML document, even if CML resources are mounted on a different server. [By the way, the URL doesn't actually point to an existing resource ... ]" If you think this is a good idea, my suggestion is now that the 'DTD owners' of the other namespaces did something similar. If we don't start getting formal about namespace names at this stage people won't take the process very seriously. P. > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Aug 5 09:04:06 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:28 2004 Subject: XSchema question Message-ID: <007401bdc03d$f84213e0$2ee044c6@arcot-main> >If I understand you you want to have a schema/DTD that changes dynamically >with time, driven by the contents of the (changing) document. This is not >common in traditional SGML where the DTD is used to constrain documents to >a pre-conceived format. Your approach is to review the contents of the log >file and change the DTD/schema to reflect them. It isn't common to generate >DTDs from documents but there is a tool called FRED from OCLC which >apparently does this. Of course a human could also do it. 'dynamic-schema' is not driven by the contents but by the needs. It is somewhat similar to namespaces except with versions. *sigh* I am not explaining this too well, am I? >XSchemas can be 'inline' in that being an XML document they can be included >(using the entity mechanism: > > >]> > >&myschema; >... rest of log file ... > Above is 'inline-expansion' and not quite 'inline'. 'myschema.xml' exists outside the document rather than being part of the stream. 'Inline-schema' looks similar to internal DTD subset except it can be any where in the XML stream and not just in the !DOCTYPE declaration section at the beginning of a XML stream. 'Dynamic-schema' is simply schema which can be changed. I don't know XSchema too well so allow me to use DTD syntax to illustrate an exampe: Am I being any clearer? Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jnava at Adobe.COM Wed Aug 5 09:10:26 1998 From: jnava at Adobe.COM (Joel Nava) Date: Mon Jun 7 17:03:28 2004 Subject: Deterministic behavior in processors In-Reply-To: Tim Bray "Deterministic behavior in processors" (Aug 4, 11:16pm) References: <3.0.32.19980804231436.00a831a0@207.34.179.21> Message-ID: <9808050009.ZM11162@atlantis> This idea of specifying the use of a validating processor over the wire got me to wonder what method(s) would be preferable for doing so. Any suggestions? Thanks, -- Joel xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Aug 5 10:10:59 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:28 2004 Subject: No subject Message-ID: <3.0.1.32.19980805100748.0070cc78@ifi.uio.no> (Sorry to be so late in submitting this. I'm having connectivity problems, which means that all email has to be transferred by floppy to my work computer.) * Lars Marius Garshol | | The CATALOG extension to the catalog file format means that TR | 9401:1997 can't be followed directly, since it does not have this | entry. * John Cowan | | How's that? This is no extension: it is documented right in | 9401:1997. (Unfortunately, there are neither clause numbers nor | HTML anchors in that document, but search for the string "The | CATALOG entry can be used".) It turns out that you're right. CATALOG entries weren't in TR 9401 originally, but I now see that they have been added later. What confused me was that they weren't mentioned in the conflict resolution part, but rather were defined on their own. Still, it seems that even with the CATALOG entries, TR 9401:1997 is compatible with my original wording. (Although that may not have been entirely obvious from the text.) | [...quote of my proposal snipped...] | | AFAIK the only difference (modulo System) is that Maps are always | processed before Delegates within a single catalog even if the Maps | physically follow. This is probably a good rule. I agree, and that's the same as in my proposal. Look at it again: all Maps are processed before any Delegates. The order within the catalog is the last sorting criterion. Maybe the bit about catalog file origin (sort criterion 1) confused you? That part is there to take care of the CATALOG entries and the cases where multiple catalog files are given to the parser. (nsgmls accepts a semicolon- separated list of catalog files.) * Lars Marius Garshol | | (NB: The SYSTEM/Remap entry is not present in the original proposal, | but I think it should be included. The functionality it provides was | part of what the PubIdResolver interface of SAX was supposed to | enable.) * John Cowan | | I still have problems with this, as it violates referential | transparency. It means that the processor of a document can change | the content of the document based on a catalog entry, and | independent of the author's declared intent. I'm uneasy about it myself, for exactly the same reasons, but I think that this will sometimes be needed, especially with DTDs. What if you're parsing a document retrieved over HTTP and it uses an explicit SYSTEM literal to refer to a DTD, also with HTTP, only the DTD URL just gives you a 404? Or you want to use the DTD modified with architectural forms declarations, or modified in some other way? | I take your point, but it is incomplete, specifically in the matter | of what to do when a Delegate entry is accepted: discard the rest of | the current catalog *and* the entire queue, and start over. No, it is not really incomplete in this regard, although perhaps this should be covered a little more explicitly. Imagine the following catalog: DELEGATE "-//W3C//DTD HTML" htmlcatalog PUBLIC "-//LMG//Article DTD//EN" "egne\article.dtd" PUBLIC "-//W3C//DTD HTML 3.2 Final//EN" HTML32.dtd Sorted, these entries come out as: PUBLIC "-//LMG//Article DTD//EN" "egne\article.dtd" PUBLIC "-//W3C//DTD HTML 3.2 Final//EN" HTML32.dtd DELEGATE "-//W3C//DTD HTML" htmlcatalog This means that if you try resolving "-//W3C//DTD HTML 3.2 Final//EN" you'll get "HTML32.dtd", and not be referred to the "htmlcatalog" catalog file. If you try resolving any other FPI starting with "-//W3C//DTD HTML" you'll be referred to the htmlcatalog. Still, if you misunderstood me I think the wording should be expanded somewhat to remove the problems: ---New proposal: 7. Conflict resolution When more than one catalog entry applies to an entity, the conflict can be resolved by using the entry that comes out first when the entries have been sorted in the order specified below. Entries from catalog files referred to by DELEGATE entries are excluded from this sorting process. If a DELEGATE entry is chosen as applicable the process is repeated with the entries gathered from the delegated catalog file. Entries are sorted by (in this order): 1) By catalog file, in the order the catalog files were processed, reckoned by when processing of the file started. CATALOG entries are to be processed in a depth-first order. 2) By the entry type (in this order): a) SYSTEM (Remap) b) PUBLIC (Map) c) DELEGATE (Delegate) 3) The order in which the entries appeared in the catalog file The conflict resolution in XCatalogs and SGML Open Catalog files (as defined in TR 9401:1997) is 100% compatible. [Perhaps this is better off in a dedicated section that describes the differences between these two proposals?] --- End of proposal -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Aug 5 10:19:31 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:28 2004 Subject: Namespace Comments (and dtd encoding) References: Message-ID: <35C831D0.8C4FD0C5@mecomnet.de> Charles Frankston wrote: > > Mr. Anderson -- > > To answer the first of your many questions: > > Yes, a syntax virtually identical to yours, that allowed multiple namespace > declarations in a single attribute was considered. The resulting syntactic > problems swayed the WG away from that approach. (Some of the issues -- you > now need an internal quoting mechanism, or a careful proscription on the > legal characters in a URI, in order to allow proper separation of the pairs. > It gets even messier to come up with a syntax to declare the default > prefix.) xml is already sufficiently baroque, that i can only presume that this was not the deciding argument. :) > > I couldn't understand most of the rest of your questions. i surmise (from the timestamp on your message) that you are actually refering here to my other posting re dtd encoding... if the questions were not understandable, then i must have misunderstood something basic about the draft's intentions. let my try again by simply posing the open question: could someone please post a "complete document" (that is including a dtd) for the third example in section 5 of the draft (the one with the root element "bk:book")? thanks. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Wed Aug 5 10:44:45 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:28 2004 Subject: Namespaces ! In-Reply-To: John Cowan's message of "Tue, 04 Aug 1998 15:10:13 -0400" References: <199808041536.RAA23101@chimay.loria.fr> <35C75C95.9E003C6D@locke.ccil.org> Message-ID: John> John Cowan 0> In article <35C75C95.9E003C6D@locke.ccil.org>, John wrote: John> Patrice Bonhomme wrote: >> If the draft says it..... It sounds strange. My parser reads a >> tag name (prefix+local) of an Element and has to wait for the >> namespace declaration to qualified this name. For me, it is as >> if we put the Element Declaration within the open tag of this >> Element, unthinkable. John> Not much of a problem, really, at least for SAX-style parsers John> that return the GI and the attribute map at the same time. It also works quite well for applications based on parsers like nsgmls, which produce an ESIS stream with the attributes before the GI. Having the NS declaration as an attribute of the topmost element to use it may help applications which process a tree extracting subtrees of a particular namespace. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Aug 5 10:51:26 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:28 2004 Subject: Namespaces in 20 lines (and dtd encoding) References: <35C69EB5.B4462AD0@jclark.com> Message-ID: <35C8394C.607A8C71@mecomnet.de> James Clark wrote: > At first glance the new namespace draft might appear rather complicated, > ... at second glance too... > String expandName(String name, Element element, boolean isAttribute) { > // ... > for (; element != null; element = element.getParent()) { > String ns = element.getAttributeValue(declAttName); // ... > } (as an addenda to my questions re dtd encoding:) how does one do attribute defaulting on attributes in the "xmlns" namespace when the universal name of the element type is not yet defined? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 5 10:55:06 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:28 2004 Subject: Deterministic behavior in processors In-Reply-To: <3.0.32.19980804231436.00a831a0@207.34.179.21> Message-ID: <3.0.1.16.19980805094610.28ef0982@pop3.demon.co.uk> At 23:16 04/08/98 -0700, Tim Bray wrote: >At 02:00 PM 8/4/98 -0400, Dean Roddey wrote: [...] >>It would serve >>everyone's best interests (IMHO) to have a very tight specification in which >>there are very few optional reactions to the same circumstances. > >Basically I think this concern is reasonable, and the fact that the So do I. I have always worried about what the parser actually does and emits. >As a registered minimalist, it never really bothered me, because I >have always thought that external entities were pretty bogus outside >the authoring arena anyhow, and anybody who sends anything across the >wire had better either: > >(a) guarantee no external entities, or >(b) potentially have external entities AND specify use of a validating > processor This really worries me and puts me in the rocks-in-head category. I have blithely assumed that external entities were a good thing. They represent a way of re-using and normalising information. I've even been telling people they are a good thing. > >In both of these scenarios the behavior is completely deterministic. > >I think that anyone who sends XML across the wire and uses external >entities and does not specify a validating processor has rocks in their >head and deserves what they get. Gulp. That's me. I have been reading the spec on and off for two years and I have clearly failed to understand this. I am suffering from SAXocephaly. I use the following construct frequently: ]> &a; &b; I have briefly re-read the spec and it's not immediately clear to me where it says that a NVP is allowed to neglect a and b if it's feeling lazy. (It does say that if these are in an external subset they can be neglected, I think.) I would hesitate to criticise the spec but if the above document does not mean what I think it should mean (or worse, depends on what software I use) then I have serious problems. I *can't* use a validating parser because it's impossible to construct a DTD for the complex information in a.xml and b.xml (uses at least 4 namespaces). I don't want a parser which bombs on the first 'invalidity' fatal error - i.e. doesn't have a DTD. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 5 10:55:06 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:28 2004 Subject: XSchema question In-Reply-To: <007401bdc03d$f84213e0$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980805093319.220f0f10@pop3.demon.co.uk> At 23:54 04/08/98 -0700, Don Park wrote: > >'dynamic-schema' is not driven by the contents but by the needs. It is >somewhat similar to namespaces except with versions. *sigh* I am not >explaining this too well, am I? Let me have another go. [This is important for XSchema since we haven't yet thought *how* we are going to use it.] One simple way to use XSchema is: myschema.xml --XCS2DTD --> myschema.dtd + mydoc.xml | | V myValidatingSAXParser | | V my tree | | V my application In this there is a static schema which is transformed into a DTD because that is what the parser software wants. [In the future parser might be written to accept schemas directly ... opinions on this will differ :-)] I think what you want to do is something like: phase1: ... initial schema ... (time, date) ... ... ... ... ... ... ... ... zillions of these with more coming in every millisecond ... This is how I think many people see XSchema being used. However we haven't got around to defining the syntax and behaviour. IOW maybe we need a trigger of some sort in a SAX application that specifically picks up an XSchema event. This would probably mean a two-pass system - one to determine that there was a schema in the file and another to re-run the parsing using it. I think one implication of your approach - which again XSchema has not addressed - but has to - is that the validation or other XSchema activity applies to what comes after it in the document. Of course, with namespaces we may be able to restrict XSchema to process only a small part of the document. Then your log info changes. You don't want to make a separate log but you need to change the schema to reflect the new info. I human changes the schema to include (say) email: phase2: ... initial schema ... (time, date) ... ... ... ... ... ... ... ... info changes ... ... new schema ... (time, date, email) ... ...... ...... ...... ...... ... ...... ...... ...... ... zillions of these with more coming in every millisecond ... This represents quite a complex processing model. It requires a processor to run through the first few gigabytes of log and then change schemas and run through the next. I think you would be better with a different file for each schema change and link them together with XLink/entities. >Am I being any clearer? Yup. Let's solve the single schema problem first. Simon? P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Wed Aug 5 11:15:22 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:29 2004 Subject: API versioning in SAX In-Reply-To: Toby Speight's message of "04 Aug 1998 10:14:53 +0100" References: <000f01bdbf08$d031a540$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: Toby> Toby M. Speight Michael> Michael Kay 0> In article 0> <000f01bdbf08$d031a540$1e09e391@mhklaptop.bra01.icl.co.uk>, Michael 0> wrote: Michael> Every time I use SAX, I forget that the parser is allowed to Michael> hand me data one character at a time if it chooses. Perhaps Michael> someone should write a SAX parser that does just that, so I Michael> can test that my application would cope with it. 0> In article , Toby wrote: Toby> You could write a SAX filter that accepts input from the parser Toby> of the moment, and delivers it a character at a time. It should Toby> be fairly trivial given the filter interface recently posted Toby> here. I forgot to mention: one could also write a filter which buffers character data and passes it on in maximal-sized gobs. I think this would be quite a popular filter. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Wed Aug 5 11:18:05 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:29 2004 Subject: Namespaces ! In-Reply-To: Your message of "05 Aug 1998 09:46:11 BST." Message-ID: <199808050914.LAA06187@chimay.loria.fr> I think that XML is really becoming HTML. I though that XML should be "a simplify subset of SGML" but it seems to be like the "Supra HTML recommandation". tms@ansa.co.uk said: ] Having the NS declaration as an attribute of the topmost element to ] use it may help applications which process a tree extracting subtrees ] of a particular namespace. No, we clearly need to make a distinction between the NS declaration and the NS itself. We could also put the Element declaration (content model, attribute list declaration) as a set of "ghost" attributes within the element itself :

... Funny, no ? This attibute-based definition for XML namespaces is really bothering me. Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 5 11:18:22 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:29 2004 Subject: Namespace Comments (and dtd encoding) In-Reply-To: <35C831D0.8C4FD0C5@mecomnet.de> References: Message-ID: <3.0.1.16.19980805101502.3007477a@pop3.demon.co.uk> At 10:20 05/08/98 +0000, james anderson wrote: [...] >could someone please post a "complete document" (that is including a dtd) for >the third example in section 5 of the draft (the one with the root element "bk:book")? I'll have a go (in my copy it's the second example); ]> The point is - I think - that the DTD parser is completely dumb. It doesn't care about colons (except to recognise that they are legal). I assume - though I haven't tried it - that this DTD will validate the example with any of the current parsers. The main problem is that some authors are going to want to include more information than title and number. This may also involve other namespaces. So then the content model gets very complex and has to be revised often. So we actually end up with: > > ]> This implies the possibility of *locally valid information components* - i.e. the XML-data content could be validated against that DTD but not the larger document. I also expect that there is a solution using Architectural Forms but I am not an expert. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Wed Aug 5 11:22:46 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:29 2004 Subject: XSchema question Message-ID: <199808050915.LAA01754@berlin.dvs1.tu-darmstadt.de> > 'Inline-schema' looks similar to internal DTD subset except it can be any > where in the XML stream and not just in the !DOCTYPE declaration section at > the beginning of a XML stream. 'Dynamic-schema' is simply schema which can > be changed. I don't know XSchema too well so allow me to use DTD syntax to > illustrate an exampe: > > > > > > > > > > > > > > Hey! Nice idea! XSchema certainly supports this -- it's just a bunch of XML elements. All your processor needs to do is recognize the XSchema elements, store the information in them, and apply it to all following elements until the next XSchema element is reached. (Remember that the root element of an XSchema document is named "XSchema" -- this makes recognition and containment of XSchema elements easy.) Some comments: 1) You've probably already realized this, but a DTD for such a file would be of little or no use. Because each XSchema section can introduce new elements and redefine old ones, the DTD would probably consist of a bunch of elements with content models of ANY. This is of no use either for validation or determining storage structures on the fly. 2) The above document is not well-formed. You need to wrap it in a container element such as . 3) The semantics of how each successive XSchema affects the previous XSchema are not well-defined (additive? total replacement? partial replacement?) and probably won't be defined in XSchema 1.0. You are therefore on your own. For safety's sake, I suggest you treat each XSchema as a completely new definition of the following elements. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Aug 5 11:23:07 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:29 2004 Subject: XSchema question Message-ID: <003401bdc050$e7832450$2ee044c6@arcot-main> Peter, What you described is exactly what I was trying to explain. It sure is nice to have others standy by to interpret my ramblings . >This represents quite a complex processing model. It requires a processor >to run through the first few gigabytes of log and then change schemas and >run through the next. I think you would be better with a different file for >each schema change and link them together with XLink/entities. I already have a working prototype that does this and it does not require complex processing model. It just looks complex. >Yup. Let's solve the single schema problem first. Simon? But don't you prefer completely crazy hairball of a problem over simple problems? Thanks for the help. I think I'll continue to kick the hairball on my own just for 'kicks'. Regards, Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Aug 5 11:46:56 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:29 2004 Subject: XSchema question Message-ID: <001801bdc054$b6746870$2ee044c6@arcot-main> >Hey! Nice idea! XSchema certainly supports this -- it's just a bunch of XML Thanks. Support is, I suppose, unintentional?;-) >Some comments: >1) You've probably already realized this, but a DTD for such a file would be of >little or no use. Because each XSchema section can introduce new elements and >redefine old ones, the DTD would probably consist of a bunch of elements with >content models of ANY. This is of no use either for validation or determining >storage structures on the fly. You are right but it makes perfect sense for transitory documents which exists only while it is moving from one place to another. Ability to redefine default attribute values should be enough of a benefit I think. >2) The above document is not well-formed. You need to wrap it in a container >element such as . Well, due to possible problems with missing root element's end tag (it ain't there if the log file is not closed), XLF data is parsed as a well-formed external entity like below. ]> &logfile; >3) The semantics of how each successive XSchema affects the previous XSchema are >not well-defined (additive? total replacement? partial replacement?) and >probably won't be defined in XSchema 1.0. You are therefore on your own. For >safety's sake, I suggest you treat each XSchema as a completely new definition >of the following elements. Food for thought. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Wed Aug 5 11:50:13 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:29 2004 Subject: XSchema question Message-ID: <199808050940.LAA01774@berlin.dvs1.tu-darmstadt.de> > But don't you prefer completely crazy hairball of a problem over simple > problems? Thanks for the help. I think I'll continue to kick the > hairball on my own just for 'kicks'. I think this is a really nice usage of XSchema and no different from most other XSchema applications -- the deciding factor is that the application gathers schema information at run time, rather than having it hard-coded. In general, the code that does this shouldn't care if the schema information changes half-way through the file. So by all means, continue to play. It will give us more concrete data about implementing XSchema and perhaps open some new ground for 2.0. I would also point out that, not only is this idea useful for validation, it is also useful for building database storage structures on the fly. As I mentioned before, we are unlikely to address this in 1.0, but I would suggest the following (non-guaranteed) semantics for forward compatibility: 1) The XSchema applies to everything following it until the next XSchema is hit. 2) Each XSchema completely replaces the previous XSchema. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Wed Aug 5 11:58:09 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:29 2004 Subject: Namespace Comments (and dtd encoding) Message-ID: <199808050955.LAA01901@berlin.dvs1.tu-darmstadt.de> > The point is - I think - that the DTD parser is completely dumb. It doesn't > care about colons (except to recognise that they are legal). I assume - > though I haven't tried it - that this DTD will validate the example with > any of the current parsers. My first reaction was that it was dumb, too, but at some point, it's got to get smart. That is, it needs to resolve the prefixes in the DTD to determine what elements are being defined. As far as I can see, the new spec does not define when this occurs. The only relevant information I can find is that it specifically omits the 'Prefix Declared' constraint from the DTD productions ([12]-[17]). In the worst possible case, you would have to resolve the DTD prefixes every time there is a change in namespace declarations. Not only is this extremely ugly, it would lead to abuse such as the following, where the second A is in a different namespace than the first A and both A's are declared with a single element declaration: ]> asdf A more reasonable solution might be a namespace constraint that says that all DTD prefixes must be declared on the root element. However, without thinking this through too carefully, I suspect you lose a good deal of flexibility. Could someone in the know comment on how this is supposed to be solved, or point us to the relevant portion of the spec in case we're missing something obvious? Thanks. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Wed Aug 5 12:32:07 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:03:29 2004 Subject: External DTD Grammar In-Reply-To: John Cowan's message of Tue, 04 Aug 1998 15:42:04 -0400 Message-ID: <199808051031.LAA22145@stevenson.cogsci.ed.ac.uk> > Replacement texts can't contain PE references (PE declarations can, > but the references are resolved at entity declaration time), so it isn't > even necessary to push back the replacement text onto the input stream. This is not true - references are expanded when the entity is declared, but that may produce text containing new entity references. Consider: Entity e1 must expand to "this is not obvious". -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 5 12:45:05 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:29 2004 Subject: Namespaces ! In-Reply-To: <199808050914.LAA06187@chimay.loria.fr> References: Message-ID: <3.0.1.16.19980805113219.28efee04@pop3.demon.co.uk> At 11:14 05/08/98 +0200, Patrice Bonhomme wrote: > >I think that XML is really becoming HTML. I though that XML should be "a >simplify subset of SGML" but it seems to be like the "Supra HTML >recommandation". No. There are already many applications which have very little resemblance to HTML. For example WIDL, CDF, XML-Data, DublinCore, RDF, XSL, Chemical Markup Language, etc. In principle most of these can be managed by namespaces and (hopefully) compound documents can be created which contain several of them. Also, XML is a metalanguage - HTML is not. XML allows the extension and the specification of an indefinitely large set of applications of which XHTML (of whatever flavour) is simply one. An important one - which is why we frequently post examples of it. > [...] >We could also put the Element declaration (content model, attribute list >declaration) as a set of "ghost" attributes within the element itself : > >

... Funny, no ? Although XML-DEV is open to any new ideas I predict you won't get an immediate enthusiastic response from the XML-WG to this suggestion. There are lots of possibilities that the WG has considered and some of them may be replayed here. But I think they have already proposed other ways of accomplishing this. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 5 12:45:05 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:29 2004 Subject: XSchema question In-Reply-To: <003401bdc050$e7832450$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980805114336.094f86aa@pop3.demon.co.uk> At 02:10 05/08/98 -0700, Don Park wrote: >Peter, > >What you described is exactly what I was trying to explain. It sure is nice >to have others standy by to interpret my ramblings . Both RonB and I are enthusiastic about what you are addressing. > [...] > >I already have a working prototype that does this and it does not require >complex processing model. It just looks complex. > >>Yup. Let's solve the single schema problem first. Simon? > > >But don't you prefer completely crazy hairball of a problem over simple >problems? Thanks for the help. I think I'll continue to kick the >hairball on my own just for 'kicks'. The point I was making was that you have reminded me (and probably others) that we should address the question of how embedded XSchemas are processed. Obviously you (and I and anyone else) can come up with our own solution, but what we are really after is a standard approach that is re-usable. Otherwise you end up doing all your own code maintained when someone else could do it for you (i.e. the community). Assuming you/we are using SAX, an obvious approach would be a handler for XSchema elements. (I hadn't thought of more than one per file, but that's the beauty of XML - it's so versatile. Be warned, however, that people from a purist SGML background may not immediately take to this idea (admittedly they have SUBDOC for this, I think). So in an early implementation I'd put this in startElement(). Later we might have a startXSchema() event. The attraction of that is that it could locally verify against the XSchema spec. And if it returns an XSchema object , that could be queried (e.g. XSchema.getElement(String universalName). If you write your own you will be constantly rehacking every time the core XML specs/ideas change. In any case, I guess that if we solve the single case, the multiple case will be almost trivial. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Aug 5 14:20:14 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:29 2004 Subject: XSchema question Message-ID: Don Park, Ron Bourret, Don Park: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > >>Hey! Nice idea! XSchema certainly supports this -- >it's just a bunch of XML > >Thanks. Support is, I suppose, unintentional?;-) Unintentional of course, but very useful and a significant improvement to XSchema. This makes the so-far-nonexistent-but-shortly-to-be-written section 5 much more interesting: 5.0 Connecting XSchemas to XML Documents 5.1 Processing Models 5.2 Processing Instruction We have plenty of room to describe this operation, though I think we'll want to offer both PI syntax for linking external schemas and this inline syntax. If this is too complex, it may get held for 1.1 or 2.0, and I suspect inline processing will be something that is described but not made mandatory. Just including XSchema elements in the document (preferably at the top, right after the document's root element) is a bit tricky, potentially requiring the XSchema to declare and verify itself (I'd just use ANY on that usage to skip a lot of redundant processing). The application would definitely have to be on the lookout for XSchema elements in the XSchema namespace and treat them specially. The application could still be a layer on top of SAX or something similar, but there's a lot of work to do here. Don Park: >You are right but it makes perfect sense for transitory documents which >exists only while it is moving from one place to another. Ability to >redefine default attribute values should be enough of a benefit I think. Ron Bourret: >3) The semantics of how each successive XSchema affects the previous >XSchema are not well-defined (additive? total replacement? partial >replacement?) and probably won't be defined in XSchema 1.0. You are >therefore on your own. For safety's sake, I suggest you treat each >XSchema as a completely new definition of the following elements. We're definitely going to have to come up with a way to address what happens when multiple XSchemas appear in a document. I think it might be worthwhile to include an attribute on the XSchema element that indicates a fresh start or an overwrite. Repeating the whole schema to change an attribute default seems like overkill. How about: Where Replace cleans the slate and Overwrite writes over previous declarations? This is pretty tricky stuff, though I'd like to see it work... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Aug 5 16:01:27 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:29 2004 Subject: Deterministic behavior in processors Message-ID: <3.0.32.19980805065510.00a85a8c@207.34.179.21> At 12:09 AM 8/5/98 -0700, Joel Nava wrote: >This idea of specifying the use of a validating processor over the >wire got me to wonder what method(s) would be preferable for doing >so. Any suggestions? Now there's a good question. At the moment, we have no mechanism aside from a prominent notice on the website/marketing-material/tech-doc saying "output from the MegaSoft XML-frobnosticator v7.4 in general uses external entities, and thus a validating processor is required to process it" or "output from the MicroCorp XML-depullulizer v0.3 does not use external entities and may be processed correctly by a non-validating XML processor" David Singer of IBM at one time suggested that we bless another PI or something in the XML declaration, saying which is an assertion that no external entities are used. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Aug 5 16:01:42 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:30 2004 Subject: Deterministic behavior in processors Message-ID: <3.0.32.19980805070235.00a8da28@207.34.179.21> At 09:46 AM 8/5/98, Peter Murray-Rust wrote: >I have briefly re-read the spec and it's not immediately clear to me where >it says that a NVP is allowed to neglect a and b if it's feeling lazy. (It >does say that if these are in an external subset they can be neglected, I >think.) Section 4.4.3. C'mon Peter, this was one of the things we spent immense time hashing out well over a year ago. Now it turns out that de facto, typical real-world NVPs will actually on demand read external entities... but it was a basic design assumption, driven mostly by the war-stories of the browser guys, that it was not reasonable to expect a lightweight web-client type of app to resolve external entities in real time. The expectation is that the *right* way to do this kind of thing is with XLink, which should have been done months ago if it hadn't been for this #%!%$@ namespace swamp. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Aug 5 16:10:19 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:30 2004 Subject: Namespace Comments (and dtd encoding) References: <3.0.1.16.19980805101502.3007477a@pop3.demon.co.uk> Message-ID: <35C86987.53F736B6@mecomnet.de> Peter Murray-Rust wrote: > > ... > > The point is - I think - that the DTD parser is completely dumb. It doesn't > care about colons (except to recognise that they are legal). I assume - > though I haven't tried it - that this DTD will validate the example with > any of the current parsers. > i do not understand how such a reduced dtd processor will suffice. before a dtd definition can be created, the universal name must be known. otherwise the prefixes have been awarded the status of (temporarily) universal qualifiers. imagine (to take the inverse tack on mr bourret's example) a situation where the processor faced with a document streams of which various external entities contain either "ambiguous" or "undetermined" prefixes. 1. "ambiguous" prefixes would arise where identical prefixes are present in disjoint external entities and require accompanying attribute declarations in order to disambiguate them - and thereby otherwise identical local names. 2. "undetermined" prefixes would arise where non-identical prefixes are present in disjoint external entities, but accompanied with attribute declarations which map respectively identical local names to the same universal name. in order to interpret either of these two cases correctly, the dtd processor must understand universal names. (i've neglected examples here. if the problem's not clear i'll put them together) i think a similar situation could well arise within a single external entity, but the spec is sufficiently unclear on valid dtd content, that i'm uncertain. i take the example of disjoint entities since it demonstrates a case where a combination of independently valid external subsets may or may not be valid dependant on the prefix<->uri bindings which hold. i had, until monday, presumed that the prefix-namespace bindings have to be understood to hold at some point before elements are read, in order that the effective dtd can be created and am having a hard time understanding how to delay this binding, so to speak, beyond the close '>' in the doctype form. i'd really like to know the binding at the point where the respective element declaration is read, otherwise i have to delay its processing until some (at the moment poorly specified) later point. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 5 16:14:31 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:30 2004 Subject: Namespaces/XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 6 References: Message-ID: <35C86899.BC561C4B@locke.ccil.org> Simon St.Laurent wrote: > (I'll probably make XSC:Doc implied, > not fixed.) The point is that XSC:Doc has controlled content, and that content is IBTWSH elements (which may contain non-IBTWSH elements via the new parameter entity "ibtwsh.include"). IBTWSH being by intention HTML-compatible, and HTML having no prefixes, IBTWSH elements shouldn't appear with prefixes either. Allowing a different "xmlns" attribute value in XSC:Doc would mean that (e.g.) a P element would *not* be an IBTWSH P, but semantically some other P altogether, while still being required to conform (by the XSchema DTD) to the content model and attribute list declarations of an IBTWSH P. > I don't see any reason the same URN can't > be used twice, and end up equivalent. If it's kosher, it's going in. URN should be URI here and below. URI means: :-) > There are other fun things we could do, like adding an attribute to > XSC:XSchema elements that identifies the namespace in which they live via the > URN (forget the prefix), After mulling it for several days, I think this is the Right Thing. Add an #IMPLIED "ns" attribute to ElementDecl and AttDef elements whose value is an URI. XSchema validation can then proceed with respect to the actual URIs, and disregarding the actual prefixes used in particular documents. This gives XSchemas a leg-up on DTDs, which are bound to specific prefixes in the name of SGML (and XML 1.0) compatibility. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 5 16:23:53 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:30 2004 Subject: Revised namespaces draft available References: <3.0.1.16.19980803233224.2197a11c@pop3.demon.co.uk> <3.0.1.16.19980804212235.0bc7e67c@pop3.demon.co.uk> Message-ID: <35C86AD7.E5DEB905@locke.ccil.org> Peter Murray-Rust wrote: > Since namespaces are so fundamental I think it's very important that we > outline the various ways forward. AIUI your filter sits on top of SAX > whereas I suspect others (including at least myself privately) want SAX to > do as much as possible. We don't want these to be incompatible. ParserFilters sit on top of SAX, but in a SAX-compliant way: a ParserFilter is a (SAX) Parser. This is deliberately analogous to the way in which you can "push" modules onto a Java InputStream, OutputStream, Reader, or Writer, and still have something that conforms to that interface but can do new things as well. So you instantiate your SAX parser of choice, instantiate a NamespaceFilter, connect the two with a single call, and then just use the NamespaceFilter as a Parser, because it is one. The rest of your application doesn't change at all (except, of course, that it gets QNames in universal format). > This isn't much fun. It would be a very easy mistake to make. Can we > package the NS stuff in a single file and do something like: > > > %namespace1; > > %namespace2; > ]> > > This makes sure it gets included. Alas, no. Only if your parser is validating (and in SAX, there isn't even a way to *ask* if a parser is validating) are you guaranteed to process this. A NVP is free to treat the above as a comment. > >> - IBTWSH > > > >IBTWSH is non-namespace rather than single-namespace. > > My point was that if I use it in (say) VHG - as I intend to - it has to > acquire a namespace. Thus: > > > XYZZY > > A magic word > > > > unless you intend that it should always have the null namespace xmlns="". I > wouldn't think that a good idea. I intend that IBTWSH always have the same ns as HTML, which is currently the null namespace. So above, make it:

A magic word

I am considering modifying the current IBTWSH DTD to define "xmlns" as the null string in all elements. This is not strictly HTML-compatible, but people usually feel free to extend HTML with new attributes. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 5 16:30:52 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:30 2004 Subject: Namespace Comments References: Message-ID: <35C86C77.166DF0F0@locke.ccil.org> Charles Frankston wrote: > Yes, a syntax virtually identical to yours, that allowed multiple namespace > declarations in a single attribute was considered. The resulting syntactic > problems swayed the WG away from that approach. (Some of the issues -- you > now need an internal quoting mechanism, or a careful proscription on the > legal characters in a URI, in order to allow proper separation of the pairs. > It gets even messier to come up with a syntax to declare the default > prefix.) Space (0x20) is clearly proscribed in both URIs and NCNames, and could have been used. (Indeed, I am leaning toward using it in the next version of NamespaceFilter.) In addition, a chosen non-ASCII character, perhaps represented by a numeric entity reference, would have done the trick, since URIs only allow ASCII in the external representation, and Names allow only a small subset of the full Unicode repertoire. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Wed Aug 5 16:36:58 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:30 2004 Subject: Namespaces/XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 6 In-Reply-To: John Cowan's message of "Wed, 05 Aug 1998 10:13:45 -0400" References: <35C86899.BC561C4B@locke.ccil.org> Message-ID: John> John Cowan 0> In article <35C86899.BC561C4B@locke.ccil.org>, John wrote: John> Add an #IMPLIED "ns" attribute to ElementDecl and AttDef elements John> whose value is an URI. XSchema validation can then proceed with John> respect to the actual URIs, and disregarding the actual prefixes John> used in particular documents. This gives XSchemas a leg-up on John> DTDs, which are bound to specific prefixes in the name of SGML John> (and XML 1.0) compatibility. This sounds good - do we want to include a "suggested prefix" (to facilitate conversion to DTD format when possible)? Or perhaps use the fully-prefixed form in the XSchema, and ignore it for direct XSchema processing? -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From samg at fundtech.com Wed Aug 5 16:46:59 1998 From: samg at fundtech.com (Sam Gentile) Date: Mon Jun 7 17:03:30 2004 Subject: Help in picking a parser In-Reply-To: <35C86899.BC561C4B@locke.ccil.org> Message-ID: <001601bdc07f$d255a650$5100000a@ftc_samg> I am working on a E-Commerce Banking system and we have finally convinced people to use XML to transport our data from the browser front-end to the Web Server and out through our TUXEDO application servers. There is a need for XM parsers in several locations. On the browser side, we have DHTML and Microsoft's Visual J++ WFC "Code Behind DHTML" Java classes. I thought there was a WFC class to do parsing but it turns out that there is a com.ms.xml.parser in the Java SDK. So that side is taken care of. Our problem is more on the Web Server side. On the client, we are streaming the Java classes into an XML buffer to go to the Web server. The Web server will need to parse this XML and use a factory to dynamically instantiate and re-create the Java class hierarchy. Then the data will be put in TUXEDO FML format for shipment to the Tuxedo servers. On the way back, I will have to take an FML buffer and convert to an XML buffer. They say they don't want to use DTDs and validating parsers and that we may need the parser to be cross-platform. So I have been looking at Nonvalidating parsers like Lark and XP. I am new to XML. It seems like these parsers are a maze of source code. Will I be better off having my code "spawn" an existing parser instead of integrating with this source code? Can Validating parsers be used even when DTDs are not used (like Microsoft's and IBM's)? Any suggestions and thoughts would be greatly appreciated. Sam Gentile Senior Software Engineer Fundtech Corporation samg@fundtech.com ? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Wed Aug 5 16:53:00 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:03:30 2004 Subject: Namespaces and URNs In-Reply-To: <35C76F92.55B85CDE@locke.ccil.org> References: <3.0.1.16.19980804193226.3befc11c@pop3.demon.co.uk> Message-ID: <3.0.5.32.19980805095008.0088e740@postoffice.swbell.net> At 04:31 PM 8/4/98 -0400, John Cowan wrote: >> Having developed 2 DTDs (CML and VHG) I need to know how to prepare URNs >> for them. It seems clear that anyone wishing to create a DTD which can be >> used for Namespaces has to buy/borrow a domain name. (I suppose they could >> buy an FPI instead, but since I already have domain names I'd prefer to >> stick with those). Note that with TC1 to ISO 8879 (SGML) that domain names are recognized as registered owner names (equivalent to URN namespace IDs), so if you already have a domain name, you can immediately construct FPIs that are guaranteed to be universally unique. They will be yours to manage as long as you own the domain name. For example, the FTI "+//IDN drmacro.com//DOCUMENT Practical Hypermedia: An Introduction to Xlink and HyTime//EN" is a valid "registered public identifier" ("registered" because it uses a registered owner name, 'drmacro.com'). For the moment, this name should be resolved to the resource at the location Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Aug 5 16:59:15 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:30 2004 Subject: Help in picking a parser Message-ID: <3.0.32.19980805080003.00a85848@207.34.179.21> At 10:46 AM 8/5/98 -0400, Sam Gentile wrote: >Will I be better off having my code >"spawn" an existing parser instead of integrating with this source code? Can >Validating parsers be used even when DTDs are not used (like Microsoft's and >IBM's)? Well, Lark, XP, et al manifest as Java classes and in most cases you do a "new Parser" or some such constructor... is that what you mean by "spawn"? Also, have a look at sax (www.megginson.com) -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From samg at fundtech.com Wed Aug 5 17:02:49 1998 From: samg at fundtech.com (Sam Gentile) Date: Mon Jun 7 17:03:30 2004 Subject: Help in picking a parser In-Reply-To: <35C86899.BC561C4B@locke.ccil.org> Message-ID: <001701bdc081$de260630$5100000a@ftc_samg> I am working on a E-Commerce Banking system and we have finally convinced people to use XML to transport our data from the browser front-end to the Web Server and out through our TUXEDO application servers. There is a need for XM parsers in several locations. On the browser side, we have DHTML and Microsoft's Visual J++ WFC "Code Behind DHTML" Java classes. I thought there was a WFC class to do parsing but it turns out that there is a com.ms.xml.parser in the Java SDK. So that side is taken care of. Our problem is more on the Web Server side. On the client, we are streaming the Java classes into an XML buffer to go to the Web server. The Web server will need to parse this XML and use a factory to dynamically instantiated and re-create the Java class hierarchy. Then the data will be put in TUXEDO FML format for shipment to the Tuxedo servers. On the way back, I will have to take an FML buffer and convert to an XML buffer. They say they don't want to use DTDs and validating parsers and that we may need the parser to be cross-platform. So I have been looking at Nonvalidating parsers like Lark and XP. I am new to XML. It seems like these parsers are a maze of source code. Will I be better off having my code "spawn" an existing parser instead of integrating with this source code? Can Validating parsers be used even when DTDs are not used (like Microsoft's and IBM's)? Any suggestions and thoughts would be greatly appreciated. Sam Gentile Senior Software Engineer Fundtech Corporation samg@fundtech.com ? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tallen at sonic.net Wed Aug 5 17:08:20 1998 From: tallen at sonic.net (Terry Allen) Date: Mon Jun 7 17:03:30 2004 Subject: Name spaces and URNs Message-ID: <199808051510.IAA03748@bolt.sonic.net> Eliot wrote in response to a question about URNs: | Note that with TC1 to ISO 8879 (SGML) that domain names are recognized as | registered owner names (equivalent to URN namespace IDs) ... A URN name space ID is not the same as a registered owner name. The name space ID would identify the name space within with the registered owner name exists. However, DNS names are not appropriate for use in URNs because they are not guaranteed to be unique over time (as a practical matter, the period of 40 years has been mentioned). If ISO (the intellectual property owner) were to define a URN NID for its specs (call it ISO) and a subdivision for FPIs, it would have to, at minimum, state that FPIs constructed with DNS names as owner names were not included. It was a really bad idea to allow domain names in FPIs, and one can only wish the proposal had been circulated more widely before being approved. Regards, Terry Allen Electronic Commerce and Publishing Consultant tallen[at]sonic.net http://www.sonic.net/~tallen/ DocBook: http://www.ora.com/davenport/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at ACADCOMP.SIL.ORG Wed Aug 5 17:12:59 1998 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 17:03:30 2004 Subject: Namespaces and URNs Message-ID: <199808051520.KAA15916@ACADCOMP.SIL.ORG> Eliot Kimber wrote: > Note that with TC1 to ISO 8879 (SGML) that domain names are recognized as > registered owner names (equivalent to URN namespace IDs), so if you already > have a domain name, you can immediately construct FPIs that are guaranteed > to be universally unique. They will be yours to manage as long as you own > the domain name. [...] Reference: (for example) http://www.ornl.gov/sgml/wg8/document/1960.htm and see sections: K.4.6 Internet domain names in public identifiers K.3.8.1 Universal Resource Names Partial extract: ============================== K.4.6 Internet domain names in public identifiers [80] owner identifier = ISO owner identifier | registered owner identifier | unregistered owner identifier | internet domain name owner identifier [83.1] internet domain name owner identifier = "+//IDN ", minimum data where the minimum data must begin with an internet domain name. Note 25: The string "IDN domain.name" is treated as an ISO/IEC 9070 "registeredowner prefix". Any sub-domain names could be expressed as owner name components. For example, the internet domain name in "http://www.someisp.net/users/mtb" could occur in an FPI as: +//IDN someisp.net::www::users::mtb or as: +//IDN www.someisp.net/users/mtb Note 26: When constructing a public text owner identifier using an internet domain name, users may wish to consider the name's potential lifespan and that of the objects to be identified by public identifiers that use it. Semicolon, exclamation point, asterisk, number sign, commercial at sign, dollar sign, underscore, and percent sign are members of the abstract character class "special", which is usable in minimum data. [and] K.3.8.1 Universal Resource Names [198.1] urn feature = ps+, "URN", ps+, ("NO"|"YES") where URN YES means public identifiers are interpreted according to the applicable Internet Engineering Task Force RFC2141 governing Universal Resource Names. If both URN and FORMAL are YES, public identifiers are interpreted either as formal public identifiers or as URNs. ================ ------------------------------------------------------------------------- Robin Cover Email: robin@acadcomp.sil.org 6634 Sarah Drive Dallas, TX 75236 USA >>> The SGML/XML Web Page <<< Tel: +1 (972) 296-1783 (h) http://www.sil.org/sgml/sgml.html Tel: +1 (972) 708-7346 (w) FAX: +1 (972) 708-7380 ========================================================================= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 5 17:17:04 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:30 2004 Subject: XSchema question References: <199808050915.LAA01754@berlin.dvs1.tu-darmstadt.de> Message-ID: <35C8770C.BC77F4F9@locke.ccil.org> Ron Bourret wrote: > 2) The above [XLF] document is not well-formed. You need to wrap it in a container > element such as . XLF logs are external parsed entities, not documents (because the end-tag for the root element would never get written). To process them, we use stub documents like this: ]> &the-log; We assume that each log entry gets appended to the entity atomically. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Aug 5 17:21:12 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:30 2004 Subject: Namespaces and URNs References: <3.0.1.16.19980804193226.3befc11c@pop3.demon.co.uk> <35C76F92.55B85CDE@locke.ccil.org> Message-ID: <35C87A10.D8534BD8@mecomnet.de> John Cowan wrote: > > .. > The only publicly available Internet-Draft that actually proposes > an URN scheme proposes "ietf", for RFCs, minutes of IETF working > groups, and so on. > there is at least one more (now expired?) at http://search.ietf.org/internet-drafts/draft-mallery-urn-pdi-00.txt, which proposes "pdi" as the namespace identifier for "persistent document identifiers". xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 5 17:28:17 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:30 2004 Subject: External DTD Grammar References: <199808051031.LAA22145@stevenson.cogsci.ed.ac.uk> Message-ID: <35C879D9.A093058F@locke.ccil.org> Richard Tobin scripsit: > > > Replacement texts can't contain PE references (PE declarations can, > > but the references are resolved at entity declaration time), so it isn't > > even necessary to push back the replacement text onto the input stream. > > This is not true - references are expanded when the entity is declared, > but that may produce text containing new entity references [by > containing hidden %s] Quite right; my mistake. So "%foo;" is an eager PE reference, but "%foo;" within an entity value is a lazy PE reference (or more accurately, a deferred-once reference). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Aug 5 17:36:12 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:30 2004 Subject: XSchema question Message-ID: <007401bdc085$7e5efe60$2ee044c6@arcot-main> >This is pretty tricky stuff, though I'd like to see it work... Yeah. My primitive prototype simply added new elements, attributes, and changed default values. I am afraid that a more general solution will take more a few more kicks. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 5 17:51:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:31 2004 Subject: Deterministic behavior in processors References: <3.0.1.16.19980805094610.28ef0982@pop3.demon.co.uk> Message-ID: <35C87F40.D43727E0@locke.ccil.org> Peter Murray-Rust scripsit: > I have briefly re-read the spec and it's not immediately clear to me where > it says that a NVP is allowed to neglect [external parseed entities] >a and b if it's feeling lazy. Clause 5.2: "[A] non-validating processor [...] need not read any part of the document other than the document entity." In particular, it need not incorporate the content of external parsed entities, it need not read the external subset, and it need not read external parameter entities. If it doesn't read them, it must also not process certain other declarations so as not to get an inconsistent result with parsers that do read external entities. Unfortunately, SAX 1.0 lacks any way for an NVP to even report that it is failing to process references to external parsed entities; about all such a parser can do on reading &a;&b; is to report: startElement("FOO") endElement("FOO") IMHO this is a *fundamental* deficiency in SAX; there is no way for a parser even to report that it is dropping part of the document's content on the floor. Such a SAX parser wouldn't even invoke its EntityResolver, since it doesn't care about resolving entities. > (It > does say that if these are in an external subset they can be neglected, I > think.) Since the whole external subset can be ignored, *a fortiori* any external entity declarations in it may never be processed. > I *can't* use a validating parser because > it's impossible to construct a DTD for the complex information in a.xml and > b.xml (uses at least 4 namespaces). I don't want a parser which bombs on > the first 'invalidity' fatal error - i.e. doesn't have a DTD. I think this is a conceptual error on your part. A validating parser checks that the document it is parsing conforms to its DTD. A document without a DOCTYPE declaration genuinely doesn't have a DTD: a validating parser then merely checks it for well-formedness. It is never an error not to have a DTD. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From samg at fundtech.com Wed Aug 5 18:00:58 1998 From: samg at fundtech.com (Sam Gentile) Date: Mon Jun 7 17:03:31 2004 Subject: Help in picking a parser In-Reply-To: <35C87F71.9464A924@eng.sun.com> Message-ID: <000001bdc08a$2842fae0$5100000a@ftc_samg> I don't have a month. I have a day. Our team leader has resolved it - use Microsoft's Java classes to do it on both ends. -----Original Message----- From: David Brownell [mailto:db@Eng.Sun.COM] Sent: Wednesday, August 05, 1998 11:51 AM To: Sam Gentile Subject: Re: Help in picking a parser Particularly if you'll be using Java, you should look at the package Sun will be providing. It's not yet on the web, but should be there later this month. Includes validating and nonvalidating parsers ... very fast, robust, conformant. Alternatively, I usually recomment XP. It has that same set of technical advantages, though it doesn't offer any validation option and is "just a parser". - Dave Sam Gentile wrote: > > I am working on a E-Commerce Banking system and we have finally convinced > people to use XML to transport our data from the browser front-end to the > Web Server and out through our TUXEDO application servers. There is a need > for XM parsers in several locations. On the browser side, we have DHTML and > Microsoft's Visual J++ WFC "Code Behind DHTML" Java classes. I thought there > was a WFC class to do parsing but it turns out that there is a > com.ms.xml.parser in the Java SDK. So that side is taken care of. > > Our problem is more on the Web Server side. On the client, we are streaming > the Java classes into an XML buffer to go to the Web server. The Web server > will need to parse this XML and use a factory to dynamically instantiate and > re-create the Java class hierarchy. > Then the data will be put in TUXEDO FML format for shipment to the Tuxedo > servers. On the way back, I will have to take an FML buffer and convert to > an XML buffer. > They say they don't want to use DTDs and validating parsers and that we may > need the parser to be cross-platform. So I have been looking at > Nonvalidating parsers like Lark and XP. I am new to XML. It seems like these > parsers are a maze of source code. Will I be better off having my code > "spawn" an existing parser instead of integrating with this source code? Can > Validating parsers be used even when DTDs are not used (like Microsoft's and > IBM's)? > > Any suggestions and thoughts would be greatly appreciated. > > Sam Gentile > Senior Software Engineer > Fundtech Corporation > samg@fundtech.com > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 5 18:33:26 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:31 2004 Subject: References: <3.0.1.32.19980805100748.0070cc78@ifi.uio.no> Message-ID: <35C88934.14D0A31A@locke.ccil.org> Lars Marius Garshol scripsit: > I agree, and that's the same as in my proposal. Look at it again: all > Maps are processed before any Delegates. The order within the catalog > is the last sorting criterion. I have adopted this rule (Maps before Delegates) in my 0.2 draft at http://www.ccil.org/~cowan/XML/XCatalog.html . > I'm uneasy about it myself, for exactly the same reasons, but I think > that this will sometimes be needed, especially with DTDs. What if > you're parsing a document retrieved over HTTP and it uses an explicit > SYSTEM literal to refer to a DTD, also with HTTP, only the DTD URL > just gives you a 404? Or you want to use the DTD modified with > architectural forms declarations, or modified in some other way? Indeed. I now define it as an optional feature of XCatalogs: a conformant processor need not do Remaps. > This means that if you try resolving "-//W3C//DTD HTML 3.2 Final//EN" > you'll get "HTML32.dtd", and not be referred to the "htmlcatalog" > catalog file. If you try resolving any other FPI starting with > "-//W3C//DTD HTML" you'll be referred to the htmlcatalog. Quite right. However, if the "htmlcatalog" file does not help you, you do *not* get returned to the original catalog or its successors (via Catalog entries) to search further. Once delegated, always delegated. Please read my new draft and let me know what you think. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Wed Aug 5 18:36:55 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:31 2004 Subject: XSA proposal Message-ID: <3.0.1.32.19980805183307.00698bc0@ifi.uio.no> Below is attached a proposal for a specification for a system I'm putting together and will use to keep my XML tools list up to date. The system is currently using a restricted version of it and so far it has worked well, apart from the fact that rather few developers use it. Making it a more "official" specification and enabling others to use it as well will hopefully change this. ====== Start of proposal: This is a proposal for XML Software Autoupdate, a system for automatically keeping track of new releases of software products. It is mainly intended for use by maintainers of software indices. The default acronym for XML Software Autoupdate is XSA. 1. Introduction 1.1 Motivation and purpose An XSA document is an XML document that describes the current status of a software product marked up with the XSA DTD. It is intended that software vendors and authors will maintain a single XSA document for all their software, updating it every time a new version of a product is released or some other information related to the product or the vendor changes. This will allow all interested parties to poll the XSA document and discover new releases and address changes automatically. The polling model has been used since it requires less resources to set up both for software vendors and XSA clients, and since is expected that the number of interested parties for each software product will be low. Should this turn out to not be the case the XSA DTD could be used with only a minor modification in a notification model. 2. Examples 2.1 Example document Here is a sample XSA document: Lars Marius Garshol larsga@ifi.uio.no http://www.stud.ifi.uio.no/~larsga/ xmlproc 0.50 19980718 http://www.stud.ifi.uio.no/~larsga/download/python/xml/xmlproc.htm l Version 0.50 conforms even more closely to the spec, some bugs have been removed and there are now several ways to access DTD information. Notation attributes are still not implemented. 2.2 Example use A maintainer of a software index might have as part of the entry for the xmlproc parser the following information: - the URL of the XSA document for this parser - the ID of the parsers product element in that document This could then be used by software to compare the information in the XSA document with the information in the software index. If the version numbers do not match the software can notify the maintainer, allowing him or her to update the index. 3. The XSA DTD 3.1 The DTD itself This is the root element of the XSA document, and contains an element with vendor information followed by elements describing that vendors software products. The vendor element contains information about the vendor, in order that the XSA software might keep track of changes in vendor names, contact addresses and home page URLs. This element must contain the name of the software vendor or author. WS treatment: normalize. (See section 3.2 for an explanation.) This element must contain an email address to be used for correspondence regarding the software products listed in the XSA document. WS treatment: remove. This element must contain the URL to a resource where information about the software vendor or author can be found. WS treatment: remove. The product element contains information about a product, to be used by XSA software to detect new releases of a product, name changes or changes in the home page URL. The id attribute must contain an identifier for the product that must be unique within the XSA document. This id should be used by XSA clients to identify a particular product within an XSA document. This element must contain only the version identifier of the software product. If the product release does not have a version identifier the release date in ISO YYY format must be used instead. WS treatment: normalize. This element should contain the date of the last release of the software in ISO YYY format. WS treatment: remove. This element must contain the URL of a resource containing information about the software product, preferably one suitable for linking to the product. If no informational resources are available the URL must refer to a resource containing the actual software instead. WS treatment: remove. This element must contain text describing the changes in the last release of the software. WS treatment: normalize. 3.2 Whitespace treatment Element PCDATA content can be processed in one of two ways before being used by XSA software: a) remove: this means that all whitespace characters as defined by the S production of the XML 1.0 Recommendation must be removed. b) normalize: this means that all consecutive sequences of whitespace characters as defined by the S production of the XML 1.0 Recommendation must be replaced by a single space character. ( ) Whitespace before and after the text must also be removed. 4. Further issues 4.1 Implementation It is my intention to develop SDKs for working with XSA documents in Java and Python, in order to lower the entry cost for XSA users. Developments in other languages are of course also welcome. 4.2 Later extensions It is likely that the XSA specification will be extended later to allow XSA documents to be HTML or other XML DTDs than the XSA one. This will probably be accomplished via SPAN elements in HTML and architectural forms in XML. It is also possible that an XSA push model may be added as an alternative to the current polling model. 5. Open questions - have an optional element in product for contact email? Defaults to the email address in the vendor element if not present. - should XSA have a namespace? - what if WS results from character entity references? how to tell and what to do? - should the architecture use namespaces somehow? - provide some means of XSA versioning and extensibility? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 5 18:48:17 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:31 2004 Subject: Namespaces/XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 6 References: <35C86899.BC561C4B@locke.ccil.org> Message-ID: <35C88CA3.6DD435E3@locke.ccil.org> Toby Speight wrote: > This sounds good - do we want to include a "suggested prefix" (to > facilitate conversion to DTD format when possible)? Yes, well, converting XSchemas to DTDs is an Official Goal. So I guess we still need the Namespace element in XSchema. Bleah. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 5 18:54:52 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:31 2004 Subject: Namespaces and URNs References: <3.0.1.16.19980804193226.3befc11c@pop3.demon.co.uk> <3.0.5.32.19980805095008.0088e740@postoffice.swbell.net> Message-ID: <35C88E3F.DE561C26@locke.ccil.org> W. Eliot Kimber wrote: > Note that with TC1 to ISO 8879 (SGML) that domain names are recognized as > registered owner names (equivalent to URN namespace IDs), so if you already > have a domain name, you can immediately construct FPIs that are guaranteed > to be universally unique. They will be yours to manage as long as you own > the domain name. A Good Thing, but not quite enough.... > For example, the FTI Is this an error for "FPI", or is this YAA (Yet Another Acronym)? > "+//IDN drmacro.com//DOCUMENT Practical Hypermedia: An > Introduction to Xlink and HyTime//EN" is a valid "registered public > identifier" ("registered" because it uses a registered owner name, > 'drmacro.com'). For the moment, this name should be resolved to the > resource at the location So far so good. But unfortunately, an XML namespace-name has to be an URI, and there is as yet no way to map FPIs into URIs, as a consequence of there being no official URNs yet. The natural way would be "urn:fpi:+%2F%2FIDN%20drmacro.com%2F%2FDOC" etc. etc. but that isn't official, just obvious. 1/2 :-) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 5 19:13:28 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:31 2004 Subject: Deterministic behavior in processors References: <3.0.1.16.19980805094610.28ef0982@pop3.demon.co.uk> <35C87F40.D43727E0@locke.ccil.org> <35C882E2.76E4612A@eng.sun.com> Message-ID: <35C892A0.EAF28310@locke.ccil.org> David Brownell wrote: > Not quite -- it's always an "error" to not have a DTD when > you're validating. But it's not a "fatal error", and it's > allowed (in fact, typical) to continue processing. Hmm. You are right and I was wrong. A DTD-less document will provoke Element Valid, Attribute Value Type, and Notation Declared validation errors. Note that clause 1.2 says validation errors should be reported at user option, whereas clause 5.1 says validation errors must be reported, period. I note that "fatal errors" are of only three kinds: failure to be WF, an encoding declaration specifying an encoding the processor cannot handle, and disallowed entity references (no unparsed entity refs, no general entity refs in the DTD, no external entity refs in attribute values). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 5 19:19:50 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:31 2004 Subject: Namespaces and URNs References: <3.0.1.16.19980804193226.3befc11c@pop3.demon.co.uk> <3.0.5.32.19980804160357.0087d1a0@postoffice.swbell.net> Message-ID: <35C8941F.4F885DCF@locke.ccil.org> W. Eliot Kimber wrote: > They are formally defined > in ISO 8879 (the SGML standard) and in ISO 9070, which defines various > registration authorities for public IDs (of which the ISBN is one). Tell me then, if you will, oh mighty oracle :-), what the rules are for non-formal public identifiers? I think I now grasp FPIs. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dgd at cs.bu.edu Wed Aug 5 19:35:27 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:03:31 2004 Subject: Namespace Comments (and dtd encoding) In-Reply-To: <199808050955.LAA01901@berlin.dvs1.tu-darmstadt.de> Message-ID: At 9:55 AM -0000 8/5/98, Ron Bourret wrote: >> The point is - I think - that the DTD parser is completely dumb. It doesn't >> care about colons (except to recognise that they are legal). I assume - >> though I haven't tried it - that this DTD will validate the example with >> any of the current parsers. > >My first reaction was that it was dumb, too, but at some point, it's got >to get >smart. That is, it needs to resolve the prefixes in the DTD to determine >what >elements are being defined. As far as I can see, the new spec does not >define >when this occurs. The only relevant information I can find is that it >specifically omits the 'Prefix Declared' constraint from the DTD productions >([12]-[17]). > >In the worst possible case, you would have to resolve the DTD prefixes every >time there is a change in namespace declarations. Not only is this extremely >ugly, it would lead to abuse such as the following, where the second A is >in a >different namespace than the first A and both A's are declared with a single >element declaration: Well, it's not ugly, it allows re-use of prefixes without creating conflicts. This is the point of a local scoping mechanism. A prefix is essentially a variable, bound to a URI. the draft allows these variables to be rebound within limite hierachically nested scopes (just like all modern programming languages). These scopes are in one-to-one correspondence with the element structure of a document, which for documents is the most relevant hierarchy. It's true that DTDs cannot be aware of this right now, but it's also true that local scoping is most useful incases where people want to add markup to existing document intances (a key scenario for namespaces). It's also true that after such dynamic markup, DTD validation is going to fail anyway. > > > > >]> > > > > asdf > > > > >A more reasonable solution might be a namespace constraint that says that all >DTD prefixes must be declared on the root element. However, without thinking >this through too carefully, I suspect you lose a good deal of flexibility. This very was considered very carefully by the SIG and the WG, and the decision was taken that you did lose flexibility. The document you give seems legal to me, although I'm not sure about the use of #IMPLIED -- what is the status of the value of the xmlns attribute of the second foo:A, given that there's no value in the instance, and no default or fixed value? I've not the time to track this down right now, but the effect of #IMPLIED in attribute inheritance is worth checking, I think. On the other hand, the following is unexceptional: ]> asdf The result of that is the following tree: [first URI]:B [second URI]:B [second URI]:A [second URI]:B -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From istvanc at microsoft.com Wed Aug 5 19:38:54 1998 From: istvanc at microsoft.com (Istvan Cseri) Date: Mon Jun 7 17:03:31 2004 Subject: Namespace Comments (and dtd encoding) Message-ID: <5BF896CAFE8DD111812400805F1991F70249B653@red-msg-08.dns.microsoft.com> Just a short comment on parsing. Yes, XML could be simpler to parse. I think it makes a lot of sense though to fall back to existing parsing behavior - which the new XMLNS attribute is doing - rather to add more to the already 'baroque' parsing rules, right ? Istvan > -----Original Message----- > From: james anderson [SMTP:James.Anderson@mecomnet.de] > Sent: Wednesday, August 05, 1998 3:20 AM > To: Charles Frankston > Cc: xml-dev@ic.ac.uk > Subject: Re: Namespace Comments (and dtd encoding) > > Charles Frankston wrote: > > > > Mr. Anderson -- > > > > To answer the first of your many questions: > > > > Yes, a syntax virtually identical to yours, that allowed multiple > namespace > > declarations in a single attribute was considered. The resulting > syntactic > > problems swayed the WG away from that approach. (Some of the issues -- > you > > now need an internal quoting mechanism, or a careful proscription on the > > legal characters in a URI, in order to allow proper separation of the > pairs. > > It gets even messier to come up with a syntax to declare the default > > prefix.) > > xml is already sufficiently baroque, that i can only presume that this was > not > the deciding argument. :) > > > > > I couldn't understand most of the rest of your questions. > > i surmise (from the timestamp on your message) that you are actually > refering > here to my other posting re dtd encoding... > > if the questions were not understandable, then i must have misunderstood > something basic about the draft's intentions. let my try again by simply > posing the open question: > > could someone please post a "complete document" (that is including a dtd) > for > the third example in section 5 of the draft (the one with the root element > "bk:book")? > > thanks. > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 5 19:54:15 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:31 2004 Subject: Deterministic behavior in processors References: <3.0.1.16.19980805094610.28ef0982@pop3.demon.co.uk> <35C87F40.D43727E0@locke.ccil.org> <35C882E2.76E4612A@eng.sun.com> <35C892A0.EAF28310@locke.ccil.org> <35C89644.64B15346@eng.sun.com> Message-ID: <35C89C24.CF0907B3@locke.ccil.org> David Brownell wrote: > And maybe more. For example, it's very useful to see the > first validation error be "no DTD provided"!! :-) My point is that there is no such Validation Constraint. A WF document that doesn't have a DTD will always provoke at least one "VC:Element Valid" error, since a WF document has to have at least one element. But having a DTD is not *as such* a VC. It's true that there's nothing in the spec preventing parsers from reporting errors where there are no errors: presumably that is a QOI issue. > > Note that clause 1.2 says validation errors should be > > reported at user option, whereas clause 5.1 says validation > > errors must be reported, period. > > The XML editors should know about such internal inconsistencies > in the spec, and address this in the errata or a forthcoming > revision of the document. > > > I note that "fatal errors" are of only three kinds: failure to be > > WF, an encoding declaration specifying an encoding the processor > > cannot handle, and disallowed entity references (no unparsed entity > > refs, no general entity refs in the DTD, no external entity refs in > > attribute values). > > But (following on an earlier thread) if you don't handle > external entities, you're not required to report all WF > errors ... sigh. > > - Dave -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jduhamel at tibco.com Wed Aug 5 19:59:05 1998 From: jduhamel at tibco.com (Joe Duhamel) Date: Mon Jun 7 17:03:31 2004 Subject: SAX Api and comments. Message-ID: <35C89C9A.FF7CDE46@tibco.com> Hi all, Is ther a facility inside sax for picking up the comments? We are using an XML Document to model a UML System and would like to 'preserve' comments from any hand editing that may have been done. -Joe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From avirr at LanMinds.Com Wed Aug 5 20:51:25 1998 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:03:31 2004 Subject: Deterministic behavior in processors In-Reply-To: <35C89C24.CF0907B3@locke.ccil.org> References: <3.0.1.16.19980805094610.28ef0982@pop3.demon.co.uk> <35C87F40.D43727E0@locke.ccil.org> <35C882E2.76E4612A@eng.sun.com> <35C892A0.EAF28310@locke.ccil.org> <35C89644.64B15346@eng.sun.com> Message-ID: At 10:53 AM -0700 8/5/98, John Cowan wrote: >David Brownell wrote: > >> And maybe more. For example, it's very useful to see the >> first validation error be "no DTD provided"!! :-) > >My point is that there is no such Validation Constraint. >A WF document that doesn't have a DTD will always provoke >at least one "VC:Element Valid" error, since a WF document >has to have at least one element. But having a DTD >is not *as such* a VC. > >It's true that there's nothing in the spec preventing >parsers from reporting errors where there are no errors: >presumably that is a QOI issue. > A lot of compilers and linkers have warnings in addition to errors. A validating parser could just use that model, allowing it to follow the spec and still be helpful to the users. Avi ________________________________________________________________ Avi Rappoport, Web Site Search Tools Maven Search Tools Consulting Site: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 5 21:36:22 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:32 2004 Subject: XML errors and fatal errors. Message-ID: <35C8B417.5ED33856@locke.ccil.org> As I posted before, there are three classes of fatal errors mentioned in the XML recommendation: violations of well-formedness constraints (when detectable); declaration of a encoding which the processor cannot process; invalid references to entities. I find also the following 20 kinds of non-fatal errors: violations of validity constraints; unescaped & or < in character data; unescaped > in "]]>" that is not the end of a CDATA section; -- within comment; DOCTYPE declaration that is not before the first element; DTD that contains text other than markup declarations; "standalone='no'" in a non-standalone document; xml:space declared as other than type "(default|preserve)" user-defined language id not beginning with "x-"; 2-letter language id not from ISO 639; text declaration provided by reference to a parsed entity; text declaration not at the beginning of an entity; UTF-16 encoded entity doesn't begin with BOM; parsed entity not encoded in UTF-8 or UTF-16 lacks encoding declaration; encoding declaration doesn't agree with actual encoding; built-in entities declared incorrectly; system identifier contains fragment identifier (optional error); non-deterministic content model; non-supported XML version (optional error); version number is "1.0" but document conforms to another version; This list was compiled by looking at occurrences of "error" and "must". Not all "must"s appear here: "must"s that constrain the processor rather than the document are omitted, as are definitional "must"s like "If an element is empty, it must be represented either by a start-tag immediately followed by an end-tag or by an empty-element tag", where "must" really means "is". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Aug 5 22:40:49 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:32 2004 Subject: Deterministic behavior in processors Message-ID: <3.0.32.19980805133744.00a8f6b8@207.34.179.21> At 11:50 AM 8/5/98 -0400, John Cowan wrote: >I think this is a conceptual error on your part. A validating parser >checks that the document it is parsing conforms to its DTD. A >document without a DOCTYPE declaration genuinely doesn't have a DTD: >a validating parser then merely checks it for well-formedness. It is >never an error not to have a DTD. However, a validating parser would report the undeclared-ness of each element type it encountered, in the case that there was no DTD. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Aug 5 22:41:51 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:32 2004 Subject: XSA proposal Message-ID: <3.0.32.19980805133922.00a9be4c@207.34.179.21> At 06:33 PM 8/5/98 +0200, Lars Marius Garshol wrote: >This is a proposal for XML Software Autoupdate, a system for >automatically keeping track of new releases of software products. Isn't this what OSD, from MS & Marimba, is supposed to do? -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Aug 5 23:13:45 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:32 2004 Subject: SAX Api and comments. In-Reply-To: <35C89C9A.FF7CDE46@tibco.com> References: <35C89C9A.FF7CDE46@tibco.com> Message-ID: <199808052112.RAA00398@unready.megginson.com> Joe Duhamel writes: > Is ther a facility inside sax for picking up the comments? We are > using an XML Document to model a UML System and would like to > 'preserve' comments from any hand editing that may have been done. No, there is not -- XML comments are purely lexical. If you want to include comments that are significant to the document, then you might want to consider representing them as elements: Last modified 1998-07-13 ... All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Thu Aug 6 01:10:39 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:32 2004 Subject: External DTD Grammar In-Reply-To: <35C879D9.A093058F@locke.ccil.org> Message-ID: On Wed, 5 Aug 1998, John Cowan wrote: > Quite right; my mistake. So "%foo;" is an eager PE reference, but > "%foo;" within an entity value is a lazy PE reference (or > more accurately, a deferred-once reference). Hmm, this got me thinking, and I think I might understand now. Basically I have been trying to figure out that if the grammar in the spec is that for *after* PE's have been included, why does it contain PEReferences? There are two instances of PEReference in the DTD grammar, one in DocTypeDecl and the other in EntityValue. I can't see any way to create a deferred PEReference in the internal subset and the only way I can see to create one in the external subset, as sighted above, is to use a CharRef (is this right?). So if you (non-recursively) process all PEReferences at the "lexical" level, you will catch all the eager ones, but the deferred ones will still make it up past the "lexical" level. Since CharRef's are forbidden in the DTD, if you process PEREferences at the "lexical" level, the only places a (deferred) PEReference can occur above this level is (only while processing the external subset) at the two places the grammar allows, DocTypeDecl and EntityValue: "> %p1; ]> This is &e1; obvious My HXP parser currently can recursively evaluate PEReferences occuring in these two positions, so all I have to do to be able to add support for parsing the external subset as well, is to process PEReferences at the lexical level rather than just where specified by the grammar. Now as I see it, this lower level processing doesn't need to be recursive to bring everything inline with the grammar, does anyone disagree with this? I am also under the impression that I don't need to process CharRef's at this lower level either? Much Thanks! --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shamada at ssel.toshiba.co.jp Thu Aug 6 02:44:18 1998 From: shamada at ssel.toshiba.co.jp (=?iso-2022-jp?B?GyRCSU1FRBsoQiAbJEI/LTBsTzobKEI=?=) Date: Mon Jun 7 17:03:32 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) Message-ID: <003501bdc0d3$80895c00$b0247385@ceres.ssel.toshiba.co.jp> I am in front of a probrem that XMLDSO doesn't process Japanese code. Please tell me to make XMLDSO process Japanese code normally. Followings are system process I implemented. 1 HTML Page has a XMLDSO Applet and JavaScript Codes and a Form Button. 2 If the button is pushed, JavaScript calls XMLDSO method "load" via LiveConnection to make XMLDSO parse XML, provided that the target XML files of "load" is generated by perl(jperl) scriptes CGI or Java CGI. 3 JavaScript makes HTML Table, reading the parsing result by DOM-Like XMLDSO methods such as "getChild". Above programs are for Internet Explorer ver 4. Candidates of points I should care I think are followings. 1 Which japanese code of XML should I choose? ex: 2 Java VM of IE4 has some probrems about Japanese codes? How should I cope with it? Please advise me. Thank you. -- HAMADA Shin'ichiro(shamada@ssel.toshiba.co.jp) S&S Lab #4, Research & Development Center, TOSHIBA Corp. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 6 03:23:47 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:32 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) In-Reply-To: <003501bdc0d3$80895c00$b0247385@ceres.ssel.toshiba.co.jp> Message-ID: <199808060127.AA01912@murata.apsdc.ksp.fujixerox.co.jp> shamada wrote: > 1 Which japanese code of XML should I choose? > ex: I would recommend UTF-16 (little endian). Unfortunately, MSIE 4.0 does not support big endian. (None of the tools from Microsoft do?) ISO-2022-JP, EUC-JP, and SHIFT_JIS works fine. But the conversion between these encoding and Unicode is a tricky business. Different tools provide different conversion. :-< Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu Aug 6 04:51:37 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:32 2004 Subject: Namespace Comments (and dtd encoding) In-Reply-To: Message-ID: <199808060254.AA01913@murata.apsdc.ksp.fujixerox.co.jp> David G. Durand wrote: > Well, it's not ugly, it allows re-use of prefixes without creating > conflicts. This is the point of a local scoping mechanism. A prefix is > essentially a variable, bound to a URI. the draft allows these variables to > be rebound within limite hierachically nested scopes (just like all modern > programming languages). These scopes are in one-to-one correspondence with > the element structure of a document, which for documents is the most > relevant hierarchy. > > It's true that DTDs cannot be aware of this right now, but it's also true > that local scoping is most useful incases where people want to add markup > to existing document intances (a key scenario for namespaces). It's also > true that after such dynamic markup, DTD validation is going to fail > anyway. As a member of the WG, I have been involved. I have agreed on colonization, and have always believed that colonization provides a good basis for the namespace extension. Now that we have local scoping and declaration by attributes, I start to wonder. (Skip the rest of this message if you do not want to hear.) Historically, we have always assumed that it should be possible to validate an XML document with namespaces with validating parsers of XML 1.0. This is not the case, any more. Since the same prefix can be bound to different namespaces, it is no longer possible to construct an equivalent XML 1.0 DTD from a collection of namespace-schema pairs. Then, what is the point of using prefixes? In my understanding, one reason that we chose colonization rather than reserved attributes is validation by XML 1.0 parsers. This reason no longer exists. (Note: The other reason was qualification of attributes.) Declaration of namespaces are inherited. But we also want to have inheritance of prefixes in the future. That is, we would like an element to inherit prefixes from superior elements. Thus, we will have complicated interaction of two types of inheritance. For example, it will become possible for an element to inherit a prefix and not to inherit a namespace dcl. One could argue that these two should always be in sync, but then what is the point of having the two? It would have been a lot simpler if we had introduced a reserved attribute for specifying the namespace of the element. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maki at inac.co.jp Thu Aug 6 05:18:55 1998 From: maki at inac.co.jp (TAKAHASHI Masayoshi) Date: Mon Jun 7 17:03:32 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) In-Reply-To: Your message of "Thu, 06 Aug 1998 10:27:05 +0900" References: <199808060127.AA01912@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <199808060318.MAA09571@mx.inac.co.jp> Hello, MURATA Makoto wrote: > ISO-2022-JP, EUC-JP, and SHIFT_JIS works fine. But the conversion > between these encoding and Unicode is a tricky business. Different > tools provide different conversion. :-< Can we define standard (or recommended) conversion (mapping table) between Unicode(UCS-2) and such encodings used in XML? I know that "Japanese profile" in KAISETSU of TR X 0008-1998 (http://www.y-adagio.com/public/standards/xml/tutr.htm) define encodings used in japanese XML document, but it doesn't define conversions between encodings. I think it's not enough to guarantee exchange. # ...masaka "UTF-{8|16} igai no encoings ha buji ni koukan dekiru # hoshou ga nai kara jissai niha tsukatte ha ikenai" to an ni # niowaseteiru wake deha nai desuyone? :-) > japanese profile I'm sure that no conversion have no problem, but better standard reduce troubles, doesn't it? p.s. I've used sample XML documents in Japanese in SGML Cafe. Thanks!(^^)>Murata TAKAHASHI Masayoshi (maki@inac.co.jp) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu Aug 6 05:49:01 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:32 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) In-Reply-To: <199808060318.MAA09571@mx.inac.co.jp> Message-ID: <199808060352.AA01915@murata.apsdc.ksp.fujixerox.co.jp> TAKAHASHI Masayoshi wrote: > Can we define standard (or recommended) conversion (mapping table) > between Unicode(UCS-2) and such encodings used in XML? JIS X 0221, Java, and Microsoft appear to have their own. Terrible confusion will happen in the near future. This is not at all a fault of the Unicode consortium or ISO. If somebody should be criticized, Japanese should be criticized. An interesting document about this issue is available at: http://hp.vector.co.jp/authors/VA001240/article/ucsnote.html > I know that "Japanese profile" in KAISETSU of TR X 0008-1998 > (http://www.y-adagio.com/public/standards/xml/tutr.htm) > define encodings used in japanese XML document, but it doesn't > define conversions between encodings. I think it's not enough > to guarantee exchange. Quite. TAKAHASHI Masayoshi wrote: > > # ...masaka "UTF-{8|16} igai no encoings ha buji ni koukan dekiru > # hoshou ga nai kara jissai niha tsukatte ha ikenai" to an ni > # niowaseteiru wake deha nai desuyone? :-) > japanese profile So, do you plan to contribute? I can give you a SJIS XML file containing a number of problematic characters. If you convert them to UTF-16 and then back to SJIS by a number of software tools and report the result to the public, that would be a great contribution. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Thu Aug 6 06:05:43 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:32 2004 Subject: Expanded names are not enough References: <3.0.1.16.19980804163721.0887b750@pop3.demon.co.uk> Message-ID: <35C925F2.DF902A32@jclark.com> Peter Murray-Rust wrote: > B: Much of the current namespace spec is about minimisation. The prefix > acts as a minimisation device. Scoping acts as a minimisation device. The > SAX interface can expand minimised parts of a document to full > UniversalNames (however held). The actual syntax of minimisation should be > irrelevant to the application, i.e.: > which prefix was used > whether a namespace was default or not > whether a prefix was implicit through scope > > (The only reason for the application receiving the prefix would be that it > wished to be able to transform the document using the same prefix). There's another reason why an application may need to know about prefixes. It may be part of the application semantics that some part of an attribute value or of the content of an element is to be interpreted as a qualified name using the namespace declarations in effect for that element. For example in an XSL stylesheet an element representing a rule can contain an attribute value with a string such as "ns:foo" with the semantic that this rule matches an element in the source of a type which has a local name "foo" and a URI equal to the URI in effect for the prefix "ns" on the rule element in the stylesheet. This means that a parser that wishes to support this kind of application needs, in addition to exposing the expanded names of element types and attributes, to make available for every element the namespace prefix to namespace URI mapping in effect for that element. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shamada at ssel.toshiba.co.jp Thu Aug 6 07:50:31 1998 From: shamada at ssel.toshiba.co.jp (=?iso-8859-1?B?lWyTYyCQTIjqmFk=?=) Date: Mon Jun 7 17:03:32 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) Message-ID: <002b01bdc0fe$48f67720$b0247385@ceres.ssel.toshiba.co.jp> Thank you for your advice. I'm sorry that I forgot that the webpage I made use MSXML Java Parser as an applet. So I think I don't use C++ MS-XML Parser in the web page but use Java one. Have I misunderstood it? >shamada wrote: >> 1 Which japanese code of XML should I choose? >> ex: > >I would recommend UTF-16 (little endian). Unfortunately, MSIE 4.0 >does not support big endian. (None of the tools from Microsoft >do?) Do you mean that C++ MS-XML Parser enbedded in IE4 can't process support big endian but UTF-16? And can Java VM of IE4 process UTF-16? -- HAMADA Shin-ichiro xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 6 08:18:37 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:33 2004 Subject: Expanded names are not enough Message-ID: <3.0.32.19980805231748.00c8c100@207.34.179.21> At 10:41 AM 8/6/98 +0700, James Clark wrote: >For example in an XSL stylesheet an element representing a rule can >contain an attribute value with a string such as "ns:foo" with the >semantic that this rule matches an element in the source of a type which >has a local name "foo" and a URI equal to the URI in effect for the >prefix "ns" on the rule element in the stylesheet. Yes, but the person writing the stylesheet knows what namespace his rule elements are in, right? So in effect, you're still specifying a match based on the underlying URI, not the prefix? I have a feeling you wouldn't have posted that if the answers weren't "wrong, and no". So could you give a motivating example. I find it really hard to be comfortable with any scenario in which the prefix, not the associated URI, has any real effect... it seems so clearly just a placeholder. I'd go so far as to say that scenarios in which the prefixes become interesting are prima facie evidence of weakness in the namespace facility. I mean, in C, are the semantics of strlen() and strcpy() ever affected by the name of the char * variable they're applied to? -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shamada at ssel.toshiba.co.jp Thu Aug 6 08:22:29 1998 From: shamada at ssel.toshiba.co.jp (=?iso-8859-1?B?lWyTYyCQTIjqmFk=?=) Date: Mon Jun 7 17:03:33 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) Message-ID: <004c01bdc102$a8bce910$b0247385@ceres.ssel.toshiba.co.jp> I seems to fail to post this mail, so I will send it again. Thank you for your advice. I'm sorry that I forgot that the webpage I made use MSXML Java Parser as an applet. So I think I don't use C++ MS-XML Parser in the web page but use Java one. Have I misunderstood it? >shamada wrote: >> 1 Which japanese code of XML should I choose? >> ex: > >I would recommend UTF-16 (little endian). Unfortunately, MSIE 4.0 >does not support big endian. (None of the tools from Microsoft >do?) Do you mean that C++ MS-XML Parser enbedded in IE4 can't process support big endian but UTF-16? And can Java VM of IE4 process UTF-16? -- HAMADA Shin-ichiro xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Aug 6 09:34:41 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:33 2004 Subject: Expanded names are not enough References: <3.0.32.19980805231748.00c8c100@207.34.179.21> Message-ID: <35C95965.4FF7F06A@jclark.com> Tim Bray wrote: > > At 10:41 AM 8/6/98 +0700, James Clark wrote: > >For example in an XSL stylesheet an element representing a rule can > >contain an attribute value with a string such as "ns:foo" with the > >semantic that this rule matches an element in the source of a type which > >has a local name "foo" and a URI equal to the URI in effect for the > >prefix "ns" on the rule element in the stylesheet. > > Yes, but the person writing the stylesheet knows what namespace his > rule elements are in, right? Right. > So in effect, you're still specifying a > match based on the underlying URI, not the prefix? Right. The point is that if a parser just gives me the expanded names for element type names and attribute names then I can't do the match on the underlying URI because I can't get the underlying URI for the prefix in the stylesheet. If I have in attribute in the stylesheet: match="foo:bar" the application needs to be able to map "foo" to the associated URI. The parser can't do it automatically, because it has no way of knowing that the value of the match attribute is supposed to be treated as a qualified name. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Aug 6 10:09:53 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:33 2004 Subject: Expanded names are not enough Message-ID: <001801bdc110$51589800$2ee044c6@arcot-main> >Right. The point is that if a parser just gives me the expanded names >for element type names and attribute names then I can't do the match on >the underlying URI because I can't get the underlying URI for the prefix >in the stylesheet. If I have in attribute in the stylesheet: > > match="foo:bar" > >the application needs to be able to map "foo" to the associated URI. >The parser can't do it automatically, because it has no way of knowing >that the value of the match attribute is supposed to be treated as a >qualified name. Looks like namespaces might have serious problems with XSL. There are also some problems with DOM also which remains to be investigated (i.e. adding and moving nodes across namespaces). Current situation is very troubling to me. We have all taken XML namespace for granted as the obvious solution to name conflict problems. I think the question that must be answered first is: which should have the 'right-of-way'? XSL or namespace? DOM or namespace? Does 'right-of-way' depend on finalization schedules? It sure feels like a game of 'chicken'... Best, Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Thu Aug 6 10:42:36 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:33 2004 Subject: Expanded names are not enough References: <001801bdc110$51589800$2ee044c6@arcot-main> Message-ID: <35C96946.4C6FC6E@jclark.com> Don Park wrote: > Looks like namespaces might have serious problems with XSL. Why do you say that? They work just fine with XSL as far as I can see. A namespace processor is going to have functions that it calls to expand element type names and qualified attribute names. All that's needed is that the namespace processor, in addition to calling these functions to expand strings that it knows to be element type names and attribute names, make these functions available to applications so that applications can call them to expand strings that the application knows to be element type names and attribute names. I suspect there will be a similar issue with XPointers. If I say: href="http://...#descendant(17,foo:bar)" I would expect that the expanded element type names to be matched, not the prefixes. That would mean that to interpret the XPointer, an application would need the namespace prefix to namespace URI mapping in effect for the element to which href attribute is attached. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Aug 6 11:35:21 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:33 2004 Subject: Expanded names are not enough Message-ID: <001001bdc11c$2e7693d0$2ee044c6@arcot-main> Whether or not namespaces have a conflict with XSL is secondary to my main point: how will conflicts between namespaces and other standards be resolved? I ask this because, frankly, I think there are some unresolvable conflicts and unacceptable costs. Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Aug 6 12:11:22 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:33 2004 Subject: Namespace Comments (and dtd encoding) Message-ID: <199808061010.MAA05384@berlin.dvs1.tu-darmstadt.de> David Durand writes: > Well, it's not ugly, it allows re-use of prefixes without creating > conflicts. This is the point of a local scoping mechanism. A prefix is > essentially a variable, bound to a URI. the draft allows these variables to > be rebound within limite hierachically nested scopes (just like all modern > programming languages). These scopes are in one-to-one correspondence with > the element structure of a document, which for documents is the most > relevant hierarchy. I take it this means I do need to recalculate how prefixes are mapped each time there is a namespace attribute? Any chance this could be clarified in the spec? > It's true that DTDs cannot be aware of this right now, but it's also true > that local scoping is most useful incases where people want to add markup > to existing document intances (a key scenario for namespaces). It's also > true that after such dynamic markup, DTD validation is going to fail > anyway. One thing I find lacking in both versions of the namespace spec is how namespaces interact with DTDs. Granted, hard-wired applications (which are probably the majority of all applications) will not ever look at DTDs. However, there are applications that will, such as authoring tools and DTD exploration tools, which might build database schemas or Java classes based on the DTD structure. I would like some sort of namespace declaration that applies to the DTD and the data. I assume the point of allowing prefixes (most notably the default prefix) to be reused is to make it easier to join files that happen to use the same prefix. If this is the case, why isn't this privilege extended to DTDs? Or is the long-term plan that an instance schema syntax will cause this requirement to go away? > > > > > > > > > > >]> > > > > > > > > asdf > > > > > > > > > The document you give seems legal to me, although I'm not sure about the > use of #IMPLIED -- what is the status of the value of the xmlns attribute > of the second foo:A, given that there's no value in the instance, and no > default or fixed value? I believe it is legal, which was my whole point. Granted, it's a matter of aesthetics, but I don't like the idea that such abusive constructions are possible. As far as I know, the xmlns attribute is inherited -- this is certainly implied by the first example in section 5 of the namespace spec. (Murata Makoto also implies in a separate message that the prefix is not inherited. Why?) I also assume that is what you are showing in the following example, although I don't understand how it is really different from mine. The value of foo is still inherited by the second foo:A -- this should be unaffected by the presence of a default. (As an aside, the first element in the resulting tree is A, not B -- a typo. Also, B is not prefixed, so it is in the global namespace, not the second URI's namespace. The lack of a prefix places it in the default namespace. Since that has not been declared, the global namespace is used.) > On the other hand, the following is unexceptional: > > > > > > ]> > > > > asdf > > > > > The result of that is the following tree: > [first URI]:B > [second URI]:B > [second URI]:A > [second URI]:B I'm beginning to wonder if the namespace problem the highest ratio of apparent innocuousness to actual complexity in the universe... -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu Aug 6 12:27:13 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:33 2004 Subject: Namespace Comments (and dtd encoding) In-Reply-To: <199808061010.MAA05384@berlin.dvs1.tu-darmstadt.de> Message-ID: <199808061030.AA01921@murata.apsdc.ksp.fujixerox.co.jp> Ron Bourret wrote: > As far as I know, the xmlns attribute is inherited -- this is certainly implied > by the first example in section 5 of the namespace spec. (Murata Makoto also > implies in a separate message that the prefix is not inherited. Why?) Because we cannot replace with something like <:B /> <:C /> This is what I meant by inheritance of prefixes, and it does not exist in the current working draft. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Aug 6 12:36:43 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:33 2004 Subject: Namespaces/XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Message-ID: <199808061035.MAA05406@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent wrote: > > There are other fun things we could do, like adding an attribute to > > XSC:XSchema elements that identifies the namespace in which they live via the > > URN (forget the prefix), John Cowan wrote: > After mulling it for several days, I think this is the Right Thing. > Add an #IMPLIED "ns" attribute to ElementDecl and AttDef elements > whose value is an URI. XSchema validation can then proceed with > respect to the actual URIs, and disregarding the actual prefixes > used in particular documents. This gives XSchemas a leg-up on DTDs, > which are bound to specific prefixes in the name of SGML > (and XML 1.0) compatibility. Toby Speight wrote: > This sounds good - do we want to include a "suggested prefix" (to > facilitate conversion to DTD format when possible)? Or perhaps use > the fully-prefixed form in the XSchema, and ignore it for direct > XSchema processing? Just to be clear, the proposal is as follows: 1) The Namespace element goes away. 2) We add the following attributes: The ns attribute states which namespace the element/attribute being declared belongs to. Thus, when validating an instance file, the validator resolves the prefix in the instance file and checks that the element/attribute matches the definition for that element/attribute in the namespace identified by the ns attribute. The prefix attribute is used only by the XSchema-to-DTD converter; if it is missing, the converter either makes up a prefix or does not use a prefix. (Note that we cannot set the ns attribute during DTD-to-XSchema conversion because we do not know what namespace applies to which prefix; this information is specified in the instance, not the DTD. For people who agreed to be unabusive about their prefix->namespace mappings, we could define a PI for use in the DTD.) If this is the case, I am in complete agreement. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Thu Aug 6 12:41:04 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:33 2004 Subject: Namespace Comments (and dtd encoding) References: <199808061030.AA01921@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <35C984E9.6BBD1F08@jclark.com> MURATA Makoto wrote: > Because we cannot replace > > > > > > > > with something like > > > <:B /> > <:C /> > > > > This is what I meant by inheritance of prefixes, and it does not exist > in the current working draft. Given that I can replace your example with I'm having a hard time understanding why I would want the sort of prefix inheritance you are talking about. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu Aug 6 12:55:14 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:34 2004 Subject: Namespace Comments (and dtd encoding) In-Reply-To: <35C984E9.6BBD1F08@jclark.com> Message-ID: <199808061058.AA01922@murata.apsdc.ksp.fujixerox.co.jp> James Clark wrote: > I'm having a hard time understanding why I would want the sort of prefix > inheritance you are talking about. Now that we have local scoping as well as default namespaces, we no longer need prefix inheritance. You are right. I was talking about a historical proposal, which should probably be turned down forever. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Thu Aug 6 13:50:47 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:34 2004 Subject: Normalization of attribute values Message-ID: Hi folks, Can you tell me whether it is still the case that XML parsers normalize the data passed to a surrounding application? Or are there smarter parsers out there now? Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Aug 6 14:22:53 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:34 2004 Subject: Normalization of attribute values In-Reply-To: Peter Jones's message of "Thu, 6 Aug 1998 12:46:56 +0100" References: Message-ID: Peter> Peter Jones 0> In article 0> , 0> Peter wrote: Peter> Can you tell me whether it is still the case that XML parsers Peter> normalize the data passed to a surrounding application? Or are Peter> there smarter parsers out there now? What do you mean by "normalise"? Do you mean that whitespace is collapsed/removed from IDREFS, NMTOKENS, and ENTITIES values? Do you mean that character and entity references are replaced? Or something different? In the first case, it's obviously not possible unless the parser reads the DTD (if not, then all attributes are treated as CDATA). [I'm assuming that by "data" you mean attribute values, since you mention that in your Subject. "data" might be a bad choice of term in this case, as to many - particularly to those who use DSSSL -it means all the character content of an element.] -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Thu Aug 6 14:29:39 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:34 2004 Subject: No subject Message-ID: P.S. I have read the XML 1 spec concerning whitespace, but this seems to contain a logical contradiction. Viz: "An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute whitespace appearing in element content. ... xml:space...attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other must be declared if it is used... The value "default" signals that applications' default white space processing modes are acceptable for this element..." This is then opposed to the value "preserve" which preserves whitespace for the element. Which suggests that the default processing is normalization of whitespace. But according to the first line above, the default XML processing is preservation of whitespace. So what is the default mode of the processor? Preserve or not? Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Aug 6 14:52:25 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:34 2004 Subject: (no subject) In-Reply-To: Peter Jones's message of "Thu, 6 Aug 1998 13:25:39 +0100" References: Message-ID: Peter> Peter Jones 0> In article 0> , 0> Peter wrote: Peter> "An XML processor must always pass all characters in a Peter> document that are not markup through to the application. A Peter> validating XML processor must also inform the application Peter> which of these characters constitute whitespace appearing Peter> in element content. ... Peter> xml:space...attached to an element to signal an intention Peter> that in that element, white space should be preserved by Peter> applications. In valid documents, this attribute, like any Peter> other must be declared if it is used... Peter> But according to the first line above, the default XML processing Peter> is preservation of whitespace. So what is the default mode of Peter> the processor? As I see it, parsers should preserve, and applications using those parsers may use the xml:spcae atttribute to control how they treat the data received from the parsers. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Thu Aug 6 14:53:49 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:34 2004 Subject: White space Message-ID: I have read the XML 1 spec concerning whitespace, but this seems to contain a logical contradiction. Viz: "An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute whitespace appearing in element content. ... xml:space...attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other must be declared if it is used... The value "default" signals that applications' default white space processing modes are acceptable for this element..." This is then opposed to the value "preserve" which preserves whitespace for the element. Which suggests that the default processing is normalization of whitespace. But according to the first line above, the default XML processing is preservation of whitespace. So what is the default mode of the processor? Preserve or not? Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Thu Aug 6 15:04:38 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:03:34 2004 Subject: XML errors and fatal errors. In-Reply-To: John Cowan's message of Wed, 05 Aug 1998 15:35:51 -0400 Message-ID: <199808061304.OAA08247@stevenson.cogsci.ed.ac.uk> > I find also the following 20 kinds of non-fatal errors: Many of these are violations of the grammar, hence making the document not well-formed (because it doesn't match the production "document"). It is surely intended that no matching the grammar is a fatal error, though I can't actually see where it says it. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Aug 6 15:12:21 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:34 2004 Subject: Namespaces (and validation) References: <199808060254.AA01913@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <35C9AD69.4B3482AC@mecomnet.de> MURATA Makoto wrote: > ... > Historically, we have always assumed that it should be possible to > validate an XML document with namespaces with validating parsers of XML 1.0. > This is not the case, any more. Since the same prefix can be bound to > different namespaces, it is no longer possible to construct an equivalent > XML 1.0 DTD from a collection of namespace-schema pairs. please give an example. if the 19980802 spec were refined to include the requisite mechanism for binding prefixes outside of the root element along with the anscilliary scoping rules, then this should be possible. the implicit pi binding mechanism and dynamic scope rule of the earlier draft were, in any event, sufficient. that is to say, the implementation of the validation component of an xml processor did not require any changes to operate on the output of a parser which was extended to conform to the 19980327 namespace wd. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Aug 6 15:35:53 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:34 2004 Subject: Expanded names are not enough Message-ID: James Clark writes: >I suspect there will be a similar issue with XPointers. If I say: > > href="http://...#descendant(17,foo:bar)" > >I would expect that the expanded element type names to be matched, not >the prefixes. That would mean that to interpret the XPointer, an >application would need the namespace prefix to namespace URI mapping in >effect for the element to which href attribute is attached. This is actually my primary concern with the current namespace proposal: that the inheritance model used here makes it difficult to extract subsections of documents reliably. I would strongly prefer NOT to have the client need to download the entire document containing the subsection referred to by the XPointer - ideally, the server could just send the piece requested. (Bandwidth still isn't free, you know.) This model opens up an awful lot of possibilities, but I fear namespaces may snuff it out. So to make a this kind of request involving a namespace, the client will need to expand the prefix within the (foo:bar) which yields URLs like http://...#descendant(17,http://www.simonstl.com/schema/v1:bar) Maybe this will work, but it sure makes for a mess. Then the server needs to keep a namespace-expanded version of the documents it's storing if it wants to process this with any degree of speed, since parsing the whole document and expanding namespaces gets to be a chore when you're answering lots of requests simultaneously. What I'd hoped to do with a simple Java servlet now looks like an _incredible_ mess. Maybe the XPointer folks have some better ideas... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Aug 6 15:51:47 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:34 2004 Subject: Expanded names are not enough Message-ID: <3.0.32.19980806064611.00bf5140@207.34.179.21> At 02:21 PM 8/6/98 +0700, James Clark wrote: >If I have in attribute in the stylesheet: > > match="foo:bar" > >the application needs to be able to map "foo" to the associated URI. >The parser can't do it automatically Right, I get it. The idea is, for the case where qualified names are given in attribute *values* (or I imagine, element content), the prefix map (or at least a qualified-name expansion function) needs to be available to application programmers - which should not be an issue for implementors since the machinery has to be there anyhow. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Aug 6 15:51:52 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:34 2004 Subject: White space Message-ID: <3.0.32.19980806065037.00c0f100@207.34.179.21> At 01:48 PM 8/6/98 +0100, Peter Jones wrote: >The value "default" signals that applications' default white space >processing modes are acceptable for this element..." > >This is then opposed to the value "preserve" which preserves whitespace >for the element. Which suggests that the default processing is >normalization of whitespace. > >But according to the first line above, the default XML processing is >preservation of whitespace. So what is the default mode of the >processor? >Preserve or not? xml:space has no effect on the behavior of the *processor* - the processor always has to pass through all the white space. It is a signal from the document author to the *application*, and if it has any effect (not guaranteed) that would be on the behavior of the application. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Thu Aug 6 15:57:56 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:34 2004 Subject: White space Message-ID: O.k. Understood Thanks for clearing that up for me. Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 >-----Original Message----- >From: Tim Bray [SMTP:tbray@textuality.com] >Sent: Thursday, August 06, 1998 2:51 PM >To: Peter Jones; 'xml-dev@ic.ac.uk' >Subject: Re: White space > >At 01:48 PM 8/6/98 +0100, Peter Jones wrote: >>The value "default" signals that applications' default white space >>processing modes are acceptable for this element..." >> >>This is then opposed to the value "preserve" which preserves whitespace >>for the element. Which suggests that the default processing is >>normalization of whitespace. >> >>But according to the first line above, the default XML processing is >>preservation of whitespace. So what is the default mode of the >>processor? >>Preserve or not? > >xml:space has no effect on the behavior of the *processor* - the >processor always has to pass through all the white space. It is a >signal from the document author to the *application*, and if it >has any effect (not guaranteed) that would be on the behavior of >the application. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Aug 6 16:20:39 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:34 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 7 Message-ID: This reflects our latest thinking regarding namespaces and XSchema. The main changes involve the removal of the Namespace element and its replacement with attributes in the XSchema element and also (to come) in element and attribute declarations. I'm hoping this will get us past the thorny namespace issues so that I can move on to the rest of the spec, compile a complete DTD and an updated complete version of the spec so far, and start work on sections 4 and 5 on processing. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.0 XSchema Syntax This section describes the XSchema document syntax. The XSchema document is an XML document containing a single XSchema element in which information describing the schema is nested. The XSchema element must be preceded by an XML declaration and may be preceded by other declarations, comments, and processing instructions. 2.1 The XSchema Element The XSchema element is the root element for all XSchema documents. The declaration for the XSchema element is: The XSchema element contains other elements describing the XSchema and building a schema. These elements are described in later sections of this specification. The XSchema element may also contain other XSchema elements nested inside of it. This nesting of XSchema elements improves reusability of XSchemas by allowing the combination of multiple XSchemas inside of a single XSchema framework. It also allows finer-grained control over documentation for subsections of an XSchema. The XSchema element's attributes include information about the namespace used by XSchema, the version of the XSchema specification used, and information about the type of documents described by the XSchema. The XSchema namespace is fixed with the xmlns attribute to correspond to the 8/2/98 working draft of Namespaces in XML. The xmlns:XSC attribute, also fixed, allows XSchema declarations to be prefixed with XSC for situations where they need to redefine the default namespace (as is the case with XSC:Doc, and may be the case with XSC:More - see Section 2.6 for more details.) The prefix attribute identifies the prefix that will be applied to all elements and attributes defined within this XSchema element during conversion to DTDs, unless overridden in the element or attribute declaration itself. The ns attribute identifies the URI which functions as the namespace name for subelements. Namespace processing is covered further in Section 3.0, "XSchema and Namespaces". Information about the XSchema specification version used to create this XSchema, contained in the Version attribute, is critical to proper handling of documents should the specification be updated in the future. This specification is identified as version 1.0. Future major and minor versions of the XSchema specification should identify themselves differently. No provision is made at this time for nesting XSchemas using different versions of the specification under a parent XSchema element. The MimeType and FileExtension attributes are used to provide a suggested MIME (Multipurpose Internet Mail Extensions) Content-type and file extension for documents created using a particular XSchema. Applications may use this information to identify XML document types. A document library that generates XML documents dynamically could assign file extensions and MIME types based on the XSchema used. Applications using this information should use the values stored in the first XSchema encountered during processing. For instance, if an XSchema includes another nested XSchema, the values for the MimeType and FileExtension attributes of the root XSchema should be used. By default, most XML documents are assumed to have a MIME type of application/xml, as described in RFC 2376, "XML Media Types," by E.J. Whitehead and Murata Makoto. Developers who need different MIME types for documents created using particular XSchemas may register other MIME types with the IETF, as described in RFC 1590, or use the 'x-' prefix syntax for subtypes, as described in RFC 1521. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Hans-Guenter.Stein at fast.de Thu Aug 6 18:01:15 1998 From: Hans-Guenter.Stein at fast.de (Hans-Guenter Stein) Date: Mon Jun 7 17:03:34 2004 Subject: unsubscribe Message-ID: <35C9D305.E5364DB5@fast.de> unsubscribe (if that doesn't work, PLEASE anybody tell me how to get of the list...) -- Hans-G?nter Stein, FAST e.V. Arabellastr. 17 | Tel +49-89-920047-55 | mailto:hgs@fast.de D-81925 Muenchen | Fax +49-89-920047-18 | http://www.fast.de/~hgs xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Aug 6 19:01:48 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:34 2004 Subject: PEReferences in comments Message-ID: <199808061658.SAA08714@berlin.dvs1.tu-darmstadt.de> Are parameter entity references in comments in the external subset supposed to be expanded? Section 4.4 defines "Reference in DTD" as "a reference within either the internal or external subsets of the DTD, but outside of an EntityValue or AttValue". Section 4.4.8 then states that such a reference is replaced with the replacement text bracketed by single spaces. I take this to mean that, outside of EntityValue and AttValue, all parameter entity references are expanded; the spaces mandated by 4.4.8 limit the usefulness of parameter references to replacing complete tokens. It therefore seems that the following statements: are equivalent to: However, MSXML ignores such parameter references, and both IBTWSH (http://www.ccil.org/~cowan/XML/ibtwsh.dtd) and part of the XML version of DocBook (http://nwalsh.com/docbook/xml/0.7/dbpoolx.mod) use parameter references in a way clearly not intended to be expanded. There is also no mention of them in Chris Hubick's external DTD grammar. (He also doesn't include PubidLiteral, which it seems would also allow PEReferences.) Since the people who wrote these are not exactly slouches, I am hard-pressed to say they are wrong, yet I can't figure out why they wouldn't be (modulo the usual concerns about validating vs. non-validating parsers). -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 19:39:43 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:34 2004 Subject: Namespace Comments (and dtd encoding) References: <199808060254.AA01913@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <35C9EA46.202C0BD3@locke.ccil.org> MURATA Makoto wrote: > Since the same prefix can be bound to > different namespaces, it is no longer possible to construct an equivalent > XML 1.0 DTD from a collection of namespace-schema pairs. Then, what is > the point of using prefixes? In my understanding, one reason that we > chose colonization rather than reserved attributes is validation by XML 1.0 > parsers. This reason no longer exists. (Note: The other reason was > qualification of attributes.) More precisely, it's still possible to construct DTDs for validation, but the DTD has to have the prefixes hard-coded into it, and the same prefix cannot be used for two different namespaces unless there are no overlapping element names (which cannot be guaranteed). > One could argue that these two should always > be in sync, but then what is the point of having the two? It would have > been a lot simpler if we had introduced a reserved attribute for specifying > the namespace of the element. Absolutely. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 19:55:43 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:34 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) References: <199808060127.AA01912@murata.apsdc.ksp.fujixerox.co.jp> <199808060318.MAA09571@mx.inac.co.jp> Message-ID: <35C9EE05.C856459A@locke.ccil.org> TAKAHASHI Masayoshi wrote: > Can we define standard (or recommended) conversion (mapping table) > between Unicode(UCS-2) and such encodings used in XML? Mapping tables are available at ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA , and for Microsoft Windows at ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Thu Aug 6 20:17:28 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:34 2004 Subject: PEReferences in comments In-Reply-To: <199808061658.SAA08714@berlin.dvs1.tu-darmstadt.de> Message-ID: On Thu, 6 Aug 1998, Ron Bourret wrote: > Are parameter entity references in comments in the external subset > supposed to be expanded? I was thinking about just this issue when this mail showed up in my inbox :-) My initial reaction would be to say that no, they shouldn't be. A comment should be just that, a comment. Allowing PEReferences inside comments would mean that if that entity was not declared that you would get an exception. If you are working on a DTD, and comment out part of it, you would expect it not to be processed. This never occurred to me while creating the external DTD grammar (don't use that as a reference, like I said in the message, I just slapped it together in 5 min to generate feedback). I have now realized that there is no external grammar before PE expansion, and have given up wiring PEReferences into my grammar processing code, that is, you will not be able to get the breakdown of an _unprocessed_ external parsed entity. I am just sitting down to write the code to do PEReference expansion at the lexical level, and was wondering if I have to be able to shut it off, or if I can just process a _whole_ external entity, which I am pretty sure I can't. Toggling reference expansion makes this _much_ more complicated. Well, if I just escaped comments looking for '' it wouldn't be that hard, but that is the cheap way out, I want this code to be more reuseable than that. My XMLSource object acts as a buffer, and the parser moves forward and back in that buffer (array type syntax) while trying to identify what is next in the file. The thing is, "what is next" in this case may (almost everything) or may not (comments) want PEReference expansion, so I have to be able to say, get me the character at index x, with PERef's expanded or without. And I am writing this parser in my _free_ time!? For fun!? God I'm a geek! --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dgd at cs.bu.edu Thu Aug 6 20:29:14 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:03:34 2004 Subject: Namespace Comments (and dtd encoding) (+ some rambling) In-Reply-To: <199808060254.AA01913@murata.apsdc.ksp.fujixerox.co.jp> References: Message-ID: At 2:54 AM -0000 8/6/98, MURATA Makoto wrote: >David G. Durand wrote: >>defense of local scoping. > >As a member of the WG, I have been involved. I have agreed on colonization, >and have always believed that colonization provides a good basis for >the namespace extension. Now that we have local scoping and declaration by >attributes, I start to wonder. (Skip the rest of this message if you >do not want to hear.) Well, I think that a bit of this discussion in public can serve an educative function. I don't think that it is likely to get changes made, but I'm not unhappy with that. I like the current proposal, _as a way to use colonized names_, even though I think we would have done better to stick with architectural forms. So I'm an advocate of this form of the namespace proposal over the alternatives, even though I'm not a namespace advocate per se. >Historically, we have always assumed that it should be possible to >validate an XML document with namespaces with validating parsers of XML 1.0. >This is not the case, any more. Since the same prefix can be bound to >different namespaces, it is no longer possible to construct an equivalent >XML 1.0 DTD from a collection of namespace-schema pairs. It's still possible to use namespaces with DTDs and get the benefits of validation and structural control that DTDs offer, while applying a fixed number of namespace constructs. And enabling the use of DTDs is all that any colonized name proposal can offer, since the prefix is changeable without changing the intended document semantics (but breaking the DTD, and validation). If you strictly avoid the use of local scoping, you can get exactly the same effect as the earlier proposals. If you only apply local scoping in restricted ways you can get the same validation effects, but are more robust in the face of some validation-hostile operations. For instance, if more locally scoped subtrees are added to the document, no element naming need occur. In any case, many uses of namespaces have always been known to be unvalidatable -- you can't both fix a structure via a DTD, _and_ add stuff to that structure on the fly. Since people do intend to do that, I think we should create a way that it can be done safely. That means that local namespace declarations should be possible. Local prefix binding can be used to radically lower the chance that a prefix conflict will lead to elements being interpreted as part of the wrong namespace, and can also reduce the number of times that document-processing software will have to re-map prefixes to avoid a conflict (a confusing as well as DTD-trashing operation). Many namespace uses, eg. for meta-data, have to do with the addition of small clumps of tags froma common namespace. If the dublin-core meta-tags at the head of a document can declare their own prefix local to the tags themselves, the chances ar emuch lower of conflict with other prefixes and tags (perhaps LC, or Dewey Decimal, or something else). > Then, what is >the point of using prefixes? In my understanding, one reason that we >chose colonization rather than reserved attributes is validation by XML 1.0 >parsers. This reason no longer exists. (Note: The other reason was >qualification of attributes.) I think qualification of attributes is the only reason that holds water, since validation is no more badly trashed by the current namespace proposal than the other one. In each case, validation is only possible if namespaces are used in a limited and relatively rigid way. >>Declaration of namespaces are inherited. But we also want to have >inheritance of prefixes in the future. That is, we would like an >element to inherit prefixes from superior elements. Thus, we will >have complicated interaction of two types of inheritance. For example, >it will become possible for an element to inherit a prefix and not to >inherit a namespace dcl. One could argue that these two should always >be in sync, but then what is the point of having the two? It would have >been a lot simpler if we had introduced a reserved attribute for specifying >the namespace of the element. This is the very limited (monovalent?) architectural form approach I proposed many times. It might have flown except for qualified attribute names (a concept I still find pretty opaque), and because people had their hearts set on the colonized name syntax. Colonized names were the strong favorite of all namespace supporters -- given the decision to use prefixes, local scoping seems to me the best way to manage those prefixes. I share your unease with respect to validation, and I still have weak hopes the some schema mechanism will actually work properly. I personally suspect that we will have many competing schema languages defined for WF XML documents. This puts us at least in a portability league with LISP S-expressions, which is actually pretty good. Perhaps no single schema mechanism _can_ be useful for all the applications of XML, and the chaos I fear will instead be a common language (of XML instances) that fall into dialects determined by fixed schemas, or a number of economical specialized schema languages. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dgd at cs.bu.edu Thu Aug 6 20:29:33 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:03:34 2004 Subject: Namespace Comments (and dtd encoding) In-Reply-To: <199808061010.MAA05384@berlin.dvs1.tu-darmstadt.de> Message-ID: At 10:10 AM -0000 8/6/98, Ron Bourret wrote: >David Durand writes: >> >> > >> > >> > >> > >> >]> >> > >> > >> > >> > asdf >> > >> > >> > >> > >> The document you give seems legal to me, although I'm not sure about the >> use of #IMPLIED -- what is the status of the value of the xmlns attribute >> of the second foo:A, given that there's no value in the instance, and no >> default or fixed value? > >I believe it is legal, which was my whole point. Granted, it's a matter of >aesthetics, but I don't like the idea that such abusive constructions are >possible. I don't see why it's abusive, since it has a clear meaning, that can be read right out of the instance. I can't think of a reason that you'd want to do that, but it doesn't seem pernicious. Certainly re-declaring a namespace prefix inside a context where it's already declared is potentially confusing, and a good example of why using namespaces can confuse validation, but it doesn't seem worse than lots of others that exist whenever namespaces are in use. >As far as I know, the xmlns attribute is inherited -- this is certainly >implied >by the first example in section 5 of the namespace spec. (Murata Makoto also >implies in a separate message that the prefix is not inherited. Why?) I >also >assume that is what you are showing in the following example, although I >don't >understand how it is really different from mine. The value of foo is still >inherited by the second foo:A -- this should be unaffected by the presence >of a >default. Now that I think about it, your version seems just fine. Indeed only for a #IMPLIED attribute does inheritance make a lot of sense. Just chock the question up to my being dense when I posted. It probably reflects my DTD-based view of the world, where you just use default or #FIXED values to explicitly put attributes where you want them. If you care about the details of how I was being stupid, read the next paragraph. It's a null-value problem. I was asking a question here, because I didn't know the answer. Many parsers treat #IMPLIED values as a special kind of value (the "not-specified" value). I was wondering if we have clear langauge in the standard about inheritance and #IMPLIED values. >(As an aside, the first element in the resulting tree is A, not B -- a typo. >Also, B is not prefixed, so it is in the global namespace, not the second >URI's >namespace. The lack of a prefix places it in the default namespace. >Since that >has not been declared, the global namespace is used.) Completely right. Charles Frankston also noted one of these typos. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Thu Aug 6 20:37:29 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:34 2004 Subject: Namespaces and URNs Message-ID: <5030300023785261000002L012*@MHS> "So if we are serious about making namespaces work we need to start using the same strings to refer to the same namespace. I agree that that means that DTD owners/maintainers need to be involved. Since most of the common DTDs are within the remit of the W3C, they should be thinking of how to identify them in namespaces. If they want to use FPIs, fine. But they should make it clear which the FPIs *are* and use them consistently. If they want to use URLs instead - fine. But they shouldn't encourage the use of both simultaneously." Ok, so I'm searching the 300,000 acronyms in my head and FPI is not popping up :-) Did I miss class that day? What does FPI stand for? On the issue of URNs, I, like you I guess, had in my mind as I read the namespace specs that there would eventually be some sort of NSNS (Namespace Naming Server) scheme out there. It seems like the obvious way to go over the long haul, though I can see that it would be a big, big step and involve a lot of overhead. Would not a another possibility be to take another cue from the object oriented world of components? COM objects and other components have a globally unique identifier that indicates a particular version of a particular interface. Could you not come up with a scheme where each creator of a DTD or Schema generates a unique id (using a well published algorithm for which public domain tools are easily available) and publishes some canonical name of the DTD, the versions that exist, the namespace names each one defines and any gotchas, and the unique id of each DTD version. Then the parser could see, even if a DTD came in from different sources via different URIs, that in effect they were the exact same version and that subsequent instances of the DTD could be just ignored and the current content used? It would involve some statement in the DTD that must come first and which identifies the cononical name and the unique id that represents the particular version. The same could applied to Schemas and XML document instances in general as well I assume. It could also allow a parser to recognize that two or more versions of the same DTD/Schema was being used simultaneously and warn about it. Really smart systems could use this to automatically build a map of synonyms I guess, though that's kind of a scary thought in some ways. It could let particular applications insure that they were getting only particular versions of particular DTDs, etc... Unfortunately its probably a bit late to be suggesting something like this, since it will require some new verbiage in the file format. But, if there is no real likelihood of getting some registration mechanism out there (and/or such a mechanism would be too much of a burden), then some such unique identification mechanism could be a decent second choice, don't you think? Something like the MD5 hash generates 128 bit hashes. Its well known, free, etc... All you need is a simple algorithm to feed it a semi-consistent input buffer made up of the canonical name, current time in milliseconds on your system, version string of the particular version, author name, etc... and the likelihood of it generating a clash with 2^128 possibilities (many, many times the number of atoms in the universe I believe) is extraordinarily low. The likelihood of two files with a clash being used by the same document is probably not even worth thinking about. Of course you could argue that you could just do a DOMHash on both files and consider them the same if they hash the same, but that seems to be unreasonable since it would leave out any non-DOM parsers from the fun. The scheme above would let everyone play and push the overhead to 'compile' time instead of runtime. So is this a totally dumb idea, or does it make some sense? It was a basically off the cuff, unencumbered by the thought process suggestion, but it makes some sense on the face of it. ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Thu Aug 6 21:21:19 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:34 2004 Subject: Namespaces and URNs Message-ID: <5030300023786739000002L092*@MHS> I'm reposting this for Murry, who was having trouble posting today... > "So if we are serious about making namespaces work we need to start using > the same strings to refer to the same namespace. I agree that that means > that DTD owners/maintainers need to be involved. Since most of the common > DTDs are within the remit of the W3C, they should be thinking of how to > identify them in namespaces. If they want to use FPIs, fine. But they > should make it clear which the FPIs *are* and use them consistently. If > they want to use URLs instead - fine. But they shouldn't encourage the use > of both simultaneously." Most of the common DTDs are not 'within the remit of the W3C'. In fact, only two that I can discern (HTML 3.2 and HTML 4.0) are. There are hundreds of popular DTDs out there that are in use in academia, industry and government, plus those defined by other standards bodies. Many have identifying FPIs. Check Robin Cover's SGML/XML Web pages for more details. http://www.sil.org/sgml/xml.html > Ok, so I'm searching the 300,000 acronyms in my head and FPI is not popping up > :-) Did I miss class that day? What does FPI stand for? Formal Public Identifier. When I was still at Spyglass I wrote up a set of SGML/HTML/etc. documentation that included info on FPIs. The "Spyglass - Cambridge Research Center Technical Reference" is still there at http://www.cm.spyglass.com/doc/ with the 'FPI RoadTrip' at http://www.cm.spyglass.com/doc/fpi.html I no longer have any connection with Spyglass, so any out of date links, etc. please forward to them, not me. Murray [BTW, Dean, could you forward this to the XML-DEV list? Nobody at Sun can apparently post to the list due to some weirdness. Thanks.] ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 21:24:15 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:34 2004 Subject: Expanded names are not enough References: <3.0.32.19980805231748.00c8c100@207.34.179.21> <35C95965.4FF7F06A@jclark.com> Message-ID: <35CA029A.2BFC15FE@locke.ccil.org> James Clark wrote: > The point is that if a parser just gives me the expanded names > for element type names and attribute names then I can't do the match on > the underlying URI because I can't get the underlying URI for the prefix > in the stylesheet. If I have in attribute in the stylesheet: > > match="foo:bar" > > the application needs to be able to map "foo" to the associated URI. > The parser can't do it automatically, because it has no way of knowing > that the value of the match attribute is supposed to be treated as a > qualified name. The parser can export an API for converting QNames to UniversalNames, which allows you to make the match. The real problem is more serious: as long as the same prefix can map to different namespaces in different part of the document, stylesheets that depend on prefixed names don't work. If a document maps the "foo" prefix to multiple namespaces, then in CSS1, if you have a rule: foo:p {indent 1em} just which foo:p is that? It has to be both, eliminating the whole utility of the local prefix. Block-structured prefix defining (as opposed to block-structured prefix defaulting) just isn't very useful, because too many other tools assume that identical GIs imply identical semantics. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 21:28:30 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: Expanded names are not enough References: <001801bdc110$51589800$2ee044c6@arcot-main> <35C96946.4C6FC6E@jclark.com> Message-ID: <35CA03C5.661063CA@locke.ccil.org> James Clark wrote: > They work just fine with XSL as far as I can see. > A namespace processor is going to have functions that it calls to expand > element type names and qualified attribute names. All that's needed is > that the namespace processor, in addition to calling these functions to > expand strings that it knows to be element type names and attribute > names, make these functions available to applications so that > applications can call them to expand strings that the application knows > to be element type names and attribute names. Indeed. But the functions can't just globally map prefixes to URIs and back, as with the previous draft. They have to have an indication, explicit or implicit, of context as well. In the DOM world, a DOM Node; in the SAX world, it would be necessary to only call the functions between the declaring elementStart and the corresponding elementEnd. Otherwise, there would be no assurance that the relevant mapping would still be correct. > I suspect there will be a similar issue with XPointers. If I say: > > href="http://...#descendant(17,foo:bar)" > > I would expect that the expanded element type names to be matched, not > the prefixes. That would mean that to interpret the XPointer, an > application would need the namespace prefix to namespace URI mapping in > effect for the element to which href attribute is attached. So I believed too, but someone on this list pointed out that because XPointers aren't queries into unknown documents, but references into known ones, the "foo:" might be the referent's "foo:" prefix rather than the referer's. Nobody knows yet. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Aug 6 21:42:34 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:03:35 2004 Subject: Expanded names are not enough In-Reply-To: <35CA029A.2BFC15FE@locke.ccil.org> (message from John Cowan on Thu, 06 Aug 1998 15:23:06 -0400) Message-ID: <199808061940.PAA19533@ruby.ora.com> [John Cowan] > The parser can export an API for converting QNames to > UniversalNames, which allows you to make the match. The real > problem is more serious: as long as the same prefix can map to > different namespaces in different part of the document, stylesheets > that depend on prefixed names don't work. If a document maps the > "foo" prefix to multiple namespaces, then in CSS1, if you have a > rule: > > foo:p {indent 1em} > > just which foo:p is that? It has to be both, eliminating the whole > utility of the local prefix. Not true. In this context, foo:p has some universal name (URI + local name), depending on the namespace map in effect when the CSS style rules appeared or were included. This style rule applies to any element with the same universal name, whatever prefix was used to get it. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Rlankford at kti.com Thu Aug 6 21:47:36 1998 From: Rlankford at kti.com (Rob Lankford) Date: Mon Jun 7 17:03:35 2004 Subject: unsubscribe Message-ID: unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 21:55:28 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: Whitespace References: Message-ID: <35CA0A07.CD6D02A3@locke.ccil.org> Peter Jones scripsit: > P.S. I have read the XML 1 spec concerning whitespace, but this seems to > contain a logical contradiction. Viz: Let's try to sort out the confusion with a few well-chosen verbs. > "An XML processor must always pass all characters in a document that are > not markup through to the application. That means that XML processors can't ever *discard* whitespace unless it's within markup. > A validating XML processor must > also inform the application which of these characters constitute > whitespace appearing in element content. That means that validating processors, but not necessarily other processors, must *flag* whitespace that is present in elements whose content model allows only other elements, not PCDATA as well. Non-validating processors are allowed to ignore this requirement because they don't necessarily know what the content model of an element is. The wise application, therefore, will not count on the presence of this flagging unless it knows that a validating parser is in use. > xml:space...attached to an element to signal an intention that in that > element, white space should be preserved by applications. In valid > documents, this attribute, like any other must be declared if it is > used... The "xml:space='preserve'" attribute value *signals* the document author's intention to make whitespace as significant to a processing application as any other character data. This intention should be implemented by the application through checking the value of this attribute: the parser has nothing to do with it. > The value "default" signals that applications' default white space > processing modes are acceptable for this element..." The "xml:space='default'" attribute value, on the other hand, signals that processing applications should follow their own rules about ignoring, selectively ignoring, or respecting whitespace, whatever those might be. Again, the parser has nothing to do with it. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 22:05:46 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: XML errors and fatal errors. References: <199808061304.OAA08247@stevenson.cogsci.ed.ac.uk> Message-ID: <35CA0C79.A99CF336@locke.ccil.org> Richard Tobin wrote: > > > I find also the following 20 kinds of non-fatal errors: > > Many of these are violations of the grammar, hence making the document > not well-formed (because it doesn't match the production "document"). Yeah, it's ugly. The claim that a document is WF if it conforms to the production "document" appears in clause 2.1 and is repeated in clause 4.3.2, but is not as such a WFC, and clause 1.2 claims only that violations of WFCs are said to be errors. So technically a document like <35C9AD69.4B3482AC@mecomnet.de> Message-ID: <35CA0D1B.36F0FEFB@locke.ccil.org> james anderson wrote: > if the 19980802 spec were refined to include the requisite mechanism for > binding prefixes outside of the root element along with the anscilliary > scoping rules, then this should be possible. Doubtless, but it doesn't and that's that. In the DTD, prefixes are without meaning. > the implicit pi binding mechanism and dynamic scope rule of the earlier draft > were, in any event, sufficient. So they were. "Dynamic" scope? More like global scope. Et iterum censeo, local ns definition (as opposed to local ns *defaulting*, which I applaud) delenda est. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 22:12:55 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: Expanded names are not enough References: Message-ID: <35CA0DA6.40E37434@locke.ccil.org> Simon St.Laurent scripsit: > So to make a this kind of request involving a namespace, the client will need > to expand the prefix within the (foo:bar) which yields URLs like > > http://...#descendant(17,http://www.simonstl.com/schema/v1:bar) Actually you need "|" rather than "#", according to the current XLink draft, if you want the server to help you. > What I'd hoped to do with a simple Java servlet now looks like an _incredible_ > mess. Maybe the XPointer folks have some better ideas... See my earlier post: XPointers don't *have* to be ns aware, since they are referencing *known* documents, not searching unknown ones. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 22:14:28 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: Expanded names are not enough References: <3.0.32.19980806064611.00bf5140@207.34.179.21> Message-ID: <35CA0E04.3734C774@locke.ccil.org> Tim Bray wrote: > Right, I get it. The idea is, for the case where qualified names are > given in attribute *values* (or I imagine, element content), the > prefix map (or at least a qualified-name expansion function) needs to be > available to application programmers - which should not be an issue > for implementors since the machinery has to be there anyhow. -T. Except for the problem of scope: the expansion function needs to know with respect to which point in the document it is operating. (Which is not necessarily the same as the current point of parsing.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 22:38:48 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: PEReferences in comments References: <199808061658.SAA08714@berlin.dvs1.tu-darmstadt.de> Message-ID: <35CA143D.B167EE69@locke.ccil.org> Ron Bourret wrote: > Are parameter entity references in comments in the external subset supposed to > be expanded? I think the answer to this question is of no direct interest, since comments are freely discardable. However, it leads to the question: is the sequence "%foo;" in a comment, where "foo" is not a known parameter entity, an error? Clearly, I say, it is not an error, but I cannot produce any warrant for this. BTW, the Goldfarb/Prescod _XML Handbook_ claims that the string " Quotes in PEReferences have come to my attention (thanks Ron Bourret), and something like the following scares me: %p1;%p0;"> ]> This is&e1; . >From what I understand, this seems well formed!? And should process as: ]> This is a quote (") test . My first thought for expanding PEReferences at the lexical level was to just convert any quotes in the replacement text to %, but that would break the above example. How does one tell to escape the quote when substituting p0, but not when substituting p1? Ahhh! Tell me this isn't well formed? Please? XP can't hack it (unclosed token) so I have hope. --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 6 22:45:20 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: PEReferences in comments References: Message-ID: <35CA158A.565730B7@locke.ccil.org> Chris Hubick wrote: > I am just sitting down to write the code to do PEReference > expansion at the lexical level, and was wondering if I have to be able to > shut it off, or if I can just process a _whole_ external entity, which I > am pretty sure I can't. Toggling reference expansion makes this _much_ > more complicated. Well, if I just escaped comments looking for '' it wouldn't be that hard, but that is the cheap way out, I want > this code to be more reuseable than that. Oh, I don't know. It's common for preprocessors to strip comments; the traditional C preprocessor did so, and so does the GNU C compiler working in preprocessor-only mode. > My XMLSource object acts as a > buffer, and the parser moves forward and back in that buffer (array type > syntax) while trying to identify what is next in the file. Why backward and forward? Pass through everything except a % or a . > The thing is, > "what is next" in this case may (almost everything) or may not (comments) > want PEReference expansion, so I have to be able to say, get me the > character at index x, with PERef's expanded or without. > > And I am writing this parser in my _free_ time!? For fun!? God I'm a geek! Sounds like you're working too hard, too. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 22:49:12 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: Namespaces and URNs References: <5030300023785261000002L012*@MHS> Message-ID: <35CA1698.2BCF7F5F@locke.ccil.org> Dean Roddey wrote: > Ok, so I'm searching the 300,000 acronyms in my head and FPI is not popping up > :-) Did I miss class that day? What does FPI stand for? Formal Public Identifiers. A convention for defining public identifiers. > Then the parser could see, even if a DTD came in from different sources via > different URIs, that in effect they were the exact same version and that > subsequent instances of the DTD could be just ignored and the current content > used? Namespace names don't have to be dereferenceable: "http://www.ccil.org/~cowan/labor_yutz" is a perfectly good namespace name, even though there's nothing there (you'll get an error if you try to dereference it), because I assigned it and the namespace names beginning http://www.ccil.org/~cowan" belong to me. In particular, there is no reason why the referent of the namespace name should be a DTD. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Aug 6 22:52:39 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:35 2004 Subject: PEReferences in comments Message-ID: <199808062044.WAA09268@berlin.dvs1.tu-darmstadt.de> > However, it leads to the > question: is the sequence "%foo;" in a comment, where "foo" is not > a known parameter entity, an error? Clearly, I say, it is not an > error, but I cannot produce any warrant for this. David Brownell's answer was the most palatable: "PE references are to be expanded in various places including markup declarations ... but comments aren't declarations. See the paragraph before rule [28] and ignore the "markupdecl" construct, which could have been better named ("dtdcontent" or somesuch)." It also excludes expanding PEReferences in PIs and IGNORE sections. -- Ron xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Aug 6 22:52:54 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:35 2004 Subject: a request for clarifications on WD-xml-names-19980802 Message-ID: <35CA1902.685333A@mecomnet.de> greetings, i appreciate that w3c and the draft's authors have provided a forum to which one can direct questions about the latest working draft. there follow several postings which pose questions. i have endeavored to determine the answers by reading the document and by posting questions to xml-dev, but (in particular with regard to issues I through IV) have not yet arrived at answers sufficient to permit me to implement conforming support in an xml processor. there are five requests for further information. i am posting them in separate messages. I please specify the extent of the prefix binding as well as the scope. II please establish a method to bind a prefix which covers external dtd subsets. III please provide examples which describe processing in the presence of entities. IV please specify the precedence rules for attribute "specification". V please explain why namespace partitions are necessary. nb. my cross-posting to xml-dev comprises this message only. thanks, bye for now, xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 6 22:58:03 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:35 2004 Subject: Expanded names are not enough References: <199808061940.PAA19533@ruby.ora.com> Message-ID: <35CA1872.C41AE786@locke.ccil.org> Chris Maden wrote: > Not true. In this context, foo:p has some universal name (URI + local > name), depending on the namespace map in effect when the CSS style > rules appeared or were included. This style rule applies to any > element with the same universal name, whatever prefix was used to get > it. Nope, nope, nope. Consider this: This is a paragraph.

John Paul II

The CSS stylesheet will blindly style both foo:p's, even though they are semantically distinct ("paragraph" vs. "pope"), because the stylesheet is global and the ns prefixes are local. The only way out is to change the second "foo" to a different prefixes, making the whole idea of local prefix definition nugatory. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Thu Aug 6 23:06:13 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:35 2004 Subject: PEReferences in comments In-Reply-To: <35CA158A.565730B7@locke.ccil.org> Message-ID: On Thu, 6 Aug 1998, John Cowan wrote: > Oh, I don't know. It's common for preprocessors to strip comments; > the traditional C preprocessor did so, and so does the GNU C compiler > working in preprocessor-only mode. No, I wan't to keep them in. My parser's main selling/giving feature is that it gives a detailed breakdown of the file, based on the grammar productions of the XML spec, right down to the character level. I think this will be very usefull in an authoring application, and I wan't to keep the comments in. > > My XMLSource object acts as a > > buffer, and the parser moves forward and back in that buffer (array type > > syntax) while trying to identify what is next in the file. > > Why backward and forward? Pass through everything except a > % or a . The lower lexical level can do as you say, but above that is the grammar level. I have a class for each production in the spec, each one capable of taking an XMLSource object and parsing itself from the given start index, generating events, and returning it's end index. Each class throws an unmatched exception if whatever was at that point did not match that grammar production, or a ProductionViolationException if it did match (was that thing), but was not well formed. So the parser figures out what is where by asking an object to parse itself from the current point, if it was that thing, fine, if not, discard it and try the next possibility. As a result of this, it moves back and forth through the XMLSource object as each XMLObject tries to parse itself, either succeeding or failing. If it succeeds, the XMLObjects can also build themselves into a tree of the document. It's very OO, and designed to be clean and extensible rather than fast. I am basically building something that will make it easy for me to play with and learn XML and related technologies, and that will also hopefully be of use to someone out there, even if only as an educational tool. --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Aug 6 23:12:02 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:03:35 2004 Subject: Expanded names are not enough In-Reply-To: <35CA1872.C41AE786@locke.ccil.org> (message from John Cowan on Thu, 06 Aug 1998 16:56:18 -0400) Message-ID: <199808062109.RAA21507@ruby.ora.com> [John Cowan] > Chris Maden wrote: > > > Not true. In this context, foo:p has some universal name (URI + > > local name), depending on the namespace map in effect when the CSS > > style rules appeared or were included. This style rule applies to > > any element with the same universal name, whatever prefix was used > > to get it. > > Nope, nope, nope. Consider this: > > > > This is a paragraph. >

> > John Paul II >

> > The CSS stylesheet will blindly style both foo:p's, even though they > are semantically distinct ("paragraph" vs. "pope"), because the > stylesheet is global and the ns prefixes are local. "[W]ill" in what sense? In the sense that IE 5, developed before the current namespace spec does this? In the sense that you think it might. The behavior of CSS in the presence of namespaces is undefined. But I have every reason to expect that it will follow the (soon-to-be-) defined behavior of XSL, which is that the universal name is compared. So consider this: This is a paragraph. John Paul II The stylesheet will only affect the first , since it is a style for http://some.net/ns-1:p, and only matches same. It would also match This is also a paragraph. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 6 23:38:27 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:36 2004 Subject: Expanded names are not enough References: <199808062109.RAA21507@ruby.ora.com> Message-ID: <35CA2233.24069835@locke.ccil.org> Chris Maden scripsit: > "[W]ill" in what sense? In the sense that IE 5, developed before the > current namespace spec does this? In the sense that you think it > might. In the sense of clause 5.4 of CSS2: "A type selector matches the name of a document language element type". The name, not the UniversalName. > The behavior of CSS in the presence of namespaces is undefined. But I > have every reason to expect that it will follow the (soon-to-be-) > defined behavior of XSL, which is that the universal name is > compared. "Every reason" as in "reasons you can't talk about"? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Thu Aug 6 23:49:14 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:36 2004 Subject: Quotes in PEReferences In-Reply-To: Message-ID: On Thu, 6 Aug 1998, Chris Hubick wrote: > > > > %p1;%p0;"> > ]> > This is&e1; . > > My first thought for expanding PEReferences at the lexical level was to > just convert any quotes in the replacement text to %, but that would > break the above example. How does one tell to escape the quote when > substituting p0, but not when substituting p1? Ahhh! Well, I figured out a way to solve this problem in my parser, when asking the lexical level for a character, the object in the grammar/parser layer can just pass down a this pointer which will give the lexical layer access to the current production hierarchy up to the point where the character is being requested. That will let me know if I am in a Comment, EntityValue, DocTypeDecl, or whatever, and allow me to take the appropriate action. I think. :-) > 4. It shall be easy to write programs which process XML documents. Did somebody say easy? :-) Compared to what? Ok, so it isn't _that_ hard, but I don't know if I would call this easy in the trivial sense of the word. PE References definitely take this beyond quick weekend hack. --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 6 23:58:00 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:36 2004 Subject: Quotes in PEReferences References: Message-ID: <35CA26C5.9A912B5F@locke.ccil.org> Chris Hubick wrote: > > 4. It shall be easy to write programs which process XML documents. > > Did somebody say easy? :-) Compared to what? Ok, so it isn't > _that_ hard, but I don't know if I would call this easy in the trivial > sense of the word. PE References definitely take this beyond quick > weekend hack. I don't think that statement was meant to include processing the external subset, and PErefs in the document proper (viz. in the internal subset) are very limited. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Fri Aug 7 00:03:21 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:03:36 2004 Subject: Expanded names are not enough In-Reply-To: <35CA2233.24069835@locke.ccil.org> (message from John Cowan on Thu, 06 Aug 1998 17:37:55 -0400) Message-ID: <199808062201.SAA22327@ruby.ora.com> [John Cowan] > Chris Maden scripsit: > > > "[W]ill" in what sense? In the sense that IE 5, developed before > > the current namespace spec does this? In the sense that you think > > it might. [s/b "might?".] > In the sense of clause 5.4 of CSS2: "A type selector matches the > name of a document language element type". The name, not the > UniversalName. Yeah, but when that was written, the colon wasn't a legal name character. (Well, strictly, it was legal but reserved.) Trying to argue that namespaces are broken, because something that doesn't know about them doesn't work with them, is broken. > > The behavior of CSS in the presence of namespaces is undefined. > > But I have every reason to expect that it will follow the > > (soon-to-be-)defined behavior of XSL, which is that the universal > > name is compared. > > "Every reason" as in "reasons you can't talk about"? No; it's just the sensical thing to do. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Aug 7 02:15:27 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:36 2004 Subject: LISTRIVIA (was Re: unsubscribe) In-Reply-To: <35C9D305.E5364DB5@fast.de> Message-ID: <3.0.1.16.19980807004521.442f9d80@pop3.demon.co.uk> At 19:00 06/08/98 +0300, Hans-Guenter Stein wrote: >unsubscribe > >(if that doesn't work, PLEASE anybody tell me how to get of the list...) 'unsubscribe' NEVER works when posted directly to a list. If you read to the bottom of this message you will find TWO copies of the instructions. The instructions occur on every message you get from the list. [Lots of people think this is unnecessary verbosity, but Henry and I think they are essential. BTW Henry gets 600 emails/week resulting from this list. So please try to do what it says first. And only in case of dire problems mail Henry. P. > >-- > > > Hans-G?nter Stein, FAST e.V. > > Arabellastr. 17 | Tel +49-89-920047-55 | mailto:hgs@fast.de > D-81925 Muenchen | Fax +49-89-920047-18 | http://www.fast.de/~hgs > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Aug 7 02:15:30 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:36 2004 Subject: a request for clarifications on WD-xml-names-19980802 In-Reply-To: <35CA1902.685333A@mecomnet.de> Message-ID: <3.0.1.16.19980807005552.487f7c80@pop3.demon.co.uk> At 22:59 06/08/98 +0200, james anderson wrote: >greetings, > >i appreciate that w3c and the draft's authors have provided a forum to which >one can direct questions about the latest working draft. Yes - you have found the right mailto: > >there follow several postings which pose questions. i have endeavored to >determine the answers by reading the document and by posting questions to >xml-dev, but (in particular with regard to issues I through IV) have not yet >arrived at answers sufficient to permit me to implement conforming support in >an xml processor. Probably worth exercising some patience. On XML-DEV there is no one person who is mandated to answer questions so if an individual thinks they are too hard or too obvious they'll keep quiet. > >there are five requests for further information. i am posting them in separate messages. > > I please specify the extent of the prefix binding as well as the scope. > II please establish a method to bind a prefix which covers external dtd subsets. >III please provide examples which describe processing in the presence of entities. > IV please specify the precedence rules for attribute "specification". > V please explain why namespace partitions are necessary. This is asking a lot... V in particular could be one line or several thousand. Like you I appreciate examples but they take time to create. They are beginning to arrive on this list so observe carefully. Also, try posting some of your own and see if you get applauded or !applauded. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Aug 7 02:15:33 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:36 2004 Subject: Namespaces and URNs In-Reply-To: <5030300023786739000002L092*@MHS> Message-ID: <3.0.1.16.19980807010856.41cf21ea@pop3.demon.co.uk> At 15:28 06/08/98 -0400, Dean Roddey wrote: > >I'm reposting this for Murry, who was having trouble posting today... Just to clarify "Murry" = Murray Altheim; The first quote here is Peter Murray-Rust... > >> "So if we are serious about making namespaces work we need to start using... > MurrayA continues... >Most of the common DTDs are not 'within the remit of the W3C'. In fact, only P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Fri Aug 7 02:20:12 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:03:36 2004 Subject: Quotes in PEReferences In-Reply-To: Chris Hubick's message of Thu, 6 Aug 1998 13:38:11 +0000 (GMT) Message-ID: <21795.199808070018@cockburn.cogsci.ed.ac.uk> > > > > %p1;%p0;"> > ]> > This is&e1; . > > From what I understand, this seems well formed!? First of all, PE references in the internal subset are required to be whole declarations, so it's not well formed for that reason. So suppose it was instead in the external subset. It would still be wrong (invalid) because declarations must start and end in the same entity (validity constraint on production 29). This doesn't rule out something like or (more simply) I'm sure it was not intended that these be allowed - the purpose of the extra space added to the expansion of PEs was to ensure that they produce complete tokens - but I don't see where it is prohibited. My parser reports "Error: Quoted string goes past entity end" for this example, and I believe this is the right behaviour. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Aug 7 03:06:57 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:36 2004 Subject: XSchema converters Message-ID: <199808070105.DAA10452@berlin.dvs1.tu-darmstadt.de> New versions of the XSchema-to-DTD and DTD-to-XSchema converters are available: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xschema/convert.html Changes: * Alignment with the current spec. These are a bit behind in changes made in the last couple of days (notably namespaces) and bit ahead in a few others. * Entity support in DTD-to-XSchema. This is not as robust as it could be, but works on all files I tried it on. WARNING: See the web page for general entity problems. Be sure to note that declaring quot and apos might cause errors. * General cleanup and testing. * The XSchema output program now correctly escapes & and < when writing Doc elements. I will be off the list for a few weeks, so please send bugs directly to me. Have fun! -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Aug 7 03:55:08 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:36 2004 Subject: XML errors and fatal errors. Message-ID: <3.0.32.19980806184830.00c16c50@207.34.179.21> At 04:05 PM 8/6/98 -0400, John Cowan wrote: >So technically a >document like > > >though not WF, is not "in error", since neither "error" nor "must" >is anywhere applied to what is wrong with it. Well, the spec is not perfect, but it makes it pretty clear that the above, while you may wish to apply the English word "document" to it, is not, in the terms of the spec, an "XML Document", and that a conforming XML Processor would emit some serious complaints when fed this particular character sequence. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Fri Aug 7 07:38:43 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:36 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) In-Reply-To: <35C9EE05.C856459A@locke.ccil.org> Message-ID: <199808070541.AA01927@murata.apsdc.ksp.fujixerox.co.jp> John Cowan wrote: > Mapping tables are available at > ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA , > and for Microsoft Windows at > ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP936.TXT . Another WWW page for the conversion between EUC-JP and Unicode 2.0 is available at: http://indy.opengroup.or.jp/jvc/cde/ucs-conv.html More than one conversion procedures certainly exist. The more I think about this issue, the more pessimistic I become. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From numa at rp.open.cs.fujitsu.co.jp Fri Aug 7 08:41:40 1998 From: numa at rp.open.cs.fujitsu.co.jp (NUMATA Toshinori) Date: Mon Jun 7 17:03:36 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) In-Reply-To: <199808070541.AA01927@murata.apsdc.ksp.fujixerox.co.jp> References: <199808070541.AA01927@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: In the message as of Aug 7 14:41, MURATA Makoto writes: > Another WWW page for the conversion between EUC-JP and Unicode 2.0 is > available at: > > http://indy.opengroup.or.jp/jvc/cde/ucs-conv.html The web page referenced above is in Japanese. English version is available at: http://www.opengroup.or.jp/jvc/cde/ucs-conv-e.html > More than one conversion procedures certainly exist. The more I think about > this issue, the more pessimistic I become. The code set conversion rule specified in JIS X 0221 (JIS version of ISO/IEC 10646-1) is different from the one distributed by Unicode Consortium. Microsoft Windows uses yet another conversion rule (which is based on the rule previously distributed by Unicode Consortium). So we already have three different conversion rules publicly available. There will be more rules for private purposes. Sigh. -- NUMATA Toshinori Planning Dept. 1, Research and Planning Div., Software Group, FUJITSU LIMITED Phone: +81-45-476-4587 (x4169) Fax: +81-45-476-4749 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 7 10:30:38 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:36 2004 Subject: XSA proposal In-Reply-To: <3.0.32.19980805133922.00a9be4c@207.34.179.21> Message-ID: <3.0.1.32.19980807102759.00cf8480@ifi.uio.no> * Lars Marius Garshol > >This is a proposal for XML Software Autoupdate, a system for >automatically keeping track of new releases of software products. * Tim Bray > >Isn't this what OSD, from MS & Marimba, is supposed to do? Yes, in a sense. However, XSA concerns itself with discovering new versions and changed addresses, while OSD goes much further, and omits some of the most useful parts of XSA. Compare the example below from the OSD spec with the XSA sample and I think you'll see what I mean. I looked at OSD before I started this, but skipped it as it simply wasn't suitable for my purposes. Solitaire Solitaire by FooBar Corporation --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Aug 7 10:54:53 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:36 2004 Subject: Namespaces: silly question Message-ID: <3.0.1.32.19980807105216.00cf9208@ifi.uio.no> Here's a really stupid question that I haven't been able to figure out the answer to: Sral, the naive XML developer, is developing an XML application. He writes a DTD that embeds John Cowans IBTWSH DTD in a certain place to provide for documentation. The IBTWSH DTD at some point contains this declaration: and Srals DTD contains: %insert-IBTWSH-here; So far, all is well. These documents are supposed to be processed in part by software written for IBTWSH documents, so Sral adds to his DTD the following declaration: so that all IBTWSH elements will use the IBTWSH namespace by default. Then, somewhere in one of his documents, Sral writes: Huba! This is where the problems begin. (Well, they really started above, but it's easier to see here.) Srals validating parser can now do one of three things if it supports namespaces: a) complain that the IBTWSH:P element has not been declared. (Which is literally true: it was declared as P.) b) complain that the http://www.purl.org/foo:P element has not been declared. c) strip out the namespace prefix and have IBTWSH:P blithely collide with the Sral:P defined in Srals DTD. In other words: as far as I can understand either DTDs must use the full namespace names in all declarations, as in (which is truly unreadable, and also not well-formed) or there must be some means by which a DTD can declare its namespace, which will of course be difficult since one may want to mix namespaces. I can't imagine that the XML WG has failed to think of this, so if some kind soul could point out what I have failed to think of here I would be most grateful. Thanks. -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Fri Aug 7 12:05:21 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:36 2004 Subject: XML DMS and indexing ? Message-ID: <199808071003.MAA15430@chimay.loria.fr> Is someone developping a system (in Java !) for indexing (using both structure and content) large XML documents in the framework of a Document Management System for example? I saw the message of Dongwook Shin about his BUS technique, and i was wondering if it exists some other systems or techniques ? 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 * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tln at insect.sd.monash.edu.au Fri Aug 7 12:50:00 1998 From: tln at insect.sd.monash.edu.au (Thuy-Linh Nguyen) Date: Mon Jun 7 17:03:37 2004 Subject: XSchema question Message-ID: <199808071053.UAA09321@insect.sd.monash.edu.au> > >Hey! Nice idea! XSchema certainly supports this -- it's just a bunch of > XML > > > Thanks. Support is, I suppose, unintentional?;-) > Hi ! Could I bring this topic back again ? :-) I'm a novice in this X-World in that I haven't implemented anything, and I have to "run at full speed to just stay still" with all the new specs :-) (In fact I haven't read about XSchema yet ! :-) Could somebody give me the reference ?). But I'm thrilled to hear somebody have a similar idea to mine :-) Don, you are certainly not alone in this world ! Now I would like to contribute some of my 2c :-).... >> 1) You've probably already realized this, but a DTD for such a file >> would be of little or no use. Because each XSchema section can >> introduce new elements and redefine old ones, the DTD would probably >>consist of a bunch of elements with content models of ANY. This is of >> no use either for validation or determining storage structures on the >> fly. >You are right but it makes perfect sense for transitory documents >which exists only while it is moving from one place to another. >Ability to redefine default attribute values should be enough of a >benefit I think. Do you have an example of this Don ? Also I think it makes a lot of sense with regards to schema evolution. I think this theory will give a lot of inputs for the design of an evolvable system. I'm working on this and have also got some papers in the last WWW8 and SCI'98 conferences. We do have some believers ! :-) As people are now free to create their own DTDs I think we would expect to have many DTDs created even in the same domain. The XSA and OSD just posted here is one example. Why don't we reused the elements that have been defined in other DTDs ? Why don't we have OO in XSchema so we can inherit features from other DTDs ?... And the problem of old XML document with new (dynamically generated) DTD that Peter mentioned in the log file example can probably be resolved using the conformal and polymorphism rules. And the dynamic schema will come in to automate the evolution process... Just a few thoughts... TL **************************************************************************** Thuy-Linh Nguyen CSSE, PO Box 197, Monash Univerisity, Caulfield East, VIC 3145, Australia Ph: 61-3-9903-2041, Fax: 61-3-9903-1077, http://www.sd.monash.edu.au/~tln/ **************************************************************************** xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Aug 7 13:21:44 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:37 2004 Subject: LISTRIVIA (Personal Prefixes, Namespaces and Unique Personal Identifiers) In-Reply-To: <199808071053.UAA09321@insect.sd.monash.edu.au> Message-ID: <3.0.1.16.19980807121846.40dfb020@pop3.demon.co.uk> At 20:50 07/08/98 +0000, [a poster] wrote: [...] >DTDs ?... And the problem of old XML document with new (dynamically >generated) DTD that Peter mentioned in the log file example can ^^^^^ Namespace collision!!! I am not sure which Peter is being talked about! (I think it's me, but all these rocks in my head make it difficult to remember). Another poster wrote: ... [submitting this msg on behalf of Murry (sic)] It's important to identify these references as precisely as possible :-) We don't yet have unique personal identifiers. The point is that some people are new to this list and may not 'know everyone'. Also Henry and I see the XML-DEV archive as a potentially valuable historic record and it's valuable to give as many clues as possible. The more consistent this is the easier it is for people to carry out reformatting (to XML of course). Ideally every quotation should be identifiable. Thus: - when you quote, try to include information identifying participants - identify them by full name if there is any chance of confusion (e.g. Murray Altheim, Peter Murray-Rust). - to keep it friendly I often use a scheme from the MOO culture - adding the initial only, thus: MurrayA, PeterMR, DavidM. Of course when this is all XMLised we shall be &murray1;, &pmr23; etc. and we can have personalised stylesheets at different points of the cascade. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Aug 7 15:06:15 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:37 2004 Subject: Namespaces: silly question In-Reply-To: <3.0.1.32.19980807105216.00cf9208@ifi.uio.no> References: <3.0.1.32.19980807105216.00cf9208@ifi.uio.no> Message-ID: <199808071305.JAA00269@unready.megginson.com> Lars Marius Garshol writes: > Sral, the naive XML developer, is developing an XML application. He > writes a DTD that embeds John Cowans IBTWSH DTD in a certain place to > provide for documentation. [...] > I can't imagine that the XML WG has failed to think of this, so if > some kind soul could point out what I have failed to think of here I > would be most grateful. Thanks. Neither the original nor the new version of the namespaces spec was designed to deal with DTD composition. It is possible to write a DTD that deals with specific, constrained uses of namespaces (and even hides the namespace machinery in #FIXED attribute values), but it is not possible to combine DTD fragments arbitrarily. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Fri Aug 7 15:15:21 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:37 2004 Subject: Processing instructions Message-ID: Can anyone supply me with a plausible example of the use of processing instructions filling in the p.i.s for me? Thanks in advance, Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Fri Aug 7 15:26:08 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:37 2004 Subject: P.I's Message-ID: Is this the sort of thing? Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Aug 7 15:54:11 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:37 2004 Subject: Namespaces: silly question Message-ID: Lars Marius Garshol writes: > I can't imagine that the XML WG has failed to think of this, so if > some kind soul could point out what I have failed to think of here I > would be most grateful. Thanks. And David Megginson writes: >Neither the original nor the new version of the namespaces spec was >designed to deal with DTD composition. It is possible to write a DTD >that deals with specific, constrained uses of namespaces (and even >hides the namespace machinery in #FIXED attribute values), but it is >not possible to combine DTD fragments arbitrarily. This may be an area in which XSchema, which is still evolving to meet the needs of the namespace spec, has an advantage. ns information, as well as prefixes, can be coded into the XSchema, making it possible for validation against an XSchema to consider namespaces 'in the original' without having to necessarily compromise element names or curse the existence of prefixes. Sound good? Element declarations coming up next... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris.m.hinds at mail.sprint.com Fri Aug 7 15:58:05 1998 From: chris.m.hinds at mail.sprint.com (chris m hinds) Date: Mon Jun 7 17:03:37 2004 Subject: unsubscribe Message-ID: Not to slam this particular person, but do that many internet people studying XML not know how to use majordomo? What's more, do they not read the footer appended to every XML-DEV message? -----Original Message----- From: Rlankford [mailto:Rlankford@kti.com] Sent: Thursday, August 06, 1998 2:44 PM To: xml-dev Cc: Rlankford Subject: unsubscribe unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 7 17:17:48 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:37 2004 Subject: Quotes in PEReferences References: <21795.199808070018@cockburn.cogsci.ed.ac.uk> Message-ID: <35CB1A84.BF1D1C31@locke.ccil.org> Richard Tobin quoted: > > > > > > > > > > %p1;%p0;"> > > ]> > > This is&e1; . > > > > From what I understand, this seems well formed!? and replied: > So suppose it was instead in the external subset. It would still be wrong > (invalid) because declarations must start and end in the same entity > (validity constraint on production 29). Yes, it's invalid. But is it WF? I say it is WF, despite the regrettable nature of this particular WF entity. Ditto with (in the external subset): %StartEntity; Foo "Foo"> Ugh, yuck. But WF. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Fri Aug 7 17:20:06 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:37 2004 Subject: XSchema question Message-ID: <002f01bdc215$91b6a5d0$2ee044c6@arcot-main> >somebody have a similar idea to mine :-) Don, you are certainly not >alone in this world ! Now I would like to contribute some of my 2c :-).... That is impossible because the size of my ego does not leave enough room for others. >>You are right but it makes perfect sense for transitory documents >>which exists only while it is moving from one place to another. >>Ability to redefine default attribute values should be enough of a >>benefit I think. > >Do you have an example of this Don ? Yes. Turn your TV on and pick any live news program. Think of what you are looking at as a XML document created out of hundreds of multimedia resources and news reports. You can record the news program and play it back but you are not recreating the up to the minute decision making. Another example would be the XML-based MUD session. Think of a MUD game played over time as a single document that is so complex that you can only consume specific slices of it. What you read depends on positions of characters, state of objects, what each active object do, and what events occur. Capture the output of a MUD session and you got a transitory document. >Also I think it makes a lot of sense with regards to >schema evolution. I think this theory will give a lot of inputs for >the design of an evolvable system. I'm working on this and have >also got some papers in the last WWW8 and SCI'98 conferences. We >do have some believers ! :-) As people are now free to create their >own DTDs I think we would expect to have many DTDs created even in >the same domain. The XSA and OSD just posted here is one example. Why >don't we reused the elements that have been defined in other DTDs ? >Why don't we have OO in XSchema so we can inherit features from other >DTDs ?... And the problem of old XML document with new (dynamically >generated) DTD that Peter mentioned in the log file example can >probably be resolved using the conformal and polymorphism rules. And >the dynamic schema will come in to automate the evolution process... To me, DTD is synonymous with the Dodo bird. Its extinction, as well as the extinction of Dodo bird hunters (DTD writers), is inevitable. Document designers and data sculpters cometh... Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 7 17:25:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:37 2004 Subject: XML errors and fatal errors. References: <3.0.32.19980806184830.00c16c50@207.34.179.21> Message-ID: <35CB1C40.9FEDBCE4@locke.ccil.org> Tim Bray wrote: > Well, the spec is not perfect, but it makes it pretty clear that the > above, while you may wish to apply the English word "document" to it, > is not, in the terms of the spec, an "XML Document", and that a > conforming XML Processor would emit some serious complaints when fed > this particular character sequence. -T. Of course. A simple fix would be to add a sentence to clause 2.1, somewhat as follows: "It is a fatal error for a document not to match the production _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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Fri Aug 7 17:27:46 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:37 2004 Subject: LISTRIVIA (Personal Prefixes, Namespaces and Unique Personal Identifiers) In-Reply-To: <3.0.1.16.19980807121846.40dfb020@pop3.demon.co.uk> Message-ID: On Fri, 7 Aug 1998, Peter Murray-Rust wrote: > It's important to identify these references as precisely as possible :-) We > don't yet have unique personal identifiers. The point is that some people > are new to this list and may not 'know everyone'. Also Henry and I see the ^^^^^ Sorry, I couldn't help it :-) --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 7 17:38:33 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:37 2004 Subject: Namespaces: silly question References: <3.0.1.32.19980807105216.00cf9208@ifi.uio.no> Message-ID: <35CB1F54.8F13ACC1@locke.ccil.org> Lars Marius Garshol scripsit: > These documents are supposed to be processed in > part by software written for IBTWSH documents, so Sral adds to his DTD > the following declaration: > > xmlns:IBTWSH "http://www.purl.org/foo" #FIXED> > > so that all IBTWSH elements will use the IBTWSH namespace by default. The problem is all the worse in that IBTWSH doesn't have a root element, being meant solely for embedding (there are no IBTWSH *documents* as such; HTML serves that function). I know you just chose IBTWSH as a well-known example, but the problem's bigger than you thought. > Then, somewhere in one of his documents, Sral writes: > > Huba! > > This is where the problems begin. (Well, they really started above, > but it's easier to see here.) Srals validating parser can now do one > of three things if it supports namespaces: > > a) complain that the IBTWSH:P element has not been declared. (Which > is literally true: it was declared as P.) Seems to me that it *must* do this in the name of SGML backward compatibility. The developers of namespaces don't seem to give a red rubber rat's **** about DTD-based validation. > In other words: as far as I can understand either DTDs must use the > full namespace names in all declarations, as in > > > > (which is truly unreadable, and also not well-formed) or there must be > some means by which a DTD can declare its namespace, which will of > course be difficult since one may want to mix namespaces. DTDs don't *have* namespaces under the new draft. DTDs understand prefixes only, without a clue as to what the prefixes might mean. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 7 17:49:20 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:37 2004 Subject: P.I's References: Message-ID: <35CB21D7.553D9D06@locke.ccil.org> Peter Jones wrote: > > That would be better managed with an unparsed entity and this DTD: and then in the document instance: > Is this the sort of thing? A better use for PIs is to instruct programs that filter or otherwise interpret XML. For example, there is a (non-standard) PI for attaching a stylesheet to a document for rendering purposes: architectural forms processing (which is essentially a scheme for mapping idiosyncratic elements or attributes into ones defined by a standard called an "architecture) use a PI to name the architecture and give useful details about it, etc. etc. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Fri Aug 7 17:52:28 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:03:37 2004 Subject: Processing instructions In-Reply-To: Message-ID: <3.0.5.32.19980807104234.007c3570@postoffice.swbell.net> At 02:11 PM 8/7/98 +0100, Peter Jones wrote: >Can anyone supply me with a plausible example of the use of processing >instructions > PIs are intended to be used to convey processor-specific messages to processors. A typical use is to indicate transient formatting stuff to composition engines, such as page breaks:

This has a page break before it

Other typical examples are the PIs that the ADEPT*Editor product uses to maintain information it needs, such as where the cursor was when you last saved, local format overrides, and the like. These are all things that can be discarded without significant loss and that are unique to the ADEPT*Editor product, so they are appropriately managed with PIs. As a rule, PIs are, by definition, stuff that can be removed without affecting the content of the document (although it may affect its processing by a particular application). Note that PIs have also been used as a substitute for formal markup declarations (e.g., the XML declaration PI) because SGML does not provide a way to declare new markup declaration types. PIs should *not* be used for things like creating hyperlinks or use-by-reference relationships among documents, pulling in graphics, and the like, unless those relationships are transient and specific to a particular processor (for example, ADEPT*Editor might use PIs to relate a document to some ADEPT-specific configuration file). Finally, note that elements, as well as PIs, can be governed by notations simply by having an attribute of type NOTATION for the element: ]> This equation is governed by the MyMath notation This is analogous to using notations as PI targets, the difference being that the notation processor (the thing that implements the notation) gets the element as its input rather than the PI. Cheers, Eliot --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From samg at fundtech.com Fri Aug 7 17:57:29 1998 From: samg at fundtech.com (Sam Gentile) Date: Mon Jun 7 17:03:37 2004 Subject: Questions on schema and other XML issues Message-ID: <000b01bdc21b$f7ea12a0$5100000a@ftc_samg> We have a spec called "XML-Data W3C Note 05 Jan 1998", which discusses schemas. It is not clear from the document what a schema is used for or what it's purpose is. Is it for designing the XML buffer only or is it read by the parser? Is it an extension to XML? Are they even necessary in basic XML? Also, we have been hearing rumors of a "short" XML notation. Is there one? We have a need to reduce the size of our buffers. Can you do this in XML:? <1> <1>test Can they have the same name or this the namespace extension we have been hearing about? What are namespaces? Are they in the spec now? Thanks very much, Sam Gentile Senior Software Engineer Fundtech Corporation samg@fundtech.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Aug 7 18:35:59 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:38 2004 Subject: Namespaces and XML validation Message-ID: <3.0.32.19980807093540.00c36cc0@207.34.179.21> At 11:37 AM 8/7/98 -0400, John Cowan wrote: > The developers of namespaces don't seem to give >a red rubber rat's **** about DTD-based validation. Well, never having actually owned any red rubber rat genitalia (unless of course you meant ***** to stand for "eyelashes" - I have lots of red rubber rat eyelashes) I can't comment on that particular transaction. Having said that, there is no doubt that when we went from document-global PI-declared namespaces do element-scoped attribute-declared namespaces, traditional DTD validation got somewhat messier. I personally am not very happy with that trade-off, but people I respect were on the other side of that vote and there's no doubt that scoping and defaulting make namespaces quite a lot more *usable*. But on further consideration... doing traditional XML validation of namespaced documents involves an (easy) syntactic problem and a (hard) compounding problem. Let's assume we have a way to make all the names in the DTDs match the ones they should in the document (the syntax problem, see below). That leaves the hard problem of constructing the compound master DTD that validates the way all the bits fit together. I'm not optimistic (ever) about solving that one, without human intervention, in the context of 8879-style markup declarations. But people are clever, so let's see. As for the syntax problem. Let's assume we've got a compound DTD, and know, for each name in there, what namespace it comes from. Let's further assume that we've got an instance that contains prefixes, including: - some defaulted elements that are namespaced even without prefixes - some cases where two different prefixes are used in different scopes to refer to the same namespace - some cases where the same prefix is used in two different scopes to refer to different namespaces So you take one pass through the instance, observing which namespace URIs are in play. You make a unique prefix for each. You take another pass through the instance, declaring all the prefixes on the root element, and eliminating all defaults, so that everything is prefixed, and that the same prefix is used for each namespace in all cases. Then you go back and munge the DTD, inserting the same namespace prefixes on all names as appropriate. Then you validate. Hey-presto! I think all the above, while icky, is perfectly tractable. But it presupposes you have some good technology for (or even industry experience in) constructing the compound DTD in the first place, which we don't. To summarize: the new namespace proposal makes the (easy) syntax munging problem somewhat harder (but not, I argue, qualitatively). It doesn't affect the (hard) compounding problem, which is the one we really ought to be worrying about more than we are. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Aug 7 18:37:33 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:38 2004 Subject: Quotes in PEReferences Message-ID: <3.0.32.19980807092011.00bf5d80@207.34.179.21> At 11:17 AM 8/7/98 -0400, John Cowan wrote: > >%StartEntity; Foo "Foo"> > >Ugh, yuck. But WF. Nope. Check out the WF constraint "Proper Declaration/PE Nesting" on production [29] in section 2.8. Of course, the real lesson in all this is that PEs are Markup From Hell and there's gotta be a better way. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 7 18:47:21 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:38 2004 Subject: Quotes in PEReferences References: <3.0.32.19980807092011.00bf5d80@207.34.179.21> Message-ID: <35CB2F65.DA320AFF@locke.ccil.org> Tim Bray wrote: > At 11:17 AM 8/7/98 -0400, John Cowan wrote: > > > >%StartEntity; Foo "Foo"> > > > >Ugh, yuck. But WF. > > Nope. Check out the WF constraint "Proper Declaration/PE Nesting" > on production [29] in section 2.8. Like I keep saying, that's a *validity* constraint. Documents with DTDs like the above aren't valid, but they *are* WF, unless someone can show a WF constraint they violate. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Fri Aug 7 19:00:11 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:03:38 2004 Subject: XML errors and fatal errors. In-Reply-To: <35CB1C40.9FEDBCE4@locke.ccil.org> (message from John Cowan on Fri, 07 Aug 1998 11:24:48 -0400) Message-ID: <199808071658.MAA17666@ruby.ora.com> [John Cowan] > Of course. A simple fix would be to add a sentence to clause 2.1, > somewhat as follows: "It is a fatal error for a document not to > match the production _document_." 2. Documents A data object is an _XML document_ if it is well-formed, as defined in this specification. [...] 2.1 Well-Formed XML Documents A textual object is a well-formed XML document if: 1. Taken as a whole, it matches the production labeled _document_. [...] So, to my reading, if it doesn't match _document_, it isn't XML, and is outside the scope of the spec. The XML spec shouldn't dictate error-handling behavior for non-XML objects; otherwise, future browsers would be required not to process GIFs, Word documents, HTML, etc. That would be silly. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 7 19:08:15 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:38 2004 Subject: Namespaces and XML validation References: <3.0.32.19980807093540.00c36cc0@207.34.179.21> Message-ID: <35CB345C.F8EB968C@locke.ccil.org> Tim Bray scripsit: > As for the syntax problem. Let's assume we've got a compound DTD, and > know, for each name in there, what namespace it comes from. The draft, to be sure, mentions no such method. But we can suppose that this proto-DTD contains PIs, let's say the PIs from the old draft, that tell us what the namespaces are, or it could just be verbose but simple PIs that say: element A belongs to namespace foo global attribute B belongs to namespace bar attribute B of element A belongs to namespace baz > So you take one pass through the instance, observing which namespace > URIs are in play. You make a unique prefix for each. You take another > pass through the instance, declaring all the prefixes on the root > element, and eliminating all defaults, so that everything is prefixed, > and that the same prefix is used for each namespace in all cases. Then > you go back and munge the DTD, inserting the same namespace > prefixes on all names as appropriate. Then you validate. > Hey-presto! Okay. So you can validate provided you are willing not only to rewrite the DTD (which is reasonable) but to rewrite the instance too! That concedes in effect that there are instances which simply *cannot* be validated, because they use the same QNames in inconsistent ways. There may be other instances, equivalent wrt namespaces, that can be validated, but that's not the same thing. (2nd response follows wrt the semantic problem) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 7 19:14:50 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:38 2004 Subject: XML errors and fatal errors. References: <199808071658.MAA17666@ruby.ora.com> Message-ID: <35CB35EA.714A272C@locke.ccil.org> Chris Maden wrote: > So, to my reading, if it doesn't match _document_, it isn't XML, and > is outside the scope of the spec. The XML spec shouldn't dictate > error-handling behavior for non-XML objects; otherwise, future > browsers would be required not to process GIFs, Word documents, HTML, > etc. That would be silly. My point is that it's regrettable that This is a broken XML document does not require a fatal error, whereas This is a broken XML document does, as it violates a specific WFC. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From samg at fundtech.com Fri Aug 7 19:18:08 1998 From: samg at fundtech.com (Sam Gentile) Date: Mon Jun 7 17:03:38 2004 Subject: including lists in XML? Message-ID: <000e01bdc227$30d2b3f0$5100000a@ftc_samg> Problem: We need a way to represent lists of items. That is, any item which will be included in an XML buffer, where we don't know at compile time the size of the list. Proposal: 1. Include a field in the database, TMS_IPM_REPOSITORY_DETAIL, to indicate to the factory to keep reading all items of a specific type untill there are no more items of that type. Or, to indicate to the factory to keep writing all items of a specific type untill there are no more items of that type. 2. If this field is set, the Generator: adds the "declare(RWGSlist, C)" to the #include for class declares the type for C as "RWGSlist(C) m_lst" wherever the class is used 3. If this the type of the item is a list, the factory has a get and put for lists. This class uses the RWGSlist member functions next() and at() to access the items. Copy of a XML buffer which has multiple instances Henry Ford Samuel Crowther Harvey S. Firestone Henry Ford Samuel Crowther My Life and Work Harvey S. Firestone Samuel Crowther Men and Rubber xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Aug 7 19:20:24 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:38 2004 Subject: Namespaces and XML validation Message-ID: <3.0.32.19980807101751.00a05800@207.34.179.21> At 01:07 PM 8/7/98 -0400, John Cowan wrote: >Okay. So you can validate provided you are willing not only to >rewrite the DTD (which is reasonable) but to rewrite the instance >too! The re-writing is pretty mechanical... having said that, I agree that the real lesson is that the requirement for a new schema facility which is a DTD superset and also namespace-sensitive is becoming glaringly obvious. >That concedes in effect that there are instances which >simply *cannot* be validated, because they use the same QNames >in inconsistent ways. That doesn't follow; you can certainly construct a DTD to describe any conceivable well-formed instance. If what you're saying is that a single namespace contains usages of the same element or attribute that are so wildly inconsistent that a DTD won't be helpful, then that is a problem of that namespace which would exist even were it standing alone - thus is orthogonal to the issue of namespaces. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 7 19:26:57 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:38 2004 Subject: Namespaces and XML validation References: <3.0.32.19980807101751.00a05800@207.34.179.21> Message-ID: <35CB38C3.3AD83ABB@locke.ccil.org> Tim Bray wrote: > >That concedes in effect that there are instances which > >simply *cannot* be validated, because they use the same QNames > >in inconsistent ways. > > That doesn't follow; you can certainly construct a DTD to describe > any conceivable well-formed instance. In the trivial sense, yes. You can declare all your elements with content model ANY, and declare every attribute which actually appears as CDATA #IMPLIED. I believe there is a tool somewhere that actually constructs this sort of DTD, given an instance. > If what you're saying is > that a single namespace contains usages of the same element or attribute > that are so wildly inconsistent that a DTD won't be helpful, then > that is a problem of that namespace which would exist even were it > standing alone - thus is orthogonal to the issue of namespaces. -Tim No, not at all. I am saying that elements (or attributes) may share QNames but come from different namespaces and have different content models (or attribute types). That is a condition which couldn't exist under the old draft. Since DTDs know only QNames, they can't cope with such conflicts, not between colliding namespaces, but between colliding prefixes. In other words, if prefixes were always mapped 1-1 to namespaces, this problem wouldn't exist. This is quite separate from locality *as such*; locality of prefixes just means that a given prefix isn't legal outside the scope of its declaration. However, following the Algol precedents, you have allowed declarations to supersede conflicting outer declarations and to coexist with conflicting non-overlapping declarations. There is some, if not overwhelming, software engineering experience to indicate that this is a Bad Idea. In short, this draft is essentially SUBDOC all over again: the scope of a namespace declaration has fundamentally different element and attribute types from its surrounding context. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Fri Aug 7 20:12:40 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:38 2004 Subject: No subject Message-ID: <5030300023825364000002L042*@MHS> >> Then the parser could see, even if a DTD came in from different sources via >> different URIs, that in effect they were the exact same version and that >> subsequent instances of the DTD could be just ignored and the current content >> used? >Namespace names don't have to be dereferenceable: >"http://www.ccil.org/~cowan/labor_yutz" is a perfectly good namespace name, >even though there's nothing there (you'll get an error if you >try to dereference it), because I assigned it and the namespace >names beginning http://www.ccil.org/~cowan" belong to me. > Hmmm. Oh well, I guess the idea is still valid though in terms of DTDs and Schemas in general. As they proliferate and go through versions, the ability to assign some form of universal ID in such as way that applications can get that information from the parser would be a very useful way of dealing with some of the potential confusion that could arise. It would be pretty simple, avoid any need for centralization, etc... It would be particularly easy to apply it to Schemas and XML files, because it would only require the agreeing on of a particular element type of attribute type or extra blah="duh" statement in the line perhaps. Since DTDs don't have anything like that (do they?), I'm not sure how it would applied to them, though they are the files that would best benefit from such a thing. >In particular, there is no reason why the referent of the namespace >name should be a DTD. Ok, so I'm confused. Maybe its just a V vs. NV thing or something. If I define a namespace, don't I also define a set of tags that are valid within that namespace? I always assumed that the URL that the namespace mapped to would be more than just a human readable unique identifier of some sort, and that it would define the tags that legally belong to that namespace. I could see how this would not be required for a NV scheme I guess, since it doesn't matter. But for validation purposes, not being able to know that "Burping" was not a valid tag within the "PoliteSociety" namespace seems like its missing out on something important for many applications. I can appreciate that just the partitioning of the global namespace has merit in and of itself, but if you look at the use of namespaces in programming languages (where I come from), its also important for them to have defined content that can be validated against uses of them. So am I missing something here? Do you mean its just not required, or that its not been thought of at all? ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hankr at dnai.com Fri Aug 7 20:35:07 1998 From: hankr at dnai.com (Hank Ratzesberger) Date: Mon Jun 7 17:03:38 2004 Subject: XML-RPC Message-ID: <35CB473E.4131B376@dnai.com> Is anyone working with XML-RPC? I am interested in what the DTD would look like for both a SSI RPC invocation and for one invoked at the client side in a browser. Is it clear what namespace/provider requests would go to? Is there an idea on who would be responsible for the call and results in a browser environment (should the server make the call, the client? should the client post the request and expect a response? Thanks to all interested parties, Hank -- -------------------- Hank Ratzesberger hankr@dnai.com -------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 7 20:38:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:38 2004 Subject: namespaces vs. schemas References: <5030300023825364000002L042*@MHS> Message-ID: <35CB495E.E8501BE3@locke.ccil.org> Dean Roddey wrote: > Hmmm. Oh well, I guess the idea is still valid though in terms of DTDs and > Schemas in general. As they proliferate and go through versions, the ability to > assign some form of universal ID in such as way that applications can get that > information from the parser would be a very useful way of dealing with some of > the potential confusion that could arise. It would be pretty simple, avoid any > need for centralization, etc... You could insert a PI like at the top of the DTD. > It would be particularly easy to apply it to Schemas and XML files, because it > would only require the agreeing on of a particular element type of attribute > type or extra blah="duh" statement in the line perhaps. Since DTDs > don't have anything like that (do they?), I'm not sure how it would applied to > them, though they are the files that would best benefit from such a thing. DTD files (entities containing external subsets, that is) can begin with " Ok, so I'm confused. Maybe its just a V vs. NV thing or something. If I define > a namespace, don't I also define a set of tags that are valid within that > namespace? Yes, but no particular way of doing this is prescribed: it can be DTD, XML-Data, XSchema, prose in English or Japanese, or what you will. Furthermore, the namespace name URI doesn't necessarily point to this description. In the previous ns draft, the namespace PI could have "src" pseudo-attributes, potentially more than one, which defined actual schemas. This facility has been removed from the current draft. > I always assumed that the URL that the namespace mapped to would be > more than just a human readable unique identifier of some sort, and that it > would define the tags that legally belong to that namespace. It ain't necessarily so.... > So am I missing something here? Do you mean its just not required, or that its > not been thought of at all? It has been thought of, but is apparently considered too large a problem to handle as yet. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 7 20:44:34 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:38 2004 Subject: Namespaces: silly question Message-ID: <35CB4AEB.D06B09BD@locke.ccil.org> Posted for Murray Altheim, who is having trouble posting to XML-Dev. My comments appear in double square brackets. John Cowan writes: [...] > The problem is all the worse in that IBTWSH doesn't have a root > element, being meant solely for embedding (there are no IBTWSH > *documents* as such; HTML serves that function). I know you just > chose IBTWSH as a well-known example, but the problem's bigger > than you thought. I'm not sure what you mean. There is no way to declare a root element in a DTD. Paraphrasing Eliot Kimber, a DTD is nothing more than a collection of markup declarations. Nothing in a DTD actually describes a document, merely structures that might make up a document. The root element can be almost any element (RefEntry rather than Book in DocBook, forinstance). [[My reply: Right. However, IBTWSH is *designed* to be used in this way, embedded in other documents with larger DTDs.]] [...] > Seems to me that it *must* do this in the name of SGML backward > compatibility. The developers of namespaces don't seem to give > a red rubber rat's **** about DTD-based validation. I don't think that's entirely true, given the long, heated arguments over the issue. It seems merely that those that wanted namespaces regardless of DTDs won out over those that thought full compatibility with XML 1.0 (including PIs and DTDs) was more important. I find that unfortunate, but I guess we'll all have to live with it now or find somewhere else to look for standardization. In all of my testing, I have found namespaces and DTDs to be inherently incompatible in all but the most constrained (and manually modified) instances. The whole point of namespaces was to allow combination of existing namespaces. If one has to modify all the element and attribute names in a DTD, the justification for namespaces evaporates: one might as well change HTML's 'pre' to 'HTML_pre' than bother to use 'HTML:pre'. [[My reply: Still worse if one must modify the instance itself, removing all non-unique prefixes, in order to achieve validation at all!]] And the idea of manually modifying the 7,623 lines of DocBook (much less TEI) is perfectly ludicrous. In all but trivial cases this must be a machine process, but given that element type names and attribute names show up undifferentiated in PEs, I don't know that this is possible. [[My reply: Remove PEs first by a preprocessor, I guess.]] Also, the namespace declaration must occur before the markup declaration it is to be applied to is parsed, but unfortunately the current draft's namespace 'declaration' doesn't occur until after the prolog, when the namespace boundaries of the various markup declarations have already been lost. IOW, if we assume a mix of several unqualified DTDs as separate entities, we must declare the prefix to be applied to each entity before they are mixed together. Murray ........................................................................... Murray Altheim, SGML Grease Monkey Member of Technical Staff, Tools Development & Support Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 "Give a monkey the tools and he'll build a typewriter." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Fri Aug 7 21:13:09 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:03:38 2004 Subject: Namespaces: silly question In-Reply-To: <35CB4AEB.D06B09BD@locke.ccil.org> Message-ID: <3.0.5.32.19980807140921.00875a10@postoffice.swbell.net> At 02:43 PM 8/7/98 -0400, John Cowan wrote: >I'm not sure what you mean. There is no way to declare a root element >in a DTD. Paraphrasing Eliot Kimber, a DTD is nothing more than a >collection of markup declarations. Nothing in a DTD actually describes >a document, merely structures that might make up a document. The root >element can be almost any element (RefEntry rather than Book in DocBook, >forinstance). Any element can be a document element. Consider: ]> This thread I think points up what I've been saying since the beginning of the name space discussion: the name space proposal doesn't solve any problems that weren't either already solvable by existing means (e.g., SGML architectures) or that can't be solved in a general way (blind syntactic combination of declaration sets or document fragments). All namespaces do is provide the illusion that you have some control over the problem space. But the fact that you must rewrite both declarations and instances in order to have something validatible suggests that there is no more control than there was before. There are two basic cases at work: 1. A single document that uses element types from different sources 2. The combination of otherwise independent fragments into a single syntactic instance (e.g., use-by-reference of one document by another). In the first case, if you use architectures to declare the mappings from element instances to governing vocabularies, then no rewriting is necessary in order to validate either the instance against its private DTD or against any one of the governing vocabularies because there is no *syntactic* interaction between the different name spaces except at the level of the name of the attributes used to map elements to architectural names, something that is trivially easy to disambiguate at the time a declaration set is defined. In the second case, if you use independent documents to manage the data and then want to combine them, the rewriting you have to do when using architectures is essentially the same that you must do if using name spaces: - Generate unique element type or attribute names and transform input instances to these new names (disambiguates name clashes). The new names can either be arbitrarily generated (they have no semantic significance in any case) or taken from one of the governing architectures (there could be more than one architecture governing a single element). - Generate new architectural mapping attribute names (equivalent to namespace prefixes in function) where two documents use the same attribute name for different architectures (unlikely but possible) and use these new names to describe the mapping. - Generate new declarations reflecting the new names (pointless but possible--since you are combining things blindly, there's no benefit in building local declarations that allow the resulting instance to validate, especially as the document can still be validated against the architectural DTDs as in case (1). The only value to local declarations would be for attribute default specification, but that doesn't require any content model munging and so is very simple to do). The result will be single document with no name clashes and the mapping of element instances to architectural element types preserved. The result can still be validated against any of the governing architectures. Note that if you want to craft the union of two previously uncombined architectures (DTDs) then you do so by creating a new architecture that reflects the crafted result. While the combination can be started by a machine, it requires human intelligence in the general case to finish the combination because either arbitrary or aesthetic choices need to be made. The definition of document structures is a creative act and therefore cannot be completely computerized. Architectures also have the advantage that, unlike name spaces, they provide *both* a definition of vocabulary and a definition of semantics (although how the semantics might be defined is up to the creator of the architecture). Because architectures use normal DTD syntax for defining their vocabulary and minimal validation rules, they are grounding in an existing and stable standardized syntax (SGML/XML DTDs) and do not require the invention of any additional syntax or processing machinery to enable validation of documents against vocabulary and structure/syntax rules. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From saiyar at unidial.com Fri Aug 7 22:22:18 1998 From: saiyar at unidial.com (Shyam Aiyar) Date: Mon Jun 7 17:03:38 2004 Subject: unsubscribe Message-ID: <35CB5EC7.EB3B306D@unidial.com> unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Aug 7 22:39:05 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:38 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 6 Message-ID: Below is the latest version of the Element Declarations section of the XSchema draft. There are two innovations: 1) In keeping with our attempt to scale the latest namespace draft, the prefix and ns attributes have been added to the ElementDecl element. These provide a prefix for DTD conversion and a namespace name for resolution. Hopefully, this means that XSchemas will be ready to run with namespaces. 2) After much debate, which still has some loud dissent, I've added the Model element to hold the content model for elements. It allows documentation of the content model separately from documentation of the element; it also will allow for friendlier containerization of content models in processing. Or so I hope. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. (I'm having problems with AOL's FTP services again, so it may be tomorrow...) Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.2 Element Declarations Element declarations in XSchemas are made using the ElementDecl element and its contents: The XSC:Name attribute identifies the name of the element, and is required. An element declaration would look like: ...additionalElementInformation... This declaration would declare an element named "Species", which would appear in an instance as: ...content... The Name attribute must be unique within the set of elements, as it provides the name of the element as declared here, and is also used by other elements to refer to this element in their content model declarations. The Name attribute must also match the Name production in the XML 1.0 spec. (Effectively, this requires element names to begin with a letter, underscore, or colon.) The id attribute, if it appears, must be unique within the document. This attribute may be used to uniquely identify this ElementDecl element for reference using XPointers and other tools. The prefix attribute identifies the prefix that will be applied to this elements and its attributes during conversion to DTDs, unless overridden in the attribute declaration itself. The ns attribute identifies the URI which functions as the namespace name for this element and its attributes. Namespace processing is covered further in Section 3.0, "XSchema and Namespaces". The Root attribute provides authoring tools with a guide for which elements are likely root elements for documents. This is intended to simplify the choices presented to authors during document composition. Composition tools could use this to build a menu of likely starting points for a document. The Root attribute is purely a suggestion and does not require any action on the part of the processor. Note that an element must declare a content model of some type, using the Model element, even if that content model is empty. Documentation (in the Doc element), non-XSchema extensions (in the More element) and attribute declarations (using AttDef elements) are optional. Documentation about the element, additional extensions, content-model information, and attribute information are stored as sub-elements of the ElementDecl element. Documentation is covered in 2.6.1, Documentation Extensions. Additional extensions are covered in 2.6.2, Further Extensions. Content Models are covered in 2.3, Content Model Declarations, and attributes are covered in 2.4, Attribute Declarations. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hankr at dnai.com Fri Aug 7 22:57:14 1998 From: hankr at dnai.com (Hank Ratzesberger) Date: Mon Jun 7 17:03:39 2004 Subject: XML-RPC References: <35CB473E.4131B376@dnai.com> <35CB4DFF.8981FDFC@Eng.Sun.COM> Message-ID: <35CB6896.19ECFBC8@dnai.com> I can see that its a bit strange. I am not trying to create another RPC spec, we have a product based on DCE or native RPC. dHTML makes a reasonable layout mechanism. What if you want to deliver the layout, but not necessarily the data? Java is an excellent cross platform solution, and we support Java as a client language. If you don't want to use java, but get cross platform results, then the browser as client seems to be a reasonable solution. Further, if you want to script the application, then either http server or browser needs to know how to parse the script, make the call and return the data. Well, I was under the impression from such sites as http://www.scripting.com/frontier5/xml/code/rpc.html that there was some interest in a standard notation, but perhaps the fun is writing your own? Hank David Brownell wrote: > > Hank Ratzesberger wrote: > > > > Is anyone working with XML-RPC? I am interested in what the DTD would > > look like for both a SSI RPC invocation and for one invoked at the > > client side in a browser. > > IMHO you just send application-specific documents. No standard DTD > needed, beyond what the applications already use. > > The world doesn't need more RPC systems ... > > - Dave -- -------------------- Hank Ratzesberger hankr@dnai.com -------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Aug 8 00:28:23 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:03:39 2004 Subject: XSchema question References: <002f01bdc215$91b6a5d0$2ee044c6@arcot-main> Message-ID: <35CB7FC1.41F200B0@allette.com.au> Don Park wrote: > To me, DTD is synonymous with the Dodo bird. Its > extinction, as well as the > extinction of Dodo bird hunters (DTD writers), is > inevitable. Document > designers and data sculpters cometh... While I grant you that either of those titles would look truly magnificent on a business card, it seems that you might be attributing them with an in-built set of skills. Are the Spice Girls really better than Handel because their music gets played on electric instuments? We humble crafters of the DTD have worked well with the tools we have been given - it's honest work. Given a chance and many years of toil, some of the younger from our ranks may one day even become real Document Designers. -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From samg at fundtech.com Sat Aug 8 00:45:19 1998 From: samg at fundtech.com (Sam Gentile) Date: Mon Jun 7 17:03:39 2004 Subject: Schemas and Other Crucial XML Questions Message-ID: <000601bdc254$faaa2d20$5100000a@ftc_samg> We have a spec called "XML-Data W3C Note 05 Jan 1998", which discusses schemas. It is not clear from the document what a schema is used for or what it's purpose is. Is it for designing the XML buffer only or is it read by the parser? Is it an extension to XML? Are they even necessary in basic XML? Also, we have been hearing rumors of a "short" XML notation. Is there one? We have a need to reduce the size of our buffers. Can you do this in XML:? <1> <1>test Can they have the same name or this the namespace extension we have been hearing about? What are namespaces? Are they in the spec now? Thanks very much, Sam Gentile Senior Software Engineer Fundtech Corporation samg@fundtech.com Sam Gentile Senior Software Engineer Fundtech Corporation samg@fundtech.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Nicolas at DigitalAirways.com Sat Aug 8 00:53:49 1998 From: Nicolas at DigitalAirways.com (Nicolas Silberzahn) Date: Mon Jun 7 17:03:39 2004 Subject: Paris XML98: Dealing with the Electronic Patient Record variability: Object Oriented XML Message-ID: <01BDC266.7057D8E0.Nicolas@DigitalAirways.com> Bonjour, My presentation "Dealing with the Electronic Patient Record variability: Object Oriented XML" Presented on the workshop "SGML/XML in Healthcare", May 18th 1998 accompanying the GCA SGML/XML Europe ?98 Conference Paris is available at: http://www.digitalairways.com/NiS/ParisXML98/ OOXML is new way to add behaviors to XML Documents: Much more powerfull than Stylesheets & Much easier to build and maintain than core Java code. Summary: The Electronic Patient Record (EPR) is complex, loosely structured, highly variable and unpredictable. It is therefore difficult to modelize. Traditional systems do not fully satisfy the demand for an EPR for clinical on-line use. The SGML-XML approach seems to satisfy the need of a data model able to capture the full range of clinical information in a format still suitable for automatic handling. Unfortunately, the navigation among the record components relies to date on proposals that do not offer sufficient capabilities to deal with the EPR complexity and variability. The Object Oriented XML that we propose, which considers each XML Element as an object that comes with its methods, could considerably increase the possibility of an XML document. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Sat Aug 8 01:01:54 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:03:39 2004 Subject: XML media types Message-ID: <199808072258.PAA28708@boethius.eng.sun.com> Following is the body of a message from Jim Whitehead to the W3C XML SIG. Please do not reply to this message or attribute its authorship to me. -- Jon ======================================================================== FYI, the IETF has issued the document for XML media types registration as Internet Informational Request for Comments 2376, and IANA has added text/xml and application/xml to the list of registered media types maintained at: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ So, text/xml and application/xml are now official Internet media types. The RFC itself can be retrieved from: ftp://ftp.isi.edu/in-notes/rfc2376.txt Since this document has significant discussion on i18n and security issues, perhaps a link to it from the W3C's (and other third-party XML resource pages) XML pages would be helpful in achieving compliance with this document. - Jim Here is the forwarded IETF announcement message: A new Request for Comments is now available in online RFC libraries. RFC 2376: Title: XML Media Types Author(s): E. Whitehead, M. Murata Status: Informational Date: July 1998 Mailbox: ejw@ics.uci.edu, murata@fxis.fujixerox.co.jp Pages: 15 Characters: 32143 Updates/Obsoletes/See Also: None URL: ftp://ftp.isi.edu/in-notes/rfc2376.txt This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Aug 8 01:05:00 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:39 2004 Subject: LISTRIVIA (was RE: unsubscribe) In-Reply-To: Message-ID: <3.0.1.16.19980807234707.78176a10@pop3.demon.co.uk> Let's not try to discuss list management issues - Henry and I will take care of that. (many people are irritated by discussions of unsubscription). And smart ones may guess that I or Henry mail people without announcing it to the list. Note also that its should NEVER be necessary to quote the XML-DEV signature in your message as just happened. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Curt.Arnold at hyprotech.com Sat Aug 8 01:21:25 1998 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:03:39 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 6 Message-ID: <724B33822AE5D011B9FD0060B0576B88E5448F@WARWICK> Sorry to reply without researching. I'm definitely in favor of the MODEL element per my some thoughts on inheritance message of a few weeks ago. I assume that MODEL is pretty much equivalent to GROUP in XML-Data? Can MODEL include other MODEL elements? I'd would really like it if the attributes could be grouped also (and also contain other attribute groups). That would make it very easy to replicate a group of attributes from another element. Don't know how complex the impact that would have on the parser. -----Original Message----- From: Simon St.Laurent [mailto:SimonStL@classic.msn.com] Sent: Friday, August 07, 1998 3:39 PM To: Xml-Dev (E-mail) Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 6 Below is the latest version of the Element Declarations section of the XSchema ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Aug 8 04:16:27 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:39 2004 Subject: Schemas and Other Crucial XML Questions In-Reply-To: <000601bdc254$faaa2d20$5100000a@ftc_samg> References: <000601bdc254$faaa2d20$5100000a@ftc_samg> Message-ID: <199808080215.WAA02524@unready.megginson.com> Sam Gentile writes: > We have a spec called "XML-Data W3C Note 05 Jan 1998", which discusses > schemas. It is not clear from the document what a schema is used for or what > it's purpose is. Is it for designing the XML buffer only or is it read by > the parser? Is it an extension to XML? Are they even necessary in basic XML? > > Also, we have been hearing rumors of a "short" XML notation. Is there one? > We have a need to reduce the size of our buffers. Sam: It might help if you clarified a little. What do you mean by an "XML buffer"? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Sat Aug 8 04:55:37 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:39 2004 Subject: XSchema question Message-ID: <004001bdc276$bd796160$2ee044c6@arcot-main> Marcus, >While I grant you that either of those titles would look >truly magnificent on a business card, it seems that you >might be attributing them with an in-built set of skills. >Are the Spice Girls really better than Handel because their >music gets played on electric instuments? I did not say Spice Girls are better than Handel but they certainly look better, eh?;-) >We humble crafters of the DTD have worked well with the >tools we have been given - it's honest work. Given a chance >and many years of toil, some of the younger from our ranks >may one day even become real Document Designers. Better tools and mediums will free us from that and allow us to concentrate on semantics and not the syntax. At that point, styles will become more important. That was all I was saying. Maybe I should have said that all the Dodo birds moved to New Yord and became fashion consultants. Best, Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Sat Aug 8 05:07:26 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:03:39 2004 Subject: Offtopic was.Re: Namespaces and XML validation Message-ID: <042001bdc27a$153a8fc0$11addccf@ix.netcom.com> Tim, why did'nt you tell us about this. We should all support it. http://www.webstandards.org Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com -----Original Message----- From: Tim Bray To: John Cowan ; XML Dev Date: Friday, August 07, 1998 12:38 PM Subject: Namespaces and XML validation xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Sat Aug 8 08:47:52 1998 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:03:39 2004 Subject: Namespaces and XML validation Message-ID: John Cowan wrote: > This is quite separate from locality *as such*; locality of prefixes > just means that a given prefix isn't legal outside the scope of > its declaration. However, following the Algol precedents, you have > allowed declarations to supersede conflicting outer declarations > and to coexist with conflicting non-overlapping declarations. > There is some, if not overwhelming, software engineering experience > to indicate that this is a Bad Idea. > I find an assertion that "software engineering experience" has shown that Algol style lexical scoping is a bad idea quite surprising. Which school of software engineering believes this? Certainly not the one I went to. John -- I think you and some others on this list are being insufficiently imaginative in tackling the problem of figuring out how to validate documents that use the namespace spec. I believe it is possible to do fragment validation against DTDs, if that is so desired. However this certainly cannot be accomplished without some modification of the mechanics of DTD validation, as Tim outlined. I.e. pre-processing the DTD and the instance to convert all names to URI, name pairs, and what some have called fragment validation using as the root of each fragment any element that introduces a tag from a new namespace. A new namespace for this purpose is defined as one from a different namespace than its parent. I do not believe the new namespace proposal with local scoping makes it any harder to do than the old PI based namespace proposal. It may make it harder to think about it. The fact that the namespace prefix may actually be declared physically in the document after the DOCTYPE doesn't matter. At the time when the instance is to be compared to see if it matches the declaration in the DTD, the prefix to URI mapping is available. Can you do this without modifying your validation code? Certainly not. However, the approach I've outlined above still has a severe problem, which I don't think is so easily solved. In order to do this form of validaton, what gets put in the DTD is the prefix, and not the URI. That is a fatal flaw, because it makes it impossible to re-use a DTD for more than one document unless all documents that use that DTD use the same prefix for the same URI. That elevates the prefix to the same status as the URI -- something one must take care to keep globally unique. The prefix is not syntactically suited to this task. For that reason, and because of other well known deficiencies in DTDs, I think the issue of validation and namespaces is better dealt with in the context of a whole new schema language. The XML-Data submission clearly showed how this could work. The new namespace proposal does no violence to XML-Data's use of namespaces. I would therefore rather spend my time working on the new schema language, as the XML WG will shortly be doing, than patching DTDs. (The XSchema work that's been going on in XML-Dev is hopefully equally adaptable -- the volume of mail is simply too high so I have not been following it closely. The key is the use of XML syntax, which enables one to use namespace declarations in the schema in a manner that mimics the instance.) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Aug 8 13:31:38 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:39 2004 Subject: Namespaces and XML validation In-Reply-To: Message-ID: <3.0.1.16.19980808123103.094fc4de@pop3.demon.co.uk> Thanks Charles, I found this a useful and optimistic review. I'd like to take it as a starting point for a discussion about where we might go next. I'll add some comments of my own about 'XML validation' to try to tie in some historical perspective. [I think the discussion on XML-DEV in the last 6 days has been extremely valuable. There are clearly people to whom the new proposal has come as a shock and it will take time to readjust. In all our discussions we must be extremely aware that a lot of personal efforts and ideas have gone into XML and that we should avoid upsetting people (usually unintentionally). It is clear that XML-DEVers are making a real effort to be constructive, even those who wished for different approaches. Keep it up!] At 23:46 07/08/98 -0700, Charles Frankston wrote: [...] > >John -- > >I think you and some others on this list are being insufficiently >imaginative in tackling the problem of figuring out how to validate >documents that use the namespace spec. I believe it is possible to do >fragment validation against DTDs, if that is so desired. However this I agree with this belief (although I haven't worked it out in detail). I think there is a critical mass of people who feel the same way (and I actually think that JohnC is among them!). >certainly cannot be accomplished without some modification of the mechanics >of DTD validation, as Tim outlined. I.e. pre-processing the DTD and the >instance to convert all names to URI, name pairs, and what some have called >fragment validation using as the root of each fragment any element that >introduces a tag from a new namespace. A new namespace for this purpose is >defined as one from a different namespace than its parent. > >I do not believe the new namespace proposal with local scoping makes it any >harder to do than the old PI based namespace proposal. It may make it Again, my assessment of the discussion is that no one has adopted the slogan "PI workable: attributes unworkable". A few people clearly feel namespaces as such do not (yet) provide their solution and a greater number are concerned that there are hidden dragons which haven't been confronted. One such dragon is the concern about retrofitting namespaces to: XPointer, XLL, XSL, DOM, etc. I take it as axiomatic - and I'd suggest XML-DEVers also do - that those responsible for these activities are actively working on how to make them namespace-compliant. This may, of course, throw up technical problems but I don't think we need to worry about convincing people of its necessity. This raises the question of what is XML 1.0 , 1.1, etc. It is absolute that namespaces have not broken XML1.0. XML parsers (including SAX-aware ones) are not broken by any decisions on namespaces. Those who had a non-namespace XML solution/product will find it still works. Those who used colonised names with their own application semantics will find they still work. This will include those who had colonised DTDs used for validation and other things. Note that we do not - at present - have any final REC that specifies how any XML element or attribute should be interpreted (other than XML1.0's xml:space and lang, and the WD for XLL - perhaps there are others in XSL.) This means that if an application receives a namespace-aware document it can simply ignore the attributes it doesn't understand. The problem of how it becomes namespace-aware is what we are addressing at present, but we should remember that we are only just starting - 19980802 has not broken anything of permanence. >harder to think about it. The fact that the namespace prefix may actually >be declared physically in the document after the DOCTYPE doesn't matter. At >the time when the instance is to be compared to see if it matches the >declaration in the DTD, the prefix to URI mapping is available. Can you do >this without modifying your validation code? Certainly not. This is an important point - I have always assumed that the final implementations of the full power of namespaces will require substantial software development. Most of us have also assumed it will have to involve the conventional DTD at some stage. The DTD might be preprocessed, or perhaps multiple DTDs might be required for a single document instance. > >However, the approach I've outlined above still has a severe problem, which >I don't think is so easily solved. In order to do this form of validaton, >what gets put in the DTD is the prefix, and not the URI. That is a fatal >flaw, because it makes it impossible to re-use a DTD for more than one >document unless all documents that use that DTD use the same prefix for the >same URI. That elevates the prefix to the same status as the URI -- >something one must take care to keep globally unique. The prefix is not >syntactically suited to this task. Agreed. > >For that reason, and because of other well known deficiencies in DTDs, I >think the issue of validation and namespaces is better dealt with in the >context of a whole new schema language. The XML-Data submission clearly >showed how this could work. The new namespace proposal does no violence to >XML-Data's use of namespaces. I would therefore rather spend my time >working on the new schema language, as the XML WG will shortly be doing, >than patching DTDs. > >(The XSchema work that's been going on in XML-Dev is hopefully equally >adaptable -- the volume of mail is simply too high so I have not been >following it closely. The key is the use of XML syntax, which enables one >to use namespace declarations in the schema in a manner that mimics the >instance.) I think this is the key point. The semantics of dealing with namespaces cannot be managed by conventional DTDs. We shall certainly need schemas. It may be possible to manage these 'below the surface' (e.g. convert a public DTD to a schema, transform this to be namespace aware and then retransform to a DTD for syntactic validation.). It could have been useful to manage prefixes by a PE like: but this isn't legal. However, if we transform to a schema we can use (general) entities to do this (e.g. &foo;:CHAPTER) and we can retransform. (As someone whose discipline is based on Fourier transformation I find this a natural approach). So we shall need software, but I don't think it's horrendous. > I'll now give my perception of possible approaches based on my (rather inadequate) knowledge of SGML. I tackled this namespace problem 3 years ago when starting to develop CML and I found I need namespaces (I used constructs like CML.MOL - I even had a language called XML, e.g. XML.ARRAY). I asked on comp.text.sgml how to do this and got the following responses: - there is no mechanism for combining DTDs - use SUBDOC (essentially compartmentalised information components in a document) - use HyTime (or some other sort of architectural forms) The problem was that SUBDOC was not supported by any free software (I was quoted a special introductory price of $10K for a system that would do SUBDOC). HyTime was also unavailable for free (and it was also effectively impossible to find out anything about it.) So my conclusion was that in 1996 (XML 0.0): multiple SGML DTDs could be combined but only within large organisations who could pay for elaborate tools. Interoperability with third parties was not supported. [A lemma was that large academic projects like TEI might also manage this.] There is therefore no 'golden age' of multi-DTD working that the current namespace proposal breaks. The key aspects of the current proposal are: - software must be widely (freely) available - recipients of multi-namespace documents must be able to use generic tools - it should be possible to combine chunks of information (information components) in a smallish variety of simple ways. The more complex the suggestions, the harder they will be to implement. - global validation for a multinamespace document is likely to be difficult if authors are allowed flexibility in the way these are combined. Validation for a very rigid document type should not be difficult. There seem to be the following ways forward: (A) SUBDOC-like (islands of validity). I'm not familiar with SUBDOC but I guess this requires software that can identify a subcomponent (probably a subtree) in a document and start up a validating parser for that component alone. (B) Architectural forms. AFAIK the new namespace proposal neither supports nor invalidates AFs. I assume (and hope) that their adherents can build prototype systems that will work with namespaced documents. (C) XLink (Tim Bray's - and my - preferred solution). The information components are kept in separate files and are transcluded rather than included in documents. Parsing, including validation, is a separate activity for each file. There is clearly a requirement for software to manage the identification and reassembly of these subtrees. We shall also need experience in how documents should be authored. I don't always like the idea that a document with 100 molecules has to have 100 separate file using XLink (though it provides excellent normalisation). I'd feel happier if I could be sure that the linking mechanism always found the right file. (D) Schemas. I am delighted by the progress that the XSC group has made over the last few days - they are clearly optimistic that NS's can be fitted to XSchema. That's great. If nothing else, this should be a superb basis for future schema work - either expanding XSchema or XML-data/W3C-based. A word of caution. I thought that XSchema would take a day or two. It's taken 2-3 months. That's with a high rate of activity. So we should accept that namespace APIs/schemas etc will take a month or so to build. I know it's a slack time of year but it's catalysed (in my mind) by the XML DevCon in Montreal in 12 days time. It would be nice to get a feeling as to what activities people are thinking of for implementing namespaces. So far we have had a few suggestions, particularly James Clark, John Cowan, David Megginson and the XSchema group. If DavidM reads this, it might be useful if he can suggest how SAX might react to namespaces... P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Sat Aug 8 13:49:42 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:03:40 2004 Subject: XSchema question References: <004001bdc276$bd796160$2ee044c6@arcot-main> Message-ID: <35CC3B96.8190FA0B@allette.com.au> Don Park wrote: > Better tools and mediums will free us from that and allow > us to concentrate > on semantics and not the syntax. At that point, styles > will become more > important. That was all I was saying. I'm probably just touchy about this because it's the second time this week (in different places) that it's come up, but I think that most DTD designers feel that they are covering as many bases as they can, given the perhaps limited knowledge they may have about how the data will eventually be used. Syntax isn't really a big part of DTD creation; the majority of the effort currently goes into data analysis. I agree completely that better tools will make life easier for all of us, but that extends to those who don't really understand what they're doing as well as those who do. Those who rely on flash tools over underlying knowledge to solve their problems may still ultimately be disappointed. Lou Reynolds (former substantial shareholder in EBT (now Inso)) left us with a great line when he was in Australia a few years ago - "Another year and we'll all be drinking champagne out of fire hoses". While I continue to believe that this will be the case, it's hard to forget that it was uttered by one who is no longer in the game ... :-) -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Aug 8 14:48:31 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:40 2004 Subject: Namespaces and XML validation In-Reply-To: References: Message-ID: <199808081247.IAA00227@unready.megginson.com> Charles Frankston writes: > I do not believe the new namespace proposal with local scoping > makes [DTD validation] any harder to do than the old PI based > namespace proposal. This claim is incorrect, though the culprit is the local scoping and defaulting rather than the declaration mechanism itself. XML 1.0 DTDs know only about one-part, unresolved names (i.e. "foo" or "bar:foo", not null + "foo" or "http://www.megginson.com/" + "foo"). Without local scoping and defaulting, there was still guaranteed to be a one-to-one relationship between unresolved names and resolved (two-part) names, and thus, only one XML unresolved name for each element type and one element type for each name; as a result, it was possible to write a DTD for _any_ document that used namespaces. With local scoping and defaulting, there is a many-to-many relationship between unresolved names and resolved names, and thus, possibly more than one XML 1.0 name for each element type and more than one element type for each name. Tim has rightly pointed out that DTD validation is possible only on a small subset of the documents allowed by the new spec -- that is, documents use only one unresolved name for each element type and one element type for each unresolved name. He also rightly points out that any XML document can be mechanically transformed so that it belongs to this subset. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Aug 8 15:10:41 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:40 2004 Subject: Namespaces and XML validation In-Reply-To: <3.0.1.16.19980808123103.094fc4de@pop3.demon.co.uk> References: <3.0.1.16.19980808123103.094fc4de@pop3.demon.co.uk> Message-ID: <199808081309.JAA00360@unready.megginson.com> Peter Murray-Rust writes: > I know it's a slack time of year but it's catalysed (in my mind) by > the XML DevCon in Montreal in 12 days time. It would be nice to get > a feeling as to what activities people are thinking of for > implementing namespaces. So far we have had a few suggestions, > particularly James Clark, John Cowan, David Megginson and the > XSchema group. If DavidM reads this, it might be useful if he can > suggest how SAX might react to namespaces... I'm looking forward to talking with as many of you as possible during the XML Dev Day(s) in Montreal. I first raised the issue of SAX and namespaces on XML-Dev a few weeks ago -- after reading dozens of postings and private messages, I am convinced that the only clean solution is to define a special data type for two-part names, something like the following: package org.xml.sax; public interface Name { public String getURI (); public String getLocalName (); } This, however, is the easy part; the hard part is figuring out how to work this into SAX. Here are some of the problems 1. How should SAX make the prefix map available to applications? One option is to create a new handler type, called NamespaceHandler: public interface NamespaceHandler { public void startNamespaceScope (String prefix, String uri); public void endNamespaceScope (String prefix); } Another option is to create a new type of object called a Namespace Resolver: public interface NamespaceResolver { public Name resolveIndependentName (String name); public Name resolveDependentName (String name); } This could be set by the NamespaceHandler: public interface NamespaceHandler { public void setNamespaceResolver (NamespaceResolver resolver); } 2. Should DocumentHandler be replaced or extended? 3. Does AttributeList now require a two-part lookup key, or should it stick to the unresolved (one-part) names? 4. Is namespace processing a core SAX service or a filter on top of SAX? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jonathan at texcel.no Sat Aug 8 15:18:49 1998 From: jonathan at texcel.no (Jonathan Robie) Date: Mon Jun 7 17:03:40 2004 Subject: Namespaces: silly question In-Reply-To: <35CB1F54.8F13ACC1@locke.ccil.org> References: <3.0.1.32.19980807105216.00cf9208@ifi.uio.no> Message-ID: <3.0.3.32.19980808091907.00c72100@pop.mindspring.com> I got way behind on XML-Dev during the finalization of namespaces. What exactly is IBTWSH? Thanks! Jonathan jonathan@texcel.no Texcel Research http://www.texcel.no xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Aug 8 17:32:47 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:40 2004 Subject: WebStandards.org Message-ID: <3.0.32.19980808080709.00bfd990@207.34.179.21> At 11:08 PM 8/7/98 -0400, Frank Boumphrey wrote: >why did'nt you tell us about this. >We should all support it. >http://www.webstandards.org Gimme a break, just found out about it at noon Friday. Yes, I think it's a worthwhile effort. It's not my idea, the other guys on the list dreamed it up and launched it. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Sat Aug 8 19:07:17 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:03:40 2004 Subject: Offtopic: Web Standards Project In-Reply-To: <042001bdc27a$153a8fc0$11addccf@ix.netcom.com> Message-ID: <3.0.5.32.19980808120229.00885da0@postoffice.swbell.net> [NOTE: The following is mostly an incoherent rant that is only marginally connected to the WSP. Consider it a potential source of comedy relief--no offence is meant to the WSP or its members--WEK.] At 11:08 PM 8/7/98 -0400, Frank Boumphrey wrote: >Tim, > >why did'nt you tell us about this. > >We should all support it. > >http://www.webstandards.org This looks interesting, and the list of names involved is certainly impressive, so I take it as a given that there is something significant here, but I'm wondering just exactly *what* the WSP can actually do to achieve its mission. Here's what I took to be the relevant info from the mission statement on the subject Web site: "Our goal is to support these core standards and encourage browser makers to do the same, thereby ensuring simple, affordable access to Web technologies for all." Realizing that the Web site claims it's not officially open until Monday (10 Aug 1998), I find it odd that there's nothing about *how* this organization (or any similar organization) can actually meet this goal. What power or authority would the WSP (or any similar group) have that the W3C, as the authority that issues the "standards", does not have? [The W3C does not make standards, it makes recommendations, but that's a fine semantic point that seems to be lost on 99.9999% of the populace.] Is it the intent of the WSP to be a clearing house for user complaints? In the absence of good faith on the part of the tool creators, the only recourse against failure to implement standards is user backlash. I can see that a user advocacy group could provide some benefit here (the Web equivalent of Ralph Naders' group?). But it's not clear what else might be done or how the WSP could serve in this capacity. The major vendors have already learned that users will take what they're given (imagine trying to earn a living in the information management industry and not use computers that run Microsoft software--it's pretty hard). Is it realistic to think that we can change Microsoft's practices? Because that's who we're talking about, Microsoft--Netscape, now that they've seen that standards and openness are their only hope of differentiation from MS, is on the side of right and good. What other vendors do we have to fear? Sun? They've got Java and everything to gain by it being a standard. Inso? As EBT, they've been good standards players from the start and have excellent technical resources who know how to do the right thing and will, I predict, do it (not that they play much outside the big-industry nitch market in any case). IBM? They're essentially pure user and understand the value of standards to themselves and their customers. Editor vendors? Maybe, but who besides MS has enough market share outside the core SGML industry to even have an effect? HP? They're in the same boat as Sun. Adobe? Maybe, but Adobe has its own de facto standard, PDF, that nobody, least of all Adobe, seems to care about formally standardizing (why should they when the US government declared it a standard by requiring its use for electronic document interchange--yet another monopoly granted by the government {anyone remember the railroad industry circa 1880}?). Adobe doesn't make browsers and their SGML/XML editor can't implement the style standards without being completely rewritten anyway. Arbortext only survives on the basis of ADEPT*Editor being as complete as possible an implementation of the SGML and XML standards (that's why people buy it). SoftQuad is in the same boat as Arbortext, but with less market share (but better prospects for producing a low-cost, high-value XML/SGML editor given their technology base). Corel tries hard and has good channels, but they've never been able to lever Word out of the way--their SGML support is good (if not perfect), but has never been marketed effectively. It seems to me that the real question is: how do we bring pressure to bear on Microsoft to support and implement standards? In fairness to MS, I should note that all the *technical* people I know at Microsoft (which is an admittedly small sample) have all been consistent in their commitment to standards and have demonstrated the ability to understand the standards sufficient to enable correct implementation of them (of course, most of the people I know I Microsoft I know because of their work on the development of XML). I'd like to think that this sample is representative. Certainly as a developer of technology, Microsoft is capable of doing whatever it decides to do. The question is, what will they decide to do and why. Certainly it is not the technologists that make the business decisions at Microsoft (if it was, they wouldn't be where they are today [and we wouldn't be having this discussion because we'd either still be mired in a swamp of competing and incompatible information system platforms, already have true standards-based systems, or still complaining about IBM as the Big Evil]). But as a business driven by an imperative to make money, Microsoft has consistently shown a disdain for standards and the needs of its customers. It essentially owns the information systems marketplace on PCs, which means most of the desktops in the world. It has a significant share of the back-end market (at ISOGEN, most of the people working on workstations use Microsoft software to do most of their work--what does that tell you?). Except for Adobe's PDF, Microsoft owns the data formats (and therefore the data) of most of the world's documents and this doesn't seem to be near to changing. Putting RTF or Excel into XML form won't change that situation much (although it will make it marginally easier to do stuff with an otherwise proprietary format because you'll be able to apply normal SGML and XML tools to it, even if you can't get reliable documentation for what it is you've got). Steve Newcomb often stresses that standards are contracts between data owners and users and the creators of tools that support those owners and users and he's 100% right. Which begs the question: what higher authority do the signatories of those contracts appeal to do resolve conflicts? National and international standards have some legal authority as contracts because they are created by national bodies that can legally and legimately put the weight of their countries behind them: they can, for example, enact laws that require the use of certain standards. The standards created by ANSI or DIN or ISO have been created by bodies that have some authority derived from the people governed by the governments that sponsor the standards authorities. The W3C, by contrast, is a consortium of vendors and users. It has no formal authority. It is not an agent of any government. It does not derive, however indirectly, from the will of the people. Therefore, it has absolutely no leverage by which to coerce or encourage respect for the recommendations it creates except the persuasive force of whatever arguments it might make or the degree to which it can influence popular opinion so as to change consumption habits. But since its members are the very organizations that need to be convinced to implement these standards, it's not realistic to expect the W3C to beat hard on its largest member. (I suppose it could bring civil suits against member companies that failed to live up to their agreements as consortium members, but who would pay for the cost of such a suit? How likely would Microsoft be to remain a W3C member if the W3C sued it?). That leaves only users themselves to demand that vendors do the right thing. Can the WSP lead that fight? Can it effect a world-wide boycott of Internet Explorer? Can it save us from our own laziness? I don't know--I hope so. If babies were dying or cute fuzzy creatures were going extinct because browsers weren't implementing HTML 4.0 correctly, I'd have more confidence. But the only thing that's at stake is our freedom from vendor oppression, something that few people even seem to realize as a threat and fewer still have the actual power or will to avoid (what operating system am I running? what browser do I use? what scheduling program do I manage with? what programming language do I hack in? do I want to use any of them? No. Do I, as long as I want to work as an IS consultant who can pick clients that aren't Unix-only, non-government-contractor shops, have a choice? No.). People aren't rioting in the streets because there are only two cable companies in the US or that 90% of all media outlets are owned by four corporations (or something close to that) or that the number of one-paper towns has increased dramatically in the last 50 years. So why should they care that a single corporation owns 90% of their data (by owning the definitions of its form and the software they have to use to access and modify it?)? So I'm wondering what the true motivation of the WSP is: publicity generator? counter to the W3C? public action group ala Nader's Raiders? The Green Peace of the Web? Tax shelter? It's definitely not clear from the WSP Web site exactly what it *is* or what it plans to *do*. I'd like to know more. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Sat Aug 8 19:21:02 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:40 2004 Subject: WebStandards.org (Off Topic) In-Reply-To: <3.0.32.19980808080709.00bfd990@207.34.179.21> Message-ID: On Sat, 8 Aug 1998, Tim Bray wrote: > At 11:08 PM 8/7/98 -0400, Frank Boumphrey wrote: > >why did'nt you tell us about this. > >We should all support it. > >http://www.webstandards.org > > Gimme a break, just found out about it at noon Friday. Yes, I think > it's a worthwhile effort. It's not my idea, the other guys on > the list dreamed it up and launched it. -T. I think it is a great effort as well. My only problem with it is that none of the web pages on the site validate. I find it hard to take an organization pushing web standards seriously if they can't even follow the standards themselves. I wrote Jefferey Zeldman, the site designer, and told him basically that... On Sat, 8 Aug 1998, Jeffrey Zeldman wrote: > chris: > thanks for writing. > > i do use harmless workarounds to avoid display errors. > > i do this because the browsers don't support the standards. > > for instance, i need to include a non-breaking space after i close > a DIV tag, because in IE 4.01/Mac, "DIV" is not treated as a block level > element, even though the standards say it should be. > > adding that non-breaking space causes the browser to follow the > with a line break, as it is supposed to do. > > as other versions of explorer do. as netscape 2, 3, and 4 do. > > in other words, when necessary to avoid errors caused by browser > bugs, i resort to workarounds which degrade well and cause no harm. > > however, those workarounds might snag an html validator. > > i can live with that more easily than i can live with a web page > that is impossible to read. > > i did discuss this with the other WaSP members, and explained my > rationale. > > but i thank you for mentioning it. > > in a way, it helps make the case for us. > > when the browser manufacturers deliver browsers that follow the > standards, we will be free to make completely validatable html. > > until that day, we have to make tough choices. this is mine. > > jeffrey I unfortunately disagree with his opinion. I think it is always possible to create web pages that validate, it just involves either sacrificing the use of some features, or recognizing that some browsers may render the site improperly. Usually most of the "harmless" hacks authors use to get things to display properly can be implemented in a way that also validates, if you take the extra time to try. http://validator.w3.org/ --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Aug 8 20:33:36 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:40 2004 Subject: Offtopic: Web Standards Project Message-ID: <3.0.32.19980808113318.00a26100@207.34.179.21> At 12:02 PM 8/8/98 -0500, W. Eliot Kimber wrote: >So I'm wondering what the true motivation of the WSP is: publicity >generator? counter to the W3C? public action group ala Nader's Raiders? The >Green Peace of the Web? Well, IMHO, the W3C has done its job in getting some potentially useful standards published. The W3C has not been effective as an advocacy or bully-pulpit organization, and it's hard to see that happening, in part because of some of the reasons raised by Eliot. It seems quite possible that the people who organized the WSP, mostly big-time site builders who spend other people's money to build highly visible Web presences, are well-positioned to get some attention and do some useful advocacy. Which is why it interests me. One interesting discussion is, which standards to focus on... my personal bet would be XML/CSS/DOM, because the implementations are just happening. Is it worthwhile, at this point in history, trying to retroactively save HTML? Real question. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eldred at mediaone.net Sat Aug 8 22:18:50 1998 From: eldred at mediaone.net (Eric Eldred) Date: Mon Jun 7 17:03:40 2004 Subject: Offtopic: Web Standards Project References: <3.0.32.19980808113318.00a26100@207.34.179.21> Message-ID: <35CC6C61.5996736@mediaone.net> Tim Bray wrote: > > At 12:02 PM 8/8/98 -0500, W. Eliot Kimber wrote: > >So I'm wondering what the true motivation of the WSP is: .... > One interesting > discussion is, which standards to focus on... my personal bet would > be XML/CSS/DOM, because the implementations are just happening. Is > it worthwhile, at this point in history, trying to retroactively > save HTML? Real question. -Tim I'm not sure what this has to do with xml-dev, other than the people, but I'll continue the thread here. I have no opinion about motives. I'm just a little guy, who would love to find ways to publish faster both to the web and to paper. XML certainly appeals to me, so any encouragement that way would help. I see several directions that would be important to pursue: 1. Talk to the *HTML editor* people. They are responsible for foisting a lot of errors on us--I don't care whether they are validated or not--they often produce such garbage (Front Page, Cold Fusion) that I can't read them with Lynx at all. The lack of a good, free XML editor is shameful (don't ask me to use emacs). 2. I use vi and some Linux tools, but one reason I do is that the *filters* from Blueberry and Filtrix included in other commercial products are useless. I'm not talking about complicated things, just elementary problems such as curly quotes and em dashes--at some point between OCR and a web page one needs to edit them by hand. There needs to be some simple rule-based filter such as Omnimark, but cheap or free. I can write some by hand in perl, but most people can't. But dealing with the white space problems is not trivial. 3. Let's face it: Netscape and Microsoft might be enemies, and they might have almost all of the browser market between them, but it will be neither necessary nor sufficient to have them agree on web standards. Because: 3a. For example, CSS1 provides for text (left and right) justification. Netscape 4's justification is force justification for the last paragraph line (thus often creating huge wordspacing on it) and Internet Explorer 4's is not force. I don't believe the standard specifies one or the other behavior. In each case, the author has no control. Much of the browser behavior that is consistent between vendors is de facto standardization, not written down anywhere. 3b. As the very example of the web pages at the webstandards.org site shows, there will always be a need for backward compatibility. Unfortunately, it is the history of web browsers that has caused all these problems, and even when version 5 browsers are released, we still have to design our pages to account for earlier ones, and text-only browsers such as Lynx. I can't see that webstandards.org can do much about that. (Well, we can stop using those features, but we don't need an organization to tell us to stop.) 4. Given that there will for a long time be used web browsers that can't support XML directly, why doesn't it make the most sense to do this at the server end? Keep pages in validated XML and filter them on the fly to HTML (whatever level your clients support) or even PDF? I realize there are problems with that-- who knows what combination of source will confuse or crash this or that browser--but at least for some time users can continue to employ the web browsers they prefer. 5. Just what level of CSS is webstandards.org going to mandate that Netscape and Microsoft support fully in their version 5 browsers? Just what level of XSL? I guess you can see there might be development schedule considerations. 6. CSS and XML are only a few of the W3C standards. I'd like to see some more encouragement for full support of the Accessibility standards (and some feedback as to how to improve them), the PICS effort, and especially the RDF effort--there needs to be an easier way to use metadata and more tools that use them, such as Dublin Core and others. 7. Seems to me that Microsoft and others are mainly interested in XML for practical, proprietary reasons: to support their CDF "push" technology, "Chrome" to justify buying a 350MHz Pentium II and get Microsoft into television markets, EDI replacements as well as on-line banking, etc. Although these efforts are based on a standard XML, the actual implementations are likely to be locked up and the otherwise "openness" of XML is lost. Standards agreements go only so far. To sum up: webstandards.org is a good idea and deserves support. Netscape and Microsoft need to be kept to their promises. We need to address more closely the significance of de facto standarization. However, we can disclose and work on some problems without having to put pressure on those big companies to do it for us. We can support the mozilla effort and work on XML/XSL etc tools that can help everybody. -- "Eric" Eric Eldred Eldritch Press mailto:EricEldred@usa.net http://eldred.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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Aug 8 22:37:32 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:40 2004 Subject: Offtopic: Web Standards Project In-Reply-To: <3.0.5.32.19980808120229.00885da0@postoffice.swbell.net> References: <042001bdc27a$153a8fc0$11addccf@ix.netcom.com> Message-ID: <3.0.1.16.19980808213754.60e70092@pop3.demon.co.uk> At 12:02 08/08/98 -0500, W. Eliot Kimber wrote [at his normal incredible typing speed]: > >[NOTE: The following is mostly an incoherent rant that is only marginally >connected to the WSP. Consider it a potential source of comedy relief--no >offence is meant to the WSP or its members--WEK.] Eliot's posts are always worth reading, but I suggest we don't spend a lot of time on discussing standards in general. It's worth considering what XML-DEV in particular can do to help the cause of interoperability. Although we all know that many people will implement the current WDs and REC's by themselves and for their own purposes it remains true that doing the whole lot - in anything but a large organisation - is a largish effort. Therefore the community in general - profit and non-profit - has found it worth their whiles to use the SAX interface that we/DavidM have developed. I think we have a similar opportunity with namespaces. I'm looking forward to seeing followups on recent postings about APIs, filters, etc. for SAX/namespaces. As several people have pointed out the syntax can be managed and a uniquified document passed to the application. I'm looking forward to being a consumer of such information as I've started to think about how multiple namespaces can be fed into display/editor - specifically for data management rather than text. I shall probably release a JUMBO snapshot of this fairly shortly - but at present it's based on 'old' namespaces. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Aug 8 23:00:59 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:40 2004 Subject: Offtopic: Web Standards Project In-Reply-To: <35CC6C61.5996736@mediaone.net> References: <3.0.32.19980808113318.00a26100@207.34.179.21> Message-ID: <3.0.1.16.19980808220146.60e7c818@pop3.demon.co.uk> At 15:18 08/08/98 +0000, Eric Eldred wrote: >Tim Bray wrote: [...] > >1. Talk to the *HTML editor* people. They are responsible >for foisting a lot of errors on us--I don't care whether >they are validated or not--they often produce such >garbage (Front Page, Cold Fusion) that I can't read them >with Lynx at all. The lack of a good, free XML editor is >shameful (don't ask me to use emacs). Well, I use Henry Thomson's XED and I think he's created an excellent tool - and it's free. More generally - writing a completely generic XML editor is hard, so I think your criticism is a bit harsh. XML is only 6 months old, and many of its components are not yet RECs. AN XML editor has to: - provide XML compatible with any DTD (i.e. requires an internal validator). Do you want this validation to be done for every keystroke? after a component has been assembled? - manage generic text editing including images, formatting. I have been using SUN's Swing classes - they are very good - but pretty complex. They use a model-view-controller approach which take a bit of getting used to. For example in the com.sun.java.swing.text package there are fifty classes. Non-trivial. - manage links, etc. This requires management of XPointers (not yet here), XLL (also not yet here). - be stylesheet driven by XSL (also not yet here). So far we have only considered text. We have also to be able to edit structure and also deal with arbitrary information objects. I have been hacking this into JUMBO and have just about finished - there are ca. 9 data types so far (int, float, boolean, string, email, url, link, html, enumeration). Each of these has to have different formatting and semantic validation (i.e. does the value make sense). At present these conform to a hardcoded DTD (XML-data-like), but I plan to develop it generically as follows. It's even more challenging to edit maths equations, molecules, music, etc. the browser/editor has to have an abstract API into which any objet can be plugged. At present I have things like: getDisplayComponent(int displayType) getUpdatedNode() isValid() isCorrectFormat() setMinimumValue() etc. These have to cover the whole spectrum of disciplines. Naturally I shall be concentrating on molecules. [...] There are many people who have put a great deal of effort into making good XML software and making it freely available. Personally I think the effort has been remarkable. Expecting high quality tools for free and calling our effort 'shameful' is not very motivational. Do you have anything to contribute to the effort? If you have a constructive proposal we'd be delighted to have it. P. > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Sun Aug 9 00:41:01 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:03:40 2004 Subject: WebStandards.org In-Reply-To: <3.0.32.19980808080709.00bfd990@207.34.179.21> Message-ID: On Sat, 8 Aug 1998, Tim Bray wrote: > At 11:08 PM 8/7/98 -0400, Frank Boumphrey wrote: > >why did'nt you tell us about this. > >We should all support it. > >http://www.webstandards.org > > Gimme a break, just found out about it at noon Friday. Yes, I think > it's a worthwhile effort. It's not my idea, the other guys on > the list dreamed it up and launched it. -T. Just a quick note - the Industry Standard story broke a little early. The official launch date wasn't supposed to be until Monday. So, please don't harrass Jeffrey Zeldman and the rest with complaints, bug reports, etc. until sometime Monday afternoon ;) I was involved at the beginning, though I can't take credit for much. You can all do your part by joining the discussion, using one of the banner ads, etc. We've gotten some good support, from PR companies and so forth, and may stand a chance at making a difference. Steve -- http://a.jaundicedeye.com <-- rants and writings http://hesketh.com/schampeo/ <-- projects and info http://dhtml.hesketh.com <-- coming soon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Sun Aug 9 01:18:52 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:03:41 2004 Subject: Offtopic: Web Standards Project In-Reply-To: <3.0.32.19980808113318.00a26100@207.34.179.21> Message-ID: On Sat, 8 Aug 1998, Tim Bray wrote: > At 12:02 PM 8/8/98 -0500, W. Eliot Kimber wrote: > >So I'm wondering what the true motivation of the WSP is: publicity > >generator? counter to the W3C? public action group ala Nader's Raiders? The > >Green Peace of the Web? (Confidential to Eliot: we start sinking French spy ships Monday at noon) > Well, IMHO, the W3C has done its job in getting some potentially useful > standards published. The W3C has not been effective as an advocacy or > bully-pulpit organization, and it's hard to see that happening, in part > because of some of the reasons raised by Eliot. Several of the founding members of the WSP are also members of the W3C working groups, or are otherwise involved with HWG, AIP, or non-browser software folks, like NetObjects, Allaire, and so forth. One thing that came up repeatedly was that the W3C couldn't risk pissing off the major vendors, and so those W3C members have stayed out of some fairly volatile discussions as a result. The W3C is in a delicate position when it comes to *enforcement* or *punishment* for non-observance or non-implementation of standards. They can't exactly say "You can't play, Microsoft, because you're putting Rob Glaser through such hell and IE4/Mac treats DIVs as inline elements." It just wouldn't work that way. > It seems quite possible that the people who organized the WSP, mostly > big-time site builders who spend other people's money to build highly > visible Web presences, are well-positioned to get some attention and do > some useful advocacy. Which is why it interests me. I think this is a key point - I spend other people's money, though I generally do more on the backend than the front end, and I /know/ that most of my clients don't know enough about standards and incompatibility to really care. They do understand that if they want bells and whistles it costs more, but many of them don't seem to understand that the core work is done in a couple of days and then we spend weeks tweaking things to make sure they're cross-browser compatible and/or degrade well. (One of our clients, Oxford University Press, needs its site to work in lynx, for example, including the order forms.) So I think that one of the duties of the WSP is to raise awareness - not among the designers and developers - we already know how broken everything is, and how risky it is to use anything beyond HTML1.0 for fear that the client's customers or users will come back with complaints and it could blow our credibility. Rather, we need to raise awareness among the folks who are writing the checks, and let them know *why* it costs so much more to deliver the cutting-edge stuff and somehow make it degrade well, or to deliver standards-compliant stuff that doesn't work anywhere due to lack of support for [insert browser-related standard here] or due to the need for ugly klugy workarounds. We've got a long road ahead of us, though, and I think we're aware of that. I mean, %$#!@, most of the suits I've worked for didn't know what 8-bit ASCII was, much less the difference between HTML4.0/CSS-P and HTML3.2... > One interesting > discussion is, which standards to focus on... my personal bet would > be XML/CSS/DOM, because the implementations are just happening. Is > it worthwhile, at this point in history, trying to retroactively > save HTML? Real question. -Tim HTML is dead - it's not even cute and fuzzy. As far as I know, the big goal right now is to try and get Netscape to ship the new layout engine in 5.0, so we can count on full CSS support and some XML, with a solid DOM. The timing issues are a problem, as we're not exactly there yet with a complete DOM spec. That, more than anything else, worries me and makes me wonder if the WSP has a snowball's chance. My main goal is to reduce the cost of maintenance of the sites I build. Period. I have no hope that the browser vendors will come to Jesus and magically support everything the W3C recommends (even if it's their own recommendation). I'd be happy if I could count on the things that make it easier to maintain a large-scale site, such as external CSS and Javascript files, being implemented according to spec. It would be nice to have a cross-platform-compatible DOM Javascript API, but that's easy enough to work around for the stuff they both support, anyway. There's been a lot of talk, here and on the WSP list, about how any org promoting standards compliance should stick to the standards. I'd just like to jump in here and say "that's horseshit". If the standards were implemented correctly, you could. Otherwise, we'd be stuck with a gray background bullet list. And frankly, that's not going to impress the target audience. Please be a bit more realistic. Besides, the WSP has not taken an official position /against/ innovation, rather, thay are trying to get the stuff that's already standardized *implemented*. I don't care if IE supports IFRAME and NS supports LAYER. I care that neither of them supports CSS the way I'd like. It makes my life more difficult, my sites more costly to maintain, and my customers spend more which reflects poorly on my company. Any flames that start with "I ran your sites through the HTML validator at the W3C, and ..." will be redirected to /dev/null. Thanks, Steve -- http://a.jaundicedeye.com <-- rants and writings http://hesketh.com/schampeo/ <-- projects and info http://dhtml.hesketh.com <-- coming soon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Aug 9 02:29:30 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:41 2004 Subject: Offtopic: Web Standards Project Message-ID: I have to say I'm awfully damn glad to hear about the WSP, because I can't say I've ever had any hope that W3C could provide a semblance of enforcement for standards implementation. Because their paychecks come directly from their members, they can't afford to be any more than a deliberative body, leaving the rest of us folks to whine and moan about how W3C standards - HTML, HTTP, XML, etc. - are hardly worth the paper they're printed on, much less the monitors on which we often read them. A lot of the work we've done so far on XML-Dev and a lot of the work to come is incredibly dependent on a very few market movers choosing to support standards they don't fully control. If XML is going to make it, those folks had better get used to liking standards they don't fully control, and which may in fact make their lives more difficult and their profits harder to come by. Interoperability means less of a lock-in for vendors - we might as well face it. A few of us are lucky enough to be working on projects, either in the SGML world or in niches of XML development where browsers per se don't matter, but the rest of us are sitting around waiting for some serious implementations from the large vendors, waiting to be able to take screen shots that demonstrate that XML can actually be used in an environment that's cheap, widely available, and standardized across platforms. XML: A Primer got by with painfully repetitive output from the MSXML parser, but the next edition had better have screen shots from multiple browsers, created with XML and CSS, or readers are going to lose interest. I hope the WSP can put some backbone in the standards process, providing a close examination of vendor claims for standards support and giving vendors a strong incentive to endorse standards - especially standards, like SMIL, in whose development they participated. Where do I send my check? Back to writing about @#X! proxy servers... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Sun Aug 9 06:07:35 1998 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:03:41 2004 Subject: Namespaces and XML validation Message-ID: > -----Original Message----- > From: David Megginson [mailto:david@megginson.com] > Sent: Saturday, August 08, 1998 5:48 AM > To: XML Dev > Subject: RE: Namespaces and XML validation > > Charles Frankston writes: > > > I do not believe the new namespace proposal with local scoping > > makes [DTD validation] any harder to do than the old PI based > > namespace proposal. > > This claim is incorrect, though the culprit is the local scoping and > defaulting rather than the declaration mechanism itself. > > XML 1.0 DTDs know only about one-part, unresolved names (i.e. "foo" or > "bar:foo", not null + "foo" or "http://www.megginson.com/" + "foo"). > Yes, David, but you're taking me somewhat too literally here (this is what I meant about being "insufficiently imaginative"). If I rephrased what I wrote as: "It is not too hard to evolve the concept of today's DTD validation to support two part locally scoped names (including the default prefix)." Would you still disagree with it? I believe this can be done -- it would obviously not be the validation as specified in XML 1.0, but a sensible evolution of the same. However, as I also said in my post, it would be essentially worthless, because it would encourage placing the prefix in the DTDs. I believe even this can be dealt with, but I'd rather spend the efforts on a new schema language, than patching DTDs. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Aug 9 11:07:39 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:41 2004 Subject: XML-DEV and Interoperability (Re: Offtopic: Web Standards Project) In-Reply-To: References: <3.0.32.19980808113318.00a26100@207.34.179.21> Message-ID: <3.0.1.16.19980809100806.0a9f0286@pop3.demon.co.uk> At 19:18 08/08/98 -0400, Steven Champeon wrote: >On Sat, 8 Aug 1998, Tim Bray wrote: > >> Well, IMHO, the W3C has done its job in getting some potentially useful >> standards published. The W3C has not been effective as an advocacy or >> bully-pulpit organization, and it's hard to see that happening, in part >> because of some of the reasons raised by Eliot. > [...] >We've got a long road ahead of us, though, and I think we're aware of that. I take these as the starting points for some comments on how XML-DEV might be involved in helping the cause of interoperability. [As always I feel it's important to stick fairly closely things related to implementation....]. A lot of people seem to be waiting for major browser m'facturers to come out with (free) shrink-wrapped browser/editors for XML, and doubtless that will happen in the medium-term. However XML is much more than browsers and editors (though that is where the current interest/hype is). For many activities and domains it represents an attractive way of laying the infrastructure of the information. A particularly good example of this is MathML (BTW a W3C-supported activity). The attraction and value of MathML is obvious and it seems likely that it will suffer from few problems of interoperability. Why should anyone create a MathML-aware tool that wasn't interoperable? Primarily through ignorance or incompetence, rather than an attempt to split the 'maths market'. A particularly important point is that the American Mathematical Society has been intimately involved with the effort (as it was with TeX). My point, therefore, is that there are many other aspects of XML than browsers. Certainly there will be a huge market for XML tools that can provide structured text, marked up and restylable. But there is also an enormous opportunity for specific subject areas to develop applications independently of, but interoperable with, browser technology. [It's not essential to have an XML browser/editor to work with MathML and it's probably even less important for CML - the MIME-based helper application or java classes can still do a huge amount without the XML being part of the text.]. An additional model of XML, therefore, is lots of independent but interoperable components in different domains. This may take a year or two to develop, but I think it's unstoppable. Thus, for example, I see XML as becoming a de facto standard in healthcare and, HenryR and I hope, in chemistry. Even if XML didn't succeed as the next generation of browsers (and I think it will), XML would still have to be invented for the domains. What are the alternatives? I can think of: - LISP (I suspect there are less than 10 chemists worldwide who would seriously consider this and perhaps 1 might try to implement it). - CORBA/Java. This is attractive for communities with well-established informatics operations which wish to interoperate. A good example is biology - all the major international and national genome and protein sites are tooling up to provide CORBA-based services. XML is yet to surface. CML and BSML are the only initiatives and they are relatively minor. The main problem with CORBA is that there is a long learning curve. Moreover interoperability is (I think) provided through fairly central global coordination - the IDLs are agreed at international level and I suspect that objects from a different domain will find it extremely difficult to interoperate with Bio-objects and vice versa. [XML has an enormous advantage here.] Moreover very few people would happily author a document using CORBA-based tools. - Legacy/binary/obfuscated software. This is the preferred current solution. I recently got a list of molecules which I cannot read because they are in binary, platform-dependent and goodness knows what else. The software is apparently the 'industry-standard'. For me, XML is the only way to go for chemistry. Even if I designed something from scratch it would still be XML. (probably XML-lite, because XML is too complex for chemists). Therefore I see it as inevitable that some day chemistry will alight on XML as the preferred solution for interchanging information. [There will also be CORBA as well, but much less.] So my real question is 'how can HenryR and I get horizontal support for this effort'? (We are obviously working on vertical support). Where can we look to in the XML community for help to make CML take off? - probably not the W3C as such because chemistry is probably not a core discipline for it (maths is). I don't know whether W3C has any initiatives in promoting XML other than for horizontal web activities. [My argument (above) would suggest that a lot of individual domain-based activities would be valuable supporting material for W3C]. - OASIS. They clearly have a strong interest in getting XML widely used. But, AIUI, they are primarily a vendor-based organisation. Are they likely to support vertical areas? Do they have an information pack I can use to help sell XML to chemists? - OMG. OMG have specialist domain areas (for chemistry it is (LSR) Life Science Research.) I talked last week with the domain specialist there and she and I have agreed to collaborate since we are both likely to find this a hard road and we certainly don't wish to compete. Objects can lead to documents and vice versa. I'd be very grateful for any authoritative statement on the relationship between UML and XML - I know there is something, but how important is it? - WSP. Presumably not directly. But perhaps membership from a large number of small domains with credible activities would help. - FSF/GNU. Unlikely for chemistry. But I still have hopes that in a year or two there will be major communal tools for XML from this sort of activity. If I want a C++ compiler I use g++. If I want UNIX I use Linux. I'd very much like to see XML-DEV helping in this sort of thing for XML. But remember that g++ and Linux have succeeded after the chaos of non-interoperability, not before. It also took considerable time. I think history may repeat itself here, and we have to keep the flame burning. An aside: I am relatively surprised how few academics there are on XML-DEV. This is an area where (I would have thought) there is a lot of potential. I haven't looked at the membership list but most seem to be *.com or *.net (the latter are presumably individuals with a forbidden passion for XML independent of their employment). Academia, though apparently powerless in the face of commercial interests and lacking the resources for shrink-wrapped development, must nevertheless make vital contributions to new disciplines. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Sun Aug 9 12:52:31 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:03:41 2004 Subject: XML-DEV and Interoperability (Re: Offtopic: Web Standards Project) In-Reply-To: <3.0.1.16.19980809100806.0a9f0286@pop3.demon.co.uk> Message-ID: On Sun, 9 Aug 1998, Peter Murray-Rust wrote: [...] > - CORBA/Java. This is attractive for communities with well-established > informatics operations which wish to interoperate. A good example is > biology - all the major international and national genome and protein sites > are tooling up to provide CORBA-based services. XML is yet to surface. CML > and BSML are the only initiatives and they are relatively minor. The main > problem with CORBA is that there is a long learning curve. Moreover > interoperability is (I think) provided through fairly central global > coordination - the IDLs are agreed at international level and I suspect > that objects from a different domain will find it extremely difficult to > interoperate with Bio-objects and vice versa. [XML has an enormous > advantage here.] Yes, though it's easy to set up a false opposition here: using CORBA to interface with remote XML or RDF data stores is an attractive proposition. The DOM comes to mind, as do various proposals for markup based IDLs. The claim that XML enables decentralised development, avoiding committee bottlenecks for vocabulary creation, has a lot going for it. But as things stand with XML there's plenty of work yet to do on the creation of a framework that allows resource types defined in different domains to coexist and interact in a rich way, so there's a danger of overhyping XML here. There's plenty of scope for more runtime-smarts to be added to the CORBA environment too; I can't think of any developments in this area where new XML cross-domain clever tricks couldn't be echoed within a CORBA based framework. > Moreover very few people would happily author a document using CORBA-based > tools. I think I disagree here, but maybe am not sure what you mean. Could you expand on this? Would they be unhappy because CORBA-based interfaces are intrinsically unsettling (slow, proprietary, buggy???), because modelling the document in object/class terms rather as an element/attribute angle-bracketted textual tree is somehow less open and interoperable, or because it's not clear what final output of such a process would amount to (ie. what would the files look like?). Are you thinking of CORBA-based tools as something like OpenDoc(RIP), or like the Linux GNOME desktop project? I for one would be more than happy to use these, and to have my document stored without angle brackets using something like IronDoc (public domain descendent of bento/quilt work from the structured storage component of OpenDoc) and accessed via an IDL that offered .toXML() methods or a DOM interface... I can't really see an opposition between XML and CORBA in this sort of scenario. It all seems reassuringly complementary. > documents and vice versa. I'd be very grateful for any authoritative > statement on the relationship between UML and XML - I know there is > something, but how important is it? Not sure about XML in the general case, but for the RDF 'dialect', a discussion NOTE from Walter Chang of Adobe was published on the W3C site last week, discussing the relationship between UML and the RDF Schema language. Note that this is a member submission and not a Working Group publication, and that it focusses on the facilities in the first (may 98) public draft of RDF Schemas; future versions of the spec may differ. See http://www.w3.org/TR/ and search for 'UML' > An aside: I am relatively surprised how few academics there are on XML-DEV. > This is an area where (I would have thought) there is a lot of potential. I > haven't looked at the membership list but most seem to be *.com or *.net > (the latter are presumably individuals with a forbidden passion for XML > independent of their employment). Academia, though apparently powerless in > the face of commercial interests and lacking the resources for > shrink-wrapped development, must nevertheless make vital contributions to > new disciplines. Exactly. That's why University of Bristol signed up to W3C... Not so sure about 'vital' but I'd definitely encourage other academics[1] to get involved. Dan [1] does neglecting a Phd in favour of web hackery count as academic? ;-) -- Daniel.Brickley@bristol.ac.uk Research and Development Unit tel: +44(0)117 9288478 Institute for Learning and Research Technology http://www.ilrt.bris.ac.uk/ University of Bristol, Bristol BS8 1TN, UK. fax: +44(0)117 9288473 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sun Aug 9 13:04:25 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:41 2004 Subject: Namespaces and XML validation In-Reply-To: References: Message-ID: <199808091103.HAA00221@unready.megginson.com> Charles Frankston writes: > Yes, David, but you're taking me somewhat too literally here (this > is what I meant about being "insufficiently imaginative"). If I > rephrased what I wrote as: > > "It is not too hard to evolve the concept of today's DTD validation > to support two part locally scoped names (including the default > prefix)." > > Would you still disagree with it? Not at all -- the thing to remember, though, is that the first generation of XML tools is just now working its way towards (or into) the channels, and that these are based on XML 1.0. For at least a year, it may be necessary to use these tools to create and process documents that use namespaces. For personal use, of course, I can write whatever I need in Java or Perl in a couple of hours, and can many XML-Dev'ers -- our software development cycle is measured in hours and days rather than months and years. It's the people who need shrink-wrapped XML software that will have the problem. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Aug 9 14:55:52 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:41 2004 Subject: XML-DEV and Interoperability (Re: Offtopic: Web Standards Project) In-Reply-To: References: <3.0.1.16.19980809100806.0a9f0286@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980809135653.6fc7145c@pop3.demon.co.uk> At 11:52 09/08/98 +0100, Dan Brickley wrote: >On Sun, 9 Aug 1998, Peter Murray-Rust wrote: >[...] >> - CORBA/Java. This is attractive for communities with well-established [...] > >Yes, though it's easy to set up a false opposition here: using CORBA to >interface with remote XML or RDF data stores is an attractive proposition. >The DOM comes to mind, as do various proposals for markup based IDLs. Indeed. And I think that - at present - CORBA is a good solution for data-based domains. XML will have to work hard in public to support data. I am frustrated by the slow progress with XML-data - until XML can define data primitives the data community won't take XML seriously. > > >> Moreover very few people would happily author a document using CORBA-based >> tools. > >I think I disagree here, but maybe am not sure what you mean. Could you >expand on this? Would they be unhappy because CORBA-based interfaces are I meant it will be some time before the Royal Society of Chemistry's Chemical Communications (a primary journal) accepts a submission as a set of CORBA objects. OTOH HenryR and I have gone a long way towards persuading them that an XML document will be the preferred means of submission in the near future, including data, molecules, links, etc. [...] > >[1] does neglecting a Phd in favour of web hackery count as academic? ;-) Depends how the web hackery turns out... you can do both if you neglect sleep. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Mon Aug 10 00:06:06 1998 From: jtauber at jtauber.com (James K. Tauber) Date: Mon Jun 7 17:03:41 2004 Subject: XSA proposal In-Reply-To: <3.0.1.32.19980807102759.00cf8480@ifi.uio.no> Message-ID: <000701bdc3e2$0d9c1540$dc6118cb@caleb> > * Lars Marius Garshol > > > >This is a proposal for XML Software Autoupdate, a system for > >automatically keeping track of new releases of software products. > > * Tim Bray > > > >Isn't this what OSD, from MS & Marimba, is supposed to do? > > Yes, in a sense. However, XSA concerns itself with discovering > new versions and changed addresses, while OSD goes much further, > and omits some of the most useful parts of XSA. It occurs to me (despite our early discussions, Lars) that we could use architectural forms---namely to link XSA and OSD. That is, by making XSA an AF of OSD. James BTW xmlsoftware.com will use XSA and possibility OSD xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Aug 10 01:23:58 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:41 2004 Subject: namespaces and XML validation References: <3.0.1.16.19980805074423.35a7b450@pop3.demon.co.uk> Message-ID: <35CE4BC3.C16EBA6C@mecomnet.de> pi-declared v/s attribute-declared namespaces do not make any difference to validation. the present wd leaves some ambiguities which affect namespace identification, but that leads to problems with all sorts of things, not just validation. the algorithm sketched out in mr bray's note is the 'string-processing' equivalent of the 'symbol-processing' approach which i have been advocating since the appearance of the previous draft. the 're-prefixed' names are the equivalent of the pointer to an interned symbol. this is sufficient to validate against dtd's from arbitrary namespaces. the advantage of a symbol based approach is that it accomplishes the 'rewrite' in one pass as in integral part of the parse. if the unambiguous serial form is required for whatever reason, it can be created by simply reserializing the document. at its most basic, the symbol-based approach would require that the name type suggested by mr megginson be modified to comprise a package and a local name rather than an uri and a local name; to place the uri in the package; and to use the package as the map between the local name and the universal name. which name is then bound into all elements, attributes, element declarations, etc., where one would now use a string. an advantage of interning by means of a package, rather than a global set of universal names is that it is easier to place a symbol in more than one package. this is often useful. according to the wd. prefixes need be bound dynamically to packages only in the process of parsing elements (modulo the issues of lexical scope for prefix bindings for dom side-effects) in order to satisfy the assumption re "knowing where each name in the dtd comes from", one also needs to bind dynamically (at least) at entity boundaries (the document proper, the external subset, external entities). note that, if this is not supported, then validation is not the only thing which suffers. validation suffers as a side effect of not being able to guarantee the identity of a name, which means, strictly speaking that no form of declaration-based processing is possible. i've dismissed elevating prefixes to universal status, since it's easy to come up with cases where that method fails. why did the wg dismiss using additional pseudo attributes on the xml declaration and on entity declarations to bind prefixes within those entities? in the present spec, where no namespace bindings extend over the dtd, there's no reason to read it, since it can't be guaranteed to have an unambiguous interpretation. ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 10 03:48:59 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:41 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) In-Reply-To: <35CAF283.5CB4F5BB@m2.dj.net.tw> Message-ID: <199808100152.AA01932@murata.apsdc.ksp.fujixerox.co.jp> Rick Jelliffe wrote: > MURATA Makoto wrote: > > > More than one conversion procedures certainly exist. The more I > > think about > > this issue, the more pessimistic I become. > > On the other hand, there has just been little practical requirement for > everyone to > synchronize until now. It is still the earliest days of Unicode and XML This is correct. We still have hope. > deployment, so cheer up! perhaps a strong request stating XML's needs to > > JIS and Microsoft (and ISO) can force a resolution. > If everyone remains stubborn, then the only thing to do is for IANA to > register > three different character sets. And perhaps XML will need another > pre-defined > attribute to indicate which character set variant is in use in an > element, to > handle cut-and-paste. What a cock-up. In the meantime, I guess the > appropriate > strategy is "damage control": as many Japanese implementors as possible > should > adopt a single mapping. Can you recommend one? What I have in mind is as follows: First, we should clarify the definition of the charset "shift_JIS" registered at IANA. I believe the least common denominator, which is JIS X0201 + JIS X0208:1997 should be adopted as the coded character set of SHIFT_JIS. NEC extensions and IBM extensions should be eliminated. 0x5C is backslash rather than yen sign, and 0x7E is tilde rather than overline. Second, we should revise the Japanese profile for XML and encourage the use of character entities to represent conversion- error-prone characters rather than directly use them. (See the end of this message.) Then, it will become easier for users to make conversion-error-free documents. User-friendly XML processors should warn users when documents in EUC-jp, iso-2022-jp, or shift_jis contain such characters. > deployed. It is better to converge on a single mapping, even if that > mapping > is not satisfactory to everyone (i.e. JIS). Actually, I am not optimistic about this, because there are many conversion policies. For example, Microsoft maps 0x5C (sjis) to 0x005C (unicode), but the glyph for yen sign is used for this code point. Microsoft converts NEC extensions and IBM extensions to Unicode characters. On the other hand, Java ignores NEC extensions and IBM extensions. (What happens if J++ is used? I do not know.) Apple appears to use more than one conversion table. Rick Jelliffe wrote: > > I have made mapping tables for entity references to thousands of > characters and > glyphs. You are talking about SPREAD entities. I recently tried to find ERCS documents, but I could find only a few. In my understanding, names of SPREAD entities contain hexadicimal numbers. But XML already have hexadecimal character entities. I would rather want to use natural language markup such as &enkigou; (enkigou should be in kanji). Here is a list of conversion-error-prone characters. < YEN SIGN > BACKSLASH < OVERLINE > TILDE < OVERLINE > FULLWIDTH MACRON < EM DASH > HORIZONTAL BAR < BACKSLASH > FULLWIDTH BACKSLASH < WAVE DASH > FULLWIDTH TILDE < DOUBLE VERTICAL LINE > PARALLEL TO < MINUS SIGN > FULLWIDTH HYPHEN-MINUS < YEN SIGN > FULLWIDTH YEN SIGN < CENT SIGN > FULLWIDTH CENT SIGN < POUND SIGN > FULLWIDTH POUND SIGN < NOT SIGN > FULLWIDTH NOT SIGN < TILDE > FULLWIDTH TILDE < BROKEN BAR > FULLWIDTH BROKEN BAR Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Mon Aug 10 06:09:35 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:41 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) In-Reply-To: <004c01bdc102$a8bce910$b0247385@ceres.ssel.toshiba.co.jp> Message-ID: <199808100412.AA01935@murata.apsdc.ksp.fujixerox.co.jp> Hamada wrote: > Do you mean that C++ MS-XML Parser enbedded in IE4 can't process support big > endian but UTF-16? It can't handle big endian UTF-16. Correct me if I am wrong. > Colleagues at Microsoft Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tln at insect.sd.monash.edu.au Mon Aug 10 08:00:04 1998 From: tln at insect.sd.monash.edu.au (Thuy-Linh Nguyen) Date: Mon Jun 7 17:03:41 2004 Subject: [help] xml4j (linux) Message-ID: <199808100603.QAA11409@insect.sd.monash.edu.au> Hi all, (I hope it's ok to ask this question here..) Has anyone installed xml4j for unix on linux and has problems ? I could not run the test jre -cp trlx -d personal.xml. The error is --p illegal option !! (Does not make sense !) TIA ! TL **************************************************************************** Thuy-Linh Nguyen CSSE, PO Box 197, Monash Univerisity, Caulfield East, VIC 3145, Australia Ph: 61-3-9903-2041, Fax: 61-3-9903-1077, http://www.sd.monash.edu.au/~tln/ **************************************************************************** xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tln at insect.sd.monash.edu.au Mon Aug 10 09:46:36 1998 From: tln at insect.sd.monash.edu.au (Thuy-Linh Nguyen) Date: Mon Jun 7 17:03:42 2004 Subject: [help] xml4j (linux) In-Reply-To: <199808100733.RAA13147@insect.sd.monash.edu.au> Message-ID: Hi ! I'm using xml4j_1_0_4, jdk 1.1.5. I tried : jre -cp xml4j.jar trlx -d personal.xml AND jre -cp xml4j_1_0_4.jar trlx -d personal.xml Both give error: uname: illegal option -- p TIA ! Thuy-Linh. > In message "[help] xml4j (linux)" > on 98/08/10, "Thuy-Linh Nguyen" writes: > > From: "Thuy-Linh Nguyen" > > To: xml-dev@ic.ac.uk > > > > Hi all, > > > > (I hope it's ok to ask this question here..) > > Has anyone installed xml4j for unix on linux and has problems ? I > > could not run the test jre -cp trlx -d personal.xml. The error is --p > > illegal option !! (Does not make sense !) > > Tell us what version of XML4J are you using and the error message as is, please. > > -- > TAMURA, Kent @ Tokyo Research Laboratory, IBM Japan > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jon at net.lut.ac.uk Mon Aug 10 10:41:39 1998 From: jon at net.lut.ac.uk (Jon Knight) Date: Mon Jun 7 17:03:42 2004 Subject: Offtopic: Web Standards Project In-Reply-To: <3.0.5.32.19980808120229.00885da0@postoffice.swbell.net> Message-ID: On Sat, 8 Aug 1998, W. Eliot Kimber wrote: > The major vendors have already learned that users will take what they're > given (imagine trying to earn a living in the information management > industry and not use computers that run Microsoft software--it's pretty > hard). Some of us manage just that and its not hard at all. And much less stressful than the alternative... :-) Tatty bye, Jim'll #!/usr/bin/perl -- -Whois++-client-in-6-lines-of-Perl -Beat-that-Z39.50! use IO::Socket;sub w{$f=shift;$a{$f}=1;($h,$p,$q)=split("/",$f);$s= IO::Socket::INET->new(PeerAddr=>"$h:$p")||return;print $s "$q\r\n";while(<$s>) {next if(/^%/);if(/^# SERVER-TO-ASK/){while(<$s>){$x=$1 if/Name: (.*)\r\n$/;$y =$1 if/Port: (.*)\r\n$/;$f="$x/$y/$q";@j=(@j,$f)if(/^# END/&&!$a{$f})}}else{ print}}close($s)}@j=shift;while(@j){w(pop(@j))}# whois++.pl host/port/query xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From samg at fundtech.com Mon Aug 10 15:21:34 1998 From: samg at fundtech.com (Sam Gentile) Date: Mon Jun 7 17:03:42 2004 Subject: Schemas and Other Crucial XML Questions In-Reply-To: <199808080215.WAA02524@unready.megginson.com> Message-ID: <002101bdc461$b69371f0$5100000a@ftc_samg> We mean just the XML data coming into the parser (coming over the wire). I guess we could call it an XML file. -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of David Megginson Sent: Friday, August 07, 1998 10:15 PM To: Sam Gentile Cc: xml-dev@ic.ac.uk Subject: Schemas and Other Crucial XML Questions Sam Gentile writes: > We have a spec called "XML-Data W3C Note 05 Jan 1998", which discusses > schemas. It is not clear from the document what a schema is used for or what > it's purpose is. Is it for designing the XML buffer only or is it read by > the parser? Is it an extension to XML? Are they even necessary in basic XML? > > Also, we have been hearing rumors of a "short" XML notation. Is there one? > We have a need to reduce the size of our buffers. Sam: It might help if you clarified a little. What do you mean by an "XML buffer"? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Aug 10 15:44:43 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:42 2004 Subject: Schemas and Other Crucial XML Questions In-Reply-To: <002101bdc461$b69371f0$5100000a@ftc_samg> References: <199808080215.WAA02524@unready.megginson.com> <002101bdc461$b69371f0$5100000a@ftc_samg> Message-ID: <199808101343.JAA05236@unready.megginson.com> Sam Gentile writes: > We mean just the XML data coming into the parser (coming over the > wire). I guess we could call it an XML file. OK, now I understand what you mean -- according to the spec, you're referring to an 'XML document', though I know that the term will sound strange to database-oriented people (XML takes a very docu-centric view of things). > Sam Gentile writes: > > We have a spec called "XML-Data W3C Note 05 Jan 1998", which > > discusses schemas. It is not clear from the document what a > > schema is used for or what it's purpose is. Is it for designing > > the XML buffer only or is it read by the parser? Is it an > > extension to XML? Are they even necessary in basic XML? XML-Data is a note that was submitted to the W3C by Microsoft and a couple of partners -- it has no official status (a W3C "Note" means roughly "here's a neat idea from one of our members"). XML 1.0 DTDs and proposed replacements/enhancements such as Microsoft's XML-Data and XML-Dev's XSchema perform three distinct roles: 1. Provide a schema for validating the *logical structure* (element/attribute/data) structure of an XML document; as a side effect, structural schemas can also provide enough information to control a guided XML authoring tool. 2. Declare the entities (internal strings or external objects) that make up the *physical structure* of an XML document. 3. Provide default logical content for an XML document (such as default values for attributes, though XML-Data goes further). Some people have argued -- quite convincingly, I think -- that these roles should be kept separate: they are mixed together right now for historical compatibility with ISO 8879:1986 DTDs. It is important to note that the W3C's XML WG will soon begin work on structural schemas and data typing, and that eventually a new W3C standard will appear -- until then, the only W3C standard for structural schemas is XML 1.0 DTDs, and XSchema or XML-Data should be considered strictly experimental. > > Also, we have been hearing rumors of a "short" XML notation. Is > > there one? We have a need to reduce the size of our buffers. No, there is no such thing. XML's parent, SGML, included extensive facilities for markup minimisation and has suffered badly for it, since SGML tools are far too difficult to write (there is still not a single Java-based SGML parser, beside probably more than a dozen Java-based XML parsers). There are, however, alternatives: for example, you could compile the XML to a compact binary format for internal storage then decompile it back to a verbose format for export -- there's no requirement to store it internally as text. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From samg at fundtech.com Mon Aug 10 16:14:41 1998 From: samg at fundtech.com (Sam Gentile) Date: Mon Jun 7 17:03:42 2004 Subject: Schemas and Other Crucial XML Questions In-Reply-To: <199808101343.JAA05236@unready.megginson.com> Message-ID: <002501bdc469$1e33bfc0$5100000a@ftc_samg> Thanks for your answers. I'm still a little confused. > > We have a spec called "XML-Data W3C Note 05 Jan 1998", which > > discusses schemas. It is not clear from the document what a > > schema is used for or what it's purpose is. Is it for designing > > the XML buffer only or is it read by the parser? Is it an > > extension to XML? Are they even necessary in basic XML? >>>XML-Data is a note that was submitted to the W3C by Microsoft and a >>>couple of partners -- it has no official status (a W3C "Note" means >>>roughly "here's a neat idea from one of our members"). Ok, that's clear. >>XML 1.0 DTDs and proposed replacements/enhancements such as >>Microsoft's XML-Data and XML-Dev's XSchema perform three distinct >>roles: >>1. Provide a schema for validating the *logical structure* >> (element/attribute/data) structure of an XML document; as a side >> effect, structural schemas can also provide enough information to >> control a guided XML authoring tool. How is this different from what DTDs do? Don't DTDs validate the *logical structure* of an XML document? >>2. Declare the entities (internal strings or external objects) that >> make up the *physical structure* of an XML document. Don't DTDs do this? 3. Provide default logical content for an XML document (such as default values for attributes, though XML-Data goes further). Some people have argued -- quite convincingly, I think -- that these roles should be kept separate: they are mixed together right now for historical compatibility with ISO 8879:1986 DTDs. >>> How about the question of namespaces? Is this legal XML? <1> <1>data <2>data or do you need namespaces? Thanks, Sam Gentile xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 10 16:21:32 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:42 2004 Subject: Schemas and Other Crucial XML Questions In-Reply-To: <002501bdc469$1e33bfc0$5100000a@ftc_samg> References: <199808101343.JAA05236@unready.megginson.com> <002501bdc469$1e33bfc0$5100000a@ftc_samg> Message-ID: <199808101420.KAA05379@unready.megginson.com> Sam Gentile writes: > Thanks for your answers. I'm still a little confused. > > > > We have a spec called "XML-Data W3C Note 05 Jan 1998", which > > > discusses schemas. It is not clear from the document what a > > > schema is used for or what it's purpose is. Is it for designing > > > the XML buffer only or is it read by the parser? Is it an > > > extension to XML? Are they even necessary in basic XML? > > >>>XML-Data is a note that was submitted to the W3C by Microsoft and a > >>>couple of partners -- it has no official status (a W3C "Note" means > >>>roughly "here's a neat idea from one of our members"). > > Ok, that's clear. > > >>XML 1.0 DTDs and proposed replacements/enhancements such as > >>Microsoft's XML-Data and XML-Dev's XSchema perform three distinct > >>roles: > > >>1. Provide a schema for validating the *logical structure* > >> (element/attribute/data) structure of an XML document; as a side > >> effect, structural schemas can also provide enough information to > >> control a guided XML authoring tool. > > How is this different from what DTDs do? Don't DTDs validate the *logical > structure* of an XML document? Yes -- as I mentioned above, these are roles that both DTDs and their proposed replacements can play. XML-Data proposes some additional types of validation, including validation for data content (is it an integer? etc.). > >>2. Declare the entities (internal strings or external objects) that > >> make up the *physical structure* of an XML document. > > Don't DTDs do this? Yes (see above). > 3. Provide default logical content for an XML document (such as > default values for attributes, though XML-Data goes further). > > Some people have argued -- quite convincingly, I think -- that these > roles should be kept separate: they are mixed together right now for > historical compatibility with ISO 8879:1986 DTDs. > >>> > > How about the question of namespaces? Is this legal XML? > <1> > <1>data > <2>data > > > or do you need namespaces? Actually, this is never valid XML 1.0 (with or without namespaces) because XML names are not allowed to begin with numbers, so let me recast your example: data data Yes, this is good, simple, well-formed XML 1.0: elements are allowed to recurse. If you were using a DTD, you might make the following declarations: All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dcarlson at ontogenics.com Mon Aug 10 16:43:24 1998 From: dcarlson at ontogenics.com (Dave Carlson) Date: Mon Jun 7 17:03:42 2004 Subject: Schemas and Other Crucial XML Questions Message-ID: <2.2.32.19980810144357.01062c98@terminal.ontogenics.com> At 09:43 AM 8/10/98 -0400, David Megginson wrote: >Sam Gentile writes: > > > Also, we have been hearing rumors of a "short" XML notation. Is > > > there one? We have a need to reduce the size of our buffers. > >No, there is no such thing. XML's parent, SGML, included extensive >facilities for markup minimisation and has suffered badly for it, >since SGML tools are far too difficult to write (there is still not a >single Java-based SGML parser, beside probably more than a dozen >Java-based XML parsers). > >There are, however, alternatives: for example, you could compile the >XML to a compact binary format for internal storage then decompile it >back to a verbose format for export -- there's no requirement to store >it internally as text. > It's important to note that an XML stream can be very highly compresses with standard tools like WinZIP. I have an XML file that's about 20K size, which includes many repititions of a small number of tags. WinZIP produced 97% compression on this file! The standard Java library includes a zip utility class for zipping/unzipping streams, so it's possible to dramatically reduce transmission bandwidth while retaining long, descriptive tag names. Cheers, Dave Carlson xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 10 16:47:01 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:42 2004 Subject: Namespaces and XML validation References: Message-ID: <35CF07C2.5E4AA348@locke.ccil.org> Charles Frankston wrote: > I find an assertion that "software engineering experience" has shown that > Algol style lexical scoping is a bad idea quite surprising. Which school of > software engineering believes this? Certainly not the one I went to. Not scoping, but shadowing. The difficult context is something like this: begin int foo; ... ... begin int foo; ... ... foo := 32; comment which foo? programmer means global, but compiler assumes local ; end end By making a (conventional) syntactic distinction between local and global variables, as is done in Smalltalk, this error is made less likely. As is well known, Dijkstra's _Discipline of Programming_ uses a mini-language in which this type of variable shadowing is a syntax error. > I believe it is possible to do > fragment validation against DTDs, if that is so desired. However this > certainly cannot be accomplished without some modification of the mechanics > of DTD validation, as Tim outlined. Precisely my complaint. In the previous ns draft, where ns declarations were global, validation could proceed in the normal fashion. With the current draft, it is possible to create documents that cannot be validated without first transforming them into other documents. > I do not believe the new namespace proposal with local scoping makes it any > harder to do than the old PI based namespace proposal. In the old proposal, there was nothing to "do"; just use normal XML validation. All namespace prefixes were global and explicitly covered the DTD (they could appear only before the DOCTYPE declaration). > The fact that the namespace prefix may actually > be declared physically in the document after the DOCTYPE doesn't matter. At > the time when the instance is to be compared to see if it matches the > declaration in the DTD, the prefix to URI mapping is available. Can you do > this without modifying your validation code? Certainly not. But in the previous draft, I didn't have to care about that mapping, because prefix-to-URI was a 1-1 relationship. > In order to do this form of validaton, > what gets put in the DTD is the prefix, and not the URI. That is a fatal > flaw, because it makes it impossible to re-use a DTD for more than one > document unless all documents that use that DTD use the same prefix for the > same URI. That elevates the prefix to the same status as the URI -- > something one must take care to keep globally unique. The prefix is not > syntactically suited to this task. Quite so. This is true of both the old draft and the new. > For that reason, and because of other well known deficiencies in DTDs, I > think the issue of validation and namespaces is better dealt with in the > context of a whole new schema language. [...] I would therefore rather > spend my time working on the new schema language, as the XML WG will > shortly be doing, than patching DTDs. This is precisely the attitude I characterized as "not giving a RRRA about DTD validation", and attributed to the authors of the current draft. (The anonymous authors, not necessarily the editors.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Aug 10 16:56:33 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:42 2004 Subject: Namespaces: silly question References: <3.0.1.32.19980807105216.00cf9208@ifi.uio.no> <3.0.3.32.19980808091907.00c72100@pop.mindspring.com> Message-ID: <35CF0A00.4AADC470@locke.ccil.org> Jonathan Robie wrote: > I got way behind on XML-Dev during the finalization of namespaces. What > exactly is IBTWSH? Why ... it's ... the .. [sings] Itsy Bitsy Teeny Weeny Simple Hypertext DTD! It's a small subset of HTML 4.0, adapted to XML syntax, and suitable for including "rich text" in documentation elements. For a commented DTD, see http://www.ccil.org/~cowan/XML/ibtwsh.dtd . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Aug 10 17:27:33 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:42 2004 Subject: IBTWSH Message-ID: <3.0.32.19980810082647.00c1d8c0@207.34.179.21> At 10:56 AM 8/10/98 -0400, John Cowan wrote: >> I got way behind on XML-Dev during the finalization of namespaces. What >> exactly is IBTWSH? ... >It's a small subset of HTML 4.0, adapted to XML syntax, and suitable >for including "rich text" in documentation elements. For a commented >DTD, see http://www.ccil.org/~cowan/XML/ibtwsh.dtd . Hey... pretty good. Is it an intentional design choice that ALL THE ELEMENT TYPES ARE SHOUTING AT ME AND HAVE UGLY SQUARE CORNERS? -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Mon Aug 10 19:07:13 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:42 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 7 Message-ID: The latest draft of the XSchema Element Declaration syntax follows. After receiving a few suggestions regarding moving attributes into a container element and considering the implications for reusability and processing, I've changed AttDef* to AttGroup?. AttDefs may still appear in the XSchema element; now I need to add AttGroup there. Eventually, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. I'm having odd problems with the AOL account and FTP right now; the entire site may move to a new URL shortly. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.2 Element Declarations Element declarations in XSchemas are made using the ElementDecl element and its contents: The XSC:Name attribute identifies the name of the element, and is required. An element declaration would look like: ...additionalElementInformation... This declaration would declare an element named "Species", which would appear in an instance as: ...content... The Name attribute must be unique within the set of elements, as it provides the name of the element as declared here, and is also used by other elements to refer to this element in their content model declarations. The Name attribute must also match the Name production in the XML 1.0 spec. (Effectively, this requires element names to begin with a letter, underscore, or colon.) The id attribute, if it appears, must be unique within the document. This attribute may be used to uniquely identify this ElementDecl element for reference using XPointers and other tools. The prefix attribute identifies the prefix that will be applied to this elements and its attributes during conversion to DTDs, unless overridden in the attribute declaration itself. The ns attribute identifies the URI which functions as the namespace name for this element and its attributes. Namespace processing is covered further in Section 3.0, "XSchema and Namespaces". The Root attribute provides authoring tools with a guide for which elements are likely root elements for documents. This is intended to simplify the choices presented to authors during document composition. Composition tools could use this to build a menu of likely starting points for a document. The Root attribute is purely a suggestion and does not require any action on the part of the processor. Note that an element must declare a content model of some type, using the Model element, even if that content model is empty. Documentation (in the Doc element), non-XSchema extensions (in the More element) and attribute declarations (using the AttGroup element) are optional. Documentation about the element, additional extensions, content-model information, and attribute information are stored as sub-elements of the ElementDecl element. Documentation is covered in 2.6.1, Documentation Extensions. Additional extensions are covered in 2.6.2, Further Extensions. Content Models are covered in 2.3, Content Model Declarations, and attributes are covered in 2.4, Attribute Declarations. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 10 19:49:48 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:42 2004 Subject: IBTWSH References: <3.0.32.19980810082647.00c1d8c0@207.34.179.21> Message-ID: <35CF32A6.C6E6CEAE@locke.ccil.org> Tim Bray wrote: > Hey... pretty good. Is it an intentional design choice that ALL THE > ELEMENT TYPES ARE SHOUTING AT ME AND HAVE UGLY SQUARE CORNERS? -Tim Thank you! I like all-caps element names, yes; I think they stand out better in mixed-case character data. As for the ugly square corners, I suppose that depends on the font? Try Lucida Sans Unicode (the name of which I think is unfortunate, as I tend to read it as "Lucida, sans Unicode"). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From epalma at fsaa.ulaval.ca Mon Aug 10 20:10:48 1998 From: epalma at fsaa.ulaval.ca (Eduardo Palma) Date: Mon Jun 7 17:03:43 2004 Subject: Xml files from databese Message-ID: <199808101811.OAA00401@hermes.ulaval.ca> Hi guys, Here is my problem, I want to use the dso applet from microsoft to generate objects from Xml. That works fine with text files conteining Xml. Is not so clear when I genereate Xml from a database web connection. (web pages or text generated on the fly). Sombebody know this aspects? Thanks Eddie xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 10 20:52:52 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:43 2004 Subject: Namespaces and XML validation Message-ID: <5030300023900581000002L012*@MHS> >I do not believe the new namespace proposal with local scoping makes it any >harder to do than the old PI based namespace proposal. It may make it >harder to think about it. The fact that the namespace prefix may actually >be declared physically in the document after the DOCTYPE doesn't matter. At >the time when the instance is to be compared to see if it matches the >declaration in the DTD, the prefix to URI mapping is available. Can you do >this without modifying your validation code? Certainly not. > >However, the approach I've outlined above still has a severe problem, which >I don't think is so easily solved. In order to do this form of validaton, >what gets put in the DTD is the prefix, and not the URI. That is a fatal >flaw, because it makes it impossible to re-use a DTD for more than one >document unless all documents that use that DTD use the same prefix for the >same URI. That elevates the prefix to the same status as the URI -- >something one must take care to keep globally unique. The prefix is not >syntactically suited to this task." I keep coming back to namespaces in the context of the programming languages that have used them, and think that these experiences should apply to XML's use to some degree or another. Maybe their uses in XML will be radically different becaues of the different uses of the two, but overall, past experience should be some guide. The C++ scenario is much like that of XML. The prefixes themselves must be unique within any conglomeration of code from multiple sources. Has this been a severe restriction in the C++ world? I don't think it has really, but some might argue that its because XML will much more often be used to slap together bits and pieces than a C++ application would. Mostly, the namespaces used are those of well known companies or standards organizations, right? We all know their prefixes and how to stay away from them. Any locally used namespaces are ours to pick, but if a clash occurs we have to deal with it manually. So, I guess the question is, how similar to C++ do people see XML's use being? Will their primarily be large, well defined namespaces that make up the bulk of the reusable goodies out there? Or, will it be the opposite? To the folks who say that it will be the opposite, I'd reply that we software coders keep saying the same thing too, but I'm not sure its happened yet :-) The other possible model, is that of Java. Java's model is basically like the "Use the whole URI" method, which is obviously yucky give the syntax of URIs. But in terms of bulk and usage, that's pretty much what Java has done. You have to use fully qualified name of a class to indicate a particular class. The obvious advantage that Java has in this respect is that they forsaw and built this in, so the names are a relatively reasonable hierarchical system that can fit over the whole universe. Perhaps this would not be a bad idea for XML as well, instead of allowing any random URL. The ability to package XML fragments as 'classes' and being able to say foons="com/ibm/xml/Businesswidgets" to get access to any of the Businesswidgets provided by IBM, would be a nice way to go. And, if there are disambiguations to do, the developer of the source document handles it, just as they do in Java by using the fully qualified name. That's just the way that the cookie crumbles, and we shouldn't expect any more magical way to deal with it? So, anyway, overall I'm just asking "How real are the problems being discussed in the domains where namespaces have been in real use" and "How relevant are those previous experiences vis a vis how similarly we feel XML's use will be to that of traditional programming languages" and "If they are relevant, and some previous experience matches expected XML usage closely, why not apply that previous experience now while we have the chance even if its a somewhat radical departure". Ok, so blast away :-) ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Mon Aug 10 20:56:30 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:03:43 2004 Subject: Schemas and Other Crucial XML Questions References: <199808080215.WAA02524@unready.megginson.com> <002101bdc461$b69371f0$5100000a@ftc_samg> <199808101343.JAA05236@unready.megginson.com> Message-ID: <35CF4250.E981808@infinet.com> David Megginson wrote: > Sam Gentile writes: > > > > Also, we have been hearing rumors of a "short" XML notation. Is > > > there one? We have a need to reduce the size of our buffers. > > No, there is no such thing. XML's parent, SGML, included extensive > facilities for markup minimisation and has suffered badly for it, > since SGML tools are far too difficult to write (there is still not a > single Java-based SGML parser, beside probably more than a dozen > Java-based XML parsers). > > There are, however, alternatives: for example, you could compile the > XML to a compact binary format for internal storage then decompile it > back to a verbose format for export -- there's no requirement to store > it internally as text. Simple some very simple compression algorithms like Huffman encoding for instance, do very well with XML documents as the Name production that is used for identifying tags among other things will be converted to some binary symbol that is used as an index to lookup the actual name production. In fact, you could do this all with entities by simply taking all of the Names specified in the DTD, spit them into a List, and then declare all entities. You could index all of this by using base 10 digits or else use something as high as base 64 to encode the array references. Then for a document which had element types with names "Foo" and "Bar" occurences of: would be converted to: <0> <1> For small documents like CDF for instance these sort of techniques may turn out to be counter-productive. Tyler BTW, on a side-note I am having a problem understanding whether the external subset or the internal subset should be parsed first. I would assume that the external subset should go first, but in this case it would make using INCLUDE and IGNORE sections to be pretty useless. This is something that is not clarified as far as I can tell in the 1.0 spec so if someone could clarify how this should be handled by a parser, then I would greatly appreciate it. Thanx in advance... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Mon Aug 10 21:16:29 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:03:43 2004 Subject: Schemas and Other Crucial XML Questions References: <199808080215.WAA02524@unready.megginson.com> <002101bdc461$b69371f0$5100000a@ftc_samg> <199808101343.JAA05236@unready.megginson.com> <35CF4250.E981808@infinet.com> Message-ID: <35CF46F4.3C03C5E5@infinet.com> Tyler Baker wrote: > David Megginson wrote: > > > Sam Gentile writes: > > > > > > Also, we have been hearing rumors of a "short" XML notation. Is > > > > there one? We have a need to reduce the size of our buffers. > > > > No, there is no such thing. XML's parent, SGML, included extensive > > facilities for markup minimisation and has suffered badly for it, > > since SGML tools are far too difficult to write (there is still not a > > single Java-based SGML parser, beside probably more than a dozen > > Java-based XML parsers). > > > > There are, however, alternatives: for example, you could compile the > > XML to a compact binary format for internal storage then decompile it > > back to a verbose format for export -- there's no requirement to store > > it internally as text. > > Simple some very simple compression algorithms like Huffman encoding for > instance, do very well with XML documents as the Name production that is used for > identifying tags among other things will be converted to some binary symbol that > is used as an index to lookup the actual name production. In fact, you could do > this all with entities by simply taking all of the Names specified in the DTD, > spit them into a List, and then declare all entities. > > You could index all of this by using base 10 digits or else use something as high > as base 64 to encode the array references. > > > > > Then for a document which had element types with names "Foo" and "Bar" occurences > of: > > > > > would be converted to: > > <0> > <1> Please forgive any confusion I may have caused but this is not valid XML as digits are not allowed as the first character in a name (only Letter's and the characters '_' and ':'). In this case, instead of using numeric digits, use characters that are Letters and simply map each letter to a corresponding digit value. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Aug 10 21:28:24 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:43 2004 Subject: Schemas and Other Crucial XML Questions In-Reply-To: <35CF4250.E981808@infinet.com> References: <199808080215.WAA02524@unready.megginson.com> <002101bdc461$b69371f0$5100000a@ftc_samg> <199808101343.JAA05236@unready.megginson.com> <35CF4250.E981808@infinet.com> Message-ID: <199808101927.PAA07368@unready.megginson.com> Tyler Baker writes: > BTW, on a side-note I am having a problem understanding whether the > external subset or the internal subset should be parsed first. I > would assume that the external subset should go first, but in this > case it would make using INCLUDE and IGNORE sections to be pretty > useless. This is something that is not clarified as far as I can > tell in the 1.0 spec so if someone could clarify how this should be > handled by a parser, then I would greatly appreciate it. The internal DTD subset is parsed first, so that entity declarations there take priority over those in the external subset -- I don't have time to check the actual language of the spec right now, however. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Mon Aug 10 22:46:35 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:43 2004 Subject: Namespaces and XML validation In-Reply-To: <199808101927.MAA29339@mehitabel.eng.sun.com> Message-ID: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> At 12:27 10/08/98 -0700, Murray Altheim wrote: [...] > >Peter, > >You speak with great optimism about the compatibility issues of the >current namespace draft. I think it would be sobering for anyone to read I am known to be overoptimistic. It occasionally has virtues. I think a lot of it comes from being an experimentalist - if most things work most of the time we are doing very well. I am also a believer in the value of kludges and (occasionally) communal self-discipline. I compare XML with C++. I went through the midnight blood with that... C++ now works - it's not pretty, but it works. It paved the way for Java. So I see XML1.0 working and being made to work. Perhaps it's just a station on the road... who knows in 5 years time? >over the working group archives to see that compatibility is not a given. These are not generally available... >In all but trivial DTDs namespaces have been shown to be incompatible with >XML 1.0 validation (or at very least more manual effort than would be >worth the trouble*). The solution for validating moderately complex >structures using qualified names without wholescale rewriting of existing >DTDs has not yet been found. It is a given that any such alternative >validation solution would be inherently incompatible with existing the >validation methodology (ie., the SGML-compatible declaration syntax in >XML 1.0). This (as I mentioned to Charles Frankston) is not a matter of >imagination but of compatibility and interoperability. I think we are in the experimental phase of XML where we are asking the wider world whether validation is valuable. To many established SGML people the lack of validation is near heresy. [In the same way I suspect many people couldn't envisage a useful OO language without multiple inheritance. But Java works. Only very occasionally do I think "it would be nice to have MI at this point". I suspect it will be the same for XML. As I have often (probably boringly) said, I think my community is far more interested in semantic than syntactic validity. (Actually they probably don't care about either much...) > >We can all hope that some new schema language solves all the problems >that arise in XML's nascent life, but we cannot do so at the expense of >incompatibility with XML 1.0. Unfortunately, I do not believe >compatibility with XML 1.0 validation is on the minds of all participants >and see a schism arising: XML 1.0 compatible, and XML-subset compatible. Subset? P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fblau at nina.snohomish.wa.gov Mon Aug 10 22:59:39 1998 From: fblau at nina.snohomish.wa.gov (Frank Blau) Date: Mon Jun 7 17:03:43 2004 Subject: XML/EDI and Healthcare Message-ID: <35CF5DB2.8756AC65@nina.snohomish.wa.gov> I am looking for information about integrated XML/EDI with healthcare EDI applications, specifically the X12 837 set. Thanks! Frank Blau xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From colds at nwlink.com Mon Aug 10 23:16:22 1998 From: colds at nwlink.com (Chris Olds) Date: Mon Jun 7 17:03:43 2004 Subject: Schemas and Other Crucial XML Questions Message-ID: <048801bdc4a3$eb8383e0$dc59fcc6@albert.salsa.walldata.com> Tyler Baker wrote: > >BTW, on a side-note I am having a problem understanding whether the external >subset or the internal subset should be parsed first. I would assume that the >external subset should go first, but in this case it would make using INCLUDE and >IGNORE sections to be pretty useless. This is something that is not clarified as >far as I can tell in the 1.0 spec so if someone could clarify how this should be >handled by a parser, then I would greatly appreciate it. The XML Recommendation says (in the last paragraph of section 2.8) "If both the external and internal subsets are used, the internal subset is considered to occur before the external subset. This has the effect that entity and attribute-list declarations in the internal subset take precedence over those in the external subset." Tim Bray's comment on this can be found at: http://www.xml.com/axml/notes/IntSubFirst.html /cco xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Mon Aug 10 23:37:05 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:03:43 2004 Subject: Namespaces and XML validation References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> Message-ID: <35CF7089.9A2A56A6@finetuning.com> peter murray rust wrote: > > As I have often > (probably boringly) said, I think my community is far more interested in > semantic than syntactic validity. (Actually they probably don't care about > either much...) How can you possibly have one without the other? If your syntax is bogus -- you won't get far with semantics. How can you? Am I wrong? Somebody please set me straight. lisa rein http://www.finetuning.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Mon Aug 10 23:49:35 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:03:43 2004 Subject: Offtopic: Web Standards Project In-Reply-To: <199808101926.MAA29336@mehitabel.eng.sun.com> Message-ID: On Mon, 10 Aug 1998, Murray Altheim wrote: > Steven Champeon writes: > [...] > > Any flames that start with "I ran your sites through the HTML validator > > at the W3C, and ..." will be redirected to /dev/null. > > I think with this statement you've rather explicitly defined your > interest in supporting existing standards, and therefore my interest > in participating or supporting the WSP. Hi, Murray. I support your right to have whatever opinions of me and my level of commitment to standards. The point I, and the WSP, are trying to make is not that innovation (and hence potential variance from standards) is bad, but that such innovation, *when it comes at the cost of a lack of full support for existing standards*, is bad. Does using a non-standard workaround for a bug in one's *markup* make a desire for fully compliant *implementations* null and void? I don't think it does. But, as I said, you are entitled to have whatever opinions you like. I have to live in the real world. Cheers, Steve -- http://a.jaundicedeye.com <-- rants and writings http://hesketh.com/schampeo/ <-- projects and info http://dhtml.hesketh.com <-- coming soon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 10 23:55:26 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:43 2004 Subject: Offtopic: Web Standards Project Message-ID: <3.0.32.19980810145436.00bd5bb0@207.34.179.21> At 05:48 PM 8/10/98 -0400, Steven Champeon wrote: >Does using a non-standard workaround for a bug in one's *markup* make a >desire for fully compliant *implementations* null and void? I don't think >it does. Steven and Murray are each entitled to their opinion. On top of which, as of this morning, the pages at the WSP site all start like so: and they validate. And if they don't that's a high-update-rate bug and they'll be fixed. And (I can say this since I had no input into their design) they look damn good too, on a wide variety of browsers. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Tue Aug 11 00:03:38 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:03:43 2004 Subject: Namespaces and XML validation In-Reply-To: <35CF7089.9A2A56A6@finetuning.com> References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> Message-ID: <3.0.3.32.19980810180256.0077de20@nexus.polaris.net> At 03:13 PM 8/10/98 -0700, Lisa Rein wrote: >peter murray rust wrote: >> As I have often >> (probably boringly) said, I think my community is far more interested in >> semantic than syntactic validity. (Actually they probably don't care about >> either much...) >How can you possibly have one without the other? If your syntax is >bogus -- you won't get far with semantics. How can you? Don't want to put words in his mouth, or his keyboard, but I think Peter's point was that his community -- chemists -- don't give a hoot whether >start< or are valid XML tags; all they care about is that (using this example) some provision is made for "starting." Peter himself seems to have a fine grasp of the interdependence between semantics and syntax. John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Veillard at w3.org Tue Aug 11 00:25:07 1998 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:03:44 2004 Subject: Schemas and Other Crucial XML Questions In-Reply-To: <2.2.32.19980810144357.01062c98@terminal.ontogenics.com>; from Dave Carlson on Mon, Aug 10, 1998 at 08:43:57AM -0600 References: <2.2.32.19980810144357.01062c98@terminal.ontogenics.com> Message-ID: <19980810182446.J27611@w3.org> > >There are, however, alternatives: for example, you could compile the > >XML to a compact binary format for internal storage then decompile it > >back to a verbose format for export -- there's no requirement to store > >it internally as text. > > It's important to note that an XML stream can be very highly compresses with > standard tools like WinZIP. I have an XML file that's about 20K size, which > includes many repititions of a small number of tags. WinZIP produced 97% > compression on this file! > > The standard Java library includes a zip utility class for zipping/unzipping > streams, so it's possible to dramatically reduce transmission bandwidth > while retaining long, descriptive tag names. A linux software database index encoded with RDF was reduced from 1.6 MBytes to a bit more of 150 KBytes using "gzip -9". Daniel -- Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks : Tel : +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html, Fax : +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Tue Aug 11 00:28:14 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:03:44 2004 Subject: Offtopic: Web Standards Project In-Reply-To: Message-ID: Just a quick note to ensure that everyone knows that anything I have said in this forum WRT the Web Standards Project should not necessarily be construed as a statement of an official policy or stance taken by the WSP. I do hope that nobody is discouraged from supporting the WSP by any statement of opinion I may have voiced here. I speak for myself, not for anyone else. Now, with that, I'll stop posting on this thread, which has already gone far afield of the core subject matter for the list. Apologies to Peter and everyone else. Steve -- http://a.jaundicedeye.com <-- rants and writings http://hesketh.com/schampeo/ <-- projects and info http://dhtml.hesketh.com <-- coming soon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From avirr at LanMinds.Com Tue Aug 11 00:35:34 1998 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:03:44 2004 Subject: Namespaces and XML validation In-Reply-To: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> References: <199808101927.MAA29339@mehitabel.eng.sun.com> Message-ID: At 9:41 PM -0700 8/10/98, Peter Murray-Rust wrote: >I think we are in the experimental phase of XML where we are asking the >wider world whether validation is valuable. To many established SGML people >the lack of validation is near heresy. [In the same way I suspect many >people couldn't envisage a useful OO language without multiple inheritance. >But Java works. Only very occasionally do I think "it would be nice to have >MI at this point". I suspect it will be the same for XML. As I have often >(probably boringly) said, I think my community is far more interested in >semantic than syntactic validity. (Actually they probably don't care about >either much...) I'm new to XML, so perhaps could be considered one of the "wider world", though I'm starting from a somewhat mundane use of it as a data interchange format creator. I think that validation is one of the major advantages of XML over other arbitrary formats. It allows other people to check their file structure and content locally and automatically, in their tool of choice, on their platform of choice. When I get a file from someone else, I can check to make sure it validates, rather than writing my own validation code for every format and every change to every format. This vastly reduces the likelyhood of confusion and mistakes, and is incredibly valuable for everyone concerned. I'm also deeply interested in how XML will change local and web-wide searching, and I think validation is important for that as well. Search indexes can process valid files in creative and powerful ways. Another optimist, I'm hoping that SGML is equivalent to C++ and XML is equivalent to Java: a sleeker and more focussed subset built from the hard experiences of the past. We could do without all the hype, though. Avi ________________________________________________________________ Avi Rappoport, Web Site Search Tools Maven Search Tools Consulting Site: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 01:22:20 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:44 2004 Subject: Check out the DCD submission Message-ID: <3.0.32.19980810162029.00a0c220@207.34.179.21> There's a new IBM/Microsoft submission at http://www.w3.org/Submission I'm a co-author. Here's the abstract: This document proposes a structural schema facility, Document Content Description (DCD), for specifying rules covering the structure and content of XML documents. The DCD proposal incorporates a subset of the XML-Data Submission [XML-Data] and expresses it in a way which is consistent with the ongoing W3C RDF (Resource Description Framework) [RDF] effort; in particular, DCD is an RDF vocabulary. DCD is intended to define document constraints in an XML syntax; these constraints may be used in the same fashion as traditional XML DTDs. DCD also provides additional properties, such as basic datatypes. I have lots of opinions about it, which can wait for Montreal now. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From epalma at fsaa.ulaval.ca Tue Aug 11 02:01:10 1998 From: epalma at fsaa.ulaval.ca (Eduardo Palma) Date: Mon Jun 7 17:03:44 2004 Subject: xml on the fly Message-ID: <199808110022.UAA17015@cerberus.ulaval.ca> ---------------------------------------------------------------------------- -- Hi guys, Here is my problem, I want to use the dso applet from microsoft to generate objects from Xml. That works fine with text files conteining Xml. Is not so clear when I genereate Xml from a database web connection. (web pages or text generated on the fly). Sombebody know this aspects? Thanks Eddie xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Aug 11 02:12:40 1998 From: wperry at fiduciary.com (W. E. Perry) Date: Mon Jun 7 17:03:44 2004 Subject: Namespaces and XML validation References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> <35CF7089.9A2A56A6@finetuning.com> Message-ID: <35CF8430.AA3A9530@fiduciary.com> Lisa Rein wrote: > peter murray rust wrote: > > > > > As I have often > > (probably boringly) said, I think my community is far more interested in > > semantic than syntactic validity. (Actually they probably don't care about > > either much...) > > How can you possibly have one without the other? If your syntax is > bogus -- you won't get far with semantics. How can you? > > Am I wrong? Somebody please set me straight. > > lisa rein I think that we have here the fundamental question of XML and, with it, the likeliest source of schism among us. XML is routinely introduced as a) the (infinitely) extensible markup language, based on the mechanical concept of well-formedness, on five hard-wired entities, and the three reserved characters ordered 'xml'; and also as b) a formal subset of ISO-standard SGML. The hope expressed with both of these formulations is that XML will be used to mark up meaning rather than presentation. Without terribly much extension, 'presentation' quickly comes to include syntactic forms, and there is a reasonable argument that the minimal definition in (a) is both as far as we should go in excluding presentation and as far as we can go while still retaining some substance to call XML. Charles Frankston's recent comments show us our choice: we can draw the line in defending the DTD as defined by XML 1.0 or we can admit that syntax is an aspect of presentation and that we are as likely to have as many different syntactic structures as style sheets to apply to the marked semantics of a given document. As this list, and the use of XML, have expanded to developers from a wider range of disciplines, new arrivals have brought from their particular experience different, and, finally, mutually exclusive, opinions of what are normal, desirable, or even permissible syntactic premises. Sticking only to text as the stuff of XML documents, we have already seen how differently the database people and the DOM people conceive the appropriate syntax for equivalent semantics. This schism was inherent in the seditious nature of XML as originally defined. By separating validity from WFness, XML implicitly offered the option of ignoring an author's DTD. It was always possible in XML, unlike SGML, to take a document 'on its own terms', even where that conflicted with the author's intent delineated in a DTD.It has from the first been only a matter of time until other schemas and processing paradigms routinely substituted their syntactic rules in the consumption of a document for those which might have constrained the author in its creation. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Tue Aug 11 02:33:17 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:03:44 2004 Subject: XSchema question Message-ID: <199808110030.RAA29421@boethius.eng.sun.com> [Marcus Carr:] | Lou Reynolds (former substantial shareholder in EBT (now | Inso)) left us with a great line when he was in Australia a | few years ago - "Another year and we'll all be drinking | champagne out of fire hoses". While I continue to believe | that this will be the case, it's hard to forget that it was | uttered by one who is no longer in the game ... :-) Ah, but Lou got his champagne: he sold EBT for a tidy sum and is now happily retired... Jon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Tue Aug 11 03:36:18 1998 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:03:44 2004 Subject: How to process Japanese Code with XMLDSO(MS-XML) Message-ID: Yes, it appears that Murata-san is correct. Note that the new MSXML.DLL that is available with the Developer Preview of IE5 supports both big and little endian UCS-2 encodings. -----Original Message----- From: MURATA Makoto [mailto:murata@apsdc.ksp.fujixerox.co.jp] Sent: Sunday, August 09, 1998 9:13 PM To: shamada@ssel.toshiba.co.jp Cc: xml-dev@ic.ac.uk Subject: Re: How to process Japanese Code with XMLDSO(MS-XML) Hamada wrote: > Do you mean that C++ MS-XML Parser enbedded in IE4 can't process support big > endian but UTF-16? It can't handle big endian UTF-16. Correct me if I am wrong. > Colleagues at Microsoft Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Tue Aug 11 03:46:51 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:47 2004 Subject: Offtopic: Web Standards Project References: <3.0.5.32.19980808120229.00885da0@postoffice.swbell.net> Message-ID: <35CFA20A.5696@hiwaay.net> W. Eliot Kimber wrote: > > It's definitely not clear from the > WSP Web site exactly what it *is* or what it plans to *do*. I'd like to > know more. They could work, as the VRML consortium and list members do, with NIST or some other legitimate and credible organization to create conformance test suites. It applies no force but it exposes a broken contract. Len Bullard Intergraph Public Safety xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 11 03:50:37 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:47 2004 Subject: Namespaces and XML validation Message-ID: Murray Altheim writes: >Unfortunately, I do not believe >compatibility with XML 1.0 validation is on the minds of all participants >and see a schism arising: XML 1.0 compatible, and XML-subset compatible. And Peter Murray-Rust writes: >Subset? Have to admit, I'm falling toward the subset camp. I talk a lot about 'simple XML', which is just the instance syntax without declarations of any kind except the XML one of course. I tried writing about the layer in between that and what I consider the 'meat' of validation, elements and attributes, and can't say I was happy, though I completed the exercise. I'll stick with XML 1.0 - all this time figuring out its quirks, and I'll still admit to liking it - but I can certainly understand why a lot of people could get along with just a subset. I'd have been a lot more comfortable with a three layer spec, for -instance syntax -structural declarations -minimization declarations But I can always pray for that next time around. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Tue Aug 11 03:55:46 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:47 2004 Subject: Offtopic: Web Standards Project References: <3.0.32.19980808113318.00a26100@207.34.179.21> Message-ID: <35CFA426.3D8E@hiwaay.net> Tim Bray wrote: > > Is > it worthwhile, at this point in history, trying to retroactively > save HTML? Real question. -Tim It is worthwhile: o To support an effort to create a standard for an object-framework that is componentized, incrementally extensible, and competitive at the level of the components o To support standard interfaces into this framework that ensure correct and testable property handling without requiring a reference implementation o To create a conformance test suite that enables developers to know with certainty the level(s) to which they conform to the framework and any data or procedural language it supports. o To create sample implementations for this framework which enable the core framework containers and components to be shared o To pick a set of core languages which are to be supported by all conforming implementations of the object framework Using your collective experience with HTML, XML, VRML, DOM, XSL, XLL, object-centric implementations with middleware standards, you can do this. Or you can work with Microsoft to complete its work toward that end. Len Bullard Intergraph Public Safety xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Tue Aug 11 04:05:36 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:03:47 2004 Subject: XSchema question References: <199808110030.RAA29421@boethius.eng.sun.com> Message-ID: <35CFA6AD.253D204C@allette.com.au> Jon Bosak wrote: > Ah, but Lou got his champagne: he sold EBT for a tidy sum and is now > happily retired... Hopefully we can all meet Lou and each other at the first annual 'Wealthy Former SGML/XMLers Confrence'. I'm proposing the Barrier Reef, but will of course be flexible... -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Tue Aug 11 04:29:19 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:49 2004 Subject: XSchema question References: <199808110030.RAA29421@boethius.eng.sun.com> <35CFA6AD.253D204C@allette.com.au> Message-ID: <35CFABF9.2DB3@hiwaay.net> Marcus Carr wrote: > > Jon Bosak wrote: > > > Ah, but Lou got his champagne: he sold EBT for a tidy sum and is now > > happily retired... I am reminded of stories of insider trading in which some retiring gentleman trumpeted overvalued stock just prior to cashing out. > Hopefully we can all meet Lou and each other at the first annual 'Wealthy Former > SGML/XMLers Confrence'. I'm proposing the Barrier Reef, but will of course be > flexible... As far as I know, you can hold that reunion in a rowboat and spell each other at the oars. SGML didn't make too many folks wealthy (I can think of three but one already had money.) XML might, but the tendancy these days is to make money on applications as the market for core technology is gutted. On the other hand, domain name trading turned profitable and I keep wondering when the rush to conquer and own namespaces will begin. In a document of interweaving hierarchies, it would be good to control the central threads. Copyright law applied to namespaces... hmm. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Tue Aug 11 05:07:31 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:03:49 2004 Subject: Namespaces and XML validation References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> Message-ID: <35CFB549.7A6CC7@allette.com.au> Peter Murray-Rust wrote: > I think we are in the experimental phase of XML where we are asking the > wider world whether validation is valuable. To many established SGML people > the lack of validation is near heresy. Not in all cases - a document written from a database is an obvious example of a one that you could accept with a fair degree of confidence, but of course this is due to the fact that a) some validation has been done by another application, and b) it is known that there are rigid and well defined boundaries, as might be the case with your data. I haven't looked at your DTD for a long time, but I assume that your structures are more regular than something like legislation, where you're forced to follow the convention of the drafters in order to avoid an unintentional change to the law (usually not a good thing). > As I have often > (probably boringly) said, I think my community is far more interested in > semantic than syntactic validity. I could see that being the case; within your community there is an implied understanding of the underlying structure - your DTD maps structures that exist in fact and have been learned by understanding the rules governing physics. With other areas of information though, I think this can be less so, so the requirement for and benefit obtained by validation is much more apparent. I feel it's more valid to frame questions such as "is validation valuable?" in a worst-case scenario - if you spend any time with legislation, you quickly realise that although there generally could be underlying common structures, the drafters often have not respected this fact. -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Tue Aug 11 05:33:56 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:03:49 2004 Subject: XSchema question Message-ID: <00a101bdc4d9$65ab14a0$95addccf@ix.netcom.com> >SGML didn't make too many >folks wealthy (I can think of three but one already had >money.) Engineers seldom get wealthy, but those that own them often do! I personally know the guy ( who is technologically brilliant, but a business incompetent) who owns the patents on one of the break through technologies in medicine, I can't tell you which or you would know who he is, (his royalties were signed off of course to his employer at the time.) His employers made tens of millions, possibly billions, and Stan? He is retired on a pitifully small pension. I take him out for a drink and a game of golf occasionally, and he's grateful. The poor b****ar can't even afford a new car! and we are talking about a technology that saved numerous lives, founded mega-corps, and made numerous shareholders rich. Without too much effort I'm sure that most of us can think of similar examples But you know what, he's happy. He did his thing, and I think that that, rather than $ is the driving force for most of us. Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com -----Original Message----- From: len bullard To: Marcus Carr Cc: Date: Monday, August 10, 1998 10:30 PM Subject: Re: XSchema question >Marcus Carr wrote: >> >> Jon Bosak wrote: >> >> > Ah, but Lou got his champagne: he sold EBT for a tidy sum and is now >> > happily retired... > >I am reminded of stories of insider trading in which some retiring >gentleman trumpeted overvalued stock just prior to cashing out. > >> Hopefully we can all meet Lou and each other at the first annual 'Wealthy Former >> SGML/XMLers Confrence'. I'm proposing the Barrier Reef, but will of course be >> flexible... > >As far as I know, you can hold that reunion in a rowboat and >spell each other at the oars. SGML didn't make too many >folks wealthy (I can think of three but one already had >money.) XML might, but the tendancy these days is to >make money on applications as the market for core technology >is gutted. > >On the other hand, domain name trading turned profitable and >I keep wondering when the rush to conquer and own namespaces >will begin. In a document of interweaving hierarchies, it >would be good to control the central threads. Copyright law >applied to namespaces... hmm. > >len > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 08:37:03 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:49 2004 Subject: Namespaces and XML validation In-Reply-To: <35CF7089.9A2A56A6@finetuning.com> References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980811065756.6c873ada@pop3.demon.co.uk> At 15:13 10/08/98 -0700, Lisa Rein wrote: >peter murray rust wrote: > >> >> As I have often >> (probably boringly) said, I think my community is far more interested in >> semantic than syntactic validity. (Actually they probably don't care about >> either much...) > > >How can you possibly have one without the other? If your syntax is >bogus -- you won't get far with semantics. How can you? I was probably being over-brief in my use of 'syntactic'. I meant that DTDs only validate the syntactic structure of the document. Obviously we shall insist on well-formed XML. Assume I have a content model: And a chemist now wishes to include additional information (electron count) in the molecule, e.g. 1 ... ... ... This breaks the content model. I have the following alternatives: - tell the author it's not allowed. Kills the whole idea of XML immediately. - produce and circulate a new DTD. Effectively impossible. It would be redefined so often as to cause chaos. - use ANY for all my content models (effectively scrapping content validation) use the DTD for a structural guide but not insist on validation. The DTD can still be used to help drive authoring tools, support software, etc. So my software tends to look like: Molecule.java: public void process() { Vector atomVector = this.getChildrenWithElementName(LOCAL, "Atom"); Vector bondVector = this.getChildrenWithElementName(LOCAL, "Bond"); } Note that this allows my to look for what I know to be there while accepting that other stuff isn't. For semantic validation I am far more concerned that an atom's atomic number is between 0 an 100 and is not "-23.7" or "Mickey Mouse". As you will agree, this is discipline-dependent but I expect to appeal beyond chemistry. HTH P. > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 08:37:10 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:49 2004 Subject: IMPORTANT (Re: XSchema question) In-Reply-To: <35CFABF9.2DB3@hiwaay.net> References: <199808110030.RAA29421@boethius.eng.sun.com> <35CFA6AD.253D204C@allette.com.au> Message-ID: <3.0.1.16.19980811071341.6c87fcae@pop3.demon.co.uk> At 21:27 10/08/98 -0500, len bullard wrote: [...] >> >> > Ah, but Lou got his champagne: he sold EBT for a tidy sum and is now >> > happily retired... > >I am reminded of stories of insider trading in which some retiring >gentleman trumpeted overvalued stock just prior to cashing out. > I am sure it was not meant this way, but please be absolutely scrupulous not to post things that could be misinterpreted and cause offence or be actionable.. We are a public mailing list, so this is a public utterance. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 08:37:10 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:49 2004 Subject: LISTRIVIA (was Re: XSchema question) In-Reply-To: <00a101bdc4d9$65ab14a0$95addccf@ix.netcom.com> Message-ID: <3.0.1.16.19980811071702.6b371a38@pop3.demon.co.uk> At 23:37 10/08/98 -0400, Frank Boumphrey wrote: >>SGML didn't make too many >>folks wealthy (I can think of three but one already had >>money.) > >Engineers seldom get wealthy, but those that own them often do! > > This is not really core XML-DEV business. [... unnecessary quoting of previous article and XML-DEV signature snipped ...] P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 08:37:17 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:49 2004 Subject: Offtopic: Web Standards Project In-Reply-To: References: Message-ID: <3.0.1.16.19980811070529.65ffb1e6@pop3.demon.co.uk> At 18:26 10/08/98 -0400, Steven Champeon wrote: > > >I speak for myself, not for anyone else. Now, with that, I'll stop >posting on this thread, which has already gone far afield of the core >subject matter for the list. Apologies to Peter and everyone else. No problem. I think you can assume that a large number of XML-DEVers support the idea of interoperability and that individuals or organisations may join you. Personally it looks a good idea. I think the relevance to XML will very much be: - can I transmit XML over the wire in a software independent manner? (e.g. I do not have to embed a processing instruction identifying the XML browser to be used). - can I embed XML in HTML and make sure that I can extract it precisely? - can I write xHTML (i.e. HTML in XML syntax) and have it cleanly and precisely processed. I suspect that we (as XML-DEV) would all say yes to these (and probably more that I haven't thought of.) You are welcome to link to this statement from your pages if it's useful :-) P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 08:37:24 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:49 2004 Subject: Namespaces and XML validation In-Reply-To: <35CF8430.AA3A9530@fiduciary.com> References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> <35CF7089.9A2A56A6@finetuning.com> Message-ID: <3.0.1.16.19980811073526.0bef9886@pop3.demon.co.uk> At 19:37 10/08/98 -0400, W. E. Perry wrote: [...] > >I think that we have here the fundamental question of XML and, with it, the >likeliest source of schism among us. XML is routinely introduced as > a) the (infinitely) extensible markup language, based on the mechanical >concept of well-formedness, on five hard-wired entities, and the three reserved >characters ordered 'xml'; > and also as > b) a formal subset of ISO-standard SGML. >The hope expressed with both of these formulations is that XML will be used to >mark up meaning rather than presentation. Without terribly much extension, >'presentation' quickly comes to include syntactic forms, and there is a >reasonable argument that the minimal definition in (a) is both as far as we >should go in excluding presentation and as far as we can go while still retaining >some substance to call XML. This encapsulates my views nicely. In fact I am in both camps. With CML (unlikely though it may seem) we have to have an extremely fluid DTD. That is because we don't understand chemistry. It was put well by Democritos "Nothing exists except atoms and empty space - all else is opinion". The Chemical Bond is simply an opinion and people fight about it just as much as over XML matters. So CML is increasingly becoming very sparse (atoms, bond and electrons, with a bit of geometry). That allows authors free expression. OTOH for a pharma company producing a compound registry validation is critical and I would support it. I am increasingly doing work in XML for healthcare and in that area validation is critical. I am constructing documents which may be included in the regulatory process and this will be DTD-driven. My guess is that I shall use a flexible componentised DTD for the initial design of a document - in that way it can be done quickly and revised in real-time. When the client comes to sign it off it can be transformed into a really rigid tool if required. I am sure that we shall not create a schism in the religious sense of the world. It's possible that some tools may be WF-centric and others DTD-centric. Hopefully many will do both. We could make a start (as we have already discussed) about giving precise instructions to parsers. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 10:20:47 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:50 2004 Subject: Check out the DCD submission In-Reply-To: <3.0.32.19980810162029.00a0c220@207.34.179.21> Message-ID: <3.0.1.16.19980811092150.6c87a34a@pop3.demon.co.uk> At 16:20 10/08/98 -0700, Tim Bray wrote: >There's a new IBM/Microsoft submission at > > http://www.w3.org/Submission I assume this is the same document as at: http://www.w3.org/TR/NOTE-dcd My comments are directed to the latter. > fashion as traditional XML DTDs. DCD also provides additional properties, > such as basic datatypes. I am primarily concerned with the basic datatypes section 4. I want to use these (or something like them) in CML, healthcare and so on. I shall extract this subset of the document and re-use the concepts in JUMBO2. (Having spent many years weaning myself off FORTRAN, I'm not very excited by section 4.3 (COBOL pictures) and shan't implement them, but I assume they meet mainstream database longings. They look awfully like bolting presentation/formatting into XML which we are told is a Bad Thing. Shouldn't this be a stylesheet issue?) I note that max and min have changed from being content to attributes. I just re-tooled to be XML-data-compatible ( and as children of the element. I used to write my variables like: 1.8 but found that things like units were too rich to be a simple attribute. So I moved, XML-data-like, to having them all as children. I am not convinced they should be attributes. Pro: they are defaulted in the schema they don't appear in the tree Con: they can't (easily) be tailored for each instance because they don't occur in the document (unless I have the schema mechanism wrong) they can't be qualified (e.g. 1.2 > >I have lots of opinions about it, which can wait for Montreal now. -Tim We'd be delighted if you feel inspired to answer any queries before then... P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Tue Aug 11 10:46:02 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:50 2004 Subject: XSA proposal In-Reply-To: <000701bdc3e2$0d9c1540$dc6118cb@caleb> References: <3.0.1.32.19980807102759.00cf8480@ifi.uio.no> Message-ID: <3.0.1.32.19980811104233.007255f4@ifi.uio.no> * James K. Tauber > >It occurs to me (despite our early discussions, Lars) that we could use >architectural forms---namely to link XSA and OSD. That is, by making XSA an >AF of OSD. I've been thinking along the same lines. Even if we don't go that far (which I'm not sure makes sense) it should be possible to use OSD documents for XSA purposes. At the very least the XSA SDK should be able to extract the relevant data from OSD documents. I'll look into this and come back with an amended proposal. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Aug 11 12:04:53 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:50 2004 Subject: Namespaces and XML validation References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> Message-ID: <35D018E5.446E07E@mecomnet.de> the assertion below re validation appears here time and again. this forum has, however, yet to bear witness to such a demonstration. Peter Murray-Rust wrote: > > At 12:27 10/08/98 -0700, Murray Altheim wrote: > [...] > > > >Peter, > > > > >over the working group archives to see that compatibility is not a given. > > These are not generally available... would someone be so kind as to edit the appropriate contributions to the working group archive to make them available for public consumption. > > >In all but trivial DTDs namespaces have been shown to be incompatible with > >XML 1.0 validation (or at very least more manual effort than would be > >worth the trouble*). The solution for validating moderately complex > >structures using qualified names without wholescale rewriting of existing > >DTDs has not yet been found. It is a given that any such alternative please give examples of the cases which cannot be validated. > >validation solution would be inherently incompatible with existing the > >validation methodology (ie., the SGML-compatible declaration syntax in > >XML 1.0). this may be true (wrt. the methodology, not the syntax), but, in the long run, that does not matter. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From byrnes at prl.research.philips.com Tue Aug 11 12:12:26 1998 From: byrnes at prl.research.philips.com (Nigel Byrnes) Date: Mon Jun 7 17:03:50 2004 Subject: Developer Course Message-ID: <35D01916.BD7CD67C@prl.research.philips.com> Hi As an xml newbie, I am looking to ramp up my xml knowledge and skills fast. I am aware of the xml developers workshop happening in Montreal later this month, but do you guys know of any other courses/tutorials which are more focused on developing/processing xml content (rather than introducing the envelope of what xml is capable of)? thanks nigel xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 13:57:56 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:50 2004 Subject: Developer Course In-Reply-To: <35D01916.BD7CD67C@prl.research.philips.com> Message-ID: <3.0.1.16.19980811125933.0ecf0f04@pop3.demon.co.uk> At 11:12 11/08/98 +0100, Nigel Byrnes wrote: >Hi > >As an xml newbie, I am looking to ramp up my xml knowledge and >skills fast. I am aware of the xml developers workshop happening >in Montreal later this month, but do you guys know of any other >courses/tutorials which are more focused on >developing/processing xml content (rather than introducing the >envelope of what xml is capable of)? This is an important area. I'd suggest looking at: - the tutorials appended (or prepended) to GCA meetings. There are several parallel sessions normally spread over a two-day period and over a wider range of material (not just XML) - try SGML University (haven't got the URL - try www.sil.org/sgml/xml.html) - try OASIS - the XML vendor/user association - was SGML Open (again look on sil.org for URL) Also we in Nottingham are developing XML training and materials. We have already run a virtual course on Java/XML (see http://www.vsms.nottingham.ac.uk) last year and would certainly resurrect it if there were demand. Since it will be modular we can configure it for different needs - it would proably be aimed at structured content rather than intricacies of textual rendering. And we are starting to run real-life seminars (at present UK) by invitation - see for example... http://www.netproject.com/netproject_pages/new_schedule.htm P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 13:59:35 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:50 2004 Subject: Availability of WG and SIG archives (was Re: Namespaces and XML validation) In-Reply-To: <35D018E5.446E07E@mecomnet.de> References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980811130033.0ecfd9a2@pop3.demon.co.uk> At 12:11 11/08/98 +0200, james anderson wrote: >would someone be so kind as to edit the appropriate contributions to the >working group archive to make them available for public consumption. [There are two issues here: - making available - editing The second is an enormous labour - e.g., close observers will note that I haven't found time for several months to edit XML-Jewels. There are several possible actions: - sanitising (i.e. taking out any thing that cannot appear in public) - normalising (i.e. removing redundant material) - annotating etc.] I have considerable sympathy with this request and suggest that if anyone on the WG reads this, they might consider pressing this inside the W3C. There are two independent archives: XML-SIG, contributed to by ca 100 invited experts including me. The SIG archive has been made available at intervals - I don't know whether there is an automatic policy. XML-WG, of about 12 members and invited experts. XML-SIG members can read the XML-WG lists and are occasionally encouraged to do so because matters are initiated there. I have the following reasons for suggesting publishing: - it saves going over existing ground. Thus the XML-SIG spent probably 2000 emails on namespaces and the discussion was of extremely high quality. It would be inappropriate to relive it all again here (although parts of it might spark of relevant discussion). I would hope that it could be published after a month or two delay. - it is a historical archive. This is extremely important to me (and to henryR). In XML we are building the railways of the 21st century and it would be a historical disaster if records were lost. It's quite possible that our e-mail discussion of 1998 will appear just as fascinating in the long-term future as the blueprints, letters and equipment of the early railways do to us. It is at least partly for the latter reason that HenryR and I try to keep some constraints on how the material appears on XML-DEV (i.e. useful thread titles, normalised contributions, clarity, etc.) Do not underestimate how quickly information decays - HenryR tells us that the early use of the Chemical Internet is now largely lost irretrievably. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Tue Aug 11 14:53:30 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:50 2004 Subject: Offtopic: Web Standards Project In-Reply-To: Steven Champeon's message of "Sat, 8 Aug 1998 19:18:29 -0400 (EDT)" References: Message-ID: Steven> Steven Champeon 0> In article , 0> Steven wrote: Steven> I mean, %$#!@, most of the suits I've worked for didn't Steven> know what 8-bit ASCII was, ... Well, I'm sure there would be plenty here who'd like to know. ASCII is a 7-bit character coding scheme - nothing more, nothing less. The term "8-bit ASCII" could be used to refer to any of a number of 8-bit codes which coincide with ASCII for values under 128: ISO-8859-1, ISO-8859-2, ..., ISO-8859-9, ISO-2022-JP (I think), the Windows and Macintosh character sets, and others. [BTW, when using US-ASCII as an entity character encoding, must one declare it as UTF-8, and use other means to ensure that multi-byte characters don't occur?] -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 15:51:59 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:50 2004 Subject: Availability of WG and SIG archives (was Re: Namespaces and XML validation) References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> <3.0.1.16.19980811130033.0ecfd9a2@pop3.demon.co.uk> Message-ID: <35D04E59.DF902CE0@mecomnet.de> Peter Murray-Rust wrote: > > At 12:11 11/08/98 +0200, james anderson wrote: > > I have considerable sympathy with this request and suggest that if anyone > on the WG reads this, they might consider pressing this inside the W3C. sympathy is nice (thank you) - i'm more concerned with the legitimacy and quality of the arguments in this forum and with the quality of the software which i produce. of which the latter depends to some extent (at least wrt. xml) on the former. thus my tenacity. i am at a point where, should the present namespace wd eventually be ratified, it would leave me no option, but to produce non-conforming software, if said software is to function adequately. not because i am at odds with the drafts goals, and not because there are inherent inadequacies in either namespaces or dtd's, but because the present draft describes an encoding and suggests implementation mechanisms which are incomplete wrt its own stated goals. furthermore, for reasons which i cannot fathom, the draft simply stops short of providing the basis for what would be sufficient mechanisms. (the initial questions are up on xml-names-issues) XSchema's, XML-Data, and Document Content Descriptions may well provide features additional to XML/DTD encoding at some point in the future. since, however, the respective proposals either do not, at least in their present versions, provide adequate support for the particular problem of disambiguating names, or depend on the support of the base xml encoding, i do not believe the arguments, to wait for these successors. it is necessary to handle "name identity" in the encoding - that is in XML itself. my experience is that it is also possible. if this is not true, could someone please explain why it is not. if this has already been hashed out in the mythical 2000 messages, then please just put them on the net. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Tue Aug 11 16:01:23 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:03:50 2004 Subject: Offtopic: Web Standards Project In-Reply-To: Toby Speight's message of 11 Aug 1998 13:55:26 +0100 Message-ID: <199808111401.PAA13797@cogsci.ed.ac.uk> > [BTW, when using US-ASCII as an entity character encoding, must one > declare it as UTF-8, and use other means to ensure that multi-byte > characters don't occur?] You don't *have* to declare it at all, since UTF-8 is the default. If you do declare it, you can use any of the ascii supersets you mention, but only UTF-8 is required to be recognised. For English documents you might also use ISO-8859-1, on the grounds that it's quite common to find apparently ascii documents that have been enlivened with a soupçon of other western European languages. You *could* declare it to be US-ASCII, which is an IANA-registered name, but I wouldn't count on many processors recognising it. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 11 16:36:33 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:50 2004 Subject: Namespaces and XML validation References: <5030300023900581000002L012*@MHS> Message-ID: <35D056D9.A5AC2B48@locke.ccil.org> Dean Roddey wrote: > The other possible model, is that of Java. Java's model is basically like the > "Use the whole URI" method, which is obviously yucky give the syntax of URIs. But note that Java uses the model of the old draft: all minimization declarations ("import" statements in Java jargon) must appear at the beginning, and are global to the 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 17:03:37 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:50 2004 Subject: Availability of WG and SIG archives (was Re: Namespaces and XML validation) In-Reply-To: <35D04E59.DF902CE0@mecomnet.de> References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> <3.0.1.16.19980811130033.0ecfd9a2@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980811160519.74bfc432@pop3.demon.co.uk> At 15:59 11/08/98 +0200, james anderson wrote: >Peter Murray-Rust wrote: >> >> At 12:11 11/08/98 +0200, james anderson wrote: >> >> I have considerable sympathy with this request and suggest that if anyone >> on the WG reads this, they might consider pressing this inside the W3C. > >sympathy is nice (thank you) - i'm more concerned with the legitimacy and >quality of the arguments in this forum and with the quality of the software >which i produce. of which the latter depends to some extent (at least wrt. >xml) on the former. thus my tenacity. To make it clear - I have no power other than that of the plebs. (i.e. I cannot release the material). I have been very conscious of the fact that many people of this list have offered services to the XML community and have done this without full knowledge of the namespace arguments. I think they have shown remarkable discipline. I agree it makes it difficult to have a full discussion if people cannot be made aware of previous arguments. I am conscious that having offered the services of this list for help with namespace implementation there are these potential constraints to finding innovative solutions. > >i am at a point where, should the present namespace wd eventually be ratified, >it would leave me no option, but to produce non-conforming software, if said >software is to function adequately. not because i am at odds with the drafts >goals, and not because there are inherent inadequacies in either namespaces or >dtd's, but because the present draft describes an encoding and suggests >implementation mechanisms which are incomplete wrt its own stated goals. My own view (which I stated to the SIG) was that the goals weren't clear enough. Unlike many other drafts there are no 10 golden rules against which to measure the draft. >furthermore, for reasons which i cannot fathom, the draft simply stops short >of providing the basis for what would be sufficient mechanisms. (the initial >questions are up on xml-names-issues) Thanks. I hope you get some feedback. > >XSchema's, XML-Data, and Document Content Descriptions may well provide >features additional to XML/DTD encoding at some point in the future. since, >however, the respective proposals either do not, at least in their present >versions, provide adequate support for the particular problem of >disambiguating names, or depend on the support of the base xml encoding, i do >not believe the arguments, to wait for these successors. I have no background on XML-Data and DCD, but XSchema people only got news of 1998-08-02 on that date and I think they have done incredibly well to reconfigure. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 17:06:11 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:50 2004 Subject: Availability of WG and SIG archives (was Re: Namespaces and XML validation) In-Reply-To: <35D04E59.DF902CE0@mecomnet.de> References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> <3.0.1.16.19980811130033.0ecfd9a2@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980811160519.0d07b77a@pop3.demon.co.uk> At 15:59 11/08/98 +0200, james anderson wrote: >Peter Murray-Rust wrote: >> >> At 12:11 11/08/98 +0200, james anderson wrote: >> >> I have considerable sympathy with this request and suggest that if anyone >> on the WG reads this, they might consider pressing this inside the W3C. > >sympathy is nice (thank you) - i'm more concerned with the legitimacy and >quality of the arguments in this forum and with the quality of the software >which i produce. of which the latter depends to some extent (at least wrt. >xml) on the former. thus my tenacity. To make it clear - I have no power other than that of the plebs. (i.e. I cannot release the material). I have been very conscious of the fact that many people of this list have offered services to the XML community and have done this without full knowledge of the namespace arguments. I think they have shown remarkable discipline. I agree it makes it difficult to have a full discussion if people cannot be made aware of previous arguments. I am conscious that having offered the services of this list for help with namespace implementation there are these potential constraints to finding innovative solutions. > >i am at a point where, should the present namespace wd eventually be ratified, >it would leave me no option, but to produce non-conforming software, if said >software is to function adequately. not because i am at odds with the drafts >goals, and not because there are inherent inadequacies in either namespaces or >dtd's, but because the present draft describes an encoding and suggests >implementation mechanisms which are incomplete wrt its own stated goals. My own view (which I stated to the SIG) was that the goals weren't clear enough. Unlike many other drafts there are no 10 golden rules against which to measure the draft. >furthermore, for reasons which i cannot fathom, the draft simply stops short >of providing the basis for what would be sufficient mechanisms. (the initial >questions are up on xml-names-issues) Thanks. I hope you get some feedback. > >XSchema's, XML-Data, and Document Content Descriptions may well provide >features additional to XML/DTD encoding at some point in the future. since, >however, the respective proposals either do not, at least in their present >versions, provide adequate support for the particular problem of >disambiguating names, or depend on the support of the base xml encoding, i do >not believe the arguments, to wait for these successors. I have no background on XML-Data and DCD, but XSchema people only got news of 1998-08-02 on that date and I think they have done incredibly well to reconfigure. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Tue Aug 11 17:44:27 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:03:51 2004 Subject: Offtopic: Web Standards Project In-Reply-To: Message-ID: On 11 Aug 1998, Toby Speight wrote: > Steven> I mean, %$#!@, most of the suits I've worked for didn't > Steven> know what 8-bit ASCII was, ... > > Well, I'm sure there would be plenty here who'd like to know. ASCII > is a 7-bit character coding scheme - nothing more, nothing less. The > term "8-bit ASCII" could be used to refer to any of a number of 8-bit > codes which coincide with ASCII for values under 128: ISO-8859-1, > ISO-8859-2, ..., ISO-8859-9, ISO-2022-JP (I think), the Windows and > Macintosh character sets, and others. Forgive me for using the vulgate. -- http://a.jaundicedeye.com <-- rants and writings http://hesketh.com/schampeo/ <-- projects and info http://dhtml.hesketh.com <-- coming soon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 18:10:06 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:51 2004 Subject: Offtopic: Web Standards Project References: Message-ID: <35D06CA5.8A8C7F0E@locke.ccil.org> Toby Speight wrote: > Well, I'm sure there would be plenty here who'd like to know. ASCII > is a 7-bit character coding scheme - nothing more, nothing less. The > term "8-bit ASCII" could be used to refer to any of a number of 8-bit > codes which coincide with ASCII for values under 128: ISO-8859-1, > ISO-8859-2, ..., ISO-8859-9, ISO-2022-JP (I think), the Windows and > Macintosh character sets, and others. ISO/IEC 8859-1 is, or was, reimplemented as an American National Standard under the title "8-bit American Standard Code for Information Interchange", i.e. "8-bit ASCII". (I can't find this in the current ANSI catalog, so it may have been revoked in favor of 8859-1.) However, this has nothing to do with the charset name "US-ASCII", which refers only to 7-bit ISO/IEC 646:1991, which is the same as 7-bit ASCII, ANSI X3.4. > [BTW, when using US-ASCII as an entity character encoding, must one > declare it as UTF-8, and use other means to ensure that multi-byte > characters don't occur?] No, you can declare it as "US-ASCII". In theory, parsers may throw a fatal error because they don't support that encoding. In practice, no parser is at all likely to do so. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Aug 11 18:26:33 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:51 2004 Subject: Check out the DCD submission Message-ID: <3.0.32.19980811092524.00c25240@207.34.179.21> At 09:21 AM 8/11/98, Peter Murray-Rust wrote: >I am primarily concerned with the basic datatypes section 4. I want to use >these (or something like them) in CML, healthcare and so on. I shall >extract this subset of the document and re-use the concepts in JUMBO2. Not now! Everyone agrees that we need datatypes. I expect some cheerful & constructive bloodletting in the SIG & WG as to which set of datatypes we need. Anybody who invests effort in that set at this time is spinning wheels. On the other hand, bearing what you say in mind, I think there may be a sane case to be made for decoupling the task of identifying the set of datatypes from that of defining the rest of the schema mechanics; however we end up specifying the datatypes, the heavy typechecking coding will be about the same, and it might be nice to give that a head-start. >I note that max and min have changed from being content to attributes. No! Read the early part of the spec. Per RDF, these things are *properties*, which can be given either as elements or attributes. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Aug 11 18:34:23 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:51 2004 Subject: Availability of WG and SIG archives (was Re: Namespaces and XML validation) References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> <3.0.1.16.19980811130033.0ecfd9a2@pop3.demon.co.uk> <3.0.1.16.19980811160519.74bfc432@pop3.demon.co.uk> Message-ID: <35D07459.6A98F1B0@mecomnet.de> Peter Murray-Rust wrote: > >... > > > >i am at a point where, should the present namespace wd eventually be > ratified, > >it would leave me no option, but to produce non-conforming software, if said > >software is to function adequately. not because i am at odds with the drafts > >goals, and not because there are inherent inadequacies in either > namespaces or > >dtd's, but because the present draft describes an encoding and suggests > >implementation mechanisms which are incomplete wrt its own stated goals. > > My own view (which I stated to the SIG) was that the goals weren't clear > enough. Unlike many other drafts there are no 10 golden rules against which > to measure the draft. i have been taking the second and third sentences in the section on "motivation and summary" at face value. they read "... documents, [which contain] markup from multiple independent sources, pose problems of recognition and collision. Software modules need to be able to recognize the markup (tags and attributes) which they are designed to process, even in the face of "collisions" occurring when markup intended for some other software package uses the same element type or attribute name. These considerations require that document constructs should have names, whose scope extends beyond the containing document. this specification describes a mechanism, XML namespaces, which accomplishes this." i may quibble with the wording, and i may differ with the authors, in that it would greatly simplfy processing if one recognized that the same problem applies to entites, notations, etc, but i understand this to be a clear and unequivocal the goal - even in the absence of golden rules. i'm not talking about inheritance - of attributes (per se) or of type, or about architectural forms, or about typing attribute values or element content. just about decoding and encoding names unambiguously. i'm directing attention to the fact, that the present draft suggests encodings and mechanisms which are not sufficient to accomplish this, its own correct and achievable goal. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 19:18:08 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:51 2004 Subject: Error in WD-DOM-19980720: Notation has no nodeType value Message-ID: <35D07CB6.F12BFC52@locke.ccil.org> Although Notation is a subinterface of Node, there is no nodeType value to represent a Notation within Node. I propose the obvious: within interface Node, add: const unsigned short NOTATION = 12; -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lauren at sqwest.bc.ca Tue Aug 11 19:26:00 1998 From: lauren at sqwest.bc.ca (Lauren Wood) Date: Mon Jun 7 17:03:51 2004 Subject: Error in WD-DOM-19980720: Notation has no nodeType value In-Reply-To: <35D07CB6.F12BFC52@locke.ccil.org> Message-ID: <199808111725.KAA20930@sqwest.bc.ca> At 11/08/98 10:17 AM , John Cowan wrote: >Although Notation is a subinterface of Node, there is no >nodeType value to represent a Notation within Node. > >I propose the obvious: within interface Node, add: > > const unsigned short NOTATION = 12; This fix will be in the next version of the DOM spec. Might I suggest you join the public DOM mailing list? To subscribe, send email to www-dom-request@w3.org with the subject "subscribe"; to send email to that list, send it to www-dom@w3.org. This way, we don't overwhelm xml-dev. thanks, Lauren xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dgd at cs.bu.edu Tue Aug 11 19:29:04 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:03:51 2004 Subject: Namespaces and XML validation In-Reply-To: <35D056D9.A5AC2B48@locke.ccil.org> References: <5030300023900581000002L012*@MHS> Message-ID: At 10:36 AM -0400 8/11/98, John Cowan wrote: >But note that Java uses the model of the old draft: all minimization >declarations ("import" statements in Java jargon) must appear at the >beginning, and are global to the document. The equivalent to this policy for XML would be for the "minimization declarations" to be local to the _entity_. This idea was discussed, but found lacking. The equivalent to the old mechanism would be if a declaration in one storage unit (Java file) could affect code in other storage units (Java files). In XML, under the original proposal, the root entity was privileged and the only one that could declare prefixes; no way was provided to prevent those prefixes from colliding with prefixes in other external entities. A Java file isn't a complete Java program, any more than an XML entity is a complete document. Careful consideration of the implications of adopting entity-based scoping led to the conclusion that it's more confusing, and harder to implement on top of things like SAX. Local declarations _allow_ the avoidance of prefix conflicts without _requiring_ any problems in validation. There's a tradeoff to be made. One can even keep validation and local declarations, if say, a particular element (say ) is always intended to hold information in a particular namespace. The element could have a #FIXED declaration in the DTD (or internal subset) and still validate just fine. Global declarations can still cause problems with validation, but _don't_ provide any way to manage prefixes to avoid collisions, especially in the case where validation is not an issue. The level of effort required for validation is higher, and it's certainly not the case that namespaces will _allow_ lots of incorrect _valid_ documents. They may make some "correct" documents invalid, but that was always a potential problem with namespaces, especially when used as an instance-fragment combining mechanism. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Aug 11 19:31:34 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:51 2004 Subject: Availability of WG and SIG archives (was Re: Namespaces and XML validation) Message-ID: <3.0.32.19980811102939.00c35ec0@207.34.179.21> At 06:42 PM 8/11/98 +0200, james anderson wrote: >i'm directing attention to the fact, that the present draft suggests encodings >and mechanisms which are not sufficient to accomplish this, its own correct >and achievable goal. Although I read this mailing list pretty regularly, I missed the posting in which you demonstrated that this was the case. I suspect others may have, as well. Could you post a pointer into the hypermail archive to the message where you argued this? -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Tue Aug 11 19:34:44 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:51 2004 Subject: Schemas and Other Crucial XML Questions Message-ID: <5030300023940327000002L072*@MHS> >XML-Data is a note that was submitted to the W3C by Microsoft and a >couple of partners -- it has no official status (a W3C "Note" means >roughly "here's a neat idea from one of our members"). > >XML 1.0 DTDs and proposed replacements/enhancements such as >Microsoft's XML-Data and XML-Dev's XSchema perform three distinct >roles: Although now IBM, MS, and Tim B. have submitted the DCD proposal, which I believe supersedes MS' proposed XML-Data spec. DCD is kind of a mixture of XML-Data and RDF schemes. Since IBM, MS, and Tim are behind it, it probably stands a good chance of making it I would think. The proposed schema has been accepted and posted on the W3C site today I think. Everyone should check it out and comment. ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Aug 11 19:42:23 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:51 2004 Subject: Schemas and Other Crucial XML Questions Message-ID: <3.0.32.19980811104107.00c2e480@207.34.179.21> At 01:39 PM 8/11/98 -0400, Dean Roddey wrote: >Although now IBM, MS, and Tim B. have submitted the DCD proposal... ... >The proposed schema has been accepted and posted on the W3C site today I think. Be careful: "accepted" doesn't mean anything other than the W3C acknowledging its existence. DCD has no more official status than any other allegedly-bright idea from anybody. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Aug 11 19:46:57 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:52 2004 Subject: Java class != XML entity In-Reply-To: References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> Message-ID: <199808111745.NAA00926@unready.megginson.com> David G. Durand writes: [writing about scoping in Java classes] > The equivalent to this policy for XML would be for the "minimization > declarations" to be local to the _entity_. Reasonable people may disagree: many of us believe (from SGML experience, especially) that entities are simply slightly-constrained storage units with no other special significance -- if Java had #include files, then those would be the equivalents of XML entities. As far as I may be allowed to compare tropical and temperate tree fruit, the equivalent of a Java class is a complete XML document. The problem is that we don't have a good name for a collection of XML documents working tightly together, the way that a collection of Java classes can work in an applet or application -- "web" seems too loose, and "docuverse" seems too New-Age. Any suggestions? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Tue Aug 11 20:04:43 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:03:52 2004 Subject: Java class != XML entity Message-ID: <3.0.32.19980811135924.00697480@polaris.net> At 01:45 PM 8/11/98 -0400, David Megginson wrote: >The problem is that we don't have a good name for a collection of XML >documents working tightly together, the way that a collection of Java >classes can work in an applet or application -- "web" seems too loose, >and "docuverse" seems too New-Age. Any suggestions? "Forest"? John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 11 20:13:10 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:52 2004 Subject: John Cowan's view on SAX extensions for ns drafts Message-ID: <35D08996.1C9AB67F@locke.ccil.org> Since I can't be at Montreal, here's my (lengthy, but hopefully complete) proposal for extending SAX 1.0. My design goals are: o Supports current ns draft o Conceptually compatible with David Megginson's XML-Dev message of 8 August o Equally useful for integral or layered implementations o Fully backward compatible with SAX 1.0 1. A new optional application-side interface to allow applications to intercept, record, and decode namespace scope events: public interface NamespaceHandler { public void startNamespaceScope (String prefix, String URI, NamespaceResolver resolver); public void endNamespaceScope (String prefix); } The startNamespaceScope event is called when a namespace comes into scope, and the endNamespaceScope event when the namespace goes out of scope. The NamespaceResolver objects passed in distinct calls to startNamespaceScope may or may not be distinct objects. Multiple namespace scopes may be declared by a single element. The order of events is: DocumentHandler.startElement, NamespaceHandler.startNamespaceScope (may be repeated), [events within scope] NamespaceHandler.endNamespaceScope (may be repeated), DocumentHandler.endElement. It is an error if the URI is the null string and prefix is *not* the null string. 2. A new standard SAX class (not an interface) for representing UniversalNames: public class UniversalName { private String _URI; private String _localPart; public UniversalName(String URI, String localPart) { _URI = URI; _localPart = localPart; } public String getURI () {return _URI;} public String getLocalPart () {return _localPart;} public long hashCode () { return _URI.hashCode() ^ _localPart.hashCode(); } public boolean equals (Object object) { if (object instanceof UniversalName) { UniversalName other = (UniversalName) object; return _URI.equals(other._URI) && _localPart.equals(other._localPart); } else return false; } } This is a class so that it can have a standard constructor. Either parsers or applications can create UniversalName objects. 3. A new optional parser-side interface for resolving qualified names: public interface NamespaceResolver { public static final String INTERNAL_XML_URI = "x-xml:xml"; public static final String INTERNAL_XMLNS_URI = "x-xml:xmlns"; public void setNamespaceHandler (NamespaceHandler handler); public UniversalName resolveElementName (String name) throws SAXException; public UniversalName resolveAttributeName (String name, UniversalName elementName) throws SAXException; public String getType (AttributeList attlist, UniversalName name); public String getValue (AttributeList attlist, UniversalName name); } To declare an interest in namespaces, an application implements NamespaceHandler and calls NamespaceResolver.setNamespaceHandler. By convention, a parser implements NamespaceResolver if and only if it is namespace-aware. (This does not necessarily mean that the NamespaceResolver objects passed to the NamespaceHandler are == to the parser object.) NamespaceResolver objects are valid from the time NamespaceHandler.startNamespaceScope is called until the matching call to NamespaceHandler.endNamespaceScope. Applications can resolve an element name passed to DocumentHandler.{start,end}Element into universal form by calling resolveElementName. If there is no prefix, the resulting UniversalName has an URI that is null. Applications can resolve an attribute name retrieved from AttributeList.getName into universal form by calling resolveAttributeName. The UniversalName of the element to which this attribute belongs is required so that the URI can be defaulted from the element if there is no prefix on the attribute. If a prefix is "xml" or "xmlns", and there has been no definition of these prefixes, then the URI is == to INTERNAL_XML_URI or INTERNAL_XMLNS_URI respectively. A SAXException is thrown if the prefix is otherwise undefined. The getType and getValue methods are convenience methods that allow an application to search a currently available AttributeList object using a UniversalName. Comments? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Tue Aug 11 20:30:18 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:52 2004 Subject: Java class != XML entity In-Reply-To: Your message of "Tue, 11 Aug 1998 13:45:51 EDT." <199808111745.NAA00926@unready.megginson.com> Message-ID: <199808111827.UAA03602@chimay.loria.fr> "David G. Durand" dgd@cs.bu.edu said: ] The equivalent to this policy for XML would be for the "minimization ] declarations" to be local to the _entity_. This idea was discussed, ] but found lacking. The equivalent to the old mechanism would be if a ] declaration in one storage unit (Java file) could affect code in other ] storage units (Java files). In XML, under the original proposal, the ] root entity was privileged and the only one that could declare ] prefixes; no way was provided to prevent those prefixes from colliding ] with prefixes in other external entities. Hmm and what about Element, Attribute and even Entity declarations within an external subset DTD? (i've got in mind the pizza model of the TEI DTD). The XML REC says that "If the same entity is declared more than once, the first declaration encountered is binding;" (4.2 Entity Declarations). Why can't we make the same kind of binding for NS prefixes ? "David Megginson" david@megginson.com said: ] Reasonable people may disagree: many of us believe (from SGML ] experience, especially) that entities are simply slightly-constrained ] storage units with no other special significance -- if Java had ] #include files, then those would be the equivalents of XML entities. I fully agree with you: "An XML document is an XML document !" I quote Lou Burnard who used to say that "an SGML document is an SGML document" talking about entities and document fragments in SGML. A Bient?t ! Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Philippe.Le_Hegaret at sophia.inria.fr Tue Aug 11 20:59:55 1998 From: Philippe.Le_Hegaret at sophia.inria.fr (Philippe Le Hégaret) Date: Mon Jun 7 17:03:52 2004 Subject: SAX and Emacs: validate XML documents. Message-ID: <35D0949F.463AE2F1@sophia.inria.fr> I made a little mode to validate XML documents with SAX in Emacs. This modes uses psgml-1.0.1 and font-lock. Try the package at this URI : ftp://koala.inria.fr/pub/plh/sxml-mode.zip or see the online documentation : http://www.inria.fr/koala/plh/sxml.html Regards, Philippe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 21:16:00 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:52 2004 Subject: Availability of WG and SIG archives (was Re: Namespaces and XML validation) References: <3.0.32.19980811102939.00c35ec0@207.34.179.21> Message-ID: <35D09A3B.D1AE7636@mecomnet.de> i had posted a note towards the end of last week with a pointer to a series of notes to xml-names-issues. (http://lists.w3.org/Archives/Public/xml-names-issues/1998JulSep/0007.html) i've held off cross-posting them here, but trust that mr murray-rust will forgive the transgression. that said - to paraphrase my original clarification request: there follow several postings which pose questions. i had endeavored to determine the answers by reading the document, but (in particular with regard to issues I through IV) had not arrived at answers sufficient to permit me to implement conforming support in an xml processor. the notes themselves contain pointers to additional messages with further illustrations. i posed five requests for further information. i am posting them in separate messages. I please specify the extent of the prefix binding as well as the scope. II please establish a method to bind a prefix which covers external dtd subsets. III please provide examples which describe processing in the presence of entities. IV please specify the precedence rules for attribute "specification". V please explain why namespace partitions are necessary. ---- VI (additional) the element name is resolved in the scope of its containing element. I, III, IV, and VI precluded implementation. II precludes the use of dtd's unless prefixes are elevated to global status - which is not the goal of the endeavour. in the intervening period, i have resolved the questions, for my immediate purposes as follows: I: prefix bindings in an element instance have dynamic scope and dynamic extent within the decoder/encoder process. the immediate - that is element-specific bindings - remain as attribute bindings available to the application for examination and side effects, but have no effect on name resolution outside of the decoding/encoding process. i had no reason to implement indefinite bindings for attribute-based prefixes, as i translate/intern attribute values (names, xpointers, etc.) as part of the decoding process based on type declarations for attributes and thereby avoid the need for the indefinite extent. i suspect that lexical bindings (eg the bindings for an entity may differ from those in effect at the point were it is included) would be difficult to follow, so i ignore the entities lexical context, but that's a minor issue. II: in addition to the wd's proposed "element instance attribute" binding mechanism, i introduced two alternatives: "entity reference" and "document/encoding declaration". the element-instance mechanism is sufficient to resolve names within the document entity. what remains is the requirement that names present in the external dtd subset or in any other external entity be resolved unambiguously. as the point of articulation is the boundary, and the respective forms on the two sides of the boundary are the entity reference (or indirectly the respective declaration) and the xml or encoding declaration, those are the appropriate locations to bind prefixes. the former is appropriate for external entities which themselves either have no support for namespaces or intend to be mapped when referenced. the latter is appropriate for external entities which intend to resolve the contained names. the bindings are encoded as additional pseudo attributes. III: see II. in keeping with I, at the point where an entity is referenced i establish the bindings declared within the entity declaration only (that is, none which were apparent within its definition context), and award them dynamic extent. IV: for the moment, i've chosen the precedence tag-content, bindings-from-containing-elements, attribute-defaults where the bindings-from-containing-elements takes its initial value from the xml-decl. V: i still haven't discovered a situation where i've needed this. the mechanism to resolve attribute declarations requires element specific stores, but that has nothing to do with the names themselves. VI (this wasn't among the original notes) the prefix/uri bindings at the point where an element name is read cannot include those effected by its attributes. a. otherwise, the universal name is not unambiguous b. given the bindings in the respective xml/encoding declarations, elements do not need to be self qualifying. it is sufficient if they qualify their context. Tim Bray wrote: > > At 06:42 PM 8/11/98 +0200, james anderson wrote: > > >i'm directing attention to the fact, that the present draft suggests encodings > >and mechanisms which are not sufficient to accomplish this, its own correct > >and achievable goal. > > Although I read this mailing list pretty regularly, I missed the posting in > which you demonstrated that this was the case. I suspect others may have, > as well. Could you post a pointer into the hypermail archive to the > message where you argued this? -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Aug 11 21:19:14 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:52 2004 Subject: wd-xml-names: the extent of the prefix binding Message-ID: <35D09AF4.DD3756BF@mecomnet.de> I. please specify the extent of the prefix binding as well as the scope while the wd is clear that the scope of a prefix-to-uri binding within an element is dynamic, the intended extent of the binding is unclear. the discussion which has appeared on xml-dev, for example, leaves room for the interpretation, that the binding has indefinite extent. a binding which is afforded dynamic extent has a clearly understandable semantics and is readily implemented, since the parser's state is sufficient to implement the "inheritance". it would even be possible to implement it on the basis of "ephemeral" attributes - which a serializer introduced into the stream on the fly as needed and which a non validating parser would be free to discard after application. if the binding is intended to have an indefinite extent, which interpretation some xml-dev discussion might be taken to imply, (see, for example, mr clark's remark on passing state between the parser and the application for the purpose of decoding attribute values: http://www.lists.ic.ac.uk/hypermail/xml-dev/9808/0173.html) then an implementation which retains a defined semantics in the presence of side effects is more difficult (it would appear analogous to the "upward funarg" problem). since the benefit of supporting indefinite binding extent is unclear, i would suspect that dynamic extent would be the better alternative, but ask for clarification. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 21:22:21 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:52 2004 Subject: wd-xml-names: external dtd subsets (and external entities in general) Message-ID: <35D09B46.D74776D7@mecomnet.de> II. please establish a method to bind a prefix which covers the internal and external dtd subsets. without such a mechanism, the dtd's denotation is undefined. if, on the other hand, such a mechanism is provided, then validation is possible on the basis of namespace-aware 1.0 conformant dtd's. additional pseudo-attributes in the XMLDecl form would suffice. please see my questions to xml-dev on this topic. (http://www.lists.ic.ac.uk/hypermail/xml-dev/9808/0112.html, and http://www.lists.ic.ac.uk/hypermail/xml-dev/9808/0129.html) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Tue Aug 11 21:23:00 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:03:53 2004 Subject: Check out the DCD submission In-Reply-To: <3.0.32.19980811092524.00c25240@207.34.179.21> Message-ID: On Tue, 11 Aug 1998, Tim Bray wrote: > At 09:21 AM 8/11/98, Peter Murray-Rust wrote: > >I am primarily concerned with the basic datatypes section 4. I want to use > >these (or something like them) in CML, healthcare and so on. I shall > >extract this subset of the document and re-use the concepts in JUMBO2. > > Not now! Everyone agrees that we need datatypes. I expect some cheerful > & constructive bloodletting in the SIG & WG as to which set of datatypes > we need. Anybody who invests effort in that set at this time is spinning > wheels. > > On the other hand, bearing what you say in mind, I think there may be > a sane case to be made for decoupling the task of identifying the set > of datatypes from that of defining the rest of the schema mechanics; > however we end up specifying the datatypes, the heavy typechecking > coding will be about the same, and it might be nice to give that a > head-start. Yes. FWIW the HTTP-NG group has a description of their proposed type system in their Architectural Model working draft at: http://www.w3.org/Protocols/HTTP-NG/#Specs particularly section 3 of http://www.w3.org/TR/WD-HTTP-NG-architecture/ is relevant to this discussion. (... RDF itself could do with having a few more interesting types than String). So separating out the list of types from the mechanics seems particularly well motivated given that there are possibly three related W3C activities which could have their own way of representating the chosen types. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 21:28:28 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: precedence rules for attribute specification Message-ID: <35D09C77.852B7F40@mecomnet.de> IV. please specify the precedence rules for attribute "specification". there are three states in the following matrix for which i cannot yet specify the effective binding: (ed = element default, cd = context default, eb = element binding, cb = context binding) default presence in attribute declaration attribute presence in element -- -- | -- ed | cd -- | cd ed --------------------------------------- | unbound | ed | cd | ? ? | -- -- | | | | ? ? | ---------------------------------------- | | | | | -- eb | eb | eb | eb | eb | ---------------------------------------- | | ? ? | | ? ? | cb -- | cb | ?* ? | cb! | ? ? | ---------------------------------------- | | | | | cb eb | eb | eb | eb | eb | ---------------------------------------- *: xml-dev discussion has implied that the context binding takes precedence, but that would lead to capturing prefix bindings on included external entities - which is not necessarily to be recommended. (see, for example, http://www.lists.ic.ac.uk/hypermail/xml-dev/9808/0152.html) !: modulo the other ambiguities i would suggest that the attribute declaration in the dtd should be afforded a "lexical" scope which takes precedence over the dynamic scope of any bindings in the element stream. [19980810: i then went ahead and implemented the opposite, but i don't yet see the choice as an essential issue, just so long as the choice is made] xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 21:29:05 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:53 2004 Subject: John Cowan's view on SAX extensions for ns drafts In-Reply-To: <35D08996.1C9AB67F@locke.ccil.org> Message-ID: <3.0.1.16.19980811202739.6c2fbcae@pop3.demon.co.uk> At 14:12 11/08/98 -0400, John Cowan wrote: >Since I can't be at Montreal, here's my (lengthy, but hopefully I don't think Montreal is critical - I don't think any RL meeting should be. It's just that I get a chance to meet lots of new people and maybe feed back some non e-ideas. No suggestion that there would be a RL XML-DEV meeting. I'm keen that this takes place by the same XML-DEV processes. I think it's essential that those who have posted on this subject start exchanging ideas and possible timescales. >complete) proposal for extending SAX 1.0. My design goals are: > > o Supports current ns draft > o Conceptually compatible with David Megginson's XML-Dev > message of 8 August > o Equally useful for integral or layered implementations > o Fully backward compatible with SAX 1.0 > Looked a useful starting point. I think our experience has shown that it takes longer than it looks (not sure why). But we need something fairly badly, I think. My own effort is rather post-SAX in than I am hoping to consume 'normalised' namespace information and then apply Java classes to it. I shall probably post the current JUMBO fairly shortly - it is based crudely on pre-0802 namespaces (e.g. it doesn't worry about the many2many mapping). One thing that we may have to bear in mind is whether we wish to preserve any of the prefixes for subsequent authoring/transformation. For example, if FOO is declared with a default namespace of http://foo.org do people mind if it gets output as something like NS3:FOO? (where the prefixes run from NS1 to NS10 or whatever). Personally - although I would like it - I think that's too advanced and that prefixes are expanded and meaningless in any transformation. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Aug 11 21:29:10 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:53 2004 Subject: Check out the DCD submission In-Reply-To: <3.0.32.19980811092524.00c25240@207.34.179.21> Message-ID: <3.0.1.16.19980811201758.0a1fd95a@pop3.demon.co.uk> At 09:25 11/08/98 -0700, Tim Bray wrote: >At 09:21 AM 8/11/98, Peter Murray-Rust wrote: >>I am primarily concerned with the basic datatypes section 4. I want to use >>these (or something like them) in CML, healthcare and so on. I shall >>extract this subset of the document and re-use the concepts in JUMBO2. > >Not now! Everyone agrees that we need datatypes. I expect some cheerful >& constructive bloodletting in the SIG & WG as to which set of datatypes >we need. Anybody who invests effort in that set at this time is spinning >wheels. It's not a problem :-). The main effort is in getting the validation, presentation, etc done. To add new datatypes or syntax is relatively straightforward. And I'm not doing the whole lot, either - just the commonest ones. And I wouldn't go near the COBOL stuff. > >On the other hand, bearing what you say in mind, I think there may be >a sane case to be made for decoupling the task of identifying the set >of datatypes from that of defining the rest of the schema mechanics; >however we end up specifying the datatypes, the heavy typechecking >coding will be about the same, and it might be nice to give that a >head-start. > You yourself came up with XML-TYPE or whatever it was called - about 10 webyears ago. IMO that was nearly a no-brainer and orthogonal to any other effort - it would have helped other activities since. And the arguments are unlikely to stray beyond what the precise definition of some weird type is... I can live without min and max in that spec if it helps. >>I note that max and min have changed from being content to attributes. > >No! Read the early part of the spec. Per RDF, these things are >*properties*, which can be given either as elements or attributes. I admit I haven't given it very much detailed attention. But given that there are ElementDefs and AttributeDefs and that the latter produce attributes... But I will read it more carefully. NNTR > -Tim Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Aug 11 21:29:46 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: namespace partitions Message-ID: <35D09CBC.92500106@mecomnet.de> V. please explain why namespace partitions are necessary. it is neither clear why the namespace partitions are necessary nor are the advantages of implementing them evident. how would they change either the expressiveness or the correctness of a document? 1. any element-relative attribute-name qualification, for example for the purpose of xlink or xsl specification could be accomplished with an additional clause which constrained the element type name. 2. since the element type name needs in itself to be unique there is no advantage to additional qualification for the attribute names for the purpose of attribute declaration. is there some other 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 21:33:46 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: prefix scope with respect to entities Message-ID: <35D09DBB.368408AE@mecomnet.de> III. please include examples which describe processing in the presence of entities i have understood the bindings which apply to entities to be those present in the dynamic context which is in effect a the time the parser "inserts" the entity value into the parse stream. given the present content of the wd, i believe that is the only possible interpretation since no binding mechanism is provided which includes the dtd within its scope. as i suspect, however, that such a mechanism is necessary, one must clarify whether the dynamic scoping rules apply there as well, whether the dynamic context is that of the definition or that of the reference, or whether, perhaps lexical scoping rules would apply. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 21:33:50 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: the extent of the prefix binding Message-ID: <3.0.32.19980811122900.00c1ad50@207.34.179.21> At 09:27 PM 8/11/98 +0200, james anderson wrote: >I. please specify the extent of the prefix binding as well as the scope The scope of the binding is the element to which the declaration is attached. I have just read your posting 3 times and don't understand what you mean by "extent". -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Aug 11 21:39:42 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: external dtd subsets (and external entities in general) Message-ID: <3.0.32.19980811123558.00c1e100@207.34.179.21> At 09:28 PM 8/11/98 +0200, james anderson wrote: >II. please establish a method to bind a prefix which covers the internal and >external dtd subsets. This was discussed by the WG and eventually voted down; the advantages of the attribute approach, combined with the desire to avoid having multiple ways to do the same thing, led to the PI approach being amputated. >without such a mechanism, the dtd's denotation is undefined. I don't understand what you mean by "denotation". In general, the usefulness of your postings would be improved by more attention to the use of terminology, and where you need to use a new term (e.g. "extent" in your previous posting and "denotation" here) you should provide a definition for it. >if, on the other hand, such a mechanism is provided, then validation is >possible on the basis of namespace-aware 1.0 conformant dtd's. Only trivially so. As I have pointed out, the hard part is not matching up the names, it's making compound DTDs. I have also pointed out how a mechanical instance/DTD rewrite could address some of the issues of namespace-aware validation. I have not suggested a solutoin for how to solve the *hard* problem, namely how to go about making a compound DTD, and would like to hear input on 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 21:40:32 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: resolve the element name in the scope of its containing element. Message-ID: <35D09F57.F6711DC9@mecomnet.de> VI resolve the element name in the scope of its containing element. until an element name is resolved, it is not possible to determine which (or even whether a) element declaration applies unless the prefixes are awarded global status. which method namespaces are intended to avoid. the containing element (or the document entity) could (assuming the encoding is supported) just as well provide the binding. this would avoid the ambiguity. what is the argument for having an element qualify its own identifier? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Aug 11 22:15:09 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: resolve the element name in the scope of its containing element. Message-ID: <3.0.32.19980811131414.00c5b530@207.34.179.21> At 09:45 PM 8/11/98 +0200, james anderson wrote: >VI resolve the element name in the scope of its containing element. > >until an element name is resolved, it is not possible to determine which (or >even whether a) element declaration applies unless the prefixes are awarded >global status. which method namespaces are intended to avoid. What do you mean by "resolve"? What do you mean by "a) element declaration applies"? The attribute-based declarations apply to the element on which they're attached and to others within that scope unless overridden. If the draft doesn't make that clear it's a bug. Please suggest wording which would make it more clear. >the containing element (or the document entity) could (assuming the encoding >is supported) just as well provide the binding. this would avoid the ambiguity. What do you mean by "encoding"? What do you mean, in this context, by "binding"? What ambiguity are you talking about? >what is the argument for having an element qualify its own identifier? What do you mean by "qualify"? What do you mean by "identifier"? I genuinely don't understand your terminology. In particular, I completely fail to understand the sentence above. Now I remember why I didn't address the issues you raised on teh first go-around: I couldn't understand them. At this point, it is obvious that we are wasting each others' time. If you have concerns with the current draft, you are going to have to express them in terms comprehensible to those who authored the spec. Hint: examples are good. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Aug 11 22:21:49 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: external dtd subsets (and external entities in general) References: <3.0.32.19980811123558.00c1e100@207.34.179.21> Message-ID: <35D0A9B0.CA92E740@mecomnet.de> Tim Bray wrote: > > At 09:28 PM 8/11/98 +0200, james anderson wrote: > >II. please establish a method to bind a prefix which covers the internal and > >external dtd subsets. > > This was discussed by the WG and eventually voted down; the advantages > of the attribute approach, combined with the desire to avoid having > multiple ways to do the same thing, led to the PI approach being > amputated. > > >without such a mechanism, the dtd's denotation is undefined. > > I don't understand what you mean by "denotation". In general, the > usefulness of your postings would be improved by more attention > to the use of terminology, and where you need to use a new term > (e.g. "extent" in your previous posting and "denotation" here) you > should provide a definition for it. re: scope and extent. The terms are relevant since, as (I believe) Mr Durand has already noted, the prefixes can be understood as variable bindings. In fact, it is possible to implement them as dynamic variable bindings within the decoding process. I work with Steele's definitions. (from his reference on common lisp) He devotes chapter 3 to them. I believe it is online, but know, unfortunately only of a location for the document in its entirety. (http://www.cast.uni-linz.ac.at/st/vision/software/lisp.html) The concepts are not his alone, but his is the reference which I have on my desk. The following definitions are excerpted from the Common Lisp hyperspec courtesy of Harlequin: (http://www.harlequin.com/education/books/HyperSpec) extent n. the interval of time during which a reference to an object, a binding, an exit point, a tag, a handler, a restart, or an environment is defined. scope n. the structural or textual region of code in which references to an object, a binding, an exit point, a tag, or an environment (usually by name) can occur. They are not 100% adequate, as it is not clear how they apply to attribute declarations, for which the "spatial or textual region" is unclear. re: denotation. In the process of implementing an XML processor, I have (defacto) produced an operational semantics for XML. Whereby I am not alone, just explaining. One "half" of the semantics is the XML encoding syntax. The other "half" is a particular storage model (DOM-like) and a collection of operations on this store. The last part is a specification for which operations on the store are entailed by a given encoding. I have been using "denotation" to mean just that: the effect of a document on the store. In the case of the dtd, it would be the entity/element/notation/... declarations which it produces. > > >if, on the other hand, such a mechanism is provided, then validation is > >possible on the basis of namespace-aware 1.0 conformant dtd's. > > Only trivially so. As I have pointed out, the hard part is not matching > up the names, it's making compound DTDs. I have also pointed out how > a mechanical instance/DTD rewrite could address some of the issues > of namespace-aware validation. I have not suggested a solutoin for > how to solve the *hard* problem, namely how to go about making a > compound DTD, and would like to hear input on that. -Tim In my case, the storage model restricts all stored names to be universal names. That is, all character sequences, which appear at a point in the encoded stream which the syntax specifies as a name, are required to denote a universal name in the store. If this requirement is met, then it is possible to automate the rewrite process which you described in your earlier post. (Please look back through the recent posts; you will note a response from me on this topic). If, on the other hand, said sequences do not denote an universal name, then the result of the decoding is undefined, since given that the names have no denotations (ie. they identify no name in the store), loosly speaking, the DTD also has none. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 22:24:56 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: precedence rules for attribute specification Message-ID: <3.0.32.19980811132331.00c677c0@207.34.179.21> At 09:33 PM 8/11/98 +0200, james anderson wrote: >IV. please specify the precedence rules for attribute "specification". > >there are three states in the following matrix I can't understand the rows & columns of the matrix. Could you provide some examples? In particular I can't understand what you mean by "default presence in attribute declaration" and "attribute presence in element". Surely you're not talking about default attribute values in At 09:34 PM 8/11/98 +0200, james anderson wrote: >it is neither clear why the namespace partitions are necessary nor are the >advantages of implementing them evident. how would they change either >the expressiveness or the correctness of a document? Sections 6.1 tries to explain this necessity at some length. However, you are not alone in your view that this is superfluous; David Megginson has no problem with elements & attributes having "the same name", thinks the applications should sort it out. A WG majority eventually decided that interoperability was improved by sorting the classes of names into partitions. >1. any element-relative attribute-name qualification, for example for the >purpose of xlink or xsl specification could be accomplished with an additional >clause which constrained the element type name. True, but enough of us liked the idea of a standalone name for unqualified attributes that we wrote it into the spec. >2. since the element type name needs in itself to be unique there is no >advantage to additional qualification for the attribute names for the purpose >of attribute declaration. There is if you want to have a way to write down an identifier for such an attribute. The key question is "what information do you need to have to find the right markup?" The answer is "the attribute name and the element name and (if any) namespace". The real reason we got there was in asking the question, WRT the following: what namespace is the HREF attribute in? The natural language answer is "in the namespace of HTML's A element". All the stuff in section 6 is an attempt to formalize 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 22:38:17 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:53 2004 Subject: The *hard* problem (was: external dtd subsets ...) References: <3.0.32.19980811123558.00c1e100@207.34.179.21> Message-ID: <35D0AB9A.59F67FCC@locke.ccil.org> Tim Bray scripsit: > I have not suggested a solution for > how to solve the *hard* problem, namely how to go about making a > compound DTD, and would like to hear input on that. -Tim As far as I can see, such a thing is not possible even in principle, except through the promiscuous use of ANY content models. Given that you want to combine two separate DTDs, {A} and {B}, with or without prefixes, initially only {A} elements will be permissible content for other {A} elements, and likewise for {B} elements. So whatever the root element of a document may be will dictate what elements are to be used within it. In order to make this otherwise, someone must decide exactly which elements from {A} can have {B} content and vice versa. That is inherently beyond the ability of an algorithmic process unless it has detailed semantic information on the elements, *far* beyond what any DTD provides. IBTWSH uses a trick, a parameter entity that a containing DTD may define in order to specify elements from the containing DTD that can appear within IBTWSH elements. But average DTDs don't have such a mechanism, and it may not even be possible. (Nonetheless, this trick suggests how DCD/XML-Data elements with "open" content might be translated back into DTD element declarations. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 11 22:41:17 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:53 2004 Subject: Check out the DCD submission Message-ID: Tim Bray: >Not now! Everyone agrees that we need datatypes. I expect some cheerful >& constructive bloodletting in the SIG & WG as to which set of datatypes >we need. Anybody who invests effort in that set at this time is spinning >wheels. Peter Murray-Rust: >It's not a problem :-). The main effort is in getting the validation, >presentation, etc done. To add new datatypes or syntax is relatively >straightforward. And I'm not doing the whole lot, either - just the >commonest ones. And I wouldn't go near the COBOL stuff. Dan Brickley: >So separating out the list of types from the mechanics >seems particularly well motivated given that there are possibly three related >W3C activities which could have their own way of representating the >chosen types. One of my biggest complaints about XML-Data (and a lot of why we started out XSchema) was that it did too much too fast in one giant spec. I'd be _much_ happier to see the W3C hash out data types (and possibly their relationship to assorted Unicode representations) in a _separate_ document. Data types are critically important, and I'd like to see them given the full attention they deserve rather than as part of something else. This would also improve their reusability, making it much easier to refer to the short and useful XML-Types spec, for instance, rather than Section 4 of the DCD spec, which only XML developers and possibly XML document authors are likely to read. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Aug 11 22:43:12 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: external dtd subsets (and external entities in general) Message-ID: <3.0.32.19980811133954.00c65600@207.34.179.21> At 10:30 PM 8/11/98 +0200, james anderson wrote: >extent n. the interval of time during which a reference to an object, a >binding, an exit point, a tag, a handler, a restart, or an >environment is defined. > >scope n. the structural or textual region of code in which references to an >object, a binding, an exit point, a tag, or an environment (usually >by name) can occur. > >They are not 100% adequate, as it is not clear how they apply to attribute >declarations, for which the "spatial or textual region" is unclear. The structural or textual (you say "spatial", why?) region *is* clear; it's the scope of the element. Which leaves me with the word I didn't understand before; what do you mean by the "extent" of namespace/prefix binding? Are you arguing that we should write temporal dependency into the spec, i.e. say that means that "foo" is bound to "http://bar" and that that binding lasts until the end of the universe? Or until 31.82 seconds have passed? Obviously I'm grasping at straws. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 11 23:00:35 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:53 2004 Subject: wd-xml-names: resolve the element name in the scope of its containing element. References: <3.0.32.19980811131414.00c5b530@207.34.179.21> Message-ID: <35D0B0D4.364AAB90@locke.ccil.org> Tim Bray wrote: > >until an element name is resolved, it is not possible to determine which (or > >even whether a) element declaration applies unless the prefixes are awarded > >global status. which method namespaces are intended to avoid. > > What do you mean by "resolve"? What do you mean by "a) element declaration > applies"? The attribute-based declarations apply to the element on which > they're attached and to others within that scope unless overridden. If > the draft doesn't make that clear it's a bug. Please suggest wording > which would make it more clear. Here's my take on it. Suppose you have the fragment: This is mixedcontent where "foo" is not a previously declared prefix. One must then consult the DTD to see whether the element declaration for "foo:a" contains a default (or fixed) value for the "xmlns:foo" attribute. If not, a namespace constraint has been violated. Without prefix mapping in the DTD, there is a possibility that the wrong "foo:a" will be fetched. Or more accurately, there can be only one set of "foo:a" ATTLIST declarations, and they had better be correct. This is the only way to determine the URI corresponding to both the "a" and "b" elements. In short: DTDs don't just serve validation, they serve attribute normalization as well, and only after attributes are normalized can the full set of namespace declarations be determined. > >the containing element (or the document entity) could (assuming the encoding > >is supported) just as well provide the binding. this would avoid the ambiguity. > > What do you mean by "encoding"? What do you mean, in this context, by > "binding"? What ambiguity are you talking about? Paraphrase: "The declaration of a namespace could be placed in the parent element, such that the prefix-to-URI mapping affects only its children, and not itself." > >what is the argument for having an element qualify its own identifier? > > What do you mean by "qualify"? What do you mean by "identifier"? Paraphrase: "What (rhetorical) argument is used to defend the position that the attributes of an element should provide the URI for its own GI?" ===== Note on my own account: The draft implies that non-validating parsers may differ from each other, and from validating parsers, on which namespaces the elements and attributes in an instance may belong to, and whether they belong to any at all, depending on whether the parser reads the DTD in full, partially, or not at all. Non-validating parsers cannot assume that because they do not know the definition of a prefix, that it is an error to use it. All these considerations fall to the ground if namespace attributes *cannot* be defaulted from the DTD (unlike other XML attributes). The draft is silent on the point. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mike_Spreitzer.PARC at xerox.com Tue Aug 11 23:13:47 1998 From: Mike_Spreitzer.PARC at xerox.com (Mike_Spreitzer.PARC@xerox.com) Date: Mon Jun 7 17:03:53 2004 Subject: Check out the DCD submission In-Reply-To: Message-ID: <98Aug11.141320pdt."53115(4)"@alpha.xerox.com> > Yes. FWIW the HTTP-NG group has a description of their proposed type > system in their Architectural Model working draft at: We also have a somewhat independent line of inquiry into a type system that will support evolution better; this should yield a type system that can better take advantage of the extensibility inherent in XML. We haven't yet gotten far enough to make a public release of this work (W3C members can find pointers to very preliminary, rough, incomplete, inconsistent, nearly incoherent drafts on the HTTP-NG Protocol Design Group home page). Once we've got the ideas worked out, we plan to integrate them into the Architectural Model. Mike xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 11 23:15:49 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:54 2004 Subject: wd-xml-names: external dtd subsets (and external entities in general) References: <3.0.32.19980811133954.00c65600@207.34.179.21> Message-ID: <35D0B400.E9453107@locke.ccil.org> Tim Bray wrote: > The structural or textual (you say "spatial", why?) region *is* clear; > it's the scope of the element. Which leaves me with the word I didn't > understand before; what do you mean by the "extent" of namespace/prefix > binding? Paraphrase: "If a general entity reference appears within the scope of a namespace declaration, does the declaration extend to elements and attributes appearing within the replacement text of the entity?" In particular, does it matter if the entity is internal or external, or not? The draft is silent. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 11 23:23:28 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:54 2004 Subject: Dynamic vs. indefinite extent Message-ID: <35D0B634.42500BC@locke.ccil.org> james anderson asks about the extent of prefix bindings. XML does not actually define the "extent" of anything. An XML processor must provide at least dynamic extent (I think: it is possible that lexical extent is meant), but is free to provide indefinite extent if that's useful to its clients. OTOH, the clients could provide the indefinite extent themselves. Nothing in XML or XML-namespace constrains an XML processor either way. (The point here, for those who don't follow this jargon, is that "dynamic extent" objects don't last after the end of their scope, like local variables in C, whereas "indefinite extent" objects last until nobody wants them any more, like heap allocations in C.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Aug 11 23:29:01 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:54 2004 Subject: Namespace Processing Hints and Rant on Scoping/Defaulting In-Reply-To: <35D0B0D4.364AAB90@locke.ccil.org> References: <3.0.32.19980811131414.00c5b530@207.34.179.21> <35D0B0D4.364AAB90@locke.ccil.org> Message-ID: <199808112127.RAA01625@unready.megginson.com> John Cowan writes: > Here's my take on it. Suppose you have the fragment: > > This is mixedcontent > > where "foo" is not a previously declared prefix. One must then consult > the DTD to see whether the element declaration for "foo:a" contains > a default (or fixed) value for the "xmlns:foo" attribute. If not, > a namespace constraint has been violated. No, the processing isn't that tricky if you think of these as layered protocols: Layer #1: The author writes the following: This is mixed content Layer #2: XML parser checks for well-formedness/validity and supplies default values: This is mixed content Layer #3: The namespace processor interprets any special attributes: This is mixed content Layer #4: The application does something interesting with the result. That said, I still really HATE the new declaration namespace syntax and the scoping/defaulting, but for reasons other than the problem of DTD validation: the whole thing reminds me too much of my first early experiences with BASIC, assembly language, etc., when people were writing giant, monolithic programs to avoid the supposed overhead of function calls. Today, some people want to build giant monolithic XML documents to avoid the supposed overhead of multiple HTTP fetches. I know that of which I speak, since embarrasingly recently I wrote the original AElfred parser in a single Java class with similar excuses. Now, every morning, I thank the higher deities that someone else has to maintain the @#$%@#@ thing (at least I commented the code well). SAX has lots of classes, and it's actually fun to maintain. Don't write an entire C program in main(); don't write an entire Java program in a single class; don't put all of your data into a single SQL table; don't force all of your information into a single XML document. If people followed these guidelines, then local scoping and defaulting of namespaces would be seen for the silly non-issues that they are, and XML with namespaces would still be simpler than SGML. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Aug 11 23:38:05 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:54 2004 Subject: wd-xml-names: resolve the element name in the scope of its containing element. Message-ID: <3.0.32.19980811143704.00c50870@207.34.179.21> At 05:00 PM 8/11/98 -0400, John Cowan wrote: [interpreting james anderson] >Here's my take on it. Suppose you have the fragment: > > This is mixedcontent > >where "foo" is not a previously declared prefix. One must then consult >the DTD to see whether the element declaration for "foo:a" contains >a default (or fixed) value for the "xmlns:foo" attribute. If not, >a namespace constraint has been violated. You go on to raise the issue in greater detail, but it is clearly the case that the rules have to be spelt out. For example, it's obvious to me that for a non-validating parser, if he hits and hasn't seen an xmlns:foo= in his encestry, the situation is broken. Should the spec mandate that in this case, a conforming program has to go and fetch any and all external parts of the DTD to make sure there isn't a default declaration? Good question. I think the answer has to be "no", thus putting the onus on the author either to (a) use a validating processor or (b) have standalone="true". >In short: DTDs don't just serve validation, they serve attribute >normalization as well, and only after attributes are normalized >can the full set of namespace declarations be determined. Just to pick nits, attribute *normalization* refers to sorting out white space in attribute *values*, so I don't think that interacts with namespaces. >Paraphrase: "The declaration of a namespace could be placed in the >parent element, such that the prefix-to-URI mapping affects only >its children, and not itself." Gosh, it's nice to have you here to interpret. If we were going to do that, then you couldn't have namespaces on the root element; so you'd need two *separate* things, one for content-only and one for self+content. Maybe the convenience of the content-only binding would make up for the pain of having to handle two different kinds of declarations; so far the WG hasn't bought that. >All these considerations fall to the ground if namespace attributes >*cannot* be defaulted from the DTD (unlike other XML attributes). >The draft is silent on the point. Obviously they can, because an XML processor is required to provide defaults, but not to tell the app that they are defaults. So there's no difference in principle between a provided and a defaulted attribute. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 11 23:45:18 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:54 2004 Subject: wd-xml-names: resolve the element name in the scope of its containing element. References: <3.0.32.19980811143704.00c50870@207.34.179.21> Message-ID: <35D0BB32.20A3C779@locke.ccil.org> Tim Bray scripsit: > You go on to raise the issue in greater detail, but it is clearly > the case that the rules have to be spelt out. For example, it's > obvious to me that for a non-validating parser, if he hits > and hasn't seen an xmlns:foo= in his encestry, the situation is > broken. Should the spec mandate that in this case, a conforming > program has to go and fetch any and all external parts of the > DTD to make sure there isn't a default declaration? Good question. > I think the answer has to be "no", thus putting the onus on the author > either to (a) use a validating processor Provided the document can be made valid per other concerns. > or > (b) have standalone="true". Well, that will work, I suppose. > Just to pick nits, attribute *normalization* refers to sorting > out white space in attribute *values*, so I don't think that > interacts with namespaces. Yes, sorry; I meant attribute *defaulting*. > Gosh, it's nice to have you here to interpret. If we were going to > do that, then you couldn't have namespaces on the root element; Not using the draft's machinery, anyhow. A PI could put a namespace on the root element. > so > you'd need two *separate* things, one for content-only and one > for self+content. Maybe the convenience of the content-only > binding would make up for the pain of having to handle two different > kinds of declarations; so far the WG hasn't bought that. > > >All these considerations fall to the ground if namespace attributes > >*cannot* be defaulted from the DTD (unlike other XML attributes). > >The draft is silent on the point. > > Obviously they can, because an XML processor is required to provide > defaults, but not to tell the app that they are defaults. So there's > no difference in principle between a provided and a defaulted > attribute. -Tim -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Aug 11 23:48:22 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:54 2004 Subject: wd-xml-names: precedence rules for attribute specification References: <3.0.32.19980811132331.00c677c0@207.34.179.21> Message-ID: <35D0BD7D.D5D4E9@mecomnet.de> Tim Bray wrote: > > At 09:33 PM 8/11/98 +0200, james anderson wrote: > >IV. please specify the precedence rules for attribute "specification". > > > >there are three states in the following matrix > > I can't understand the rows & columns of the matrix. Could you Gee, and I thought that, of all the questions, this one was the clearest... There are two places the attribute can be "attached": in the element itself and in some element in its context. The respective attachment can be by appearance in the start tag or by declaration of a default in attlist. i had understood the draft to allow both forms of attachment. (the recent examples to xml-dev - including from mr. clark, left me in the belief that i was correct) thus the 16 positions in the table. default = attlist declaration binding = presence in the start tag. the problem state are (cb/-- X --/ed) a context binding and element default (--/-- X cd/ed) nothing present in the elements in the document entity, just in the declarations (cb/-- X cd/ed) a combination of the above > provide some examples? In particular I can't understand > what you mean by "default presence in attribute declaration" > and "attribute presence in element". > Just now i have to catch a train (i'm nine hours ahead of you folks). if this is all still unclear in the morning i'll set myself to some examples. > Surely you're not talking about default attribute values in > are there if it's not explicitly specified, they're not there if > it is explicitly specified, there can be no ambiguity. -Tim Please look at the table again, given my explanation above. What about the case where it appears as a default in the containing element and as a default in the contained element? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 11 23:54:23 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:54 2004 Subject: wd-xml-names: resolve the element name in the scope of its containing element. References: <3.0.32.19980811143704.00c50870@207.34.179.21> Message-ID: <35D0BF62.EBCDAD00@mecomnet.de> Tim Bray wrote: > > At 05:00 PM 8/11/98 -0400, John Cowan wrote: > > [interpreting james anderson] > > >Here's my take on it. Suppose you have the fragment: > > > > This is mixedcontent > > > >where "foo" is not a previously declared prefix. One must then consult Even if a declaration has appeared, what is the processor to do were (given the present definitions for declaration scope) the "intended" element was associated with an attribute declaration which included a default value for the respective attribute? > >the DTD to see whether the element declaration for "foo:a" contains > >a default (or fixed) value for the "xmlns:foo" attribute. If not, > >a namespace constraint has been violated. > > You go on to raise the issue in greater detail, but it is clearly > the case that the rules have to be spelt out. For example, it's > obvious to me that for a non-validating parser, if he hits > and hasn't seen an xmlns:foo= in his encestry, the situation is > broken. Should the spec mandate that in this case, a conforming > program has to go and fetch any and all external parts of the > DTD to make sure there isn't a default declaration? Good question. > I think the answer has to be "no", thus putting the onus on the author > either to (a) use a validating processor or > (b) have standalone="true". How is the validating processor to do this unless either a, it elevates the prefixes to global status, or b, it has a means is to determine the corresponding universal names for qualified names in the DTD? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Aug 11 23:57:51 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:54 2004 Subject: Namespace Processing Hints and Rant on Scoping/Defaulting References: <3.0.32.19980811131414.00c5b530@207.34.179.21> <35D0B0D4.364AAB90@locke.ccil.org> <199808112127.RAA01625@unready.megginson.com> Message-ID: <35D0BE10.3310CC9B@locke.ccil.org> David Megginson wrote: > No, the processing isn't that tricky if you think of these as layered > protocols: The trouble arises in this case: This thing belongs to URI A ... This thing belongs to URI B where the same prefix is meant to map to more than one URI in the course of the document. The DTD can't supply "xmlns:foo" default attribute values for both foo:a elements, because to a DTD they are the same element type. > That said, I still really HATE the new declaration namespace syntax > and the scoping/defaulting, but for reasons other than the problem of > DTD validation: the whole thing reminds me too much of my first early > experiences with BASIC, assembly language, etc., when people were > writing giant, monolithic programs to avoid the supposed overhead of > function calls. Today, some people want to build giant monolithic XML > documents to avoid the supposed overhead of multiple HTTP fetches. I can't agree with you. The utility of namespaces is not so much to create merged documents, but to create documents representing merged designs: in particular, namespaces allow documents to "mix in" existing element semantics as and where needed. The alternative is to invent your own elements and "just know" (namely, encode in programs) what their semantics are. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fblau at nina.snohomish.wa.gov Wed Aug 12 00:00:59 1998 From: fblau at nina.snohomish.wa.gov (Frank Blau) Date: Mon Jun 7 17:03:54 2004 Subject: HL7 vs X12 w/XML Message-ID: <35D0BD06.8235F918@nina.snohomish.wa.gov> Does anyone have any comparisons between HL7 and X12 w/XML for transmission of Healthcare Data? Frank xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Aug 12 00:05:10 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:54 2004 Subject: wd-xml-names: resolve the element name in the scope of its containing element. References: <3.0.32.19980811143704.00c50870@207.34.179.21> <35D0BB32.20A3C779@locke.ccil.org> Message-ID: <35D0C1B3.A612562D@mecomnet.de> John Cowan wrote: > > Tim Bray scripsit: > > > > Gosh, it's nice to have you here to interpret. If we were going to > > do that, then you couldn't have namespaces on the root element; > > Not using the draft's machinery, anyhow. A PI could put a namespace > on the root element. > Agreed. The declaration is for "content only". A second declaration form for "self + content" is not necessary. Either the PI form or the method of putting pseudo attributes on "physical-entity-specific" declarations is sufficient. For the former method, the PI should be permitted in external entities in addition to within the prologue, in order to afford the necessary control over declarations. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 12 00:20:14 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:54 2004 Subject: Dynamic vs. indefinite extent References: <35D0B634.42500BC@locke.ccil.org> <35D0C33C.C216E5A9@mecomnet.de> Message-ID: <35D0C376.1B4C6D7B@locke.ccil.org> james anderson wrote: > i (of all people to ask for it) would need a definition for lexical extent. Sorry, that was a brain fart. There is, of course, no such thing as lexical extent. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Aug 12 01:31:41 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:54 2004 Subject: Namespace Processing Hints and Rant on Scoping/Defaulting In-Reply-To: <35D0BE10.3310CC9B@locke.ccil.org> References: <3.0.32.19980811131414.00c5b530@207.34.179.21> <35D0B0D4.364AAB90@locke.ccil.org> <199808112127.RAA01625@unready.megginson.com> <35D0BE10.3310CC9B@locke.ccil.org> Message-ID: <199808112330.TAA01999@unready.megginson.com> John Cowan writes: > The trouble arises in this case: > > This thing belongs to URI A > ... > This thing belongs to URI B > > where the same prefix is meant to map to more than one URI in > the course of the document. The DTD can't supply "xmlns:foo" > default attribute values for both foo:a elements, because to > a DTD they are the same element type. [I will continue in my role as a _very_ reluctant defender of the new WD.] This is a problem with defaulting, not with validation -- although DTDs can do both, the two are distinct. Exactly the same problem occurs with architectural forms, where you might want to derive an element of the same type from different architectural forms at different points in a document. From the perspective of DTD design, you have three major choices: 1. Provide a non-#FIXED default value, allowing the user to specify a different value when necessary. 2. Make the attribute #REQUIRED, forcing the user to specify a value every time. 3. Make the attribute #IMPLIED, allowing the user to specify a value only when necessary. With AF's, you can also use an enumerated value to limit the possibilities, but few URNs would fit the constraints of an XML name. > > That said, I still really HATE the new declaration namespace syntax > > and the scoping/defaulting, but for reasons other than the problem of > > DTD validation: the whole thing reminds me too much of my first early > > experiences with BASIC, assembly language, etc., when people were > > writing giant, monolithic programs to avoid the supposed overhead of > > function calls. Today, some people want to build giant monolithic XML > > documents to avoid the supposed overhead of multiple HTTP fetches. > > I can't agree with you. The utility of namespaces is not so much > to create merged documents, but to create documents representing > merged designs: in particular, namespaces allow documents to > "mix in" existing element semantics as and where needed. > The alternative is to invent your own elements and "just know" > (namely, encode in programs) what their semantics are. We're talking about different things: I *like* the logical model behind namespaces (which is what you're describing), but that has nothing to do with the particulars of declaration syntax or local scoping and defaulting. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Wed Aug 12 04:52:06 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:55 2004 Subject: Namespace Processing Hints and Rant on Scoping/Defaulting In-Reply-To: <199808112127.RAA01625@unready.megginson.com> Message-ID: <199808120255.AA01960@murata.apsdc.ksp.fujixerox.co.jp> David Megginson wrote: > That said, I still really HATE the new declaration namespace syntax > and the scoping/defaulting, but for reasons other than the problem of > DTD validation: the whole thing reminds me too much of my first early > experiences with BASIC, assembly language, etc., when people were > writing giant, monolithic programs to avoid the supposed overhead of > function calls. Today, some people want to build giant monolithic XML > documents to avoid the supposed overhead of multiple HTTP fetches. I agree on this feeling. I also think that the new WD makes an XML document monolithic. Since the namespace of an element can be declarared by any of its superiors, we can no longer "divide and conquer" XML documents. (Fragment validation is no longer possible.) Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Wed Aug 12 05:00:18 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:55 2004 Subject: Namespaces and XML validation References: <3.0.1.16.19980810214125.0c978e1a@pop3.demon.co.uk> <35CF7089.9A2A56A6@finetuning.com> <3.0.1.16.19980811073526.0bef9886@pop3.demon.co.uk> Message-ID: <35D104A9.6458@hiwaay.net> Peter Murray-Rust wrote: > > I am sure that we shall not create a schism in the religious sense of the > world. It's possible that some tools may be WF-centric and others > DTD-centric. Hopefully many will do both. We could make a start (as we have > already discussed) about giving precise instructions to parsers. As is oft noted, DTDs serve different purposes in the production process. Thinking beyond single applications, where a DTD exists, the file can be proved valid. This is a legal concept as much as a computer science technology. Different tools for different purposes indeed. We create standards to serve both human and computer processes. Correct-by-construction techniques are well-understood. The trust they provide in computer communications is established. Where content has longer lifecycles and the intent of the *author* is part of the information to be maintained, the abstract schema is a useful form of contracting, hence, the BNF in the specifications. While there are efforts to replace the SGML schemata syntax, some effort should be given to extending it. As requirements are developed for the alternatives, I suggest that the working group for SGML make the same effort for SGML DTDs as the requirements there have a different emphasis. Len Bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Wed Aug 12 05:25:30 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:55 2004 Subject: Java class != XML entity References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> Message-ID: <35D10AA8.12B0@hiwaay.net> David Megginson wrote: > As far as I may be allowed to compare tropical and temperate tree > fruit, the equivalent of a Java class is a complete XML document. Class or an object of a class? Even that is not great. Colonized namespaces can contain property values from different classes of objects in a single document yes? To me as an SGMLer, a colonized document *looks like* an SGML document with multiple doctype statements. > The problem is that we don't have a good name for a collection of XML > documents working tightly together, the way that a collection of Java > classes can work in an applet or application -- "web" seems too loose, > and "docuverse" seems too New-Age. Any suggestions? I call them aggregates but I think of that from a process point of view. When I look at a colonized file, I think of weaving together different document types into an aggregate type, loosely a collection. A 3D model would help. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Wed Aug 12 06:37:24 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:55 2004 Subject: IMPORTANT (Re: XSchema question) References: <199808110030.RAA29421@boethius.eng.sun.com> <35CFA6AD.253D204C@allette.com.au> <3.0.1.16.19980811071341.6c87fcae@pop3.demon.co.uk> Message-ID: <35D11B5F.3439@hiwaay.net> > Jon Bosak wrote: > >> > >> > Ah, but Lou got his champagne: he sold EBT for a tidy sum and is now > >> > happily retired... Len Bullard wrote: > >I am reminded of stories of insider trading in which some retiring > >gentleman trumpeted overvalued stock just prior to cashing out. Peter M-R wrote: > I am sure it was not meant this way, but please be absolutely scrupulous > not to post things that could be misinterpreted and cause offence or be > actionable.. We are a public mailing list, so this is a public utterance. Absolutely right. Some humor doesn't work without the smiley. Thanks for minding my netiquette for me. If Lou shares his champagne, I'll apologize personally. Thinking about compound document types. Interesting. If unvalidatible, one of the most compelling benefits of markup-based technology goes away. It makes the case for XML weaker. I understand the concern expressed by Dr. Goldfarb that message-oriented-markup could weaken the capabilities of presentation-oriented-markup. ADA? Packages? Hmm... len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tln at insect.sd.monash.edu.au Wed Aug 12 10:27:48 1998 From: tln at insect.sd.monash.edu.au (Thuy-Linh Nguyen) Date: Mon Jun 7 17:03:55 2004 Subject: [help]xml4j (linux) Message-ID: Hi ! Now jre seems to work ok. But when running this command: >jre -cp xml4j.jar trlx -d personal.xml I got this error: >SIGSEGV 11* segmentation violation > >Full thread dump: >Killed I'm running xml4j 1.0.4 and jdk 1.1.3. I've tried >jre -cp xml4j_1.0.4.jar trlx -d personal.xml and still got the same error Could someone help me again please ? (And many thanks to those who answered me before !) TIA ! Thuy-Linh xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tln at insect.sd.monash.edu.au Wed Aug 12 11:50:47 1998 From: tln at insect.sd.monash.edu.au (Thuy-Linh Nguyen) Date: Mon Jun 7 17:03:55 2004 Subject: [help]xml4j (linux) In-Reply-To: Message-ID: Hi ! I've solved my problem !!! :-))) Sorry to bother you ! Thanks ! Thuy-Linh. On Wed, 12 Aug 1998, Thuy-Linh Nguyen wrote: > Hi ! > > Now jre seems to work ok. But when running this command: > >jre -cp xml4j.jar trlx -d personal.xml > > I got this error: > > >SIGSEGV 11* segmentation violation > > > >Full thread dump: > >Killed > > I'm running xml4j 1.0.4 and jdk 1.1.3. I've tried > >jre -cp xml4j_1.0.4.jar trlx -d personal.xml > > and still got the same error > > Could someone help me again please ? > (And many thanks to those who answered me before !) > > TIA ! > Thuy-Linh > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From David.Rosenborg at xsse.se Wed Aug 12 13:18:51 1998 From: David.Rosenborg at xsse.se (David Rosenborg) Date: Mon Jun 7 17:03:55 2004 Subject: John Cowan's view on SAX extensions for ns drafts References: <3.0.1.16.19980811202739.6c2fbcae@pop3.demon.co.uk> Message-ID: <35D17985.5F8EA280@xsse.se> Peter Murray-Rust wrote: > > One thing that we may have to bear in mind is whether we wish to preserve > any of the prefixes for subsequent authoring/transformation. For example, > if FOO is declared with a default namespace of http://foo.org do people > mind if it gets output as something like NS3:FOO? (where the prefixes run > from NS1 to NS10 or whatever). Personally - although I would like it - I > think that's too advanced and that prefixes are expanded and meaningless in > any transformation. First I would like to say that I think using a seperate namespace handler in SAX is an excellent solution. About preserving prefixes: That's true if the applications, processing the output of the transformation, are also namespace aware. However, if they are not namespace aware, like most existing validation SGML/XML software, they may rely literally on the prefixes. In my opinion, it would be nice to have the prefixes reported by SAX, but that's only for convenience. I could do without it but then I would have to write a namespace aware postprocessor that maps the URIs back to the expected prefixes, and throw it away when the subsequent applications also get namespace aware. About namespace resolver: Is it really necessary for the parser to deal with namespaces at all (if we don't consider namespace aware validation for the moment)? In a previous posting David Megginson outlined a layered approach which clearly shows how simple this part of namespace processing could be. In this model the parser may be namespace aware for validation purposes but it does not have to for other reasons. In my opinion, having a namespace resolver in SAX is an overkill. I'm not saying it wouldn't be useful, just that it shouldn't be part of the SAX interface. I think it would be sufficient if the start namespace scope method was just startNamespaceScope (String prefix, String URI) and then the application/SAX Filter would have to maintain a stack of namespaces just as a typical SAX application keeps a stack of open elements if it is building a tree. A namespace resolver could be part of the helper classes though. Also I think the startNamespaceScope events should occur before the corresponding startElement event since the element is itself inside the scope it declares. ______________________________________________________________________ David.Rosenborg@xsse.se Stockholm Stock Exchange xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 12 14:06:05 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:55 2004 Subject: Java class != XML entity In-Reply-To: <35D10AA8.12B0@hiwaay.net> References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> Message-ID: <199808121204.IAA00214@unready.megginson.com> len bullard writes: > David Megginson wrote: > > > As far as I may be allowed to compare tropical and temperate tree > > fruit, the equivalent of a Java class is a complete XML document. > > Class or an object of a class? Exactly -- here's where such analogies can fall flat on their collective faces. On can argue that the XML document type is equivalent to an abstract Java interface, that the XML document is equivalent to a class implementing that interface, and that the various transformations of that XML document (formatted output, database tables, lawn-sprinkler spinning, etc.) are equivalent to Java objects instantiating the class. On the other hand, as you point out, it is just as easy to argue that the document type is the equivalent to the class, and that the document is equivalent to an object instatiating the class. Perhaps we're best letting each fruit stick to its own tree. > ... Colonized namespaces can contain property values from different > classes of objects in a single document yes? To me as an SGMLer, a > colonized document *looks like* an SGML document with multiple > doctype statements. Or a class implementing multiple interfaces (sorry, I couldn't resist). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Aug 12 14:12:04 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:55 2004 Subject: Namespace Processing Hints and Rant on Scoping/Defaulting References: <3.0.32.19980811131414.00c5b530@207.34.179.21> <35D0B0D4.364AAB90@locke.ccil.org> <199808112127.RAA01625@unready.megginson.com> <35D0BE10.3310CC9B@locke.ccil.org> <199808112330.TAA01999@unready.megginson.com> Message-ID: <35D1886F.B3C4BE47@mecomnet.de> David Megginson wrote: > > John Cowan writes: > > > The trouble arises in this case: > > > > This thing belongs to URI A > > ... > > This thing belongs to URI B > > > > where the same prefix is meant to map to more than one URI in > > the course of the document. The DTD can't supply "xmlns:foo" > > default attribute values for both foo:a elements, because to > > a DTD they are the same element type. > > This is a problem with defaulting, not with validation -- although > DTDs can do both, the two are distinct. They were distinct. Both now depend on unambiguous names. With the present namespace WD, unambiguous names depend, in turn, in some cases, on attribute defaults. Which is circular, since that depends on an unambiguous name for the respective element, and makes validation depend on defaulting. I would have prefered to keep the two orthogonal, but I'm just trying to implement it, not design it... > > Exactly the same problem occurs with architectural forms, where you > might want to derive an element of the same type from different It's not _quite_ the same, since those _names_ are presumed unambiguous. > architectural forms at different points in a document. From the > perspective of DTD design, you have three major choices: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Wed Aug 12 15:32:00 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:03:55 2004 Subject: Java class != XML entity In-Reply-To: <199808111745.NAA00926@unready.megginson.com> References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> Message-ID: <3.0.5.32.19980812081714.007ea170@postoffice.swbell.net> At 01:45 PM 8/11/98 -0400, David Megginson wrote: > >The problem is that we don't have a good name for a collection of XML >documents working tightly together, the way that a collection of Java >classes can work in an applet or application -- "web" seems too loose, >and "docuverse" seems too New-Age. Any suggestions? Bounded object set? Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Aug 12 16:10:52 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:55 2004 Subject: Java class != XML entity Message-ID: <004401bdc5f9$b5b098a0$2ee044c6@arcot-main> >> The problem is that we don't have a good name for a collection of XML >> documents working tightly together, the way that a collection of Java >> classes can work in an applet or application -- "web" seems too loose, >> and "docuverse" seems too New-Age. Any suggestions? There is a spec named "XML-Package" which addressed the problem of packaging multiple XML documents and related resources into a single XML document. While the spec itself is on-hold at the moment, "package" or "pack" sounds like a good name. BTW, Docuverse is my company name so don't wear it out . Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 12 16:13:04 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:55 2004 Subject: John Cowan's view on SAX extensions for ns drafts References: <3.0.1.16.19980811202739.6c2fbcae@pop3.demon.co.uk> <35D17985.5F8EA280@xsse.se> Message-ID: <35D1A282.E3B2ABE@locke.ccil.org> David Rosenborg wrote: > Is it really necessary for the parser to deal with namespaces at > all (if we don't consider namespace aware validation for the moment)? Depends what you think "the parser" is. My design was for something that a parser could implement if it wanted to, but could also be layered over a ns-blind parser. > Also I think the startNamespaceScope events should occur > before the corresponding startElement event since the element > is itself inside the scope it declares. A very good point, which I gladly adopt. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Wed Aug 12 16:13:12 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:55 2004 Subject: Java class != XML entity Message-ID: The problem is that we don't have a good name for a collection of XML >documents working tightly together, the way that a collection of Java >classes can work in an applet or application -- "web" seems too loose, >and "docuverse" seems too New-Age. Any suggestions? Sorry to be rather facetious, but how about A Docsplat! Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From assunta.ciervo at primeur.com Wed Aug 12 16:22:02 1998 From: assunta.ciervo at primeur.com (assunta ciervo) Date: Mon Jun 7 17:03:55 2004 Subject: (no subject) Message-ID: <35D1A52D.43856F13@primeur.com> unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Aug 12 16:27:02 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:56 2004 Subject: James Anderson's table Message-ID: <35D1A613.A9CD0EFD@locke.ccil.org> I finally figured out what the terminology in the table means: > (ed = element default, cd = context default, > eb = element binding, cb = context binding) "Element default" means "an ns attribute of the current element, defaulted from the DTD"; "Context default" means "an ns attribute of an ancestral element, defaulted from the DTD"; "Element binding" means "an ns attribute of the current element, explicitly present in the instance"; "Context binding" means "an ns attribute of an ancestral element, explicitly present in the instance". What makes this table hard to understand is that while logically it is 2 x 2 x 2 x 2, it is presented as 4 x 4, but the things grouped together don't really belong together. The axes of the 4 x 4 table are not "ancestral element" vs. "current element", but "explicitly present in the attribute" (rows) vs. "defaulted from the DTD" (columns). But anyway, here are the correct values, based on the principle that a value defaulted from the DTD is equivalent in every way to one explicitly present in the instance (except of course that if both are available, the explicit one takes precedence): > default presence in attribute declaration > > attribute > presence in > element -- -- | -- ed | cd -- | cd ed > --------------------------------------- > | unbound | ed | cd | ed | > -- -- | | | | | > ---------------------------------------- > | | | | | > -- eb | eb | eb | eb | eb | > ---------------------------------------- > | | ed | cd | ed | > cb -- | cb | | cb | | > ---------------------------------------- > | | | | | > cb eb | eb | eb | eb | eb | > ---------------------------------------- The cell "cb" vs. "cd" can come out either way, depending on which is the nearer ancestor. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 12 16:35:27 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:56 2004 Subject: John Cowan's view on SAX extensions for ns drafts In-Reply-To: <35D17985.5F8EA280@xsse.se> References: <3.0.1.16.19980811202739.6c2fbcae@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980812153049.336f9768@pop3.demon.co.uk> At 12:16 12/08/98 +0100, David Rosenborg wrote: [... very helpful analysis snipped...] Thanks very much for the comments David - this is exactly the sort of feedback we need to get the next phase going. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 12 16:41:30 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:56 2004 Subject: DCD submission [from Dave Bergacker] Message-ID: <3.0.1.16.19980812154014.3787dc56@pop3.demon.co.uk> [forwarded on behalf of Dave Bergacker] >Return-Path: >Date: Wed, 12 Aug 1998 09:30:49 -0500 >From: bergackd@dgabby.mfldclin.edu (Dave Bergacker) >To: peter@ursus.demon.co.uk >Subject: DCD submission > >Hi there, I am a subscriber to the XML-Dev list, digest form. I have a few questions >about the DCD submission that I would like to put forward to Mr. Bray, and as they >are legal questions about the publishers retention of intellectual property rights, >I think the discussion would be interesting to the XML-dev list in general. Am I >allowed to post to the list? If not, would you know of someone willing to re-post >for me? [PMR: anyone can subscribe to the list] > >My questions are pretty basic: > >1) What is the status of the intellectual property of this submission until such time > as the W3C approves a version as a "Recommendation"? Both IBM and Microsoft only address > what happens after it is a "Recommendation" of the W3C. > >2) Is IBM claiming an interest in collecting royalties for works based on this submission? > The first sentence of their Declaration re: Intellectual property rights states: > "..will make licenses available... including royalty rates." I am not a lawyer and have > no idea what this sentence is supposed to convey. > >3) Is Microsoft reserving it's rights to collect royalties/assert patents if any company other > than a W3C member implements this specification? It certainly seems to read that way. > >Thanks in advance > >cc: > bergacker, dave > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Wed Aug 12 17:33:20 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:56 2004 Subject: DCD submission [from Dave Bergacker] Message-ID: <3.0.32.19980812083155.00bddc90@207.34.179.21> At 03:40 PM 8/12/98, Peter Murray-Rust wrote: >>Hi there, I am a subscriber to the XML-Dev list, digest form. I have a >few questions >>about the DCD submission that I would like to put forward to Mr. Bray I certainly don't speak for either IBM or Microsoft. Should DCD get taken up by W3C on the "Recommendation" track (and there's no guarantee of that), one of the requirements is that the W3C copyright applies, which essentially means that anyone can use it for anything. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dgd at cs.bu.edu Wed Aug 12 19:21:27 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:03:56 2004 Subject: Java class != XML entity In-Reply-To: <199808111745.NAA00926@unready.megginson.com> References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> Message-ID: At 1:45 PM -0400 8/11/98, David Megginson wrote: >David G. Durand writes: > > [writing about scoping in Java classes] > > > The equivalent to this policy for XML would be for the "minimization > > declarations" to be local to the _entity_. > >Reasonable people may disagree: many of us believe (from SGML >experience, especially) that entities are simply slightly-constrained >storage units with no other special significance -- if Java had >#include files, then those would be the equivalents of XML entities. >As far as I may be allowed to compare tropical and temperate tree >fruit, the equivalent of a Java class is a complete XML document. I was writing about Java source files, the relevant scoping region for package declarations. A Java file is a _compilation_ unit, not a class, since it is possible (if not favored practice) to put several classes into one source file. I agree that entities and include files are somewhat similar, and that explains some of the problems with entities: potential name clashes or namespace prefix capture by the entity referencing context. Part of my point is in direct agreement with your point; all such analogies are hazardous and should be treated like radiactive material -- potentially useful, and potentially deadly. People _do_ however, use entities as a mechanism for reuse, and they were designed for reuse. I think that local scoping can enhance that kind of reuse by allowing a declaration that only needs limited scope to be tightly bound to that scope, and also by ensuring that the declaration does not affect other portions of the document. >The problem is that we don't have a good name for a collection of XML >documents working tightly together, the way that a collection of Java >classes can work in an applet or application -- "web" seems too loose, >and "docuverse" seems too New-Age. Any suggestions? This is an old question. I find the HyTime term "BOS (Bounded Object Set)" rather opaque. Docuverse is not really correct, since that term was coined by Nelson to describe the total interlinkined machine readable literature of the planet. Currently, the Web itself is a nascent docuverse. Web was the historical term in the HT research community, but its use as synonym for World Wide Web would cause lasting confusion if we adopted it in its original sense. I wasn't able to come up with a good name. I like "nest", or "tangle". One of the problems is that the notion in question isn't necessarily all documents linked directly or indirectly from some (set of) starting point(s). It's a set of documents (including sets of independent links) that should be processed together, or should at least be simultaneously available. I suspect the final term will follow the evolution of an actual authoring practice. The term "web site" already hasmuch of the meaning in question, as it does not _necessarily_ map into a single server or URL, but rather to a set of documents provided with a single purpose and (usually) having a well-defined starting point. Personal web sites are often just a sub-directory on a larger school or ISP server, while corporate web sites may involve hundreds of servers on many continents. -- David -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Wed Aug 12 19:25:07 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:56 2004 Subject: Java class != XML entity Message-ID: >The problem is that we don't have a good name for a collection of XML >>documents working tightly together, the way that a collection of Java >>classes can work in an applet or application -- "web" seems too loose, >>and "docuverse" seems too New-Age. Any suggestions? > >how about > >Doc _ toffee! > >Peter Jones >WebDev Technical Editor >Wrox Press >mailto:peterj@wrox.com >*************** >Wrox Press UK Ltd. >http://www.wrox.co.uk >Tel 44 121 706 6826 >Fax 44 121 706 2967 > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Wed Aug 12 19:49:19 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:03:56 2004 Subject: Doctype dec and Namespaces Message-ID: I've just been looking at the Namespaces WD of 2-Aug-98 and I saw the following: doctypedecl ::= '' I notice that a QName occurs in the definition. Does this mean that a Namespace which is global for the (presumably valid) document is declared between the and the doctype decl.? Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Wed Aug 12 20:22:38 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:03:56 2004 Subject: Java class != XML entity References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> <199808121204.IAA00214@unready.megginson.com> Message-ID: <35D1DD74.731A9095@infinet.com> David Megginson wrote: > len bullard writes: > > David Megginson wrote: > > > > > As far as I may be allowed to compare tropical and temperate tree > > > fruit, the equivalent of a Java class is a complete XML document. > > > > Class or an object of a class? > > Exactly -- here's where such analogies can fall flat on their > collective faces. > > On can argue that the XML document type is equivalent to an abstract > Java interface, that the XML document is equivalent to a class > implementing that interface, and that the various transformations of > that XML document (formatted output, database tables, lawn-sprinkler > spinning, etc.) are equivalent to Java objects instantiating the > class. > > On the other hand, as you point out, it is just as easy to argue that > the document type is the equivalent to the class, and that the > document is equivalent to an object instatiating the class. Or you can argue that each class represents an Element. The enclosing Document is merely a container for all of these elements. In the XML Framework we have done, this is exactly how handlers are used for Elements by logically mapping XML Elements to Java classes. The handler for every sub-element is dynamically generated as needed. You could say this is a data-driven approach and works quite well for most applications, but for some applications I can see its limitations. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Aug 12 20:37:47 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:56 2004 Subject: REQ: ISO 8601 Comments Message-ID: <008501bdc61e$fcc09540$2ee044c6@arcot-main> Those of us working on the XLF (Extensible Log Format) are faced with the issue of deciding on the timestamp format. I thought it would be prudent to seek comments on the subject in general and specifically on use of the ISO 8601 standard from the XML-DEV members. The choices we are considering are: 1. Single timestamp attribute using ISO 8601 2. Single timestamp attribute using custom format designed for searching, sorting, and parsing efficiency. 3. Timestamp info broken up into multiple attributes (year, month, date, hour, minute, second, milliseconds, nanoseconds. 4. Timestamp info broken up into two or three attributes (year/month/date, hour/minute/second, etc.) with the possibility of using ISO 8601. A related side issue is whether to require global time or allow local time as well. It is interesting to note that the recently released DCD spec uses ISO 8601 subset (whatever that means). Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Wed Aug 12 20:50:04 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:56 2004 Subject: REQ: ISO 8601 Comments In-Reply-To: <008501bdc61e$fcc09540$2ee044c6@arcot-main> Message-ID: On Wed, 12 Aug 1998, Don Park wrote: > Those of us working on the XLF (Extensible Log Format) are faced with the > issue of deciding on the timestamp format. I thought it would be prudent to > seek comments on the subject in general and specifically on use of the ISO > 8601 standard from the XML-DEV members. Has anyone tackled the problem of general time representation in XML yet? I kind of wondered this before when I was whipping up a quick XML application to create my timesheets for work. I am not at all familiar with the time standards out there, but it would be handy if someone wrote a DTD for time info that we could all reuse. On the more general note...is there a repository for general domain nonspecific DTD's for stuff like times, dates, directory listings, etc? It would be nice if we could have one place for all this, and software for parsing and representing information stored in these formats. I mean, as soon as I find myself creating declarations for stuff like datetime I know someone else must have done it already, and probably have a Java class which can load itself using SAX events. What are the large companies such as Microsoft using for this in stuff like Office 2000? --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 12 21:04:11 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:56 2004 Subject: REQ: ISO 8601 Comments In-Reply-To: <008501bdc61e$fcc09540$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980812200335.3d3f9bae@pop3.demon.co.uk> At 11:27 12/08/98 -0700, Don Park wrote: >Those of us working on the XLF (Extensible Log Format) are faced with the >issue of deciding on the timestamp format. I thought it would be prudent to >seek comments on the subject in general and specifically on use of the ISO >8601 standard from the XML-DEV members. Thanks very much for raising this, Don. It's an issue I suspect a lot of us are wrestling with. A communal solution would be extremely valuable. In general I suspect that most people using XLF are also going to be dealing with date/times in other contexts so XLF should be friendly to those. I also think that you can't necessarily rely on everyone converting to global time (e.g. people can transcribe the time from the log but may make mistakes when converting.) I wrote a date class for JUMBO using Java 1.02 and now it's broken because Java 1.1. uses a different approach which I still haven't figured out - it requires the use of Calendar, etc. [1]. (all the 1.02 methods are deprecated). Dates are trickier than they look and I wouldn't suggest that people wrote perl scripts to convert them. I would therefore always allow raw date-times as an option (in ISO 8601 format of course). P. [1] private help by e-mail gladly accepted :-) > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 12 21:15:59 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:56 2004 Subject: XML libraries (was ISO 8601 comments) In-Reply-To: References: <008501bdc61e$fcc09540$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980812201415.3ae743ea@pop3.demon.co.uk> At 11:44 12/08/98 +0000, Chris Hubick wrote: [...] > On the more general note...is there a repository for general >domain nonspecific DTD's for stuff like times, dates, directory listings, >etc? It would be nice if we could have one place for all this, and >software for parsing and representing information stored in these formats. >I mean, as soon as I find myself creating declarations for stuff like >datetime I know someone else must have done it already, and probably have >a Java class which can load itself using SAX events. What are the large >companies such as Microsoft using for this in stuff like Office 2000? I completely agree with this - I make this sort of suggestion every two months or so on XML-DEV. The collection of additional libraries for XML (in common languages like Java, Perl, C(++)) would be of enormous value. Some should be directly related to XML functionality (e.g. isValidXMLName(String version)) while others would provide CDC-like support. As an example, isValidXMLName() is probably liftable from various parsers (I am sure it's well exposed in XML4J). It takes time, of course, and to do it as a virtual community would be an enormous challenge. A first step would be to identify that functionality where it already exists in publicly available software. And for authors to announce this availability when the announce software. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 13 00:00:30 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:56 2004 Subject: Revised NamespaceFilter Message-ID: <35D21069.DBA7341E@locke.ccil.org> A revised NamespaceFilter SAX parser, conforming (more or less) to the new namespace draft, is now available at: http://www.ccil.org/~cowan/XML/ns.jar . This is source code only. It now looks *exactly* like a regular SAX parser, and can be specified to any SAX application using -Dorg.xml.sax.parser=org.ccil.cowan.sax.NamespaceFilter. The real SAX parser must be specified as the value of the Java property org.ccil.cowan.sax.ParserFilter.org.ccil.cowan.sax.NamespaceFilter. Yes, I know it's ugly. This version uses the dagger (U+2020) in UniversalNames to separate the URI from the localPart. When the event structure for namespace-aware SAX parsers settles, I will modify it to use that. Note that the JDK1.1.5 console driver prints the dagger as "?", but it isn't really a "?". Feedback is earnestly solicited. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 13 00:09:30 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:56 2004 Subject: Forthcoming: UnDOM, InheritanceFilter, LocalMarkupFilter Message-ID: <35D2127E.FB38A2AD@locke.ccil.org> New projects soon to be forthcoming: UnDOM: a SAX parser that reads a org.w3c.dom.Document rather than an InputSource, and generates the appropriate SAX events for each object in the DOM document tree. This was originally going to be called "DOMinion", as being the opposite of "FreeDOM", but the latter is changing its name. UnDOM should work with any conformant Java DOM implementation, and allows tricks like parsing a file into a DOM and then replaying it multiple times. InheritanceFilter: a SAX parser filter that detects inherited attributes and returns them as part of every element within the scope. Initially only "xml:space" and "xml:lang" are inherited, but an application may add any attributes it likes. In addition, a PI will allow a document to specify such attributes too. LocalMarkupFilter: a SAX parser filter that detects and expands locally defined markup characters within XML character data. This is a simpler analogue of SGML shortrefs, but (because it is less flexible) can be done after ordinary XML parsing rather than integrated with it. It eliminates some of the need to parse character data with a separate post-XML parser. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Thu Aug 13 01:17:12 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:03:56 2004 Subject: Java class != XML entity References: Message-ID: <35D22244.DAFED6E7@allette.com.au> > The problem is that we don't have a good name for a collection of XML > documents working tightly together, the way that a collection of Java > classes can work in an applet or application -- "web" seems too loose, > and "docuverse" seems too New-Age. Any suggestions? What about "weaves" - it leaves scope to define things like looms (that create weaves) and strands (generally the equivalent of an XML document). -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Aug 13 01:31:06 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:57 2004 Subject: Forthcoming: UnDOM, InheritanceFilter, LocalMarkupFilter In-Reply-To: <35D2127E.FB38A2AD@locke.ccil.org> Message-ID: <3.0.1.16.19980813003101.4c370bbe@pop3.demon.co.uk> At 18:09 12/08/98 -0400, John Cowan wrote: >New projects soon to be forthcoming: Looks brilliant. The InheritanceFilter is exactly what I have been asking for. (At least I assume it will be). You obviously enjoy this :-). P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tln at insect.sd.monash.edu.au Thu Aug 13 02:54:13 1998 From: tln at insect.sd.monash.edu.au (Thuy-Linh Nguyen) Date: Mon Jun 7 17:03:57 2004 Subject: [help]xml4j (linux) Message-ID: <199808130057.KAA06057@insect.sd.monash.edu.au> Hi ! Thank you Ross, for reminding me that :-) The problem is requoted here: >Now jre seems to work ok. But when running this command: >>jre -cp xml4j.jar trlx -d personal.xml >I got this error: >>SIGSEGV 11* segmentation violation >> >>Full thread dump: >>Killed >I'm running xml4j 1.0.4 and jdk 1.1.3. I've tried >>jre -cp xml4j_1.0.4.jar trlx -d personal.xml >and still got the same error Solution: change to jdk1.1.5 ! I'm not sure whether my jdk1.1.3 installation has something wrong with it, or the 1.1.3 version does not work with xml4j. I got both of them on my machine, and a soft link from "java" to jdk1.1.3. All what I did was to change "java" to link to jdk1.1.5. Cheers, Thuy-Linh. > Date: Wed, 12 Aug 1998 20:11:10 +1000 > To: Thuy-Linh Nguyen > From: Ross Moore > Subject: Re: [help]xml4j (linux) > >Hi ! > >I've solved my problem !!! :-))) Sorry to bother you ! > > > Glad to hear it... > > ...but would you please give a brief indication of what was wrong, > so it's on record in case it happens to someone else too > --- even if only something silly like not setting a path variable. > > That fact that you had a problem is already on record, > so the solution ought to be there as well. > > Cheers, > > Ross Moore > **************************************************************************** Thuy-Linh Nguyen CSSE, PO Box 197, Monash Univerisity, Caulfield East, VIC 3145, Australia Ph: 61-3-9903-2041, Fax: 61-3-9903-1077, http://www.sd.monash.edu.au/~tln/ **************************************************************************** xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Aug 13 05:17:21 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:57 2004 Subject: Java class != XML entity References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> <199808121204.IAA00214@unready.megginson.com> Message-ID: <35D25A4C.63A6@hiwaay.net> David Megginson wrote: > > > ... Colonized namespaces can contain property values from different > > classes of objects in a single document yes? To me as an SGMLer, a > > colonized document *looks like* an SGML document with multiple > > doctype statements. > > Or a class implementing multiple interfaces (sorry, I couldn't > resist). Ok. It's all hanging under an object tree with a classID in the toys they give me at work. Sigh.. we are MSThralls and while it may not be kosher, the code runs. :-) If wrong, kick me. An ns attribute addresses a schema. That schema defines the namespace. In some examples, that points to a DTD, doing the job a Doctype does without the other stuff and no assertion about the capability of the schema except that it can be used to disambiguate the namespace for properties in the local scope. In others, it points to a classID in a registry. One might be semi-sorta-kinda-liftTongue BNF, and the other is, here in ThrallLand, an Active-X object. So it looks to me like both models are right and both represent different things. For the purposes of creating a compound instance, namespaces look good. Validation? Having one file with multiple parse/validation contexts seems to go way beyond the skill of the DePH, and is maybe HarderThanSGML????? Where are those simple requirements? Ok, what IS a compound document type definition (CDTD)? It is a very interesting problem. Here is my challenge: regardless of public relations and so on, an SGML DTD is a reasonable thing to look and use to eyeBall parse a file given resolution of the parameter entities. It takes a little practice, but most oldSGMLers can do it. An XML compound DTD should also provide this ability. len PS: I promise to read XML-Data ASAP. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From avirr at LanMinds.Com Thu Aug 13 05:22:25 1998 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:03:57 2004 Subject: REQ: ISO 8601 Comments In-Reply-To: References: <008501bdc61e$fcc09540$2ee044c6@arcot-main> Message-ID: > On the more general note...is there a repository for general >domain nonspecific DTD's for stuff like times, dates, directory listings, >etc? It would be nice if we could have one place for all this, and >software for parsing and representing information stored in these formats. >I mean, as soon as I find myself creating declarations for stuff like >datetime I know someone else must have done it already, and probably have >a Java class which can load itself using SAX events. What are the large >companies such as Microsoft using for this in stuff like Office 2000? XML Exchange (http://www.xmlx.com/) is a good location for this kind of thing. It's now sponsored by CommerceNet and I'm sure we could get an "essential tool" category installed. Avi ________________________________________________________________ Avi Rappoport, Web Site Search Tools Maven Search Tools Consulting Site: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jylee at t2000.co.kr Thu Aug 13 05:50:50 1998 From: jylee at t2000.co.kr (Jiyun Lee) Date: Mon Jun 7 17:03:57 2004 Subject: [Q]single Vs. double quote in representing AttValue Message-ID: <01BDC6B8.BAF6CAE0@jylee.t2000.re.kr> I found some documents which use single quotation marks to surround attribute's values. ex. from XML spec in XML : ......... decl. Is there any differences between sigle quote and double quote in representing the attribute's value? In the spec, both are possble. I'd like to know the rule for using them, if the rule exists. Thank you inadvance. __ Lee, Jiyun Technical Center, Techno2000 Project, Inc. E-mail : jylee@t2000.co.kr 807 Wallpyung-dong Seo-gu Voice : +82-42-483-2851 Taejon, Korea Fax : +82-42-483-2854 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 13 06:21:08 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:03:57 2004 Subject: [Q]single Vs. double quote in representing AttValue References: <01BDC6B8.BAF6CAE0@jylee.t2000.re.kr> Message-ID: <35D26988.2A074D3D@allette.com.au> Jiyun Lee wrote: > Is there any differences between sigle quote and double quote > in representing the attribute's value? In the spec, both are possble. > I'd like to know the rule for using them, if the rule exists. No, there's no difference. This has been carried through as a limited means of presenting attribute values that contain quotation marks as data characters. For instance, you might use: or but still not or as the first occurrence of a quotation mark that matches the opening one delimits the attribute value. The rule is - be careful... -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Aug 13 09:57:10 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:57 2004 Subject: Helping with specific problems (was Re: [help]xml4j (Linux)) In-Reply-To: <199808130057.KAA06057@insect.sd.monash.edu.au> Message-ID: <3.0.1.16.19980813083613.4d7fdd64@pop3.demon.co.uk> At 10:54 13/08/98 +0000, Thuy-Linh Nguyen wrote: [... about a problem with xml4j ...] and then wrote in great jubilation... > >> >Hi ! >> >I've solved my problem !!! :-))) Sorry to bother you ! >> > and Ross Moore advised... >> Glad to hear it... >> >> ...but would you please give a brief indication of what was wrong, >> so it's on record in case it happens to someone else too >> --- even if only something silly like not setting a path variable. This is exactly what we'd like, and thanks for suggesting it. Help of this kind can make the difference between getting some sleep and none at all :-). Java has particular problems with CLASSPATH and also loading incompatible class libraries. I think I had the latter when I was using an out-of-date Jar file for one of the parsers. Quite difficult to pick up. BTW there was a discussion on XML-DEV some months ago about how Java could stamp versions of classes so it was impossible to pick up the wrong ones. Has that made it into JDK1.2 and if so, is it recommended? P. BTW many thanks to those who wrote privately to me and pointed out that java.text.SimpleDateFormat is the class to start using instead of java.util.Date. It works reasonably well, but doesn't seem to throw errors on things like 1998-08-32 Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Aug 13 10:50:42 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:57 2004 Subject: James Anderson's table References: <35D1A613.A9CD0EFD@locke.ccil.org> Message-ID: <35D2AAAC.D1018204@mecomnet.de> John Cowan wrote: > > [... yes, thank you.] > > But anyway, here are the correct values, based on the principle > that a value defaulted from the DTD is equivalent in every way I am not certain that this is "correct". As I had noted in the "cover note", I had followed one of the alternatives: IV: for the moment, i've chosen the precedence tag-content, bindings-from-containing-elements, attribute-defaults where the bindings-from-containing-elements takes its initial value from the xml-decl. The justification is that lexically apparent bindings (modulo the answer on entities) take precedence over declared defaults. One could reasonable take that a step further, and argue that the distinction fixed v/s simply default on a declared attribute should figure here as well, with the effect that fixed defaults take precedence over the bindings in the lexical context, while simple defaults do not. I didn't do that, but the information is there to make the distinction, and I don't see anything "wrong" with it. > to one explicitly present in the instance (except of course that > if both are available, the explicit one takes precedence): > > ... > > The cell "cb" vs. "cd" can come out either way, depending on which > is the nearer ancestor. This is also not self-evident. The presence of the lexically apparent binding could quite reasonably be said to take precedence. I would hestitate to say proximity is the right criteria for precedence until either I've seen some 'real' instances or the standard describes the situation and specifies how to resolve it. [Even then I might differ on whether it was "right", but at least I'd be certain about what to implement...] xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From David.Rosenborg at xsse.se Thu Aug 13 11:01:25 1998 From: David.Rosenborg at xsse.se (David Rosenborg) Date: Mon Jun 7 17:03:57 2004 Subject: John Cowan's view on SAX extensions for ns drafts References: <3.0.1.16.19980811202739.6c2fbcae@pop3.demon.co.uk> <35D17985.5F8EA280@xsse.se> <35D1A282.E3B2ABE@locke.ccil.org> Message-ID: <35D2AAD2.8B735B0B@xsse.se> John Cowan wrote: > > David Rosenborg wrote: > > > Is it really necessary for the parser to deal with namespaces at > > all (if we don't consider namespace aware validation for the moment)? > > Depends what you think "the parser" is. My design was for something > that a parser could implement if it wanted to, but could also be > layered over a ns-blind parser. > Yes, sorry, my question was irrelevant. Still I think that the NamespaceResolver should not be part of the event. One reason, as I said, is that it could easily live as a utility on the application side and it would then better match the other events in style. A second, and more important reason I think, is that as it is specified now, it introduces a new kind of state. This state is transient just as the state of AttributeLists. The difference is that it lives beyond the method handling the event and is terminated at some time later. I think this adds an unnecessary complexity to SAX. Instead you could provide a helper interface and even an NamespaceEnabledHandlerBase that implemented that interface together with the namespace handler interface. Then you could write, without worrying about namespace scope and state at all: class Foo extends NamespaceEnabledHandlerBase { public void startElement (String name, AttributeList attributes) throws SAXException { UniversalName uname = resolveElementName (name); ... } } ______________________________________________________________________ David.Rosenborg@xsse.se Stockholm Stock Exchange xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Aug 13 13:08:26 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:57 2004 Subject: XP 0.4 available Message-ID: <35D2C5E7.EB8C0D9B@jclark.com> XP 0.4 is now available. See http://www.jclark.com/xml/xp/ for more information. The main change in this release apart from bug fixes is that XP now makes available much more information about the markup of the document (non-ESIS information) including information about comments, entity references and the document type. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricker at xmls.com Thu Aug 13 13:16:20 1998 From: ricker at xmls.com (Jeffrey Ricker) Date: Mon Jun 7 17:03:58 2004 Subject: XSA proposal In-Reply-To: <3.0.1.32.19980807102759.00cf8480@ifi.uio.no> References: <3.0.32.19980805133922.00a9be4c@207.34.179.21> Message-ID: Lars, My first reaction was just like Tim's: this is OSD. But then I saw that it was more of the e-commerce part rather than the mechanics of software distribution. Am I right? If so, perhaps it should be a part of a larger effort. Have you spoken to the RosettaNet project about your ideas? Jeffrey Ricker ricker@xmls.com At 10:27 AM 8/7/98 +0200, Lars Marius Garshol wrote: > >* Lars Marius Garshol >> >>This is a proposal for XML Software Autoupdate, a system for >>automatically keeping track of new releases of software products. > >* Tim Bray >> >>Isn't this what OSD, from MS & Marimba, is supposed to do? > >Yes, in a sense. However, XSA concerns itself with discovering >new versions and changed addresses, while OSD goes much further, >and omits some of the most useful parts of XSA. > >Compare the example below from the OSD spec with the XSA sample >and I think you'll see what I mean. I looked at OSD before I >started this, but skipped it as it simply wasn't suitable for >my purposes. > > > Solitaire > Solitaire by FooBar Corporation > > > > > > > > > > > > > > > > > > > > > > >--Lars M. > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Aug 13 13:33:29 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:58 2004 Subject: LISTRIVIA (was Re: XSA proposal) In-Reply-To: References: <3.0.1.32.19980807102759.00cf8480@ifi.uio.no> <3.0.32.19980805133922.00a9be4c@207.34.179.21> Message-ID: <3.0.1.16.19980813123337.09f7d666@pop3.demon.co.uk> At 07:11 13/08/98 -0400, [... an XML-DEVer] wrote: [... a short message, followed by unnecessary quoting of the previous longer one including the xml-dev sig...] P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Aug 13 14:25:04 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:58 2004 Subject: Java class != XML entity In-Reply-To: <35D25A4C.63A6@hiwaay.net> References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> <199808121204.IAA00214@unready.megginson.com> <35D25A4C.63A6@hiwaay.net> Message-ID: <199808131223.IAA00210@unready.megginson.com> len bullard writes: > If wrong, kick me. An ns attribute addresses a schema. > That schema defines the namespace. The namespace URI is simply a unique prefix that can be shared by a collection of names -- it is not guaranteed to point to anything at all (some people wanted to *forbid* it from pointing to anything), nor is it guaranteed that all names with the same prefix are defined by the same schema (or by any explicit schema). > PS: I promise to read XML-Data ASAP. I'd recommend starting with DCD, which is newer. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Aug 13 14:27:03 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:58 2004 Subject: XSA proposal In-Reply-To: References: <3.0.1.32.19980807102759.00cf8480@ifi.uio.no> <3.0.32.19980805133922.00a9be4c@207.34.179.21> Message-ID: <3.0.1.32.19980813142157.0072b968@ifi.uio.no> * Jeffrey Ricker > >My first reaction was just like Tim's: this is OSD. But then I saw that it >was more of the e-commerce part rather than the mechanics of software >distribution. Am I right? To tell you the truth my first reaction now was that I need to rewrite the motivation part. :-) XSA is supposed to solve a very simple problem: I and lots and lots of other people maintain lists of software and we have a very difficult time keeping them up to date. New versions are released that make our descriptions obsolete, email addresses change, links die, product names change etc etc If developers could maintain XSA documents that listed these things anyone who was interested could poll them for changes at intervals and discover these things automatically. Today most software list maintainers simply don't even try to keep their coverage up to date and instead rely on developers to do it for them. The developers usually have their products listed in too many places for this to be feasible, hence XSA. What I've done besides the specification is to write a Java API and a client that can be run from a cron job so that list maintainers (and whoever else might be interested) can get email when something happens. E-commerce never entered the picture, but that's not to say that an expanded version might be useful in such a context as well. Or that XSA might not make use of information published for e-commerce purposes. >If so, perhaps it should be a part of a larger effort. That would suit me well. For this to work people need to write actual XSA documents, publish them and update them. This is the Achilles heel of the project: if nobody does that XSA is dead. The more official this looks the greater the chance that people will take it seriously to do it. (Which is why I've now added OSD support. It's tested and it works, as far as it goes.) To alleviate this I've made two CGI scripts that give users a form to fill out and return a validated XSA document ready for publishing. That simplifies creation, but the real problem is to be taken seriously. Also, the reason I've kept XSA as simple as possible (and omitting almost everything in OSD) is to make the documents easy to create and modify. For the purpose I had in mind I don't see any benefits to more information, but that would make XSA harder to get started with. >Have you spoken to the RosettaNet project about your ideas? Never heard of it, I'm afraid. The stuff I dug up with AltaVista looks like something that it might be possible to integrate with XSA (sort of like I've now done with OSD), but I just didn't know about it before. Do you have some URLs with details and perhaps some contact addresses? --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Thu Aug 13 17:07:36 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:03:58 2004 Subject: DCD and namespaces. Message-ID: <00bd01bdc6cc$b68c06a0$a9acdccf@ix.netcom.com> Hi, a quick question about DCD. Is a namespace declaration necessary in the same way it is in XML-Data, and if it is which of the following (if either) is correct. Example1. http://w3.org/Schemas/DCD Greeting Data Hello World! Example2 Greeting Data Hello World! TIA, Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 13 17:51:05 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:58 2004 Subject: James Anderson's table References: <35D1A613.A9CD0EFD@locke.ccil.org> <35D2AAAC.D1018204@mecomnet.de> Message-ID: <35D30B4E.AE306CD0@locke.ccil.org> james anderson wrote: > IV: for the moment, i've chosen the precedence > tag-content, > bindings-from-containing-elements, > attribute-defaults > where the bindings-from-containing-elements takes its initial value from the xml-decl. This cannot be correct XML, and what is not correct XML is not correct XML-ns. An XML processor, as Tim Bray pointed out the other day, must implement attribute defaulting (modulo problems with not reading external DTD/parameter entities), but need not tell the application whether the attribute was explicitly present or defaulted. Therefore, no application can make distinctions on this basis. An attribute of the current element, explicit or defaulted, takes precedence over an attribute inherited from an ancestral element. The final example in clause 2.12 of the XML Rec is indicative: it shows a variety of elements with default values for xml:lang, also an inherited attribute. The intent of that example is clearly that "poem" elements are French by default, and "gloss" and "note" elements are English by default, independent of context. All other elements presumably inherit the language from context. > This is also not self-evident. The presence of the lexically apparent binding > could quite reasonably be said to take precedence. You value explicit attribute values over implicit ones in a way that has no warrant in the XML Rec. > I would hestitate to say > proximity is the right criteria for precedence until either I've seen some > 'real' instances or the standard describes the situation and specifies how to > resolve it. Unfortunately, all the examples in the draft are DTD-less. Nevertheless, based on the precedent of xml:lang and Tim's remarks, I feel sure that I am correct. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Thu Aug 13 17:59:04 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:03:58 2004 Subject: XSA proposal In-Reply-To: <3.0.1.32.19980813142157.0072b968@ifi.uio.no> Message-ID: On Thu, 13 Aug 1998, Lars Marius Garshol wrote: > XSA is supposed to solve a very simple problem: I and lots and lots of > other people maintain lists of software and we have a very difficult > time keeping them up to date. New versions are released that make our > descriptions obsolete, email addresses change, links die, product names > change etc etc Yes. > If developers could maintain XSA documents that listed these things anyone > who was interested could poll them for changes at intervals and discover > these things automatically. Today most software list maintainers simply > don't even try to keep their coverage up to date and instead rely on > developers to do it for them. The developers usually have their products > listed in too many places for this to be feasible, hence XSA. Linux developers (especially those using RedHat Package Manager, which - side note to Tim - is one of the finest pieces of software for configuration management I've ever worked with) have something like this already, though not markup-language-based, called the Linux Software Map. http://www.linux.org/apps/lsm.html http://www.ExecPC.com/lsm/ Every piece of software produced for (or ported to) Linux is expected to have a .lsm file included in its distribution. The format of the document is simple, and described in this readme: ftp://ftp.execpc.com/pub/lsm/LSM.README I think this would make an excellent foundation for an XML application. It might be useful to look at this as well as the IAFA format also described the the above readme. S (my opinions only, not those of the WSP :) Heh. -- http://a.jaundicedeye.com | "Do not allow your children to become http://hesketh.com/schampeo/ | desensitized to violence. Beat them http://dhtml.hesketh.com | harder every day!" - the Onion xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Thu Aug 13 18:06:32 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:03:58 2004 Subject: DCD and Global attributes. Message-ID: <00cb01bdc6d4$bf6b7960$a9acdccf@ix.netcom.com> Hi, it is my understanding that an AttributeDef can take a attribute/value Boolean of Global. For example in HTML nearly all elements can take the attributes ?class, style, name, id, type etc.? If we were using DCD to define the HTML4 schema we could do the following etc Which mean that the attributes would apply to all the ElementDef?s declared in the element simply by adding. Attribute= ?class? For example (I assume that one can convert the attribute element in this way for the second syntax form) This could lead to a lot of repetious mark-up in a large document. It struck me that it may be preferable to default every thing to the global attributes, and provide a means of exempting elements that we do not wish them to apply to. Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 13 18:13:35 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:58 2004 Subject: What XML parsers have to report (was Re: James Anderson's table) In-Reply-To: <35D30B4E.AE306CD0@locke.ccil.org> References: <35D1A613.A9CD0EFD@locke.ccil.org> <35D2AAAC.D1018204@mecomnet.de> <35D30B4E.AE306CD0@locke.ccil.org> Message-ID: <199808131611.MAA00315@unready.megginson.com> John Cowan writes: > james anderson wrote: > > > IV: for the moment, i've chosen the precedence > > tag-content, > > bindings-from-containing-elements, > > attribute-defaults > > where the bindings-from-containing-elements takes its initial value from the xml-decl. > > This cannot be correct XML, and what is not correct XML is not correct > XML-ns. An XML processor, as Tim Bray pointed out the other day, > must implement attribute defaulting (modulo problems with not reading > external DTD/parameter entities), but need not tell the application > whether the attribute was explicitly present or defaulted. One of the new items of work assigned to the XML Working Group is the creation of a formal XML data model, specifying what information XML parsers must deliver to an application (but not how the information should be delivered -- that's up to formal or informal standards like the DOM and SAX). This matters quite a bit because right now, a processor is not required to report attribute values at all (for example); here's what the spec says (3.3.2, "Attribute Defaults"): If a default value is declared, when an XML processor encounters an omitted attribute, it is to behave as though the attribute were present with the declared default value. Later, in 3.3.3, the spec does include the words "Before the value of an attribute is passed to the application or checked for validity...", implying an intention, at least, that the value should be passed on, but it's never stated as a requirement. Here's what the XML 1.0 REC explicitly requires parsers to report to applications: 1) Processing instructions (2.6). 2) All non-markup characters, including whitespace (2.10) [presumably only those within the document element, though the spec is unclear]. 3) Normalised line-ends (2.11) [exception to #2]. 4) The external identifiers of unparsed entities and notations (4). 5) Unreferenced external parsed entities (4.4.3). Note that elements and attributes are _not_ in the list (oops!). Only the common sense (or blissful ignorance) of parser writers has guaranteed that that information is always available. In any case, John is correct: it shouldn't matter whether an attribute value is defaulted or specified. As a logical task, namespace processing takes place *after* XML 1.0 parsing and validation, not before -- for SGML weenies, think of namespace processing as a transformation applied to a grove. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 13 18:26:00 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:58 2004 Subject: Revised NamespaceFilter Message-ID: <35D31355.5103A900@locke.ccil.org> I have had a report that my ns.jar downloads in garbled form. The trouble arises because the Web server at www.ccil.org (which I do not control) reports unknown extensions as type "text/plain", so people downloading from non-Unix sites are getting unwanted LF->CRLF conversions. Please download from http://www.ccil.org/~cowan/XML/ns.zip instead. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Veillard at w3.org Thu Aug 13 18:49:09 1998 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:03:58 2004 Subject: XSA proposal In-Reply-To: ; from Steven Champeon on Thu, Aug 13, 1998 at 11:58:44AM -0400 References: <3.0.1.32.19980813142157.0072b968@ifi.uio.no> Message-ID: <19980813124837.B27268@w3.org> Steven Champeon wrote: > Linux developers (especially those using RedHat Package Manager, which - > side note to Tim - is one of the finest pieces of software for configuration > management I've ever worked with) have something like this already, though > not markup-language-based, called the Linux Software Map. > > http://www.linux.org/apps/lsm.html > http://www.ExecPC.com/lsm/ I guess you should have a look at my RPM RDF database. Principle: I mirror apprximately 15000 RPM packages from various distributions I use a specific tool rpm2html [1] to extract all the metadata from the packages, it dump them as a set of hyperlinked HTML [2] pages (the link expressing verious dependencies between packages and distributions). The same informations are encoded as an RDF database [3]. I also developped a client side tool rpmfind [4] which uses HTTP to query the database and select the best packages for the current user setup (by looking at the local installed software base too !). This provide the user a list of packages to download to install a given software (e.g. to install gimp you may need an exotic graphic library not available on your system, rpmfind will solve that), then it also query the database for mirrors and try to find the nearest one, and does the FTP transfer for you if you want. This software is based on (sorry !) my own XML and RDF code [5], currently the database format is not valid XML but I will upgrade soon (probably within a week) to something decent (with new namespace encoding). The FTP and HTTP transfer are done using libWWW [6]. Example: ---------- /linux/RDF/redhat/5.1/i386/libc-5.3.12-27.i386.rdf --------- libc 5.3.12 27 i386 Linux Manhattan Red Hat Software Red Hat Software <bugs@redhat.com> Libraries Compability libraries for old libc.so.5 applications Older Linux systems (including all Red Hat Linux releases between 2.0 and 4.2, inclusive) were based on libc 5. This package includes these libraries and other libraries based on libc 5, allowing old applcications to run on glibc (libc 6) based systems. distributable * Tue May 05 1998 Cristian Gafton <gafton@redhat.com> - fixed postuninstall script * Mon Apr 27 1998 Prospector System <bugs@redhat.com> - translations modified for de, fr, tr * Tue Dec 23 1997 Cristian Gafton <gafton@redhat.com> - updated for the vsyslog() security-fixed libc - uses a BuildRoot * Mon Nov 10 1997 Erik Troan <ewt@redhat.com> - updated Xpm lib to one built w/ dependency info - added svgalib * Tue Sep 23 1997 Erik Troan <ewt@redhat.com> - added ncurses libraries * Mon Sep 08 1997 Erik Troan <ewt@redhat.com> - updated X libraries to 3.1.1 - added provides of libm.so.5 * Sun Aug 24 1997 Erik Troan <ewt@redhat.com> - initial build as compatibility package libc-5.3.12-27.src.rpm ftp://ftp.redhat.com/pub/redhat/redhat-5.1/SRPMS Tue May 5 23:54:21 1998 894426861 5420357 porky.redhat.com libc libc.so.5 libstdc++.so.27 libg++.so.27 libm.so.5 /sbin/ldconfig grep fileutils /lib/ld-linux.so.1 /bin/sh /usr/i486-linux-libc5/lib /usr/i486-linux-libc5/lib/libICE.so.6.0 /usr/i486-linux-libc5/lib/libICE.so.6.3 /usr/i486-linux-libc5/lib/libPEX5.so.6.0 /usr/i486-linux-libc5/lib/libSM.so.6.0 /usr/i486-linux-libc5/lib/libX11.so.6.1 /usr/i486-linux-libc5/lib/libXIE.so.6.0 /usr/i486-linux-libc5/lib/libXaw.so.6.1 /usr/i486-linux-libc5/lib/libXaw3d.so.6.1 /usr/i486-linux-libc5/lib/libXext.so.6.1 /usr/i486-linux-libc5/lib/libXext.so.6.3 /usr/i486-linux-libc5/lib/libXi.so.6.0 /usr/i486-linux-libc5/lib/libXmu.so.6.0 /usr/i486-linux-libc5/lib/libXpm.so.4.9 /usr/i486-linux-libc5/lib/libXt.so.6.0 /usr/i486-linux-libc5/lib/libXtst.so.6.1 /usr/i486-linux-libc5/lib/libc.so.5.3.12 /usr/i486-linux-libc5/lib/libform.so.1.9.9e /usr/i486-linux-libc5/lib/libg++.so.27.1.4 /usr/i486-linux-libc5/lib/libm.so.5.0.6 /usr/i486-linux-libc5/lib/libmenu.so.1.9.9e /usr/i486-linux-libc5/lib/libncurses.so.1.9.9e /usr/i486-linux-libc5/lib/libpanel.so.1.9.9e /usr/i486-linux-libc5/lib/libstdc++.so.27.1.4 /usr/i486-linux-libc5/lib/libtermcap.so.2.0.8 /usr/i486-linux-libc5/lib/libvga.so.1.2.11 /usr/i486-linux-libc5/lib/libvgagl.so.1.2.11 ----------------------------------------------------------------------- You can grab linux binaries and source at: ftp://rufus.w3.org/pub/rpmfind/ There is now quite a few mirror for the HTML pages and 2 mirrors for the RDF database, Daniel [1] http://rufus.w3.org/linux/rpm2html/ [2] http://rufus.w3.org/linux/RPM/ [3] http://rufus.w3.org/linux/RDF/ [4] http://rufus.w3.org/linux/rpm2html/rpmfind.html [5] http://dev.w3.org/cgi-bin/cvsweb [XML,rpmfind,rpm2html] [6] http://www.w3.org/Library/ -- Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks : Tel : +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html, Fax : +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Thu Aug 13 18:55:24 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:03:58 2004 Subject: XSA proposal In-Reply-To: <19980813124837.B27268@w3.org> Message-ID: On Thu, 13 Aug 1998, Daniel Veillard wrote: > I guess you should have a look at my RPM RDF database. *jaw drops* Wow. Um, yeah, like *that*. :) *bows* -- http://a.jaundicedeye.com | "Do not allow your children to become http://hesketh.com/schampeo/ | desensitized to violence. Beat them http://dhtml.hesketh.com | harder every day!" - the Onion xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 13 19:52:29 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:58 2004 Subject: Java class != XML entity Message-ID: <5030300024032611000002L012*@MHS> >I was writing about Java source files, the relevant scoping region for >package declarations. A Java file is a _compilation_ unit, not a class, >since it is possible (if not favored practice) to put several classes into >one source file. I agree that entities and include files are somewhat >similar, and that explains some of the problems with entities: potential >name clashes or namespace prefix capture by the entity referencing context. >Part of my point is in direct agreement with your point; all such >analogies are hazardous and should be treated like radiactive material >-- potentially useful, and potentially deadly. I think though that drawing from the existing body of experience is still important, right? When I was polled about the namespace draft by our folks, I said I thought it should go forward because the issues of scoping were well proven in existing programming languages. However, I (being still kind of new to the XML world) did not fully understand the new spec. If I had understood that it was not suggesting the use of namespaces in a way anything like that of the languages I had experience with, I probably would have said the opposite. Back to the C++ example... As someone rightly pointed out, its model is that of the "declare them all up front" genre. Scoping is not used to nest invocations of namespaces, but to nest the use of instances of types. And, it did not sink into my tiny reptilian brain that namespaces would be named by every individual user of them as apposed to being given a name and being used that way forever more by everyone. So the existing spec would be like this (in unreal pseudo code): using namespace Hubba as Bubba; Bubba::SomeType foo() { if (blah blah blah) { using namespace Jean as Bubba; return Bubba::SomeType(0); } } So is this 'legal' or not? It would depend upon the particular namespace mapped to Bubba at the time where the foo() method was prototyped I guess. But visually, I would be hard pressed to figure it out myself according to how convoluted a path I got foo() into my program by. I wouldn't want a progrmaming language that worked that way particularly, nor would I use it that way if it did provide those services. It would present all of the same problems that everyone else has brought up. I (and my compiler) could never know what Bubba::SomeType really meant without a lot of effort that isn't worth what you get out of it. It seems to me, if you were to follow the previous experience forward, you would have to go back to the "declare'em all up front" mechanism, and apply scoping only to those things that previous experience has shown it useful for, which would be 'variables' From david at megginson.com Thu Aug 13 21:39:24 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:58 2004 Subject: Revised NamespaceFilter In-Reply-To: <35D21069.DBA7341E@locke.ccil.org> References: <35D21069.DBA7341E@locke.ccil.org> Message-ID: <199808131938.PAA00385@unready.megginson.com> John Cowan writes: > This version uses the dagger (U+2020) in UniversalNames to separate > the URI from the localPart. When the event structure for > namespace-aware SAX parsers settles, I will modify it to use that. Why not use a space? It is forbidden in URIs and XML names as well, and looks a little cleaner. I'm still looking forward to trying out your code, if all of the dust in the rest of my life settles before Montr?al. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 13 22:02:39 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:59 2004 Subject: Revised NamespaceFilter References: <35D21069.DBA7341E@locke.ccil.org> <199808131938.PAA00385@unready.megginson.com> Message-ID: <35D34641.3A1D2D15@locke.ccil.org> David Megginson wrote: > Why not use a space? It is forbidden in URIs and XML names as well, > and looks a little cleaner. Because UniversalNames are conceptually unitary, and it's hard to see "http://www.baz.bar/zam FOO" as a unitary object (unless you come from the ITS world, where " " was the pathname delimiter). I'm switching to "^", which is ASCII but illegal in both URIs and Names. I've also simplified the property name for the underlying parser to just "org.ccil.cowan.sax.NamespaceFilter.useParser". > I'm still looking forward to trying out your code, if all of the dust > in the rest of my life settles before Montr?al. I hope so. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 13 23:19:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:59 2004 Subject: Local Markup Message-ID: <35D35842.6A7173E3@locke.ccil.org> The following is put forth for comments. 1. Abstract This document describes a local markup facility for XML. This serves some of the purposes of SGML short references, but can be layered over XML parsing rather than integrated into it. By declaring appropriate processing instructions, character data within selected elements with mixed content can be effectively turned into element content. Terms not defined here are as in the XML Recommendation. 2. Motivating Example A DATE element may appear in an XML document with #PCDATA content containing an ISO 8601 date, as follows: 1998-08-13T14:15:16 A conformant local markup processor, given appropriate PIs, can process this as if it were: 19980813141516 where the dashes have been turned into empty D elements, the T separating time and date (a feature of ISO 8601) has been turned into an empty T element, and the colons into empty C elements. In this way, the application reading this data can allow the XML parser to be the only parser, rather than having a separate date parser behind the XML parser. One possible set of relevant PIs are: The above interpretation, though much more useful than the raw character data, does not take into account the existence of hierarchical information. This document, therefore, also provides a way to make the interpretation come out as follows: 1998 08 13 14 15 16 (The indentation is shown here for clarity only.) This is still not as nice as actual eleements named YEAR, MONTH, DAY, etc., but preserves the structure of the original. Here are some PIs that do the job: 3. Processing Instructions There are two PIs used to support local markup. The PI target "LM-DEF" defines which characters are or may be local markup; the PI target "LM-USE" specifies when local markup is in effect. Both should appear before the start tag of the document element. Neither affects the DTD in any way. Both PIs use pseudo-attributes (PAs) in the style of the XML declaration; the pseudo-attributes may appear in any order. 3.1 LM-DEF Pseudo-Attributes These PAs are required in an LM-DEF PI. It is an error to have two PIs with the same "char" and "group" values. 3.1.1 "char" The "char" PA value has a value that either a Char or a numeric character reference, which the LM processor will expand. 3.1.2 "group" The "group" PA value matches Name. This Name is matched with the "group" pseudo-attribute in an LM-USE PI. 3.1.3 "element" The "element" PA value matches Name. It specifies the element name corresponding to the character defined by "char". 3.2. LM-USE Pseudo-attributes The "group" and "element" PAs are required in an LM-USE PI. The "model" PA is optional. It is an error to have two PIs with the same "element" value. [Query: maybe should be an error only if both "group" and "element" values are the same?] 3.2.1 "group" The "group" PA value matches Name. This Name is matched with the "group" pseudo-attribute in an LM-DEF PI. 3.2.2 "element" The "element" PA value matches Name. It specifies the name of an element type. The characters in the group specified by "group" are processed when found in the character data of elements with this name. 3.2.3 "model" The "element" PA matches Names. It names sub-elements which are to be placed as children of the "element" element. 4. Processing Model A conformant Local Markup processor reads and records all LM-DEF and LM-USE PIs. It then processes the rest of the document, searching for elements with names matching those declared in the "element" PA of some LM-USE PI. All other elements and markup remain unaltered. When an element with an associated LM-USE PI is found, its character data is searched for characters defined in LM-DEF PIs which share the same "group" PA as the element. These characters are the element's *local markup*, and the element is called the *base element*. Each local markup character has a corresponding element type. Local markup can be either *free* or *hierarchical*. 4.1 Free Local Markup Local markup is free in an element if it does not meet the conditions for hierarchical local markup. If the element associated with a markup character is not mentioned in the "model" PA corresponding to the base element, the markup is always free. Free local markup characters are processed as if the corresponding element was present in empty form. Thus if "!" has the element "BANG", then a "!" will be treated like "", as follows: foo!bar!baz is treated as if it were: foobarbaz 4.2 Hierarchical Local Markup Hierarchical local markup can be present only if the base element has an associated "model" PA. If so, then the elements mentioned in the "model" PA are made the child, grandchild, great-grandchild ... of the base element. For example: This is foo is treated as if it were: This is foo Local markup characters are processed hierarchically only if two conditions are met: the element corresponding to the character must be part of the model, and the character must appear as a child of the base element, not as part of some descendant of the base element. Thus, in the following: This is ! Empty !. Here is # the first "!" is hierarchical, but the second "!" and the "#" are free. A local markup character that is hierarchical is treated as if it were a set of end-tags followed by a set of start-tags. The end-tags are successively those from the end of the model, backward to and including the one associated with the character. The start-tags are the same but in reverse order. The previous example is therefore treated as if it were: This is Empty . Here is ignoring the extra whitespace shown here for clarity only. Using the second set of PIs in section 3, the element 1997T is treated as if it were: 1997 because the T generates , of which the last tag merges with the closing to form an empty PART element. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Aug 13 23:28:40 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:59 2004 Subject: Local Markup: addendum Message-ID: <35D35A67.7F9E6A24@locke.ccil.org> Having just written all this out, I am now considering doing it not with PIs but with attributes, in AF/XLink style. So if you don't like PIs, think of the pseudo-attributes as real attributes on random elements. Or maybe LM-DEF should be a PI and LM-USE should be attributes.... -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Fri Aug 14 03:28:47 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:59 2004 Subject: Java class != XML entity References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> <199808121204.IAA00214@unready.megginson.com> <35D25A4C.63A6@hiwaay.net> <199808131223.IAA00210@unready.megginson.com> Message-ID: <35D39257.2B70@hiwaay.net> David Megginson wrote: > The namespace URI is simply a unique prefix that can be shared by a > collection of names -- it is not guaranteed to point to anything at > all (some people wanted to *forbid* it from pointing to anything), Hmm. How is that better than having a Doctype root if subdocs were inlined? I can understand it not pointing to anything but only in the context of how FPIs work in Doctypes. So what am I to assume if I see a dt: prefix that has a classID in the ns attribute, and another that *appears* to point at a schema of some sort? > nor > is it guaranteed that all names with the same prefix are defined by > the same schema (or by any explicit schema). Outside a formal registry, I don't think that guarantee would work anyway as the long long long debates on URI/URN/URLs showed. John Cowan writes: >Not necessarily. An ns attribute has an URI (URL or URN) as its >value, but that URI doesn't have to point to anything in particular, >as long as it's unique and syntactically valid. Syntactically valid, OK. Unique? How is that enforced or proven? Yes, I watched the namespace debates. It is hard to tell what the namespace is good for if the ns attribute is essentially a valid but purposeless bit holder. Ok, it *indicates* a scope. ???? I realize something subtle is being defined, but maybe it is too subtle to be useful for much. Consider me standing up to type... If DCD isn't clearer than namespaces, than the HyTime drubbing goes down as one of the great crimes of critique. Precision aside, if the concepts and tools are harder to figure out than SGML and HyTime, this time next year I won't be the only one with a sore bottom. Wired and XavierMcLipps are watching. -) Ah so... back to reading the XML pages at www.microsoft.com which for some reason are understandable and have working code with which to test them. MSThralls rejoice. Another names for a colonized document: braid. len len bullard wrote: > If wrong, kick me. An ns attribute addresses a schema. > PS: I promise to read XML-Data ASAP. Read DCD instead, it's shorter and clearer. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Fri Aug 14 03:42:03 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:03:59 2004 Subject: DCD and Global attributes. References: <00cb01bdc6d4$bf6b7960$a9acdccf@ix.netcom.com> Message-ID: <35D39556.79A5@hiwaay.net> Frank Boumphrey wrote: > > It struck me that it may be preferable to default every thing to the global > attributes, and provide a means of exempting elements that we do not wish > them to apply to. Because I haven't read DCD yet, but will, take this with a grain of salt: this has the same awful feeling that putting include declarations on SGML DTD root element type declarations with excludes in branches did. Very messy if convenient at times. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Fri Aug 14 04:45:29 1998 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:03:59 2004 Subject: DCD and Global attributes. Message-ID: I think this is better handled by the use of inheritance. I.e. you create a base element that has all the attributes you wish to be "universal", and derive all you elements from this base. This re-uses a mechanism we want anyway, and allows finer grain control than universal vs. one-at-a-time. > -----Original Message----- > From: Frank Boumphrey [mailto:bckman@ix.netcom.com] > Sent: Thursday, August 13, 1998 9:09 AM > To: Charles Frankston > Cc: xml mailing list > Subject: DCD and Global attributes. > > > It struck me that it may be preferable to default every thing > to the global > attributes, and provide a means of exempting elements that we > do not wish > them to apply to. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 14 06:37:53 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:03:59 2004 Subject: Expat 1.0 available Message-ID: <35D3BB9F.A3779ECB@jclark.com> Expat 1.0 is now available. See http://www.jclark.com/xml/expat.html for more information. This is the first production release. The only changes since the last beta version are a few minor bug fixes. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Fri Aug 14 13:24:19 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:59 2004 Subject: Local Markup In-Reply-To: John Cowan's message of "Thu, 13 Aug 1998 17:18:58 -0400" References: <35D35842.6A7173E3@locke.ccil.org> Message-ID: John> John Cowan 0> In article <35D35842.6A7173E3@locke.ccil.org>, John wrote: John> The following is put forth for comments. John> John> 2. Motivating Example John> John> A DATE element may appear in an XML document with #PCDATA content John> containing an ISO 8601 date, as follows: John> John> 1998-08-13T14:15:16 John> John> A conformant local markup processor, given appropriate PIs, can John> process this as if it were: John> John> 19980813141516 John> John> where the dashes have been turned into empty D elements, the T John> separating time and date (a feature of ISO 8601) has been turned John> into an empty T element, and the colons into empty C elements. Are you trying to re-invent SGML's SHORTREF? -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Aug 14 15:01:51 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:00 2004 Subject: More on Namespaces In-Reply-To: <35D39257.2B70@hiwaay.net> References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> <199808121204.IAA00214@unready.megginson.com> <35D25A4C.63A6@hiwaay.net> <199808131223.IAA00210@unready.megginson.com> <35D39257.2B70@hiwaay.net> Message-ID: <199808141300.JAA00271@unready.megginson.com> len bullard writes: > David Megginson wrote: > > > The namespace URI is simply a unique prefix that can be shared by a > > collection of names -- it is not guaranteed to point to anything at > > all (some people wanted to *forbid* it from pointing to anything), > > Hmm. How is that better than having a Doctype root if subdocs > were inlined? I can understand it not pointing to anything but > only in the context of how FPIs work in Doctypes. Personally, I'd like to separate the issue of global names from that of document composition: I do not think that namespaces are a useful substitute for subdocuments (inline or out-of-line) -- that issue still needs to be dealt with. Namespaces simply allow an element or attribute to have a name that can be compared across documents and document types. The name is something that other facilities, such as schemas or stylesheets, can act upon, but it has no significance in itself. In other words, an element named "http://www.megginson.com/ + para" in one document and an element named "http://www.megginson.com/ + para" in a second document have the same name. Make of it what you will. > So what am I to assume if I see a dt: prefix that has a classID > in the ns attribute, and another that *appears* to point at > a schema of some sort? I'm not certain that I understand the question -- could you give an example? > If DCD isn't clearer than namespaces, than the HyTime drubbing > goes down as one of the great crimes of critique. > Precision aside, if the concepts and tools are harder to > figure out than SGML and HyTime, this time next year I > won't be the only one with a sore bottom. Wired and XavierMcLipps > are watching. -) The concepts underlying namespaces are simple enough (or could be, with a little rewriting): XML 1.0 elements and attributes have one-part names that are always local to the document; namespaces allow the transformation of those one-part local names into two-part global names, where the first part is a URI and the second part is a simple name. The WD contains much in the line of confusing and mostly-irrelevant philosophical musings that (I hope) will eventually be deleted -- if Len finds the spec confusing, I'm terrified of what will happen when it hits the webmasters. With the latest namespaces WD, however, XML can no longer fairly claim to be simpler or more transparent than SGML -- the contextual dependencies built into local scoping and defaulting are in the same class as the contextual dependencies built into SHORTREF and OMITTAG (both of which XML wisely discarded), though the algorithms for resolving the namespaces are considerably simpler. It is up to the reader to decide whether the fact of this complexity vindicates HyTime or indicts XML. The temptation to obfuscate is hard to resist. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From anderst at toolsmiths.se Fri Aug 14 15:04:46 1998 From: anderst at toolsmiths.se (Anders W. Tell) Date: Mon Jun 7 17:04:00 2004 Subject: Corba IDL to XML generator Message-ID: <35D36F3B.75F41CCF@toolsmiths.se> Hi All, Im just about to finish the first implementation of a Corba IDL to XML generator and Im not sure which DTD I should follow for the generated XML. Does anyone know of appropriate DTDs that i can use ? Or should I create one of my own ? Regards /Anders -- /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ / Financial Toolsmiths AB / / Anders W. Tell / /_/_/_/_/_/_/_/_/_/_/_/_/_/_/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Fri Aug 14 16:31:18 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:04:00 2004 Subject: Doctype dec and Namespaces In-Reply-To: Peter Jones's message of Wed, 12 Aug 1998 18:45:06 +0100 References: Message-ID: Peter Jones writes: > I've just been looking at the Namespaces WD of 2-Aug-98 > and I saw the following: > > doctypedecl ::= ' | PEReference | S)* ']' S?)? '>' > > I notice that a QName occurs in the definition. Does this mean that a > Namespace which is global for the (presumably valid) document is > declared between the and the doctype decl.? Nope. The QNames in the prolog are all interpreted as atoms for now. Namespace declarations are ONLY allowed on actual elements. The interaction of namespaces and validation has not yet really been addressed: wait for an update to the XML recommendation itself for that, I expect. The best short authoritative description of all this is in David Megginson's message to this list on 11 August (Message-Id: <199808112127.RAA01625@unready.megginson.com>), http://www.lists.ic.ac.uk/hypermail/xml-dev/9808/0395.html. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 14 18:43:05 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:00 2004 Subject: Local Markup References: <35D35842.6A7173E3@locke.ccil.org> Message-ID: <35D468F1.4C1A83E1@locke.ccil.org> Toby Speight wrote: > Are you trying to re-invent SGML's SHORTREF? Yes, but in a way that can be readily layered over SAX. Please examine my proposal on its own merit: the operative word is "re-invent". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Aug 14 18:55:10 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:04:00 2004 Subject: Local Markup Message-ID: <3.0.32.19980814095347.00a1ae00@207.34.179.21> At 05:18 PM 8/13/98 -0400, John Cowan wrote: >This document describes a local markup facility for XML. This serves >some of the purposes of SGML short references Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrgh! Another idea: let's mount a land invasion of Russia just as winter is setting in. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fblau at nina.snohomish.wa.gov Fri Aug 14 19:22:05 1998 From: fblau at nina.snohomish.wa.gov (Frank Blau) Date: Mon Jun 7 17:04:00 2004 Subject: HCFA 1500 DTD? Message-ID: <35D4708B.F7D74C7@nina.snohomish.wa.gov> Does anyone have information about a DTD or even a HTML version of the HCFA 1500 form? Frank xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 14 19:54:59 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:00 2004 Subject: Revised NamespaceFilter References: <35D21069.DBA7341E@locke.ccil.org> <199808131938.PAA00385@unready.megginson.com> <3.0.1.16.19980813232008.3b973380@pop3.demon.co.uk> Message-ID: <35D479C7.C7306295@locke.ccil.org> Peter Murray-Rust wrote: > So am I :-) - I still have problems. The zip file expands in Winzip but > gives 0-length files on W95 machine and invalid headers on 3.1 (under > winzip). Or is it pkzipped? I'm still bewildered. I have unzipped the files, which are now at http://www.ccil.org/~cowan/XML/ParserFilter.java http://www.ccil.org/~cowan/XML/NamespaceFilter.java http://www.ccil.org/~cowan/XML/NamespaceFilter.txt All tests I applied to the ns.zip file proved it sound; it expands with jar, pkunzip, and INFO-ZIP unzip equally well. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Aug 14 20:20:03 1998 From: jtauber at jtauber.com (James K. Tauber) Date: Mon Jun 7 17:04:00 2004 Subject: repository for general DTDs (was RE: REQ: ISO 8601 Comments) In-Reply-To: Message-ID: <000f01bdc7b0$7af3a000$ee6118cb@caleb> > On the more general note...is there a repository for general > domain nonspecific DTD's for stuff like times, dates, > directory listings, etc? Although everything on it is domain specific at the moment, I intend my site schema.net to be available for stuff like this too. see http://www.schema.net/ At present it is just a catalogue of DTDs but soon it will also (subject to the permission of the relevant DTD owners) include the actual DTDs for retrieval. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Sat Aug 15 00:42:58 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:00 2004 Subject: RDF and Microsoft Message-ID: <000001bdc7d3$957631e0$2ee044c6@arcot-main> Anyone know if Microsoft is doing anything with RDF? I am aware that Andrew Layman is one of the editors of the RDF Schema spec but I have not heard any other news. Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Aug 15 00:55:58 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:04:00 2004 Subject: More on Namespaces References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> <199808121204.IAA00214@unready.megginson.com> <35D25A4C.63A6@hiwaay.net> <199808131223.IAA00210@unready.megginson.com> <35D39257.2B70@hiwaay.net> <199808141300.JAA00271@unready.megginson.com> Message-ID: <35D4BFFB.96B@hiwaay.net> David Megginson wrote: > > Personally, I'd like to separate the issue of global names from that > of document composition: I do not think that namespaces are a useful > substitute for subdocuments (inline or out-of-line) -- that issue > still needs to be dealt with. Yes. But when I read the specs and look at the examples on some sites, the assumptions are easy to make. There are documents that use the words "namespace" and "schema" in the same sentence too often to assume otherwise. > In other words, an element named "http://www.megginson.com/ + para" in > one document and an element named "http://www.megginson.com/ + para" > in a second document have the same name. Make of it what you will. Ok. I understand that. Taken on its face, if the URL is unique, the element strings are identical. It is the URL that is the unique part. It only establishes a mechanism for making it unique. It doesn't carry the promise as a Doctype does that at the other end of this, say, system literal is a description which not only provides a unique local namespace, but also the frequency and occurence of that element in an instance. > > So what am I to assume if I see a dt: prefix that has a classID > > in the ns attribute, and another that *appears* to point at > > a schema of some sort? > > I'm not certain that I understand the question -- could you give an > example? Not from home. I have seen examples in which the namespace URL points to different things; specs, schemas, and classIDs. That confused me but given the above, I think I understand what you are getting at. The schema may be there but that is not the namespace mechanism. > The WD contains much in the line of confusing and mostly-irrelevant > philosophical musings that (I hope) will eventually be deleted -- if > Len finds the spec confusing, I'm terrified of what will happen when > it hits the webmasters. Well, Len is spending his free days reading everything on the public W3C site to work through all the specs. I don't think one can fairly work out the system without understanding all of the components. Some of this relates to work, some curiosity and the markupJones, and some because of the issues with VRML and the kudzuProperty of markup systems. Anyway, as I wake up from some years of insulin deprivation, maybe my grokking will improve, so I am not a fair comparison right now and certainly have to catch up. > With the latest namespaces WD, however, XML can no longer fairly claim > to be simpler or more transparent than SGML -- the contextual > dependencies built into local scoping and defaulting are in the same > class as the contextual dependencies built into SHORTREF and OMITTAG > (both of which XML wisely discarded), though the algorithms for > resolving the namespaces are considerably simpler. I trust you are right. I never had to write code to do those and I never used those features. Yet, perhaps it is time to acknowledge that this project is not simply SGML On The Web: given the DOM, et al, it is the project to overhaul the WWW products and provide a stronger and extensible, and more importantly, standardizable system. Flying in the faces of the vendors doesn't work. We need requirements, specs, and conformance tests. IOW, make it clear enough and cheap enough to do the right thing so that doing the wrong thing simply makes no economic sense. The best way to get them follow the standards is to make it expensive to do otherwise. > It is up to the reader to decide whether the fact of this complexity > vindicates HyTime or indicts XML. XML won't be indicted. We will suffer for the early hype as HyTime did. OTOH, we have to be clear along the lines of the statements I used to make to the IETM community: when you say interactive, you say code. HTML spawned a community that believed it could do multimedia without code. While that group may mainly only consist of marketing wonks now, we have to deal with the issue that XML 1.0 is just the syntax piece of a much broader system that taken altogether is more complicated than SGML because it attempts to do more than SGML attempts. HyTime may be vindicated by something most of us already knew and XML+TheRest makes clear: open hypermedia based on open standards is a very hard problem. Since every document I've read on the W3C sites clearly acknowledges parentage, there is no call for official vindication. We just have to acknowledge the problem is hard, we learned a lot from the previous attempts, and now we are iterating through yet another design, older, wiser, and ready to get it done. > The temptation to obfuscate is hard > to resist. Ha! We are victims of our erudition. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sat Aug 15 05:54:35 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:04:00 2004 Subject: More on Namespaces Message-ID: David Megginson writes: >With the latest namespaces WD, however, XML can no longer fairly claim >to be simpler or more transparent than SGML -- the contextual >dependencies built into local scoping and defaulting are in the same >class as the contextual dependencies built into SHORTREF and OMITTAG >(both of which XML wisely discarded), though the algorithms for >resolving the namespaces are considerably simpler. > >It is up to the reader to decide whether the fact of this complexity >vindicates HyTime or indicts XML. The temptation to obfuscate is hard >to resist. I suspect that from the average webmasters point of view, HyTime is irrelevant (except as possible inspiration) - so XML is indicted, and, I fear, guilty as charged. There may be a way around this for the average webmaster or hacker, but not with the current DTD structure. Another schema may be capable of handling this both transparently and intelligibly. Hopefully the W3C will take these issues into account for both the namespaces proposal and for whatever schema we end up with. More next week, after I finish this list @#X! chapter. XSchema should be ready for final review by early next week, and I'll have time to wonder about complexity again. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Aug 15 07:46:01 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:04:00 2004 Subject: More on Namespaces References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> <199808121204.IAA00214@unready.megginson.com> <35D25A4C.63A6@hiwaay.net> <199808131223.IAA00210@unready.megginson.com> <35D39257.2B70@hiwaay.net> <199808141300.JAA00271@unready.megginson.com> Message-ID: <35D52025.5168@hiwaay.net> David Megginson wrote: > > I'm terrified of what will happen when > it hits the webmasters. > > With the latest namespaces WD, however, XML can no longer fairly claim > to be simpler or more transparent than SGML Ok. But the average webmaster like the average Perl hacker like the average web user may all be mythical beasts. We all have an idea what they are, but in fact, other requirements drive the design. Winer says the designers are all scientists and not technologists, and there is a bit of truth to it. I'm a content developer so I'm just waiting for toys. But as a content developer, whatever the schema mechanism, the colonized namespace must validate or I don't buy the toys. Yes, when to use validation is process dependent, but it IS a fundamental functionality of using markup in production. So, my question to the scientists is, will it validate? len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Aug 15 13:01:29 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:00 2004 Subject: More on Namespaces (long, but optimistic) In-Reply-To: <35D4BFFB.96B@hiwaay.net> References: <5030300023900581000002L012*@MHS> <35D056D9.A5AC2B48@locke.ccil.org> <199808111745.NAA00926@unready.megginson.com> <35D10AA8.12B0@hiwaay.net> <199808121204.IAA00214@unready.megginson.com> <35D25A4C.63A6@hiwaay.net> <199808131223.IAA00210@unready.megginson.com> <35D39257.2B70@hiwaay.net> <199808141300.JAA00271@unready.megginson.com> Message-ID: <3.0.1.16.19980815120155.374f9506@pop3.demon.co.uk> There seems to be a certain amount of gloom over namespaces. I think this is because they appear to offer lots of exciting new possibilities, but it's not clear how or whether these will work. There is a lot we can do without namespaces, or by using them in simple manners, and I have tried to separate out some of the parts of the confusion... Personally I remain very optimistic. At 17:53 14/08/98 -0500, len bullard wrote: [...] > >HTML spawned a community that believed it could do multimedia without >code. While that group may mainly only consist of marketing wonks >now, we have to deal with the issue that XML 1.0 is just the syntax >piece of a much broader system that taken altogether is more >complicated than SGML because it attempts to do more than SGML >attempts. Len has put this precisely and accurately. The point is that in principle XML holds out the opportunity to combine information components from multiple sources. Even more, it suggests that we may be able to do this without specific coding for each type of component. Put another way, the dream is that an XML-unaware person (client) can receive a complex multicomponent document and it will automatically 'do what is required' without effort on the client's part. That is a year or two away at least, but many of us are pointing in that direction. It's enormously ambitious and will change the human race. What is described here is more modest. We have to address lesser dreams at present. The current perceived problem is, I think, that the current namespace draft might give the impression that the dream is realisable today. We all know it will require software to make it work but above all it will require a change in the way that we think communally. [An analogy is e-mail - how long has it taken to become universal? How many directors still get their secretaries to type up their e-mail?] I suspect that implementing the whole of the namespace draft - with its links into the other required components (RDF, XSL, XLL, XPointer, DOM, DCD) is going to take a considerable time to work through. Since these are parallel activities it's not easy (or possibly desirable) to plan everything to the last nut and bolt. I am confident that - as with HTML - locally optimal solutions for important problems will be found. Some will be elegant, some will be kludgy. Many will depend on communally available software. The more of this we can stimulate here, the more experiments can be tried. I'll like to suggest a spectrum of activities where prefixes and possibly namespaces should be quite tractable. I make it clear that I am in favour of XML validation in the right circumstances. As evidence of commitment I have authored an XML DTD for terminology (VHG , http://www.vhg.org.uk) and I use it to validate documents. Validation matters since I'm working on an industrial strength project with it. Essentially the DTD functions as a contract, especially where components have to be handed over, or signed off. I'll try to show how it may incorporate namespaces. STAGE 1 When I started namespaces were still under wraps so early versions looked like: XML The world's number one markup language and a number of glossaries - which contained only VHG element types - were created. They are validatable satisfactorily, can be updated and continue to be validatable. These glossaries can be used in standalone mode (e.g. for reference or bedtime reading). So the full power of parsers, stylesheets, JUMBO, etc. can be unleased on them *now*. We should not underestimate the importance of well-crafted, standalone validatable monoDTD XML documents. The next step was that the glossaries might contain information from other DTDs, such as HTML for hypertext, or molecules. There are two possibilities: - planned and regulated - unplanned and unregulated By planned and regulated I mean that every instance contains a precisely known set of elementTypes from 2 (or more) DTDs in known contexts. It would therefore be possible to write STAGE 2 XML

The world's number one markup metalanguage

 where

, are from the HTML DTD (say 2.0), or IBTWSH. Since there is no tag collision between VHG and HTML (deliberate!) we don't have a problem. We can construct a content model for which is validatable. Now, suppose I have a tag collision between VHG and HTML I can use prefixed elementNames. e.g. STAGE 3 XML The world's number one markup language Note - I don't (think) I need to have any namespace declarations yet, do I? This is well-formed, validatable XML. The content models include: STAGE 4 Now, suppose I want to include molecules in . [Example: I have the following possibilities: - think of all possible content, hardcode it into the DTD and ban anything else until the next revision. - revise the DTD every time I want to include a new type. - use a content model of ANY - use XLink to link to the actual information, e.g.: where VHG:Link is a cunning pointer to another document and includes the attributes show="embed" actuate="auto" Although we have prefixed names we still haven't used namespaces. Now, suppose someone else wishes to use VHG terminology in their own document. They want to write something like: STAGE 5 Please send five hundred widget A specification for part of a graphics screen Beer widget widget A gasification apparatus in a beer can Screen widget If the creator of this document wants it to be validatable (I shall use 'validatable' as 'something more than ANY') they have to think where the VHG stuff is going to occur in the document. If the VHG stuff matters (and it probably does since its role is to make precise identification) then this effort has to be taken. XLink remains an alternative throughout: STAGE5a Please send five hundred widget A specification for part of a graphics screen Beer widget widget A gasification apparatus in a beer can Screen widget None of this has required anything other than standard XML1.0. The problem only surfaces when people start mixing material in which - there will be tag collisions - they want the namespaces to mean something. Tag collisions are unavoidable (I first invented 'XML' as an SGML application before the current XML). Suppose Vanity Homes and Gardens wishes to produce a catalog. And suppose that they already use other DTDs. And because of this they have already produced their own DTD as a prefixed one, e.g. carrot artichoke and, because people don't know what sort of artichoke it is, they use a glossary: STAGE 6 carrot artichoke Jerusalem artichoke A delicious tuber which causes flatulence globe artichoke globe artichoke A delicious thistle-like plant Jerusalem artichoke Note that this is perfectly OK, since there are (coincidentally) no tag collisions between the two DTDs. It may not be pretty, but it's perfectly OK. None of this has required namespaces. STAGE7 If there *is* a tag collision, then one of the DTDs has to yield its prefix. An example might be: carrot artichoke Jerusalem artichoke A delicious tuber which causes flatulence globe artichoke globe artichoke A delicious thistle-like plant Jerusalem artichoke This is a syntactic problem and requires tools. The tools have to do the following: - recognise the names from each DTD in a document and convert them - recognise the same names in the DTD and convert them in precisely the same manner We still don't need namespaces at this stage, just unique names. But we do need the tools. And these tools may have to convert DTDs quite often and keep track of which ones are used. The problems ONLY arise when we start trying to put some semantics/meaning on the names. Since we don't have much experience at this for unqualified names it's not surprising we find it hard. The main namespace problems therefore are: (a) - what does FOO mean? (in and FOO="baz") (b) - can I attach meaning through algorithms (schemas, stylesheets, Java) (c) - can I identify the same FOO in different documents even if it has different prefixes? Namespaces ONLY address the third concern. This may not even be important if (a) and (b) are not solved. [There is another aspect to namespaces - scoping. IMO this is simply a minimisation procedure. Personally I think it's unnecessary and dangerous and confusing and opens up the dream too early. I would recommend that we include all prefixes explicitly to avoid confusion. This is a syntactic concern which can be dealt with at parser or SAX level and should be kept as far away from the application programmer as possible. I have had my say repeatedly - please don't overcomplicate. We don't *have* to use the complex bits of XML or namespaces.] There is a real problem with multiDTD documents. If we have a document which reasonably includes: - DC - RDF - DCD - XSL - XLL - HTML/IBTWSH - Application1 - Application2 I cannot see, with the best will we have, how we can possibly build a DTD that can validate this (unless it's a VERY formal document - legal, patent, safety, etc.) It's an n-squared problem. So I don't accept that 'namespaces have broken validation' but rather that complex monolithic XML documents are inherently unvalidatable except for expensive vital 'in-house' requirements. I think that XLink provides a solution, but only if we are happy with passing bundles of documents over the WWW with the belief that the integrity of the bundle survives. We haven't cracked that yet, have we :-) Now it happens that I also want to solve (a) and (b) :-). I can't use namespaces for this, because they deliberately don't solve it. My best hope is XSchema (or RDF) which allows me to define - hopefully along with lots of other people - ways of attaching meaning. My current approach is then something like: carrot artichoke Jerusalem artichoke A delicious tuber which causes flatulence globe artichoke globe artichoke A delicious thistle-like plant Jerusalem artichoke This breaks the namespace problem into its components. It says that certain names (VHG: and possibly some scoped attributes - I'm not yet sure) are mapped onto the *STRING* "http://vhg.org.uk". It I used a different prefix (e.g. VirtualHG) in another document I could still relate them through the ns URI. The jumbo:namespace PI can be neglected. For those with a JUMBO browser and jumbo.vhg.*.class it can add semantic enhancement - and I'll show this at Montreal. But there can be other ways of associating semantics with the *STRING* "http://vhg.org.uk" - stylesheets, other classes, etc. So it is a semantic handle onto which anyone can map anything they like. The challenge is whether we can come up with communal portable tools for doing that easily and avoiding babelisation. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Sat Aug 15 17:30:22 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:00 2004 Subject: More on Namespaces (long, but optimistic) Message-ID: <002401bdc860$523802e0$2ee044c6@arcot-main> Perhaps it would be helpful for the XML developer community if we came up with a list of problematic or controversial aspects of the new Namespace proposal. The list differs from the spec in that it details the benefits and problems of each namespace features. Such a list can be used to assess the impact of the new namespace proposal on one's work. Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Aug 15 17:55:31 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:00 2004 Subject: More on Namespaces (long, but optimistic) In-Reply-To: <002401bdc860$523802e0$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980815165537.08cfb764@pop3.demon.co.uk> At 08:20 15/08/98 -0700, Don Park wrote: >Perhaps it would be helpful for the XML developer community if we came up >with a list of problematic or controversial aspects of the new Namespace >proposal. The list differs from the spec in that it details the benefits >and problems of each namespace features. Such a list can be used to assess >the impact of the new namespace proposal on one's work. Sounds a useful suggestion. I think it would be particularly useful if it highlighted those parts of the spec which could be implemented/discussed independently of each other (if this is the case). To extract things out of my previous message I'd highlight: - the mechanics of changing prefixes in documents with name collisions (including verifying uniqueness of prefixes - the mechanics of changing prefixes in DTDs when confronted with a given document instance - a beginner's guide to scoping. What it is meant to do. This should include clear examples of scoped documents, their interpretation and their fully expanded form. Maybe JohnCowan's NamespaceFilter will do the latter bit. Personally I work best from examples. Since DonP made the suggestion I suggest that replies are posted to XML-DEV but that DonP collates and summarises them... P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Sun Aug 16 17:26:06 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:01