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 2004 Subject: More on Namespaces (also long, but also optimistic) 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> <3.0.1.16.19980815120155.374f9506@pop3.demon.co.uk> Message-ID: <35D6FBE9.E838A98C@mecomnet.de> Peter Murray-Rust wrote: > > There seems to be a certain amount of gloom over namespaces. I think this I hope that neither the tone nor the content of my posts has contributed to this impression. Upon further reflection, I am actually more pleased with the present draft that with the former version. Since the recent draft eliminates the namespace pi, and makes no claim as to the universal name which coresponds to a given name in the DTD, it no longer requires that a prefix/uri binding include the entire dtd within its scope. Presuming that the application is informed of the declarations, this permits an application to employ an analogous pi to rebind prefixes as needed to be able to peform the operations which you identified as STAGE7/c. > [...] > > STAGE 4 and 5 These sections discuss issues of DTD semantics - in particular reuse, model combination, inclusion, and evolution - which arise even in cases which exhibit no name ambiguity. Shouldn't they be titled something like 'STAGE I', and 'STAGE II' to indicate that thay have no direct relation to namespaces. > [...] > > STAGE7 > > If there *is* a tag collision, then one of the DTDs has to yield its > prefix. An example might be: > > > [...] > > > 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. This point is not clear. You describe exactly the purpose which namespaces (in general) serve. Given attribute-based bindings, there is no reason to yield the prefix. > > 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? (c) is incomplete: both sameness and difference matter to identity; intra-document identity matters. (c.i) - can I identify the a FOO even if it occurrs have with different prefixes? (c.ii) - can I identify different FOO in a given documents even if they occur with the same prefix? > > Namespaces ONLY address the third concern. This may not even be important > if (a) and (b) are not solved. If (c) is not addressed, it is not possible to address (a) and (b). One cannot say that the something in the given examples means "what FOO means" until one can say that the something "is" "FOO". Enabling architectures, for example, provide the ability to remap attributes. Despite the fact that the word "namespace" never appears in the standard document, the remapping mechanism performs exactly that function. > > [There is another aspect to namespaces - scoping. IMO this is simply a > minimisation procedure. The issues scope and extent are not directly related to minimisation. That it is permitted to bind the null prefix is related. Once that is permitted, the given rules for the scope and extent of that binding determine whether and which universal name corresponds to a given unprefixed name. This is, however, only a specific instance of their application. > Personally I think it's unnecessary and dangerous If a syntactic form is to have an effect with respect to other forms within its document and over a process, it is necessary to specify that part of the document within which the the effect is observed (the scope) and the duration over which the effect holds (the extent). > [...] > > 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. It is not an n^2 problem. It is a On problem. Each DTD-(fragment) must be permitted to bind its own prefixes to its own URI(s). Each document must be permitted to bind those URIs which it uses to prefixes which it chooses. This can be accomplished by partitioning the names into as many regions as there are URIs, and binding the URI's to the specified prefixes for the duration of the parse of the respective entity (document entity, external subset, internal subset, external parsed entities). At any given time, there are at most n effective bindings, where n is the total numer of namespaces which appear in the document. This permits a form of "qualified" validation. "Qualified", since it could be performed by a processor application only given the universal names. That is the stages need to be parse -> namespace-filter -> validate whereby the namespace filter can actually be integrated into the parser. > 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. 'Namespaces' cannot not "break validation". Ambiguous names preclude anything other than trivial validation. Given ambiguous names, either the failure to match or the resulting duplicates lead to trivially invalid documents. The present draft does not "fix validation" because it does not ensure a 1-1 correspondence between names in the DTD and universal names, but it can't be said to "break" it. The previous draft (if followed strictly wrt. the placement of namespace pi's) actually did break it. I suggest an alternative to your current approach. If one assumes, that the respective DTDs are present at the locations given below, and that the names in the respective DTD, for this example, are unqualified (I understood that they do not reference each other), then the following is sufficient to encode the names unambiguously and to permit a processor to determine the qualified validity of the document. Note that the binding which effects the VHG:termEntry needs to be in the containing element. Otherwise a consistent mechamism cannot be used to determine its corresponding universal name unambiguously, given possible attribute defaults. %VanityDTD %VHGDTD ]> carrot artichoke Jerusalem artichoke A delicious tuber which causes flatulence globe artichoke globe artichoke A delicious thistle-like plant Jerusalem artichoke If the parser reports attribute and element declarations, a processor would be able to validate this document. The application would use the namespace instructions, in addition to the namespace attributes, as the basis to rewrite ALL names to universal names in a manner similar to that described by Mr Bray some time back. That it is possible to assert prefix bindings for the DTD solves the problem left open in his description. The document might not be "xml-1.0 valid", since 1. the DTD could contain more than one element declaration for the same qualified name; 2. there may be duplicate attribute declarations with conflicting constraints for a given qualified name; 3. the DTD may contain no element or attribute declarations for a given qualified element or attribute name. Despite this, it would be possible to determine conformance, since 1. it would be possible to assert that there should be a 1-1 correspondence between the universal names which correspond to element tag names and those which correspond to the names appearing in element and attlist declarations; 2. it would be possible to assert the same for element tag names and the names which appear in content models; 3. it would be possible to do the same for attribute names in tags and those which appear in attlist declarations; 4. if 1-3 were satisfied by the specific document entity and DTD, then it is possible to determine whether attribute and element content comply with the DTD's constraints. No gloom and doom here. I'm actually very optimistic. Given this result, it is now possible to think about STAGES I and II. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Sun Aug 16 17:46:26 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:04:01 2004 Subject: SAX and Attribute value of type ENTITY ? Message-ID: <199808161544.RAA12465@chimay.loria.fr> If an Attribute value is of type ENTITY ( ) what value should return a SAXDriver ? The entity or the value of the entity ? Example : ]> blah A SAX Driver should return "mydoc" or resolve the entity and return mydoc.xml ? 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 peter at ursus.demon.co.uk Sun Aug 16 20:20:20 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:01 2004 Subject: More on Namespaces (also long, but also optimistic) In-Reply-To: <35D6FBE9.E838A98C@mecomnet.de> 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> <3.0.1.16.19980815120155.374f9506@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980816192022.2a9f00a8@pop3.demon.co.uk> At 17:36 16/08/98 +0200, james anderson wrote: >Peter Murray-Rust wrote: >> >> There seems to be a certain amount of gloom over namespaces. I think this > >I hope that neither the tone nor the content of my posts has contributed to >this impression. Not at all. There are some people who worry about the inability to validate documents which use namespaces. My posting was to try to clarify (at least in my own mind) the issues involved. I personally feel that namespaces have not prevented us from doing anything we could do already. >> 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. > >This point is not clear. You describe exactly the purpose which namespaces (in >general) serve. Given attribute-based bindings, there is no reason to yield >the prefix. > What I meant is that the documents could appear without the xmlns attributes. We have identified the problem as being that of renaming names in the DTD, which I contended was independent of whether we used an xmlns attribute. >> >> 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? > >(c) is incomplete: both sameness and difference matter to identity; > intra-document identity matters. > (c.i) - can I identify the a FOO even if it occurrs have with >different prefixes? > (c.ii) - can I identify different FOO in a given documents even if >they occur > with the same prefix? >> >> Namespaces ONLY address the third concern. This may not even be important >> if (a) and (b) are not solved. > >If (c) is not addressed, it is not possible to address (a) and (b). One cannot >say that the something in the given examples means "what FOO means" until one >can say that the something "is" "FOO". Agreed. I probably put them in the wrong order. (a) and (b) are 'harder' problems than (c). > >Enabling architectures, for example, provide the ability to remap attributes. >Despite the fact that the word "namespace" never appears in the standard >document, the remapping mechanism performs exactly that function. > >> >> [There is another aspect to namespaces - scoping. IMO this is simply a >> minimisation procedure. > >The issues scope and extent are not directly related to minimisation. That it Ah. If that is true, then I need to clarify my thoughts. My understanding was that 'scope' per se had no agreed meaning in the document other than to bind unique names to names. If those names were explicitly prefixed, then scope would be irrelevant. But I suspect other people put more meaning on scope. Example (a)

An HTML paragraph

(b) An HTML paragraph I regard these documents as being syntactically identical. (a) is simply a minimised version of (b). The H:P element has the same unique name in both. That it is within a given scope should be irrelevant to the application. As far as the application is concerned it gets two elements with universal names: "http://w3.org/html HTML" and "http://w3.org/html P" One happens to be a child of the other, that is all. The fact that P is in the scope of the xmlns declaration seems unimportant. If I'm wrong on this, then application programmers are going to have some tough programming. [...] >> 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. > >It is not an n^2 problem. It is a On problem. Each DTD-(fragment) must be I meant that the problem of checking unique prefixes is O(n^2). If I have 6 namespaces in a document (or DTD) and bring in another I have to make 6 checks that the prefixes do not clash, - n(n-1)/2 in all. [...] > >Note that the binding which effects the VHG:termEntry needs to be in the >containing element. Otherwise a consistent mechamism cannot be used to >determine its corresponding universal name unambiguously, given possible >attribute defaults. > > > SYSTEM "http://VanityHouseAndGarden.org.uk/DTD/VHG.dtd" > > SYSTEM "http://VHG.org.uk/DTD/VHG.dtd" > > > > %VanityDTD > > > %VHGDTD > >]> > > I'm lost with these PIs. I thought they had disappeared.... [...] > P. Thanks for taking the time to read it in detail. It may be worth rehashing what I wrote. 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 Sun Aug 16 20:23:49 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:01 2004 Subject: SAX and Attribute value of type ENTITY ? In-Reply-To: <199808161544.RAA12465@chimay.loria.fr> from "Patrice Bonhomme" at Aug 16, 98 05:44:36 pm Message-ID: <199808151823.OAA15648@locke.ccil.org> Patrice Bonhomme scripsit: > If an Attribute value is of type ENTITY ( > ) what value should return a SAXDriver ? The entity or the value of the entity > ? The name of the entity. Remember that attributes of type ENTITY have values which are the names of *unparsed* (aka NDATA) entities. The whole point of such attributes is to be able to refer to unparsed entities at all; they have no *values* as such. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Aug 17 00:42:27 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:01 2004 Subject: More on Namespaces (also long, but also optimistic) 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> <3.0.1.16.19980815120155.374f9506@pop3.demon.co.uk> <3.0.1.16.19980816192022.2a9f00a8@pop3.demon.co.uk> Message-ID: <35D7622A.29321EF6@mecomnet.de> Peter Murray-Rust wrote: > > [...] > >Note that the binding which effects the VHG:termEntry needs to be in the > >containing element. Otherwise a consistent mechamism cannot be used to > >determine its corresponding universal name unambiguously, given possible > >attribute defaults. > > > > > > > > SYSTEM "http://VanityHouseAndGarden.org.uk/DTD/VHG.dtd" > > > > SYSTEM "http://VHG.org.uk/DTD/VHG.dtd" > > > > > > > %VanityDTD > > > > > > %VHGDTD > > > >]> > > > > > > I'm lost with these PIs. I thought they had disappeared.... > Ah, but since the standard no asserts an interpretation for them which precludes validation, a processor is free to use them in a way which enables validation. Take them, for the sake of discussion, to establish a prefix/URI binding for which the scope is the remainder of the logical entity in which they appear. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dgd at cs.bu.edu Mon Aug 17 02:47:12 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:04:01 2004 Subject: More on Namespaces (also long, but also optimistic) In-Reply-To: <35D7622A.29321EF6@mecomnet.de> 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> <3.0.1.16.19980815120155.374f9506@pop3.demon.co.uk> <3.0.1.16.19980816192022.2a9f00a8@pop3.demon.co.uk> Message-ID: At 6:53 PM -0400 8/16/98, james anderson wrote: >Peter Murray-Rust wrote: >> > >> >> I'm lost with these PIs. I thought they had disappeared.... >> > >Ah, but since the standard no asserts an interpretation for them which >precludes validation, a processor is free to use them in a way which >enables validation. I am assuming you meant to type "now asserts an interpretation..." But this isn't true. It provides a facility which can be used in a validation compatible way (just as the original facility), and which can also be used in a validation-incompatible way, just like the earlier one. In both cases you need to know what's in the instance to create a DTD which will make an instance valid -- that's an ineveitable side-effect of mixing "namespaces" with out a namespace-aware validator. Interestingly, this gives you no worse validation than architectural forms do, although AF validation was one argument againt AFs and _for_ namespaces... Anyway that's water under the bridge. The thing that the current proposal gives you if you are _not_ validating -- and I take the NS people at their word when they claim that they think they can live without validation -- is the ability to limit the scope of a namespace prefix declaration, and thus, limit the region of the document within which that prefix cannot be used to declare another namespace. Since a prefix is essentially a variable, bound to a URI, and used to differentiate like-named elements, this kind of scoping mechanism is not unsensible. The contextual dependency implied by the element-nesting of declarations may create entity re-use problems, but with care those problems can be avoided. Many people argue that there are other problems with entity reuse (David Megginson and Eliot Kimber are two worthy adherents to this belief). >Take them, for the sake of discussion, to establish a prefix/URI binding for >which the scope is the remainder of the logical entity in which they appear. To the extent that you are proposing a separate namespace standard, I hope that you are unsuccessful. It's a hard thing sometimes to buckle under to the fact that much of the time _any_ standard that is accepted is in fact better than a custom solution that is not accepted. Namespaces per se are unnecessary, since Architectural Forms can do the same thing, but since we have a decent namespace standard, we should use it where it makes sense. -- 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 avirr at LanMinds.Com Mon Aug 17 05:25:02 1998 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:04:01 2004 Subject: RDF and Microsoft In-Reply-To: <000001bdc7d3$957631e0$2ee044c6@arcot-main> Message-ID: At 3:32 PM -0700 8/14/98, Don Park wrote: >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. The DCD proposal, , says it's consistent with RDF, right there in the summary. Charles Frankston from Microsoft is one of the editors, so that might be considered of a vote of confidence. 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 Patrice.Bonhomme at loria.fr Mon Aug 17 08:19:39 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:04:01 2004 Subject: SAX and Attribute value of type ENTITY ? In-Reply-To: Your message of "Sat, 15 Aug 1998 14:23:02 EDT." <199808151823.OAA15648@locke.ccil.org> Message-ID: <199808170617.IAA20162@chimay.loria.fr> Thanks for your answer. I said: ] If an Attribute value is of type ENTITY ( > ) what value should return a SAXDriver ? The entity or the ] value of the entity > ? cowan@locke.ccil.org said: ] The name of the entity. Remember that attributes of type ENTITY have ] values which are the names of *unparsed* (aka NDATA) entities. The ] whole point of such attributes is to be able to refer to unparsed ] entities at all; they have no *values* as such. Ok, so how can i get the corresponding ENTITY value within a SAX application ? And i think that the example i gave was not good because the XML Rec says : "No External Entity References In Attribute Values". I said: ] ] ]> blah If the Entity 'mydoc' was not an External entity (let's say a simple internal entity, ) what should return the SAX driver ? 'mydoc' or 'mydoc.xml' ? Could i have something like this : ? If SAX returns the name of the Entity, how could i handle entities within a SAX application ? Thanks for any informations. 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 James.Anderson at mecomnet.de Mon Aug 17 10:06:57 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:01 2004 Subject: More on Namespaces (also long, but also optimistic) 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> <3.0.1.16.19980815120155.374f9506@pop3.demon.co.uk> <3.0.1.16.19980816192022.2a9f00a8@pop3.demon.co.uk> Message-ID: <35D7E671.4CA10962@mecomnet.de> David G. Durand wrote: > > ... > >Ah, but since the standard no asserts an interpretation for them which > >precludes validation, a processor is free to use them in a way which > >enables validation. > > I am assuming you meant to type "now asserts an interpretation..." > Actually no. the missing word is "longer". as in "no longer asserts". Sorry for the confusion. I happen to type my mail on a machine on a mac on which a backup program also runs. Occasionally it polls network clients. Which can cause the mail editor to drop characters. Usually they're incomplete words and I catch them. I missed this one. Again my apologies. > But this isn't true. It provides a facility which can be used in a > validation compatible way (just as the original facility), and which can > also be used in a validation-incompatible way, just like the earlier one. > In both cases you need to know what's in the instance to create a DTD which > will make an instance valid -- that's an ineveitable side-effect of mixing The problem with the former version appears when one has to work with existing DTDs and does not want to rewrite them manually. If there are tags which lead to "name collision", the former proposal precluded validation (or led to "trivially invalid" documents) while the present proposal permits a more meanigful form of validation. > ... > > To the extent that you are proposing a separate namespace standard, I hope > that you are unsuccessful. It's a hard thing sometimes to buckle under to > the fact that much of the time _any_ standard that is accepted is in fact > better than a custom solution that is not accepted. > The present proposal specifies no correspondence between qualified names in the dtd and universal names. As I read it, it does not specify that there is no correspondence; it specifies nothing. If it were to say how a processor is to work with the names in the DTD, I might have something to "buckle under to". At the moment is says nothing. Which I had understood to mean that an application could well assert such a correspondence and still conform to the standard. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Mon Aug 17 10:32:51 1998 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:04:01 2004 Subject: To validate or not to validate, that is the question Message-ID: <01bdc9ae$da8b59e0$LocalHost@sgml.u-net.com> Let me see if I can suffer the slings and arrows of outrageous fortune and pose you all a question: "Why do compound documents need to be validated as a whole?" The point of namespace proposal is to allow users to say "This part of my document conforms to the rules specified in this DTD: that part of my document conforms to the rules in that DTD. Here are some URIs that you can use to find the rules used for checking each part of the document structure." If I create my document fragments using the relevant DTDs, I validate them against those DTDs, not against a compound DTD. Once they have been validated against the DTD I can import them into a compound document as already validated fragments. In the compound DTD all I need to do is to recognize when the same element name has been used within the DTDs of two fragments. I then have two choices: 1) To decide to change the name of one of the elements to a qualified form to disambiguate it from the other (changing both the DTD and the previously validated instance, so that I need to revalidate the document for safety afterwards) 2) Change the model to the element concerned to ANY in the DTD and rely on the fact that I have already validated the fragments against their own DTDs to avoid any errors. (I may also have to change any attributes used by both DTDs to CDATA to make sure there are no clashes in permitted values, but this is equally trivial.) As 2) is much simpler to manage I would do that in any case where I could be sure that my imported fragments had been prevalidated. Why does this group seem to feel there is an overpowering need to develop a DTD that can be used to validate the compound structure, rather than its individual fragments? Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maki at inac.co.jp Mon Aug 17 10:56:20 1998 From: maki at inac.co.jp (TAKAHASHI Masayoshi) Date: Mon Jun 7 17:04:02 2004 Subject: ANNOUCE: XML Parser Module for Ruby Message-ID: <199808170855.RAA28955@mx.inac.co.jp> XML Parser Module for Ruby ========================== XML Parser Module for Ruby (by YOSHIDA Masato) version 0.3.3 is released. What's this ----------- "XML Parser Module for Ruby" is a Ruby module to use expat, XML Parser toolkit made by James Clark (http://www.jclark.com/xml/expat.html). Expat's version that this module supported is 1.0. What's Ruby ----------- Ruby is the interpreted scripting language for quick and easy object-oriented programming. It has many features to process text files and to do system management tasks (as in perl). It is simple, straight-forward, and extensible. APIs ---- This module provides XMLParser Class for Ruby. There are two kinds of interfaces, event handler and iterator. Event handler is like SAX(Simple API for XML). You can define your original classes inherited XMLParser class, and define event handler methods. Iterator is 'rubyish' method. If you want to know iterator in Ruby, please see Ruby's manual and/or Ruby's Users' Guide. Sample Libraries ---------------- This module has sample libraries. * XML::SimpleTree library for making and accessing XML tree with API like W3C DOM. * XML::SimpleTreeBuilder library for parsing XML document and building tree. Encodings --------- This module can handle UTF-8 and UTF-16. But with Uconv module (and Kconv module), You can use EUC-JP, Shift_JIS and ISO-2022-JP. Uconv module is another ruby extentional module by Yoshida. It converts UTF-8 and UCS-2 into EUC-JP, and EUC-JP into UTF-8 or UCS-2. Kconv module is Ruby's standard extension. It can handle Shift_JIS, EUC-JP, and ISO-2022-JP. Documents --------- XML Parser Module (and Uconv Module) have README file. URLs ---- * XML Parser Module (and Uconv Module) for Ruby http://www.bekkoame.ne.jp/~yoshidam/Ruby.html (in Japanese) * Docuemnt http://www.bekkoame.ne.jp/~yoshidam/xmlparser_en.txt * Ruby Homepage http://www.netlab.co.jp/ruby/ http://www.netlab.co.jp/ruby/jp/ (in Japanese) * A Invitaton to ruby http://www.math.sci.hokudai.ac.jp/~gotoken/ruby/ * Ruby's Users' Guide http://pauli.math.sci.hokudai.ac.jp/~gotoken/ruby-uguide/ * Expat http://www.jclark.com/xml/expat.html 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 ht at cogsci.ed.ac.uk Mon Aug 17 11:03:05 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:04:02 2004 Subject: wd-xml-names: namespace partitions In-Reply-To: Tim Bray's message of Tue, 11 Aug 1998 13:23:34 -0700 References: <3.0.32.19980811132124.00c643e0@207.34.179.21> Message-ID: Can I endorse the WG's decision here: as an XML parser writer, I've always used the equivalent of partitioned names as a matter of internal declaration management hygiene. The necessity of catering in the API for the occasional use of an attribute name WITHOUT its associated element type name is a real pain. 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 James.Anderson at mecomnet.de Mon Aug 17 14:22:20 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:02 2004 Subject: To validate or not to validate, that is the question References: <01bdc9ae$da8b59e0$LocalHost@sgml.u-net.com> Message-ID: <35D82241.53EC47CA@mecomnet.de> Martin Bryan wrote: > > Let me see if I can suffer the slings and arrows of outrageous fortune and > pose you all a question: "Why do compound documents need to be validated as > a whole?" > my minimum concern is to be able to default attributes. > ... > > If I create my document fragments using the relevant DTDs, I validate them > against those DTDs, not against a compound DTD. Once they have been > validated against the DTD I can import them into a compound document as > already validated fragments. i am working with document entities in which "references" are made to elements from various sources. if they use enabling architectures, then the mixed references are within a single tag. > > ... > > Why does this group seem to feel there is an overpowering need to develop a > DTD that can be used to validate the compound structure, rather than its > individual fragments? it's actually the defaults i'm after. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 17 15:10:48 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:02 2004 Subject: SAX and Attribute value of type ENTITY ? In-Reply-To: <199808170617.IAA20162@chimay.loria.fr> References: <199808151823.OAA15648@locke.ccil.org> <199808170617.IAA20162@chimay.loria.fr> Message-ID: <199808171308.JAA00408@unready.megginson.com> Patrice Bonhomme writes: > Ok, so how can i get the corresponding ENTITY value within a SAX > application ? And i think that the example i gave was not good > because the XML Rec says : "No External Entity References In > Attribute Values". > > I said: > ] > ] ] 'mydoc.xml'> ]> blah > > If the Entity 'mydoc' was not an External entity (let's say a > simple internal entity, ) what should > return the SAX driver ? 'mydoc' or 'mydoc.xml' ? Could i have > something like this : > ? The last one is the only one that you're allowed to have -- ENTITY attributes must contain the names of NDATA entities (no internal or external text entities allowed). SAX has a special handler called DTDHandler that will tell the application about all declared NDATA entities and notations before parsing the document element: public interface DTDHandler { public void notationDecl (String name, String publicId, String systemId); public void unparsedEntityDecl (String name, String publicId, String systemId, String notationName); } A common practice is to use these callbacks to build two hash tables -- one for entities, and one for notations -- and then look up ENTITY and NOTATION attributes in those tables when you are parsing within the document element. 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 Mon Aug 17 16:37:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:02 2004 Subject: SAX and Attribute value of type ENTITY ? References: <199808170617.IAA20162@chimay.loria.fr> Message-ID: <35D8400D.6319F401@locke.ccil.org> Patrice Bonhomme scripsit: > Ok, so how can i get the corresponding ENTITY value within a SAX application ? The so-called value of an unparsed entity is simply the data specified by the URL (or the public identifier). Its format is specified by the notation name. > And i think that the example i gave was not good because the XML Rec says : > "No External Entity References In Attribute Values". Your example was valid. Don't confuse an entity *reference*, which is of the form "&name;", with the use of the name of an entity as the value of an ENTITY or ENTITIES attribute. XML says that entity *references* appearing in attribute values, like this: must be internal: "baz" has to be an internal parsed entity, not an external entity. > I said: > ] > ] ] 'mydoc.xml'> ]> blah > > If the Entity 'mydoc' was not an External entity (let's say a simple internal > entity, ) *That* would be invalid. In this use, "mydoc" *must* be an external unparsed entity (there are no internal unparsed entities, of course). > what should return the SAX driver ? > 'mydoc' or 'mydoc.xml' ? Could i have something like this : SYSTEM 'mydoc.xml' NDATA xml> ? Yes, that is valid. But the SAX driver will return only "mydoc". > If SAX returns the name of the Entity, how could i handle entities within a > SAX application ? You can declare a DTDHandler to capture the systemid and notation name of the external unparsed entity. However, if the entity is declared elsewhere than in the internal subset, your parser may or may not read it. It's up to your application, in the example above, to decide that "NDATA xml" means this is an XML document, and to parse 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 Mon Aug 17 16:45:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:02 2004 Subject: To validate or not to validate, that is the question References: <01bdc9ae$da8b59e0$LocalHost@sgml.u-net.com> Message-ID: <35D841F0.59C1ABB3@locke.ccil.org> Martin Bryan wrote: > Why does this group seem to feel there is an overpowering need to develop a > DTD that can be used to validate the compound structure, rather than its > individual fragments? I think your model of "compound document" is too simple. You seem to model it as a set of self-contained fragments enclosed in a container. I expect to see much more complex documents: a Chemical ML description of a molecule, with (a) embedded HTML English-language documentation, which itself contains several inclusions of MathML, and (b) a SMIL document that marshals a non-XML movie of the molecule. How would you validate just the HTML part, given that the HTML DTD does not understand MathML? -- 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 creitzel at mediaone.net Mon Aug 17 16:56:41 1998 From: creitzel at mediaone.net (Charles Reitzel) Date: Mon Jun 7 17:04:02 2004 Subject: More on Namespaces (also long, but also optimistic) Message-ID: <199808171456.KAA23098@chmls05.mediaone.net> I attempted a post earlier, but I now realize this is a moderated list. Perhaps whoever recieves this (Mr. Murray-Rust?) would be kind enough to forward this mail to the list or, even better, to folks in the WG. I have been working on my own XML parser part-time for a couple months now as part of an effort to build an Internet aware, XML based EDI translator. My background is in developing transaction-oriented database and GUI applications and, recently, web-based application servers. I am writing to complain (I know, I know) about the new namespace WD and the (apparent) lack of a strategy to develop XML schemas. I am also writing to get an idea off my chest that I think will greatly improve XML and assist in the development of schemas. o Namespaces Namespaces are an inherently global construct and I can see no reason why document writers cannot live with a single prefix per global identifier within a document. Put another way, element level prefix declarations are simply not necessary. They solve no real-world problem and create many. The original processing instruction for declaring a prefix seemed fine. If folks wish to add default prefix scoping, well that is a great idea, but an independent issue. For example (using a hypothetical ns syntax): <-- now that?s globally unique --> <-- any globally unique string, right? --> <-- Associate the dtd'd with their locally defined namespace prefixes. --> %isbndtd; %foodtd; %bardtd; ]> <-- Begin elements: Everything above can be pre-parsed and cached for frequent document types. --> My Life As A Dog<subtitle>Tail of a programmer</subtitle> 123456789-234-234 Yusef Lateef 97 Bob Dobbs Horatio Alger In this example, all of the names of attributes and child elements of are resolved in the foo namespace, unless a prefix indicates otherwise (e.g. isbn:number). Likewise, the names of attributes and child elements of are resolved in the namespace of the containing element. Scoping is a useful extension of namespaces that is in no way dependent on element level declarations. The exact syntax of the namespace declaration is unimportant, except to note that it should be part of the document header. o Expanded Names The issue of expanded names reminds me a great deal of C++ name mangling. The C++ committee chose not to standardize mangled names. Consequently, it is impossible to link libraries compiled by different libraries. This has not been a show stopper for C++, but is worth avoiding with XML. For example, a style sheet processor and XML processor should be able to match elements and attributes based on the global namespace identifier. If the two programs expand the name to slightly different strings - no go. As an aside, the stylesheet processor might want to match by prefix, which would insulate documents from changes in the namespace ID, which might change to reflect DTD version changes. o Schemas www.w3c.org is starting to look like Schema-of-the-Month Club. I am confused about where things are going. I have noticed a couple recurring themes to these projects: 1) strong data types and 2) semantic validation. There are good reasons why neither of these are included in the base XML spec. The user communities are too diverse. That said, all non-trivial XML applications must grapple with these important subjects. Thus, it seems worthwhile for the XML to include hooks to support strong data types and provide guidance for semantic validation for schema spec writers and application developers. The basic issue with data types is to notate how non-text data is to be converted to and from the XML text format. Well known data domains include dates, numbers, currencies, social security number, phone numbers, etc., etc. In each of these examples, the actual internal representation used by a program may not be the same as the text format. Note that this is a wholly separate issue from presentation, which describes size, font, color, etc. Applications need this format information to successfully transform the data into their respective internal formats. I submit the following proposal for data format support in XML. Simply allow a new "xml:fmt" pseudo-attribute in both entity and attribute declarations. It could also be allowed as a predefined attribute for each element. The xml parser need only pass along the text of the format specifier. It is up to the application to use it to do useful work. For example, 19980808 It may be that, for attribute values, this syntax is redundant with NOTATION syntax. But no one has seen fit to use it yet and it is helpful to a) make it explicit and b) consistent for both element and attribute values. In fact, xml:fmt could supercede xml:space, which governs two different text formats. The no xml:fmt would leave the current default text handling with all whitespace preserved. xml:fmt="xml:nospace" would compress all whitespace to a single space character (#x20;). If you like being explicit, use xml:fmt="xml:space" to denote that you want whitespace preserved. Again, the exact syntax is not important. The important thing is the ability to preserve format information along with the data in a compact, normalized form. This information will be highly useful to query tools and xml applications such as EDI translators. Part of a schema specification would be the definition of data formats used to transform various data types. My only other issue with various schemas to date is that they are overlap too much with DTD?s. This is dangerous at this early stage in the XML life-cycle. This is not to say that schemas are unnecessary, simply that they should use the facilities of XML to the extent possible. If a schema provides only incremental benefit over a DTD, then perhaps the DTD specification itself warrants reexamination. Whither XML 1.1? We need this to integrate namespaces and links and provide guidance on schema development. I hope you find these comments and suggestions constructive. Best regards, Charlie Reitzel xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Aug 17 17:02:26 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:04:02 2004 Subject: To validate or not to validate, that is the question In-Reply-To: <35D841F0.59C1ABB3@locke.ccil.org> Message-ID: On Mon, 17 Aug 1998, John Cowan wrote: > Martin Bryan wrote: > > > Why does this group seem to feel there is an overpowering need to develop a > > DTD that can be used to validate the compound structure, rather than its > > individual fragments? > > I think your model of "compound document" is too simple. You seem > to model it as a set of self-contained fragments enclosed in a > container. > > I expect to see much more complex documents: a Chemical ML description > of a molecule, with (a) embedded HTML English-language documentation, > which itself contains several inclusions of MathML, and (b) a SMIL > document that marshals a non-XML movie of the molecule. How would > you validate just the HTML part, given that the HTML DTD does not > understand MathML? Nice real-life example. The paper 'Web Architecture: Extensible Languages', by Tim Berners-Lee & Dan Connolly, URL: http://www.w3.org/TR/NOTE-webarch-extlang ... has a number more and discusses broader motivations for tackling this. In particular http://www.w3.org/TR/NOTE-webarch-extlang#Mixing should be of interest. Dan -- Daniel.Brickley@bristol.ac.uk Institute for Learning and Research Technology http://www.ilrt.bris.ac.uk/ University of Bristol, Bristol BS8 1TN, UK. tel: +44(0)117 9288478 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Mon Aug 17 17:39:35 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:04:02 2004 Subject: More on Namespaces (also long, but also optimistic) References: <199808171456.KAA23098@chmls05.mediaone.net> Message-ID: <35D84B3B.425225C6@jclark.com> Charles Reitzel wrote: > Namespaces are an inherently global construct and I can see no reason why > document writers cannot live with a single prefix per global identifier > within a document. See http://www.w3.org/TR/NOTE-webarch-extlang#Local for some reasons. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Aug 17 17:41:32 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:02 2004 Subject: More on Namespaces (also long, but also optimistic) In-Reply-To: <199808171456.KAA23098@chmls05.mediaone.net> References: <199808171456.KAA23098@chmls05.mediaone.net> Message-ID: <199808171538.LAA11997@unready.megginson.com> Charles Reitzel writes: > o Namespaces > > Namespaces are an inherently global construct and I can see no > reason why document writers cannot live with a single prefix per > global identifier within a document. Put another way, element > level prefix declarations are simply not necessary. They solve no > real-world problem and create many. The original processing > instruction for declaring a prefix seemed fine. If folks wish to > add default prefix scoping, well that is a great idea, but an > independent issue. Some people imagine that parts of large XML documents will be constructed by many subprocesses spawned by a master process. These subprocesses may need to declare and use their own namespaces -- the thinking is that it would be unacceptable to require them to communicate with the master process to negotiate a namespace-declaration and prefix, so they must be able to declare namespaces that are applicable only to the fragments under their control. Personally, I believe that it makes much more sense -- and keeps XML much simpler -- if each of those processes constructs a separate XML document (still using namespaces) rather than chunks of the same monolithic document. The documents can be packaged before transmission (in a JAR, a CAB, a zip file, or what have you), so there is no additional HTTP overhead. As I've mentioned before, the monolithic approach to XML documents reminds me of computer programming in the 1970s ("function calls are too slow; let's use goto instead!"). Hard-core developers already learned these lessons the hard way -- the web community, which has been clogging its arteries for a couple of years by repeatedly cramming HTML, CSS, and Javascript into a single file, is about to learn the same. 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 Mon Aug 17 17:57:52 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:03 2004 Subject: More on Namespaces (also long, but also optimistic) References: <199808171456.KAA23098@chmls05.mediaone.net> Message-ID: <35D852E8.510D0162@locke.ccil.org> Charles Reitzel wrote: > o Namespaces Because the development of XML-related standards isn't open (you gotta pay $$$$ to play), nobody's likely to listen to your idea, which is essentially that of the (current - 1)th namespace draft. > o Expanded Names > > The issue of expanded names reminds me a great deal of C++ name mangling. > The C++ committee chose not to standardize mangled names. Consequently, it > is impossible to link libraries compiled by different libraries. That was intentional, since different compilers use different callling conventions anyhow. > As an aside, the stylesheet processor might want to match by prefix, which > would insulate documents from changes in the namespace ID, which might > change to reflect DTD version changes. Maybe so. > www.w3c.org is starting to look like Schema-of-the-Month Club. The stuff they're publishing is Notes, which means "neat ideas by members; W3C doesn't endorse them in any way." > I am > confused about where things are going. So say we all (except perhaps people who are constrained by W3C confidentiality from saying anything). -- 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 jieli at cs.umbc.edu Mon Aug 17 18:03:15 1998 From: jieli at cs.umbc.edu (Li Jiefeng) Date: Mon Jun 7 17:04:03 2004 Subject: a small question on xml Message-ID: Hello, Will someone help me with the representation of special characters in .xml files? For example, or I used IBM Parser for XML, but it shows some error. It seems that " and < are not properly represented. Thanks a lot. Jiefeng CSEE of UMBC http://www.cs.umbc.edu/~jieli xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Aug 17 18:19:57 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:04:03 2004 Subject: More on Namespaces (also long, but also optimistic) In-Reply-To: <35D852E8.510D0162@locke.ccil.org> Message-ID: On Mon, 17 Aug 1998, John Cowan wrote: > > www.w3c.org is starting to look like Schema-of-the-Month Club. > > The stuff they're publishing is Notes, which means "neat ideas by > members; W3C doesn't endorse them in any way." It's not all member submission Notes... eg. http://www.w3.org/TR/WD-rdf-schema/ (new version as of last week) ...is the result of a W3C working group for RDF Schemas. It addresses some but not yet all of the issues in the TimBL/DanC paper and looks, from where I'm standing, to be pretty complimentary to the ideas behind the DCD submission. > > I am confused about where things are going. > > So say we all (except perhaps people who are constrained by W3C > confidentiality from saying anything). The nearest I've found to something looking remotely like a master plan is the publically available overview note at http://www.w3.org/TR/NOTE-rdfarch 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 donpark at quake.net Mon Aug 17 19:30:12 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:03 2004 Subject: a small question on xml Message-ID: <002801bdca03$63084180$2ee044c6@arcot-main> > Will someone help me with the representation of special characters >in .xml files? For example, > > > or > > > I used IBM Parser for XML, but it shows some error. It seems that >" and < are not properly represented. Please read section 2.4 of the XML spec. I appologize for not giving a direct answer but I believe in that fisherman story. 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 lisarein at finetuning.com Mon Aug 17 19:57:30 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:03 2004 Subject: RDF and Microsoft References: Message-ID: <35D877CD.7FC8C171@finetuning.com> in terms of software. the "official" word is still "no". A few months ago executives were telling me they "still don't see what RDF brings to the table" -- but at least they're not comparing it to CDF anymore! (due to this RDF smart bookmark stuff making it look like a CDF/sitemap rival) DCD can be taken as sort of an XML-Data Schema/RDF Schema bridge....even though the new RDF Schema specs reads a little like walking the plank! But remember, XML-Data is only a member submission (as is DCD), and it is very likely that schema support will be taken on by the XML WG -- making both specs experimental.... Hope this helps: lisa Avi Rappoport wrote: > > At 3:32 PM -0700 8/14/98, Don Park wrote: > >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. > > The DCD proposal, , says it's consistent > with RDF, right there in the summary. Charles Frankston from Microsoft is > one of the editors, so that might be considered of a vote of confidence. > > 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) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 17 19:59:17 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:04:03 2004 Subject: More on Namespaces Message-ID: <5030300024138440000002L002*@MHS> >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. Is that really true? If there was going to be an official content to what the URI of a namespace points too, shouldn't it just be a definition of the element names its supports and some human consumable documentation of what they should be used for in a conforming document? It seems that mixing up namespaces and DTDs/Schemas is incorrect. DTDs and Schemas would *use* namespaces, but a namespace itself should be just a namespace, shouldn't it? Making a namespace and a DTD/Schema one and the same means that the tags in that namespace could only be used in a document that matched that DTD/Schema, which obviously would not be optimal for very open ended sets of tags. Of course, in many cases, there would be a namespace 'definition' and a DTD/Schema that was intended as its primary use I guess. But, overall, does it not make sense that the namespace 'definition' just define the tags it can support since that's really all that a namespace is: a set of tags that have meaning as a group? Just a thought... ---------------------------------------- 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 SimonStL at classic.msn.com Mon Aug 17 20:03:16 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:04:03 2004 Subject: More on Namespaces (also long, but also optimistic) Message-ID: >On Mon, 17 Aug 1998, John Cowan wrote: > > www.w3c.org is starting to look like Schema-of-the-Month Club. > > The stuff they're publishing is Notes, which means "neat ideas by > members; W3C doesn't endorse them in any way." And Dan Brickley wrote: >It's not all member submission Notes... > >eg. http://www.w3.org/TR/WD-rdf-schema/ (new version as of last week) > >...is the result of a W3C working group for RDF Schemas. >It addresses some but not yet all of the issues in the TimBL/DanC paper >and looks, from where I'm standing, to be pretty complimentary to the >ideas behind the DCD submission. I hate to say it, but it's looking like the W3C is heading into the "let's get complicated as quickly as possible" thicket after a fairly refreshing period that produced XML 1.0. Between RDF and DCD, not to mention namespaces, is a swirling vortex of bizarrely complicated stuff that describes pretty simple stuff. XSchema (which will finish this week before a two-week review period) contributes yet another schema to the soup, so I can't claim I'm innocent, though simplification was one of my goals. Still, could somebody slow this stuff down so that XML can have a tiny chance to grow? We're not even at the first round of browser implementations and already it looks like XML is attempting self-immolation at the shrine of complexity. The specs are doing too many things in too many places. 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 bckman at ix.netcom.com Mon Aug 17 20:14:28 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:04:03 2004 Subject: a small question on xml Message-ID: <02e401bdca0b$63ca5f60$02addccf@ix.netcom.com> Li wrote: > I used IBM Parser for XML, but it shows some error. It seems that >" and < are not properly represented. >From section 2.4 of the XML spec obtainable at http://www.w3.org/TR/REC-xml The ampersand character (&) and the left angle bracket (<) may appear in their literal form only when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. They are also legal within the literal entity value of an internal entity declaration; see "4.3.2 Well-Formed Parsed Entities". If they are needed elsewhere, they must be escaped using either numeric character references or the strings "&" and "<" respectively. The right angle bracket (>) may be represented using the string ">", and must, for compatibility, be escaped using ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section. " 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: Li Jiefeng To: Date: Monday, August 17, 1998 12:07 PM Subject: a small question on xml xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Aug 17 20:14:29 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:03 2004 Subject: More on Namespaces In-Reply-To: <5030300024138440000002L002*@MHS> References: <5030300024138440000002L002*@MHS> Message-ID: <199808171812.OAA31635@unready.megginson.com> Dean Roddey writes: > It seems that mixing up namespaces and DTDs/Schemas is > incorrect. DTDs and Schemas would *use* namespaces, but a namespace > itself should be just a namespace, shouldn't it? Making a > namespace and a DTD/Schema one and the same means that the tags in > that namespace could only be used in a document that matched that > DTD/Schema, which obviously would not be optimal for very open > ended sets of tags. Absolutely correct -- the XML WG came to the same conclusion. Although the schema mechanism is not yet defined, it will certainly be possible to have a many-to-many relationship among schemas and namespaces. I can write my own structural schema that happens to use names from the TEI and Docbook namespaces, but arranged according to my own requirements (i.e. this is a TEI paragraph, but I'm allowing it only here). 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 Mon Aug 17 20:41:29 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:03 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) In-Reply-To: References: Message-ID: <199808171839.OAA31724@unready.megginson.com> Simon St.Laurent writes: > Still, could somebody slow this stuff down so that XML can have a > tiny chance to grow? We're not even at the first round of browser > implementations and already it looks like XML is attempting > self-immolation at the shrine of complexity. The specs are doing > too many things in too many places. This is progress: it took SGML over a decade to get this complicated. More seriously, if (as -- I think -- Tim Bray has suggested), XML is the new ASCII, then it is perfectly acceptable for people to standardise special uses of it. ASCII is not more complicated because C++ programs can be written using it, nor does the complexity of the ANSI C++ spec make ASCII any harder. What frightens me is the danger that some people might forget about layering and try to overload the XML core. XML 1.0 has some warts, but in general, it's beautifully simple. I have no objection to seeing RDF, DCD, Namespaces, etc. built *on top of* XML, but I don't want to see them built *into* XML -- imagine if every program that worked with ASCII had to be able to parse C++ as well, or if every IP router had to know about HTTP! In other words, don't fight the new standards -- they will live or die on their own (the market will probably kill about 80 per cent of them fairly quickly: even the power of Microsoft couldn't save CDF) -- but stand ready to bar the door if any of them gets too close. 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 lisarein at finetuning.com Mon Aug 17 20:46:53 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:03 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) References: <199808171839.OAA31724@unready.megginson.com> Message-ID: <35D88359.30DC52C@finetuning.com> well said. I think it's also very important to project to the public that any syntaxes calling themselves "XML-based" that don't comply with the XML 1.0 spec ARE NOT XML and should be disregarded, and certainly not implemented. It's our only hope at preserving interoperability. But you all know this :-) lisa David Megginson wrote: > > Simon St.Laurent writes: > > > Still, could somebody slow this stuff down so that XML can have a > > tiny chance to grow? We're not even at the first round of browser > > implementations and already it looks like XML is attempting > > self-immolation at the shrine of complexity. The specs are doing > > too many things in too many places. > > This is progress: it took SGML over a decade to get this complicated. > > More seriously, if (as -- I think -- Tim Bray has suggested), XML is > the new ASCII, then it is perfectly acceptable for people to > standardise special uses of it. ASCII is not more complicated because > C++ programs can be written using it, nor does the complexity of the > ANSI C++ spec make ASCII any harder. > > What frightens me is the danger that some people might forget about > layering and try to overload the XML core. XML 1.0 has some warts, > but in general, it's beautifully simple. I have no objection to > seeing RDF, DCD, Namespaces, etc. built *on top of* XML, but I don't > want to see them built *into* XML -- imagine if every program that > worked with ASCII had to be able to parse C++ as well, or if every IP > router had to know about HTTP! > > In other words, don't fight the new standards -- they will live or die > on their own (the market will probably kill about 80 per cent of them > fairly quickly: even the power of Microsoft couldn't save CDF) -- but > stand ready to bar the door if any of them gets too close. > > 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 SimonStL at classic.msn.com Mon Aug 17 21:10:50 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:04:03 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) Message-ID: David Megginson writes: >What frightens me is the danger that some people might forget about >layering and try to overload the XML core. XML 1.0 has some warts, >but in general, it's beautifully simple. I have no objection to >seeing RDF, DCD, Namespaces, etc. built *on top of* XML, but I don't >want to see them built *into* XML -- imagine if every program that >worked with ASCII had to be able to parse C++ as well, or if every IP >router had to know about HTTP! David's got it right, though routers are learning more about HTTP all the time. (_Expensive_ ones, anyway.) I think layering may provide an elegant answer to the schema/feature clusterbombing we're experience now, though it too may require some reconfiguration of XML. Basically, it looks like we have: * Core syntax (<, >, / - elements, attributes, the XML declaration) * Minimization (entities and their friends, plus lots of other charmers) * Schemas (DTDs, DCDs, XSchemas, RDF, etc.) * Data typing (Goes with schemas, but I'd like to see it independent of any particular schema) * Linking (XLink) * Referencing (XPointer) [Yes, I know I'm making a questionable distinction.] * Styling (CSS, XSL) * Core syntax extensions - namespaces, xml:lang, xml:space We need to find a way to keep these things separate while making sure they can work with each other, and not muddy the name XML too terribly. If understanding XML is going to require namespaces and RDF, a lot of folks are going to choke. If XML is about elements and attributes and the rest of it is gravy, then I think we'll be all right. I was going to write a very grumpy essay about this, but it looks like it's a widely held concern that people in the right places will likely notice, so I'll keep the fire and brimstone to a minimum. 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 digitome at iol.ie Mon Aug 17 21:20:12 1998 From: digitome at iol.ie (Sean Mc grath) Date: Mon Jun 7 17:04:04 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) Message-ID: <1.5.4.32.19980817190549.0090522c@gpo.iol.ie> >Simon St.Laurent writes: > > > Still, could somebody slow this stuff down so that XML can have a > > tiny chance to grow? We're not even at the first round of browser > > implementations and already it looks like XML is attempting > > self-immolation at the shrine of complexity. The specs are doing > > too many things in too many places. > [David Megginson] >This is progress: it took SGML over a decade to get this complicated. > :=) I share Simon St. Laurents concern that namespaces, schemas etc. are getting rather hairy. I think there is a possibility that the sleek Dolphin that is XML might begin to morph into a Duck Billed Platypus. XML came about in a remarkably short period of time and yet exhibits substantial "beauty" in its simplicity. The reason for this goes deeper than the fact that some great minds designed it -- XML is the result of over a *decade* of experience with SGML. Some good things in SGML were dropped, some good things were retained, but all the while, the decisions were based on rubber-on-the-road *experience*. By contast, namespaces, schemas etc. are very, very new to SGML/XML. There is no decade of directly relevant, collective wisdom on which the great minds designing them can draw. This makes me wonder which is best to do. Standardise asap or create "exposure drafts" first. What is mean is : create "exposure drafts" for difficult areas with a timescale for comments of, say, 1 year. Let implementors create trial implementations, lobby for changes, based on these and feed back information about what works and what doesn't. >From there, create the recommendations. Just a thought. Sean Mc Grath http://www.digitome.com/sean.htm +353 96 47391 "There are three types of people in the world - those who can count and those who cannot." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 17 21:24:27 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:04:04 2004 Subject: What's that buzz? Message-ID: <3.0.32.19980817122312.00bf4730@207.34.179.21> Check out the "word from the wasp" at www.webstandards.org. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Tue Aug 18 05:34:56 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:04:04 2004 Subject: DOM tutorials. Message-ID: <000801bdca59$b7946de0$9cacdccf@ix.netcom.com> For those who may be interested, I have added tutorials on the W3 and IE5 DOM's for HTML and XML to my web pages (www.hypermedic.com/style/index.htm). Follow the DOM link. I am aware that there will probably be revisions to both these DOM's in the near future, so the tutorials are only available as a text file (55K, no illustrations)or a Word6 file (255K) at the present time. I decided to go ahead and post them anyway as I understand the changes will not be of a major nature. Also I have been promising to post them for 4 months now! When the DOM situation stabalizes, I will revise them and convert the files to HTML. Regards, Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mika.kekkonen at vtt.fi Tue Aug 18 09:01:56 1998 From: mika.kekkonen at vtt.fi (mika.kekkonen@vtt.fi) Date: Mon Jun 7 17:04:04 2004 Subject: element and entity declaration Message-ID: <3.0.32.19980818095919.009aae80@vttmail.vtt.fi> 1) If I have entity declarations in my dtd, do I need the element declarations also? I have experience that I must have element declarations in dtd, if I have dtd. For example file &horse; with horse.dtd produces all the time result that I must have declaration of MODULE element. Why? If I don't have entities, I don't need dtd at all. 2) Which entities all xml parsers have to know without declarations? I know that they can handle &, but how about ä etc? Thanks Mika xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mtbryan at sgml.u-net.com Tue Aug 18 09:47:38 1998 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:04:04 2004 Subject: To validate or not to validate, that is the question Message-ID: <01bdca7c$36c55760$LocalHost@sgml.u-net.com> John Cowan wrote: >I think your model of "compound document" is too simple. You seem to model it as a set of self-contained fragments enclosed in a container. Most current proposals for using namespaces take just that approach. Namespaces were initially conceived as a way of allowing controlled sets of metadata to be added to files. Their extension to a general purpose mechanism, while useful, should not blinker us from the real user requirement, which is to take data generated by other applications and add it to a file that has previously been validated using a specific DTD. >I expect to see much more complex documents: a Chemical ML description of a molecule, with (a) embedded HTML English-language documentation, which itself contains several inclusions of MathML, and (b) a SMIL document that marshals a non-XML movie of the molecule. How would you validate just the HTML part, given that the HTML DTD does not understand MathML? I would not try to validate the whole thing in one go. I would create the MathML within a Maths generator module that could only generate validated MathML. I would validate any HTML I needed to embedded within the document with an HTML editor which had enough sense to ignore any element that had a namespace other than HTML specified, together with any nested elements that were not declared to be HTML compliant. I would edit the Chemical ML material in an SGML/XML editor that was set-up to validate material in that DTD, but ignore any element (and its contents) that had a namespace specification for another DTD. Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Tue Aug 18 13:33:35 1998 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:04:04 2004 Subject: a small question on xml Message-ID: <199808181133.MAA29245@GPO.iol.ie> >> Will someone help me with the representation of special characters >>in .xml files? For example, >> >> >> or >> >> >> I used IBM Parser for XML, but it shows some error. It seems that >>" and < are not properly represented. The "<" character is very special in XML and should only appear when you want the parser to treat what follows as some sort of markup. In all other cases, use "<" which is a built in "entity" that the parser knows about that translates post-parse to the "<" character. The ">" character is less constrained but it is good defensive authoring practice to escape it as well using ">" Sean Book of condolences for the Omagh bombing: http://www.rte.ie/condolences.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 18 13:40:54 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:04:04 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 8 Message-ID: I'm finally free of the proxy server nightmare, so XSchema will be coming out shortly. I hope to close down the process by Friday for sections 1, 2, and 3, putting them out for two weeks of review. Yes, a complete copy of both the spec and the DTD will be available by that point. I won't be in Montreal, but I hope a few of you bring copies of the spec with you to talk about. The only changes here are the addition of AttGroup to the XSchema element (note that AttDef elements are still possible there) and the correction of a date - 8/2/98 is now 2 August 1998, so no one should think the namespace section is from February. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. The site is moving this week as well; AOL finally tried my patience too far and I'm setting up simonstl.com anyway. The PURL will bring you to a current location; it will change as the location changes. 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 2 August 1998 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 amitr at abinfosys.com Tue Aug 18 15:58:46 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:04:04 2004 Subject: Any examples of server side XML apps. using XSL for client presentation. Message-ID: <00c501bdcab0$b829bd80$0101a8c0@server.abinfosys.com> Hello, Would anyone be knowing of :- 1) Any real time server side XML applications which use XSL stylesheet files (along with an XSL processor) to process and present XML data to the client? 2) Would anyone be knowing of XSL processors which take XML streams as input.Most of them out there take XML files as URLs.(especially MSXSL). Is there any XSL processor which would take a parsed XML tree as an input alongside with an XSL stylesheet to display HTML. Any answers /Suggestions would be appreciated Thanks, AMIT I have tried the sample apps at www.microsoft.com/xml among other sample demos, but no where have I come across a proper distributed client server implementation involving both XML and XSL. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Aug 18 16:16:42 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:04:04 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 6 Message-ID: Here's the latest content model declarations. There are two big changes: 1) A Model element now contains the content model declarations. This provides for documentation of the content model as a whole, and permits better (eventual) modularization. 2) All the XSC: prefixes have been stripped out per the new namespaces setup. 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.3 Content Model Declarations Content model declarations are made within Model sub-element of the declaration for the element to which they apply. Reference, Mixed, Choice, and Sequence models may appear inside XSchema elements for reusability, documentation, and reference, but will need to be linked to particular element declarations through mechanisms not yet defined (most likely XLink). All content model declarations have an optional id value for reference. The Model element holds the content model for an element. 2.3.1 Empty Content Model The simplest content model is empty, which indicates that the parent element has no sub-elements and no character data content. The Empty element indicates that an element is empty. For example, to declare the Species element shown in the previous section empty, use the following XSchema declaration: This would not allow the Species element to contain any text or sub-elements. 2.3.2 Any Content Model The Any content model, which allows the element to contain parsed character data or any other elements as content, is equally simple: Using the Any content model is much like using the Empty content model. To declare that the Species element had a content model of any, use the following declaration: This allows the Species element to contain text and any sub-elements an author desired. 2.3.3 PCData Content Model The PCData content model, which allows the element to contain only parsed character data, is also represented by a single empty element. Using the PCData content model is much like using the Empty and Any content models. For example, to assign the Species element a content model of PCData, use the following declaration: This allows the Species element to contain text, but no sub-elements. 2.3.5 Reference Content Model The Reference content model allows an element to specify other elements which it may contain, as well as their quantity. Ref elements identify the element to be contained, as well as the frequency with which it must appear: The Element attribute must refer to the Name attribute of an ElementDecl element elsewhere in the XSchema document. An ElementDecl element may contain at most one Ref element. The Frequency attribute controls the number of referenced elements that may occur. To define content models that permit or require the use of more elements, the Any, Mixed, Choice, or Sequence content models should be used as appropriate. To declare that the Species element may contain a single CommonName element, and nothing else, use the following declaration: This requires the Species element to contain a single CommonName element. To make the CommonName element optional - though it may still only appear once, set the Frequency attribute to 'Optional': Optional is the equivalent of the ? occurrence indicator in XML 1.0 DTDs. To require the Species element to contain at least one but possibly multiple CommonName elements, set the Frequency attribute to 'OneOrMore': OneOrMore is the equivalent of the + occurrence indicator in XML 1.0 DTDs. Finally, to allow the Species element to contain any number (including zero) of CommonName elements, set the Frequency attribute to 'ZeroOrMore': ZeroOrMore is the equivalent of the * occurrence indicator in XML 1.0 DTDs. 2.3.6 Mixed Content Model Mixed content model allows the unordered use of different element types and character data. Content within an element that uses a mixed declaration must be PCData or one or more of the elements referenced by Ref elements nested within the Mixed declaration. Only Ref elements can be nested under an Mixed element; the PCData content is inherent in the Mixed content model. To declare that the Species element may contain a mix of PCData, CommonName elements, LatinName elements, and PreferredFood elements in any order, use the following declaration: The XSchema processor should ignore any frequency attributes in Ref elements that appear as subelements of the Mixed element. 2.3.7 Choice Content Model The Choice content model allows for either-or inclusions of elements and groups of elements. The Choice content model represents groups of element content possibilities and must contain at least two sub-elements. Situations where only one element is needed should use the Ref content model instead of Choice. The Choice element may indicate a frequency, allowing the content model defined by the Choice model to appear one, one or zero, one or more, or zero or more times. The simplest Choice element will contain two Ref elements and a frequency attribute. By default, the Choice element's content model is required to appear once. To declare that a Species element may contain either a common name or a Latin name, but not both, use the following declaration: The Ref elements in an Choice element may also specify the frequency with which they appear, as may the Seq elements described in section 2.3.8. The Choice element is the equivalent of the choice group (element | element) in XML 1.0 DTDs. The ordering of the sub-elements within an Choice element has no effect. 2.3.8 Sequence Content Model The Sequence content model allows for the sequential appearance of sub-elements. Elements, if they are required to appear, must appear in the order of the Choice and Ref sub-elements in the Seq element. The Seq element may also indicate a frequency, allowing the content model defined by the Seq model to appear one, one or zero, one or more, or zero or more times. The simplest Seq element will contain two Ref elements in the order in which they should appear and a frequency attribute. By default, the Seq element's content model is required to appear once. To declare that the Species element requires a common name and a Latin name, in that order, use the following declaration: The Ref elements in an Seq element may also specify the frequency with which they appear, as may the Choice elements. The Seq element is the equivalent of the sequence group (element, element) in XML 1.0 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 Tue Aug 18 16:18:55 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:04 2004 Subject: More on Namespaces (also long, but also optimistic) In-Reply-To: <199808171456.KAA23098@chmls05.mediaone.net> Message-ID: <3.0.1.16.19980818144458.2267ff2c@pop3.demon.co.uk> At 10:56 17/08/98 -0400, Charles Reitzel wrote: >I attempted a post earlier, but I now realize this is a moderated list. NO! You have to subscribe but you appear to have done this successfully! Theoretically HenryR and I have the power to unsubscribe people but that hasn't happened and I doubt it will (other than perhaps for spam). I occasionally make moderatorial messages on the list (LISTRIVIA) suggesting styles of posting. [Recently I received two private posts - one repeated thrice - suggesting these were too frequent and so the rest of August is holiday season for LISTRIVIA. Go wild!] >Perhaps whoever recieves this (Mr. Murray-Rust?) would be kind enough to >forward this mail to the list or, even better, to folks in the WG. It's already on XML-DEV> XML-DEV offered its services to the WG for helping to provide a forum where namespaces could be worked out. There are a number of WG members who read XML-DEV and I think your points will be carefully considered by them. If they think that there is something new I am sure they will re-post it to XML-WG (private W3C list). Note that there has already been a lot of (private) discussion about namespaces and it is probable - though not inevitable - that ideas posted here will have already been considered. Thus the <|NAMESPACE> and construct have certainly been thrashed out - I can't remember why they weren't adopted. I appreciate that for you this is frustrating - it doesn't mean your post won't be read. The chance of any reversal of the current syntax is extremely improbable, but I'm not suggesting it can't be discussed. However, as always on XML-DEV out highest priority is to try to make the current draft or spec actually work and do something useful. So several people (including me) are hacking software to make namespaces do something. If the work/don't_work you'll read about it here :-) [...] > >I hope you find these comments and suggestions constructive. I did. I am sure that they will be considered by a number of people. Don't be too downhearted if they don't get enthusiastic support - it happens to all of us. Not all my postings get 'answered' :-) 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 18 16:18:56 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:04 2004 Subject: Is XML getting too hard? In-Reply-To: Message-ID: <3.0.1.16.19980818151048.2be7bcdc@pop3.demon.co.uk> At 19:09 17/08/98 UT, Simon St.Laurent wrote: >David Megginson writes: >>What frightens me is the danger that some people might forget about >>layering and try to overload the XML core. XML 1.0 has some warts, >>but in general, it's beautifully simple. I have no objection to >>seeing RDF, DCD, Namespaces, etc. built *on top of* XML, but I don't >>want to see them built *into* XML -- imagine if every program that >>worked with ASCII had to be able to parse C++ as well, or if every IP >>router had to know about HTTP! > >David's got it right... I agree. >time. (_Expensive_ ones, anyway.) > >I think layering may provide an elegant answer to the schema/feature I agree with this analysis, and I'd like to see us tackle those components which are isolable and can be prototyped at present. I know it's difficult with most of them being in a fluid situation. I'd be also grateful for some timescale on PRs, etc for these. >clusterbombing we're experience now, though it too may require some >reconfiguration of XML. Basically, it looks like we have: > >* Core syntax (<, >, / - elements, attributes, the XML declaration) >* Minimization (entities and their friends, plus lots of other charmers) >* Schemas (DTDs, DCDs, XSchemas, RDF, etc.) >* Data typing (Goes with schemas, but I'd like to see it independent of any >particular schema) >* Linking (XLink) >* Referencing (XPointer) [Yes, I know I'm making a questionable distinction.] >* Styling (CSS, XSL) >* Core syntax extensions - namespaces, xml:lang, xml:space > >We need to find a way to keep these things separate while making sure they can >work with each other, and not muddy the name XML too terribly. If >understanding XML is going to require namespaces and RDF, a lot of folks are >going to choke. If XML is about elements and attributes and the rest of it is >gravy, then I think we'll be all right. Some of these are dependent on others, right? If so, which - because that affects the order we start on. For example I suspect that XLink isn't very much use without XPointer, but the reverse isn't necessarily true. (i.e. one can envisage uses of XPointer without Xlink syntax). I have a feeling that *if* we use prefixed names, then nearly everything else is going to have to depend on how they are used. Similarly any minimisation has to be resolved at an early stage. >I was going to write a very grumpy essay about this, but it looks like it's a >widely held concern that people in the right places will likely notice, so >I'll keep the fire and brimstone to a minimum. Thanks. I think people will notice and will be grateful for constructive ways forward. I suspect that those who drafted the latest WD are somewhat exhausted by the process and would be grateful for help. One idea that is worth exploring is how far we can get without using complex constructs. The idea of bundling up many files - promoted by David Megginson - is an exciting one. If I could be assured that I could send a jar file to a client and they could unbundle it seamlessly and effortlessly then I might very well eschew the complexities of namespaces (I'd still use simple ones). Effectively each namespaced object would be a file with a unique namespace. These could be referenced from the document either as NDATA (am I right?) or by XLink. However I am not convinced that this is a good idea for storing files client-side or manipulating them locally. Either they would remain as *.jar - which are unreadable by humans - or they would be expanded to lots of little files which could very easily get lost or overwritten. My own suggestion would be for a 'multipart' file where the different XML components were concatenated - perhaps even by special syntax. Then they are both human-readable and physically bound. 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 18 16:23:37 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:04 2004 Subject: XSA, OSD, LSM, RPM RDF, IAFA ... Message-ID: <3.0.1.32.19980818161834.00d85f04@ifi.uio.no> Well, this was something of a shock. I thought I'd done my homework properly, but I'd overlooked both LSM and rpmfind, despite having heard of both already. (Thank you Steven Champeon and Daniel Veillard for mentioning these!) LSM seems very similar to XSA, although with slightly more information and a different syntax. From some comments on the LSM home pages it appears that the time may be ripe for an XML LSM syntax. >From the information on the LSM pages it appears that IAFA is rather similar to LSM, both syntactically and with respect to the actual information in the records. Daniel Veillards RPM RDF and OSD appear rather similar, and seem to have a rather different focus from XSA/LSM/IAFA. Still, cooperation may be useful here as well. (And, yes, I _am_ impressed with the rpmfind system. Way to go, Microsoft. :) I'll contact the developers of LSM and come back with an update once I know what they think. Daniel, do you see any benefit to aligning yourself with an XSA/LSM effort? Your data seem to come from a different source and to be used for a different purpose, but I don't really know your system. Or do you think an XSA/LSM system should be aligned with yours somehow? Other opinions are of course also most welcome. -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Tue Aug 18 16:38:45 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:04 2004 Subject: Any examples of server side XML apps. using XSL for client presentation. In-Reply-To: <00c501bdcab0$b829bd80$0101a8c0@server.abinfosys.com> Message-ID: <3.0.1.32.19980818163544.00d8c574@ifi.uio.no> * Amit Rekhi > >1) Any real time server side XML applications which use XSL stylesheet files >(along with an XSL processor) to process and present XML data to the client? docproc sounds like what you want: >2) Would anyone be knowing of XSL processors which take XML streams as >input.Most of them out there take XML files as URLs.(especially MSXSL). Is >there any XSL processor which would take a parsed XML tree as an input >alongside with an XSL stylesheet to display HTML. Not AFAIK, I'm afraid. You should be aware that XSL as it described in the current Note and implemented in current tools will be obsolete once the new WD is released (should be any day now). From what I'm told the new WD will be substantially different from the Note. --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 peter at ursus.demon.co.uk Tue Aug 18 16:45:45 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:04 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 8 In-Reply-To: Message-ID: <3.0.1.16.19980818154527.398764b2@pop3.demon.co.uk> At 11:39 18/08/98 UT, Simon St.Laurent wrote: >I'm finally free of the proxy server nightmare, so XSchema will be coming out >shortly. I hope to close down the process by Friday for sections 1, 2, and 3, >putting them out for two weeks of review. Yes, a complete copy of both the >spec and the DTD will be available by that point. I am sure we are extremely grateful to Simon and colleagues for the work they have put in on XSchema. I believe that we have software that implements it and converts back and forth between DTD<->XSchema. If so, I shall certain use it for documenting my VHG DTD when I have the time. I have also recently hacked JUMBO so that it supports most of IBTWSH in Swing so this means we should be able to have an XSchema browser/editor. [Yes I shall release JUMBO 2 asap - at present bits are so awful I daren't...] 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 18 16:56:50 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:04 2004 Subject: To validate or not to validate, that is the question References: <01bdca7c$36c55760$LocalHost@sgml.u-net.com> Message-ID: <35D9960B.B7F0D334@locke.ccil.org> Martin Bryan wrote: > I would validate any HTML I needed to embedded within the document > with an HTML editor which had enough sense to ignore any element that had a > namespace other than HTML specified, together with any nested elements that > were not declared to be HTML compliant. I would edit the Chemical ML > material in an SGML/XML editor that was set-up to validate material in that > DTD, but ignore any element (and its contents) that had a namespace > specification for another DTD. Of course, if you are allowed to invent whatever tools you need, you can do whatever you want. I was asking for a *general* method of validating document parts with alien subparts. Architectural forms can perhaps provide this ability: I still don't understand them well enough to be sure. -- 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 18 17:15:59 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:04 2004 Subject: XSA, OSD, LSM, RPM RDF, IAFA ... References: <3.0.1.32.19980818161834.00d85f04@ifi.uio.no> Message-ID: <35D99A7F.465D5194@locke.ccil.org> Lars Marius Garshol wrote: > LSM seems very similar to XSA, although with slightly more information > and a different syntax. From some comments on the LSM home pages it > appears that the time may be ripe for an XML LSM syntax. I proposed this to the Trove folks, who are trying to redesign large software archives (http://www.ccil.org/~esr/trove), but they vetoed it for now in favor of an RFC-822 style syntax. -- 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 jon at net.lut.ac.uk Tue Aug 18 17:34:59 1998 From: jon at net.lut.ac.uk (Jon Knight) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? In-Reply-To: <3.0.1.16.19980818151048.2be7bcdc@pop3.demon.co.uk> Message-ID: On Tue, 18 Aug 1998, Peter Murray-Rust wrote: > The idea of bundling up many files - promoted by David Megginson - is an > exciting one. If I could be assured that I could send a jar file to a > client and they could unbundle it seamlessly and effortlessly then I might > very well eschew the complexities of namespaces (I'd still use simple > ones). Effectively each namespaced object would be a file with a unique > namespace. These could be referenced from the document either as NDATA (am > I right?) or by XLink. Does a *.jar file imply that XML is getting tightly bound to Java? What about people wanting to use other programming language with XML? Surely XML's architecture should be independent of the programming languages used to implement its tools? 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 tyler at infinet.com Tue Aug 18 18:06:57 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:05 2004 Subject: DOM Node.cloneNode() Message-ID: <35D9A689.D3E7F31E@infinet.com> In the most recent DOM spec the method Node.cloneNode(boolean deep) does not really specify how the Node should be cloned (e.g. a shallow copy or a deep copy). It has a boolean "deep" argument that would imply a true deep copy, but still this is not totally clear as a true deep copy would be a copy by value instead of the implicit copy by reference. In other words, if I have a Node named "A" with two children named "B" and "C", would you do something like this in Java for A: public Node cloneNode(boolean deep) { Node newNode = new NodeImpl(); // Do attribute copies here if (deep) { newNode.appendChild(B); newNode.appendChild(C); } return newNode; } or else would you do something like: public Node cloneNode(boolean deep) { Node newNode = new NodeImpl(); // Do attribute copies here if (deep) { newNode.appendChild(B.cloneNode(deep)); newNode.appendChild(C.cloneNode(deep)); } return newNode; } Similiarly, what happens with the Attributes of a Node is also not too clear to me. Are attributes copied by value or by reference as well? What happens to the parent attribute? Should it be copied as well or should it just have the implicit DocumentFragment reference as its parent? What happens to the references to the siblings of a node? Any help on these issues would be greatly appreciated... Thanx in advance, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Tue Aug 18 18:16:14 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? In-Reply-To: Message-ID: On Tue, 18 Aug 1998, Jon Knight wrote: > On Tue, 18 Aug 1998, Peter Murray-Rust wrote: > > The idea of bundling up many files - promoted by David Megginson - is an > > exciting one. If I could be assured that I could send a jar file to a > > client > > Does a *.jar file imply that XML is getting tightly bound to Java? For starters I think this is all HTTP 1.1's job, it provides persistant connections, and the framework for compression. As for Jar files, they are just zip files with a different extension and a manifest file included. --- 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 david at megginson.com Tue Aug 18 18:49:26 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? In-Reply-To: <3.0.1.16.19980818151048.2be7bcdc@pop3.demon.co.uk> References: <3.0.1.16.19980818151048.2be7bcdc@pop3.demon.co.uk> Message-ID: <199808181647.MAA01902@unready.megginson.com> Peter Murray-Rust writes: > The idea of bundling up many files - promoted by David Megginson - > is an exciting one. If I could be assured that I could send a jar > file to a client and they could unbundle it seamlessly and > effortlessly then I might very well eschew the complexities of > namespaces (I'd still use simple ones). Effectively each namespaced > object would be a file with a unique namespace. These could be > referenced from the document either as NDATA (am I right?) or by > XLink. I think that I might have caused a little confusion here. I am *not* suggesting an alternative to namespaces -- I support namespaces in principle, and expect that they would still be used in the individual documents. What I'm explaining is a simpler and more obvious solution to the specific problem of multiple processes constructing a single XML document (this was the motivating example that brought in local scoping -- namespace prefixes that are in force for only part of an XML document). 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 Tue Aug 18 18:54:44 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? In-Reply-To: References: <3.0.1.16.19980818151048.2be7bcdc@pop3.demon.co.uk> Message-ID: <199808181652.MAA01923@unready.megginson.com> Jon Knight writes: > Does a *.jar file imply that XML is getting tightly bound to Java? > What about people wanting to use other programming language with > XML? Surely XML's architecture should be independent of the > programming languages used to implement its tools? Peter was using *.jar by way of casual example, not precept. In fact, since jar is based on zip, it is unsuitable for this sort of work (the whole file has to be read before any can be processed). A streaming protocol similar to tar or cpio is the only reasonable alternative for packaging, since an application can start working with the contents before the whole archive has been downloaded. Note also that packaging does not concern only XML entities -- there's also the problem of bundling non-XML entities, such as vector and raster graphics, audio and video clips, VRML worlds, etc., that are referenced from within an XML document. In the end, then, this is a problem that we have to solve anyway. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Aug 18 22:08:27 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:05 2004 Subject: DOM Node.cloneNode() Message-ID: <003f01bdcae2$a8979d10$2ee044c6@arcot-main> Tyler, >In other words, if I have a Node named "A" with two children named "B" >and "C", would you do something like this in Java for A: A shallow clone of "A" will result in a node of same type as "A" with no children. A deep clone of "A" will result in a node of same type as "A" with clones of "B" and "C". A node has exactly one parent or no parent at all so "B" and "C" can not be children of both "A" and its clone. Since it is inappropriate for cloneNode to move "B" and "C" from "A" to its clone, a clone is made and added during deep clone. >Similiarly, what happens with the Attributes of a Node is also not too >clear to me. Are attributes copied by value or by reference as well? >What happens to the parent attribute? Should it be copied as well or >should it just have the implicit DocumentFragment reference as its >parent? What happens to the references to the siblings of a node? Whether an attribute is copied by value or by reference depends on the implementation. I think most implementations will copy assigned attributes by value and default attributes by reference. Attributes does not have a parent nor siblings so it can not return DocumentFragment as its parent. Hope this helps, 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 jborden at mediaone.net Tue Aug 18 22:16:43 1998 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? Message-ID: <01f501bdcae4$e252e6c0$0b2e249b@fileroom.Synapse> > >The idea of bundling up many files - promoted by David Megginson - is an >exciting one. If I could be assured that I could send a jar file to a >client and they could unbundle it seamlessly and effortlessly then I might >very well eschew the complexities of namespaces (I'd still use simple >ones). Effectively each namespaced object would be a file with a unique >namespace. These could be referenced from the document either as NDATA (am >I right?) or by XLink. > > However I am not convinced that this is a good idea for storing files >client-side or manipulating them locally. Either they would remain as *.jar >- which are unreadable by humans - or they would be expanded to lots of >little files which could very easily get lost or overwritten. My own >suggestion would be for a 'multipart' file where the different XML >components were concatenated - perhaps even by special syntax. Then they >are both human-readable and physically bound. multipart/related works well. Each part gets a Content-ID label which translates into a "cid:xxx" URI. This allows each part to be internally linked. The other advantage is that different parts can have different Content-Types so that binary data can interoperate with XML. This is especially true if an overall DOM is developed with integrates XML and other datatypes. Jonathan Borden JABR Technology Corporation jborden@mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Aug 19 01:44:20 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:04:05 2004 Subject: XSchema Specification - Extensions (Section 2.6), Draft 3 Message-ID: The latest draft for the XSC:Doc and XSC:More elements follows, updated for namespaces. Because these elements may (or must, in the case of XSC:Doc) contain elements that use other namespaces, the rules are slightly different. 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.6 XSchema Extensions XSchema provides areas in which XSchema developers can provide supplemental information and metadata regarding XSchema components in both human- and machine-readable formats. Human-readable information is provided through the use of a subset of HTML that conforms to XML syntax, while machine-readable information may be provided through the XSC:More element. 2.6.1 Documentation Extensions Human-readable documentation for XSchemas should be provided using the Itsy Bitsy Teeny Weeny Simple Hypertext (IBTWSH) format created by John Cowan. The full DTD is available at http://www.ccil.org/~cowan/XML/ibtwsh.dtd. Documentation that uses portions of the IBTWSH format may be included in the XSC:Doc element, a subelement available to all declarations. The XSC:Doc element provides basic formatting options for XSchema documentation. %ibtwsh; Note that because XSC:Doc redefines the default namespace to support IBTWSH, the XSC: prefix must be used for XSC:Doc. Any element allowed in the IBTWSH horiz.model set of elements (A, BR, SPAN, XML, CITE, CODE, DFN, EM, KBD, SAMP, STRONG, VAR, or parsed character data) may be used in the XSC:Doc element. Note that IBTWSH does not use namespaces in order to preserve compatibility with HTML. XSchema applications should ignore all XSchema declarations (i.e., elements prefixed with XSC: or another appropriate XSchema prefix) within an XSC:Doc element. (The XML element of IBTWSH allows an ANY content model.) 2.6.2 Other Extensions The XSC:More element provides an area which developers can use to create their own supplements to XSchema, defining content types more tightly than is possible through XSchema 1.0. The XSC: More element has a simple ANY content model, though XSchema processors should ignore the appearance of any elements from the XSchema namespace in this area. Because XSC:More redefines the default namespace, the XSC: prefix must be used for XSC:More. Developers may override the blank value of the xmlns attribute to define their own default namespace for elements contained in the XSC:More 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 SimonStL at classic.msn.com Wed Aug 19 02:11:12 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:04:05 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 6 Message-ID: This section is large and has absorbed significant changes. 1) It has been updated for namespace handling. 2) The AttDefs are now contained in an AttGroup container element. 3) The attributes used to identify #REQUIRED, #FIXED, #IMPLIED, and default values for attributes have been reduced to two from three. Many thanks to Jeni Tennison for her insightful analysis on this, and to Ron Bourret for helping develop it. Hopefully, we're about there. 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.4 Attribute Declarations 2.4.1 Overview Attribute declarations are made with AttDef elements nested inside of AttGroup container elements. AttGroup elements may be nested inside of ElementDecl element declarations or XSchema elements. The type of an attribute is defined with an attribute, as is a declaration of whether or not it is required and a possible default value. Values for enumerated types are provided with subelements. In XSchema 1.0, attribute declarations (AttDef elements inside of an AttGroup element) may be nested within the element declaration (ElementDecl element) for the element to which the attribute belongs, or outside of that structure in an XSchema element. If the AttGroup element appears nested inside an ElementDecl element, the Element attribute must be ignored. Similarly, if an AttDef element appears nested inside an AttGroup element, its Element attribute must be ignored in favor of that of the AttGroup. If an AttGroup or AttDef element appears nested under the XSchema element, the Element attribute may contain a name token corresponding to the Name attribute of the element to which this attribute applies. If the Element attribute is missing, that AttDef or AttGroup declaration may only be used by reference. AttGroup elements are container elements. All of their attributes, except for id, apply to the child AttDef elements and may be overridden by the attributes of those child elements. The Name attribute of the AttGroup element is provided for convenient reference within the XSchema. This attribute should be ignored in conversions to DTDs. The Name attribute of the AttDef element provides the name by which the attribute will be identified. Attribute names must be unique within the element in which they are declared. A nested declaration is shown below. ...additionalElementInformation... This declares an element with the name Species that has an attribute named status. If the status attribute was declared outside of the Species element declaration, the declarations would appear as shown below. ...additionalElementInformation... ... Merely naming an attribute may be adequate. Attribute declarations may identify types and provide information about whether the attribute is required. By default, attributes will be assumed to contain character data (CData), not be required, and have no default value. This information is declared using additional attributes. The simplest attribute declaration possible identifies an attribute as containing character data (CData) and allows the attribute to be optional, as shown below. Applications may also use the id attribute to provide unique identifiers for attribute declarations using values that are unique within the XSchema. The prefix attribute identifies the prefix that will be applied to this attribute during conversion to DTDs. The ns attribute identifies the URI which functions as the namespace name for this attributes. Namespace processing is covered further in Section 3.0, "XSchema and Namespaces". 2.4.2 Attribute Types XSchema 1.0 provides equivalents for all of the XML 1.0 DTD attribute types. All of them are declared using attribute values within the AttDef element. The CData attribute type is one of the most common, permitting an attribute to contain character data as defined by the XML 1.0 specification. If the Species element were to contain an attribute providing the Latin name of the species, the declaration could look like the following. (The Type attribute could actually be omitted in this case, as CData is the default type.) ...additionalElementInformation... This attribute would then be available for use in instances of the Species element: ...additionalContent... The ID attribute type is used to uniquely identify elements in a document for application processing. IDRef and IDRefs attribute types are used to refer to a single ID value in the same document or multiple ID values in the same document, separated by whitespace, respectively. These attribute declarations must be used with the same constraints as apply to ID, IDREF, and IDREFS attribute types in XML 1.0. The Entity and Entities attribute types identify the names of unparsed entities. The use of these attribute types must be made with the same constraints as apply to the ENTITY and ENTITIES attribute types in XML 1.0. If a document is checked directly against an XSchema without a conversion to a DTD, information regarding unparsed entities must be available from the parser for these attribute types to be meaningful. The Nmtoken and Nmtokens attribute types are used to declare attributes that must contain information conforming to the Nmtoken and Nmtokens productions in XML 1.0. The Notation and Enumerated attribute types are more complex, requiring Enumeration subelements to identify their possible content. These two declarations use similar syntax, but the allowed values of Notation declarations must match the Notations declared elsewhere in the XSchema document. If the status attribute of the Species element were to allow the values of extinct, endangered, protected, and non-threatened, an appropriate enumerated type declaration would look like: ...additionalElementInformation... A Species element created conforming to this declaration might look like: ...additionalContentAboutDodos... 2.4.3 Attribute Defaults XSchema requires attribute declarations to provide information about the default value of a given attribute. XSchema provides for the four cases supported by XML 1.0: #REQUIRED, #IMPLIED, #FIXED AttValue, and AttValue, though they are expressed as choices between required and not required with an optional default value. There may be only one default value declaration per attribute. Required attributes (identified in XML 1.0 by #REQUIRED) are identified by assigning the value "Yes" to the Required attribute of an AttDef element. For instance, if the Latin attribute described above was required by the Species element, the AttDef element would contain a Required attribute with a value of "Yes": ...additionalElementInformation... Optional attributes (identified in XML 1.0 by #IMPLIED) are identified assigning the value "No" to the Required attribute of an AttDef element and not assigning a value to the AttValue attribute. Implied indicates that there is no default value provided, and also that no value is required. If the Latin attribute is optional, the AttDef element would contain a "No" value for the Required attribute. (Note that this is the default status and the Required declaration does not need to be made explicitly.) ...additionalElementInformation... Fixed attributes (identified in XML 1.0 by #FIXED AttValue) are identified through the use of the Required attribute in combination with the AttValue attribute, which must contain the fixed value for the attribute. Attributes declared using fixed value cannot declare a different value for that attribute. Fixed effectively hard codes attribute values into particular elements. If the Required attribute has a value of "Yes", and the AttValue attribute is present, the attribute value should be treated as a #FIXED value in XML 1.0. For example, to declare a planet attribute for the Species element, a Required attribute given the value of "Yes" would identify the fixed nature of the attribute and the AttValue attribute would provide the value. ...additionalElementInformation... Attributes may also be provided with a default value that may be overridden by other declarations. These default values are identified through the use of the AttValue attribute. The status attribute of species elements described above would be an appropriate target for such a default value, especially if most species being described fell into a particular category: ...additionalElementInformation... Any default (required, fixed, etc.) may be used with any attribute type, though default values should always correspond to acceptable values for the attribute type. 2.4.4 Combinations of Types, Defaults, and Default Values This notation also permits the declaration of certain attributes (IDs with defaults, for instance) that are prohibited by the standard XML 1.0 DTD syntax. Developers who use these combinations should test that their documents will behave as expected in DTD-only environments as well as XSchema environments. Additional processing of document instances may be necessary to produce normalized-for-DTD use documents if they included such attributes as default values. The attribute type should always be considered more important than its default values in XSchema to DTD conversion. The table below summarizes the possible combinations of XSchema attribute defaults and their XML 1.0 DTD equivalents. Required AttValue XML 1.0 Equivalent Yes #FIXED Yes -- #REQUIRED No AttValue No -- #IMPLIED (-- indicates an empty or undeclared value) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Wed Aug 19 02:26:04 1998 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) In-Reply-To: <1.5.4.32.19980817190549.0090522c@gpo.iol.ie> Message-ID: <199808190025.KAA29591@fep2.mail.ozemail.net> At 05:05 18/08/1998 , Sean Mc grath wrote: | >Simon St.Laurent writes: | > | > > Still, could somebody slow this stuff down so that XML can have a | > > tiny chance to grow? We're not even at the first round of browser | > > implementations and already it looks like XML is attempting | > > self-immolation at the shrine of complexity. The specs are doing | > > too many things in too many places. | > | [David Megginson] | >This is progress: it took SGML over a decade to get this complicated. | > | :=) | | I share Simon St. Laurents concern that namespaces, schemas etc. are | getting rather hairy. I think there is a possibility that the | sleek Dolphin that is XML might begin to morph into a Duck Billed | Platypus. | | XML came about in a remarkably short period of time and yet exhibits | substantial "beauty" in its simplicity. The reason for this goes deeper | than the fact that some great minds designed it -- XML is the result of | over a *decade* of experience with SGML. Some good things in SGML were | dropped, some good things were retained, but all the while, the decisions | were based on rubber-on-the-road *experience*. | | By contast, namespaces, schemas etc. are very, very new to SGML/XML. | There is no decade of directly relevant, collective wisdom on which | the great minds designing them can draw. I apologise in advance for the low information content of this message. It's just that I've been lurking on this list for a while now, while keeping busy implementing practical SGML solutions ... and I think I've reached the "straw that broke the camel's back". I think the whole XML/XSL/XML-Data/etc approach is reaching crisis time --- it's killing itself before it has even grown from infancy. I have just read the comments regarding the recently-released XSL spec, and frankly I am horrified by the use of another grammar that is not XML! This comes hard on the heels of the namespace spec, which has not been well received in a number of areas. Now I have been in the SGML field for a number of years, but frankly, I find many of the discussions on this list esoteric to say the least. I don't have time to read all of these increasingly-complex specs, and I'm in the field! So I ask: what happened to XML being simple? Or to put it another way: if I have to support namespaces, XSL, XML-Data (and more) in order to do anything, I'm going back to SGML --- it's simpler! For heaven's sake W3C, stop releasing specs. I vote for withdrawing all the latest specs, and placing them in a "for discussion" state. We can then get back to them when we have a year's experience under our belt. Instead, lets pour all our efforts into releasing XML-aware software. Make it a standard first before aiming for the moon ... Again, apologies for the rant. However, it's a worry when even propeller-heads in the SGML industry like me feel like they're falling behind ... Cheers, James ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Aug 19 02:37:32 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:05 2004 Subject: Fw: DOM Level 1 Proposed Recommendation Message-ID: <004f01bdcb08$3b1a7b10$2ee044c6@arcot-main> If you are celebrating the release of the new XSL spec, here is another cause for celebration. What a great day, eh? Don Park -----Original Message----- From: Arnaud Le Hors To: www-dom@w3.org Date: Tuesday, August 18, 1998 4:02 PM Subject: DOM Level 1 Proposed Recommendation >Hi all, >I'm glad to announce that the DOM Level 1 specification has just been >released as a W3C Proposed Recommendation! >It's available to the public at >http://www.w3.org/TR/1998/PR-DOM-Level-1-19980818/ > >Thanks to all of you, for the feedback you sent while we were making >this spec! >-- >Arnaud Le Hors - W3C, User Interface Domain - www.w3.org/People/Arnaud > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Aug 19 02:56:25 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) In-Reply-To: <199808190025.KAA29591@fep2.mail.ozemail.net> References: <1.5.4.32.19980817190549.0090522c@gpo.iol.ie> <199808190025.KAA29591@fep2.mail.ozemail.net> Message-ID: <199808190054.UAA04672@unready.megginson.com> James Robertson writes: > So I ask: what happened to XML being simple? > > Or to put it another way: if I have to support namespaces, XSL, > XML-Data (and more) in order to do anything, I'm going back to SGML > --- it's simpler! There is some truth in what James says, but it's important to note that he cannot simply go back to SGML -- he will have to go back to SGML, Architectural Forms (for namespace management), DSSSL (for formatting), and HyTime (for data typing) if he wants an equivalent to the above list. If James doesn't need Architectural forms, DSSSL, and HyTime in SGML, then he shouldn't need namespaces, XSL, and XML-Data (which seems to have been obsoleted by DCD anyway) in XML, unless someone decides to start cramming them down all implementors' throats whether they will or no. 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 jjc at jclark.com Wed Aug 19 03:04:41 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:04:05 2004 Subject: XSL implementation available Message-ID: <35DA2108.D4C47BD1@jclark.com> I've hacked up a little implementation in Java of the tree construction/transformation half of the new XSL draft. An alpha release is now available. See http://www.jclark.com/xml/xt.html for more information. It also incidentally implements the latest namespaces WD. It is free even for commercial use and includes complete sources. I would emphasize that this really is an alpha. It has had virtually no testing. I am releasing this at an earlier stage than I usually release software because I want people to have an implementation to play with as they read about the new draft. This release is not intended as a tool for getting real work done. If you find bugs, please be sure to report them. If you find what seems to be a really blatant, crippling bug don't assume that you must be doing something wrong and don't assume somebody else will have reported it. 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 SimonStL at classic.msn.com Wed Aug 19 03:28:05 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) Message-ID: James Robertson wrote: > So I ask: what happened to XML being simple? > > Or to put it another way: if I have to support namespaces, XSL, > XML-Data (and more) in order to do anything, I'm going back to SGML > --- it's simpler! and David Megginson writes: >If James doesn't need Architectural forms, DSSSL, and HyTime in SGML, >then he shouldn't need namespaces, XSL, and XML-Data (which seems to >have been obsoleted by DCD anyway) in XML, unless someone decides to >start cramming them down all implementors' throats whether they will >or no. True - but does anyone else need that stuff either? Okay, that's going too far. But does everyone else need it? I don't think so. This train is moving too fast, and apparently has no brakes. I never thought I'd complain about standards moving too _quickly_, but XML seems to be breaking new ground in many different ways. 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 jamesr at steptwo.com.au Wed Aug 19 03:39:22 1998 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:04:05 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) In-Reply-To: Message-ID: <199808190138.LAA18873@fep2.mail.ozemail.net> At 11:27 19/08/1998, Simon St.Laurent wrote: | David Megginson writes: | | >If James doesn't need Architectural forms, DSSSL, and HyTime in SGML, | >then he shouldn't need namespaces, XSL, and XML-Data (which seems to | >have been obsoleted by DCD anyway) in XML, unless someone decides to | >start cramming them down all implementors' throats whether they will | >or no. | | True - but does anyone else need that stuff either? Okay, that's going too | far. But does everyone else need it? I don't think so. This train is moving | too fast, and apparently has no brakes. I never thought I'd complain about | standards moving too _quickly_, but XML seems to be breaking new ground in | many different ways. Exactly! I can change the world with only: XML, some DTDs, and a useful range of XML-aware editors, manipulators, converters, etc. Simple stuff applied widely. So: let's get the tools sorted out for one standard before moving on to all the rest ... Cheers, James ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Wed Aug 19 05:03:12 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:04:06 2004 Subject: DOM tutorials. Message-ID: <003701bdcb1e$6e3eaaa0$20addccf@ix.netcom.com> Jeff, >P.S: >Your Word file size is not 255K but 2.87M or 2870K !!! ;) Ouch!!!! Thanks for the correction!! The Word 97 file is only 255K, I can't beliieve how the conversion to Word6 made it so huge!!!! And to think I converted it to make it more accessible. I am going to post a Word97 version right away (which incidently looks much better). 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: Jeff ESTIVAL To: Frank Boumphrey ; xml mailing list ; hwghtm.list ; Dom mailing list Cc: 'Style Sheet mailing list' ; XSL STYLE LIST Date: Tuesday, August 18, 1998 3:20 PM Subject: RE: DOM tutorials. >This is VERY interesting and useful, thank you ! > >Jeff > >P.S: >Your Word file size is not 255K but 2.87M or 2870K !!! ;) > >> -----Original Message----- >> From: owner-hwg-techniques@hwg.org >> [mailto:owner-hwg-techniques@hwg.org]On Behalf Of Frank Boumphrey >> Sent: Monday, August 17, 1998 8:39 PM >> To: xml mailing list; hwghtm.list; Dom mailing list >> Cc: 'Style Sheet mailing list'; XSL STYLE LIST >> Subject: DOM tutorials. >> >> >> For those who may be interested, I have added tutorials on the W3 and IE5 >> DOM's for HTML and XML to my web pages >> (www.hypermedic.com/style/index.htm). >> Follow the DOM link. >> >> I am aware that there will probably be revisions to both these >> DOM's in the >> near future, so the tutorials are only available as a text file (55K, no >> illustrations)or a Word6 file (255K) at the present time. I decided to go >> ahead and post them anyway as I understand the changes will not be of a >> major nature. Also I have been promising to post them for 4 months now! >> >> When the DOM situation stabalizes, I will revise them and convert >> the files >> to HTML. >> >> Regards, >> Frank >> >> Frank Boumphrey >> >> XML and style sheet info at Http://www.hypermedic.com/style/index.htm >> Author: - Professional Style Sheets for HTML and XML http://www.wrox.com >> > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 19 05:21:16 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:06 2004 Subject: DOM Node.cloneNode() References: <003f01bdcae2$a8979d10$2ee044c6@arcot-main> Message-ID: <35DA449B.5494AFA0@infinet.com> Don Park wrote: > Tyler, > > >In other words, if I have a Node named "A" with two children named "B" > >and "C", would you do something like this in Java for A: > > A shallow clone of "A" will result in a node of same type as "A" with no > children. > A deep clone of "A" will result in a node of same type as "A" with clones of > "B" and "C". > > A node has exactly one parent or no parent at all so "B" and "C" can not be > children of both "A" and its clone. Since it is inappropriate for cloneNode > to move "B" and "C" from "A" to its clone, a clone is made and added during > deep clone. > > This is what I would assume, but DOM stands for Document Object Model and so I was not sure if the purpose of the DOM was to simply build a tree or else a complex graph. In the latter case, you would not need to really enforce this condition. I would take it that an implementation would call clone() on all children to retrieve the references to the objects in the case of a deep copy... > >Similiarly, what happens with the Attributes of a Node is also not too > >clear to me. Are attributes copied by value or by reference as well? > >What happens to the parent attribute? Should it be copied as well or > >should it just have the implicit DocumentFragment reference as its > >parent? What happens to the references to the siblings of a node? > > Whether an attribute is copied by value or by reference depends on the > implementation. I think most implementations will copy assigned attributes > by value and default attributes by reference. Attributes does not have a > parent nor siblings so it can not return DocumentFragment as its parent. > > The spec says: "The Attribute inherits the Node interface, which has a parentNode attribute. This attribute is set to the Element associated with the attribute as an expedient way of getting from the attribute to the Element. Note: In XML, the value of an attribute is represented by the child nodes of an attribute node, since the value can be contain entity references. Thus, attributes which contain entity references will have a child list containing both text nodes and entity reference nodes. In addition, tokenised attribute types, such as NMTOKENS will result in a child list where each child represents a single token from the attribute value." As I understand this, an AttributeNode has an Element as a parent and there is nothing that says an Attribute cannot have siblings. In this sense you could think of a list of attributes in some particular order as all being siblings of each other. From this statement, Attributes can also have children which really does not make a lot of sense to me. >From a personal perspective, it would really suit the DOM much better if you totally did away with the Node interface altogether and traverse the DOM tree by element. The other option would of course be to nest elements, text, PIs, etc. inside a Node object just like you would with any basic tree implementation. In other words you would have in C: typedef struct { Node* parent_node; NodeList* child_nodes; Node* previous_sibling; Node* next_sibling; unsigned int type; void* object; } Node; or of course in Java: public interface Node { Node getParentNode(); NodeList getChildNodes(); Node getPreviousSibling(); Node getNextSibling(); int getType(); Object getObject(); }; Right now in the current DOM implementation I have, for at least the Element interface implementation, whenever I come across a sub-element that I need to locate a handler for, I need to pass a lot of information to the super constructor such as a reference to a previous sibling and a reference to the parent that otherwise would not be necessary if I did not have to inherit the abstract Node implementation in the first place. This is doable from an implementation standpoint, but very yucky IMHO. Last but not least, why on earth are the constants for "Type" shorts? Is this to conserve memory? In Java, all integer operations are done on 32 bit integers so if you use shorts, you are slowing your case statements down considerably as a cast is necessary to convert the short into an int anyways. Most systems out there now are 32 bit, so why worry about an extra 2 bytes per node. If memory was a concern, why not just use octal values as constants? BTW, thanx for the response... 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 bckman at ix.netcom.com Wed Aug 19 06:00:12 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:04:06 2004 Subject: DOM Level 1 Proposed Recommendation Message-ID: <00a701bdcb26$6ba96020$20addccf@ix.netcom.com> Don wrote: >What a great day, eh? Well, I'll call it a bitter-sweet day. The DOM proposal exceeds my expectations, on first read I think it's great! The XSL proposal (on first, second, and third read!) is rather disappointing, but perhaps it will grow on me. Whereas I see the DOM being rapidly implemented, I can't say the same thing about the XSL spec. I really don't see that many people will use it in preference to CSS or DSSSL. It's transformation functions can be done just as well with PERL. (and perhaps PERL is easier to learn!) I hope I'm wrong! I wonder how many books on XSL will be on the shelves 6 months from now! Will Joe Hacker want to learn it? Or will he invest his energies else where! Possibly if a simple implementation like MSXSL.EXE is quickly forthcoming (and I havn't looked at James Clarke's app. yet http://www.jclark.com/xml/xt.html ) it will take off. Time will tell. On the bright side I predict a rapid implementation of the DOM. I know that I am going to start writing about it tomorrow! 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: Don Park To: Date: Tuesday, August 18, 1998 8:40 PM Subject: Fw: DOM Level 1 Proposed Recommendation >If you are celebrating the release of the new XSL spec, here is another >cause for celebration. > >What a great day, eh? > >Don Park > >-----Original Message----- >From: Arnaud Le Hors >To: www-dom@w3.org >Date: Tuesday, August 18, 1998 4:02 PM >Subject: DOM Level 1 Proposed Recommendation > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 19 06:07:54 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:06 2004 Subject: DOM Node.cloneNode() Message-ID: <003201bdcb25$a069aaf0$2ee044c6@arcot-main> Tyler, >The spec says: > >"The Attribute inherits the Node interface, which has a parentNode attribute. >This attribute is set to the Element associated with the attribute as an >expedient way of getting from the attribute to the Element. Note: In XML, the >value of an attribute is represented by the child nodes of an attribute node, >since the value can be contain entity references. Thus, attributes which contain >entity references will have a child list containing both text nodes and entity >reference nodes. In addition, tokenised attribute types, such as NMTOKENS will >result in a child list where each child represents a single token from the >attribute value." Please read the just recently released Proposed Recommendation version of the DOM spec which says: "DOM Attribute objects inherit the Node interface, but since they are not actually child nodes of the element they describe, the DOM does not consider them part of the document tree. Thus, the Node attributes parentNode, previousSibling, and nextSibling have a null value for Attribute objects." >>From a personal perspective, it would really suit the DOM much better if you >totally did away with the Node interface altogether and traverse the DOM tree by >element. The other option would of course be to nest elements, text, PIs, etc. >inside a Node object just like you would with any basic tree implementation. I don't think we are on the same page. 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 ht at cogsci.ed.ac.uk Wed Aug 19 11:34:09 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:04:06 2004 Subject: DOM Level 1 Proposed Recommendation In-Reply-To: "Frank Boumphrey"'s message of Wed, 19 Aug 1998 00:02:30 -0400 References: <00a701bdcb26$6ba96020$20addccf@ix.netcom.com> Message-ID: "Frank Boumphrey" writes: > [comparison of XSL draft and DOM PR deleted] I would observe in defense of the XSL draft that it is the first public working draft, whereas the DOM is a PR whose first working draft was out roughly a year ago. You're comparing unripe apples to oranges . . . ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Aug 19 13:46:01 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:06 2004 Subject: Factories and XML....[from George Olsen] Message-ID: <3.0.1.16.19980819093126.0b0781be@pop3.demon.co.uk> >___________________________________________________________________________ ___ > >There's an interesting article about how: > >"Suddenly, the World Wide Web is moving onto the factory floor, providing >companies with an inexpensive means to link workers and the machines they >operate to remote repositories of information. Distant managers now watch >what's going on, literally, from wherever they are." > >http://www.msnbc.com/news/188588.asp?st.ne.fd.mnaw > >I'm sure these companies would probably be interested in full support for >XML in the browsers they use for these purposes. > >Anybody know people who are involved in this area? > >___________________________________________________________________________ ___ > >Thanks for your time. If you have any questions feel free to contact me. > > >George Olsen >Design Director/Web Architect - 2-Lane Media - http://2lm.com >Project Leader - The Web Standards Project - http://www.webstandards.org > 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 19 13:46:51 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:06 2004 Subject: XSL implementation available In-Reply-To: <35DA2108.D4C47BD1@jclark.com> Message-ID: <3.0.1.16.19980819103537.2b57cfe2@pop3.demon.co.uk> At 07:49 19/08/98 +0700, James Clark wrote: >I've hacked up a little implementation in Java of the tree [...] > >for more information. It also incidentally implements the latest >namespaces WD. I'm lost for words! We continue to owe James an enormous debt for his support for XML. [XSL on XML-DEV. I am sure many people will want to discuss XSL per se (why, how, when, who ...) - and: XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list is the appropriate place for that. However there are issues of implementation which may be more relevant here (e.g. namespaces, layering, APIs, etc.) Note also that XSL includes a transformation language which (I hope) can be used for things other than rendering and may therefore be a generic XML tool. This could be highly relevant to certain XML-DEV interests. As always, use your brain and don't cross post (and certainly don't cross-reply). 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 19 13:48:32 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:06 2004 Subject: Is XML getting too hard? In-Reply-To: <199808190025.KAA29591@fep2.mail.ozemail.net> References: <1.5.4.32.19980817190549.0090522c@gpo.iol.ie> Message-ID: <3.0.1.16.19980819105632.0b07a410@pop3.demon.co.uk> At 10:25 19/08/98 +1000, James Robertson wrote: [...] >I apologise in advance for the low information content of >this message. It's just that I've been lurking on this list >for a while now, while keeping busy implementing practical >SGML solutions ... and I think I've reached the "straw that >broke the camel's back". > Don't feel the need to apologise. So long as something constructive arises that is all that XML-DEV cares about. [...] > >Instead, lets pour all our efforts into releasing XML-aware >software. Make it a standard first before aiming for the >moon ... > I have great sympathy with this. There is no doubt that multiple independent variant semi-conforming parallel semi-implementations of all these specs would kill XML. In practice I think we have to: - have implementations of XML that are either FEW or completely interchangeable. The latter is critically dependent on public activity and involves APIs, freeware, portable s/w (i.e. not platform-specific), examples and tutorials. - develop in a modular fashion, use layering, develop APIs. - do nothing that isn't necessary. - get some simple tools out to prove the XML concept. Editing and browsing are clearly key. I personally share this feeling of being overwhelmed, but postings like James Clark's today [early free releases of XSL and WD] may just about work for me. But I have had 2-3 years to learn XML and I spend a lot of time on 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 bckman at ix.netcom.com Wed Aug 19 15:14:23 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:04:06 2004 Subject: DOM Level 1 Proposed Recommendation Message-ID: <02a901bdcb73$d3edda60$20addccf@ix.netcom.com> >I would observe in defense of the XSL draft that it is the first >public working draft, whereas the DOM is a PR whose first working >draft was out roughly a year ago. You're comparing unripe apples to >oranges . . Henry, Point taken , after all we can't exactly claim that the four previous rewrites of the DOM spec were models of clarity ! Frank -----Original Message----- From: Henry S. Thompson To: Date: Wednesday, August 19, 1998 5:36 AM Subject: Re: DOM Level 1 Proposed Recommendation xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ascotth at imperium.co.uk Wed Aug 19 15:54:05 1998 From: ascotth at imperium.co.uk (Anthony Scott-Hodgetts) Date: Mon Jun 7 17:04:06 2004 Subject: Is XML getting too hard? In-Reply-To: <3.0.1.16.19980819105632.0b07a410@pop3.demon.co.uk> References: <199808190025.KAA29591@fep2.mail.ozemail.net> <1.5.4.32.19980817190549.0090522c@gpo.iol.ie> Message-ID: <3.0.5.16.19980819144815.0e4fd6be@mail.netlink.co.uk> Peter, On the subject of tools proving the XML concept, you may be interested (assuming you don't already know...) that the recently released Early Access Release 2 of Javasoft's JavaHelp API is based firmly upon (DTD-less) XML docs. For what it's worth, I'm very optimistic about the future of XMl. I'm involved in creating a Java product which uses XML as its data storage/interchange "format", and we have a fairly pragmatic approach - keep a good eye on emerging ideas/specs/standards, whilst building applications based on either DTD-less or single-DTD documents. I suspect that many of the next wave of XML-enabled applications will be similarly focussed. After that - well, we'll see... So, from the sidelines - we wish you well. Anthony Scott-Hodgetts At 10:56 19/08/98, Peter Murray-Rust wrote: >[...] >I have great sympathy with this. There is no doubt that multiple >independent variant semi-conforming parallel semi-implementations of all >these specs would kill XML. In practice I think we have to: > - have implementations of XML that are either FEW or completely >interchangeable. The latter is critically dependent on public activity and >involves APIs, freeware, portable s/w (i.e. not platform-specific), >examples and tutorials. > - develop in a modular fashion, use layering, develop APIs. > - do nothing that isn't necessary. > - get some simple tools out to prove the XML concept. Editing and browsing >are clearly key. >{...} xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 19 21:43:56 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:07 2004 Subject: Commentary on DCD Message-ID: <35DB2AC3.D8EC2E1@locke.ccil.org> Here are a few tentative comments on the DCD proposal. I am writing from my experience developing XSchema, but I am not writing *for* the XSchema team. 1. The Description and Value properties seem to extend the RDF syntax in ways not warranted by the current RDF draft (more bluntly: "are erroneous RDF"). The value of these properties is evidently a Resource which is encapsulated within the property element. An example appears in clause 3.4.2 of DCD. However, the RDF syntax in the current draft (1998-07-20) supports only three kinds of content for property elements: #PCDATA representing the string value of the property, a container element as value of the property, and an RDF:Description element serving as a proxy object. There are no provisions for embedding arbitrary mixed content and calling that the value of the property: data can't go inside metadata, roughly speaking. To make Content and Value conform to the current draft, they would need to be pulled out of the RDF part of the document altogether, tagged with an ID attribute, and referred to from within the RDF using or the like. Clause 2.1.1 is silent on this extension to RDF. 2. Based on XSchema discussions, I believe that more suitable values for the Root property would be "Recommended", "Unlikely", and "Forbidden" or the like. Distinguishing between "Recommended" and "Unlikely" assists authoring tools in limiting normal use of document roots without constraining abnormal but still permissible uses, thus furthering design principle 3. 3. The DCD draft is totally silent about notations, in violation of its own design principle 1 (clause 1.2) Although notations are not part of namespaces, they are still an important factor in XML. Perhaps as a consequence, the datatype "notation" in clause 4.1 fails to provide for the list of legal notations that the XML attribute-type model requires: there are no XML attributes of type "notation" simpliciter. 4. The list of primitive datatypes is still too long and cluttered. Id, idref, and idrefs are really NAME and NAMES with the separate id-roles property. Fixed-point values should be represented with a denominator property rather than the less general (decimal) scale. General rational numbers need support (353/113, e.g.). The various forms of date-time are clutter: there should be only one kind of timestamp, useless SQL specifications notwithstanding. All the i2, i4, etc. etc. are just values of max and min. There is no way to represent the difference between exact and inexact values. (Yes, I know I'm making work for everyone.) -- 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 19 22:13:51 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:07 2004 Subject: RDF Made Easy Message-ID: <35DB31D7.FCF1C971@locke.ccil.org> I have updated my RDF Made Easy paper (http://www.ccil.org/~cowan/XML/RDF-made-easy.html) to the July 20 RDF draft. Because this draft is not as confusing as its predecessor, the paper is less useful, but I don't want it to be downright incorrect. -- 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 h.rzepa at ic.ac.uk Thu Aug 20 13:32:41 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:04:07 2004 Subject: LISTADMIN: Archiving the XML discussions Message-ID: Dear all, This message is both to inform (actually remind) and to seek volunteers. As part of my "chemical" hat, we are publishing via Imperial College Press (ISBN 981-02-3594-1 ) the proceedings of the ECHET98 conference on CD ROM shortly. With about 400 Mbytes of free space on the CD, the opportunity arises to archive eg the XML-DEV discussions for "posterity" by including the hypermail archive on the CD (the costs of producing an XML-only CD ROM would be around $1500, and as the list has no funding source of its own, this would currently not be possible). Having watched several of the original HTML dicsussion lists apparently "evaporate" during 1994, I feel that the XML-LIST, which has generated some 6000 contributions during some 20 months of operation, is worthy of preserving as an archive of the development of the subject over this period. My intention is simply to include the raw (in fact, very raw) HTML documents that comprise the archive on the CD ROM, with my editing being limited to removing the duplicate footers, and deleting any obviously offensive messages (there have been very few spams as such). Can I ask the list therefore to a) inform me of any messages that might risk crossing the boundary of acceptability. Clearly, with 6000 to scan, its an interesting task. I set it as a challenge to the XML community! I do not intend to remove all LISTADMIN messages, since that is part of the list process, but there may be a small number that do need removing. b) I ask for volunteers to eg convert the 6000 HTML documents to a richer XML-based form. I have very little time over the next two months to spend on this, so will have to rely on volunteers. I can provide a tar archive of the list. For this purpose, I intend making the archive final as of 28 August (to allow the inclusion of any response to this posting). One prepared today is available at http://www.ch.ic.ac.uk/ectoc/echet98/email/xml-dev-2008.tar.gz (5.4 M) Anyone wishing to return "processed" material could do so via ftp://ftp.ch.ic.ac.uk/ in directory incoming (not working just yet, but soon will be) Obviously, platform independent tools such as Java could be included on the CD ROM. We are also probably be indexing the HTML documents using http://www.jobjects.com/ This is a fairly simple "low-structure" index engine. If anyone has other suggestions, they are most welcome. The default action is obviously that nothing from b) is included. I hope the final CD ROM might be "burnt" around the end of September. Copies (up to 10 ) will be available free of charge to anyone who contributes to the above task. Otherwise, copies will be available from IC Press for a fairly nominal amount (probably around $30). Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Aug 20 14:53:09 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:07 2004 Subject: XSchema Specification - Introduction (Section 1, Version 4) Message-ID: <199808201252.IAA03411@hesketh.com> Remember this, from a long long time ago? It's the XSchema introduction, freshly revised with a list of contributors. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Please note that I am changing email addresses. Please address future XSchema correspondence to simonstl@simonstl.com. (The old address will work as well as it ever did - poorly - but I won't be checking it as often.) Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 1.0 Introduction In order for document processing to be reliable, it is necessary to be able to describe classes of documents and to verify individual documents' membership in these classes -- in other words, to be able to express constraints on documents and thus define 'document types'. XML inherits a mechanism for doing this from SGML: the Document Type Definition. XML DTDs can perform a subset of the functions of SGML DTDs. DTDs have limited expressiveness and it is necessary to experiment with new ideas in schema design. These ideas include a syntax that is more like that of XML document content, certain kinds of extensibility and a cleaner separation between parsing and verifying. XSchema is an experimental schema language designed to provide a starting point for these experiments. So that XSchemas will be immediately useful with existing software, the XSchema specification will describe a conversion from XSchema documents to DTDs. This initial version of the XSchema specification is deliberately simple, providing an initial base for implementations while introducing as few complicating factors as possible. Authors accustomed to DTD creation will find their toolset constricted; it is hoped that supporting software and tools available from other standards will make up for this reduced toolset. 1.1 Status The XSchema specification is the product of discussions on the xml-dev mailing list. This document has no official status. The editors have no affiliation with the World Wide Web Consortium (W3C), the organization developing and maintaining the XML standard, nor any affiliation with any W3C member organizations. While it is hoped that this document may eventually be submitted to the W3C as a Note, it is not an official specification and should be considered experimental. 1.2 Origin and Goals Proposals for describing SGML document type definitions using document syntax rather than the separate declaration syntax have been under development for a number of years, and used by several tools for documentation. The current proposal arose from a number of concerns surrounding XML's usability and consistency. Originally conceived of as a mapping of DTD syntax to document syntax, the project has developed into an effort focused on creating schemas describing element and attribute structures rather than preserving every function provided by XML 1.0 DTDs. The list of goals developed by the xml-dev discussion follows: 1. XSchema documents shall use XML document syntax, using element nesting and attributes to describe all constraints that may be verified by a processor using XSchema . 2. XSchema shall define a transformation from XSchema documents to DTDs. 3. XSchema documents shall be capable of representing the normalized element and attribute structures defined in XML 1.0 DTDs, and provide namespace support. 4. XSchema documents shall be parseable, manageable, and manipulable using the same tools used to parse, manage, and manipulate XML documents. 5. XSchema documents shall be easy to create, read, and modify, and shall provide authoring support for XML documents. 6. XSchema documents shall be easy to use in combination with a parser to provide structural validation of documents. 7. XSchema shall include an XSchema document and an XML 1.0 DTD defining the structure of XSchema documents . 8. XSchema shall suggest mechanisms for applying XSchema documents to documents. 9. XSchema shall include mechanisms for extending the information included in XSchema documents to support metadata. 10. The XSchema specification shall be readable, clear, and rigorous, using terminology and nomenclature as close to the XML 1.0 specification as possible. 11. The XSchema specification will comply with and be consistent with W3C recommendations. 12. XSchema documents shall provide constructs for human- and machine-readable documentation. 1.3 Relation to Standards XSchemas use XML 1.0 document instance syntax and may be applied to XML 1.0 documents. XSchemas are also designed to make use of XML namespaces. It is hoped that XSchemas and RDF Schemas may be mapped to each other. This specification has also been influenced by the discussion of the XML-Data proposal made to the W3C on 5 January, 1998. XSchema also refers to several IETF standards, notably Multipurpose Internet Mail Extensions (MIME). 1.4 Terminology The requirement levels used throughout this document reflect the approach of RFC 2119 (http://www.isi.edu/in-notes/rfc2119.txt), though keywords (like may and must) are not capitalized. Other terms used are defined in the XML 1.0 Recommendation, available at http://www.w3.org/TR/1998/REC-xml-19980210. 1.5 Authors and Contributors The XSchema specification is the result of contributions from a large number of people on the XML-Dev list, coordinated by a smaller group of authors. Authors: Simon St.Laurent Ron Bourret John Cowan Contributors: Paul Prescod Peter Murray-Rust Alain Deseine Chris Maden Rick Jelliffe Toby Speight Jeni Tennison Marcus Carr Michael Kay James Anderson David Megginson Don Park James K. Tauber Tim Bray John Simpson Steven Champeon Andrew Layman Arjun Ray Curt Arnold Bill la Forge Bryan Gilbert Carl Hage Dan Brickley David Brownell David G. Durand David Ornstein David Rosenborg Eric Albright Francis Norton Frank Boumphrey Gisli Olafsson Dirk Gouders Guy Huard Jacek Ambroziak Jack Bolles Jarle Stabell Jeremy H. Griffith Jon Bosak Lars Marius Garshol Liam Quin Lisa Rein Mark D. Anderson Matt Mower Matthew Gertner Mark Tucker Kenneth J. Meltsner Murata Makoto Murray Maloney Parameshwor Karki Paul Haahr Paul Rabin Robin Cover Scott Vanderbilt Sean McGrath Simon North Stefan Wagner Steve Withall Steven R. Newcomb Thuy-Lin Nguyen Todd Ross W.E. Perry Will Hunt 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 simonstl.com Thu Aug 20 16:15:04 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:07 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 9 Message-ID: <4.0.1.19980820090648.00dcb970@pop.hesketh.net> Now that we have a content model container element, it makes sense to use it to contain the random parts that were clustering in the XSchema element. Hence, a revised and simplified XSchema element. Hopefully, this is the _last_ revision of this section. 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 XSchema document syntax. In version 1.0, 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. In future versions of XSchema, XSchema elements may be embedded in instance documents. 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 2 August 1998 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 simonstl at simonstl.com Thu Aug 20 16:15:08 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:07 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 7 Message-ID: <199808201414.KAA04086@hesketh.com> Here is what I hope to be the last round of revisions for the content model section. The Model element can now include Model subelements, as can Seq and Choice. 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.3 Content Model Declarations Content model declarations are made within Model sub-element of the declaration for the element to which they apply. Reference, Mixed, Choice, and Sequence models may appear inside XSchema elements for reusability, documentation, and reference, but will need to be linked to particular element declarations through mechanisms not yet defined (most likely XLink). All content model declarations have an optional id value for reference. The Model element holds the content model for an element. Model elements are pure containers, and act much like parentheses in XML 1.0 DTD declarations. If a Model element used as a part of a declaration contains content that is inappropriate to that declaration (for instance, a Mixed model in a Choice or Seq model), the processor should halt and signal a fatal error. 2.3.1 Empty Content Model The simplest content model is empty, which indicates that the parent element has no sub-elements and no character data content. The Empty element indicates that an element is empty. For example, to declare the Species element shown in the previous section empty, use the following XSchema declaration: This would not allow the Species element to contain any text or sub-elements. 2.3.2 Any Content Model The Any content model, which allows the element to contain parsed character data or any other elements as content, is equally simple: Using the Any content model is much like using the Empty content model. To declare that the Species element had a content model of any, use the following declaration: This allows the Species element to contain text and any sub-elements an author desired. 2.3.3 PCData Content Model The PCData content model, which allows the element to contain only parsed character data, is also represented by a single empty element. Using the PCData content model is much like using the Empty and Any content models. For example, to assign the Species element a content model of PCData, use the following declaration: This allows the Species element to contain text, but no sub-elements. 2.3.5 Reference Content Model The Reference content model allows an element to specify other elements which it may contain, as well as their quantity. Ref elements identify the element to be contained, as well as the frequency with which it must appear: The Element attribute must refer to the Name attribute of an ElementDecl element elsewhere in the XSchema document. An ElementDecl element may contain at most one Ref element. The Frequency attribute controls the number of referenced elements that may occur. To define content models that permit or require the use of more elements, the Any, Mixed, Choice, or Sequence content models should be used as appropriate. To declare that the Species element may contain a single CommonName element, and nothing else, use the following declaration: This requires the Species element to contain a single CommonName element. To make the CommonName element optional - though it may still only appear once, set the Frequency attribute to 'Optional': Optional is the equivalent of the ? occurrence indicator in XML 1.0 DTDs. To require the Species element to contain at least one but possibly multiple CommonName elements, set the Frequency attribute to 'OneOrMore': OneOrMore is the equivalent of the + occurrence indicator in XML 1.0 DTDs. Finally, to allow the Species element to contain any number (including zero) of CommonName elements, set the Frequency attribute to 'ZeroOrMore': ZeroOrMore is the equivalent of the * occurrence indicator in XML 1.0 DTDs. 2.3.6 Mixed Content Model Mixed content model allows the unordered use of different element types and character data. Content within an element that uses a mixed declaration must be PCData or one or more of the elements referenced by Ref elements nested within the Mixed declaration. Only Ref elements can be nested under an Mixed element; the PCData content is inherent in the Mixed content model. To declare that the Species element may contain a mix of PCData, CommonName elements, LatinName elements, and PreferredFood elements in any order, use the following declaration: The XSchema processor should ignore any frequency attributes in Ref elements that appear as subelements of the Mixed element. 2.3.7 Choice Content Model The Choice content model allows for either-or inclusions of elements and groups of elements. The Choice content model represents groups of element content possibilities and must contain at least two sub-elements. Situations where only one element is needed should use the Ref content model instead of Choice. The Choice element may indicate a frequency, allowing the content model defined by the Choice model to appear one, one or zero, one or more, or zero or more times. The simplest Choice element will contain two Ref elements and a frequency attribute. By default, the Choice element's content model is required to appear once. To declare that a Species element may contain either a common name or a Latin name, but not both, use the following declaration: The Ref elements in an Choice element may also specify the frequency with which they appear, as may the Seq elements described in section 2.3.8. The Choice element is the equivalent of the choice group (element | element) in XML 1.0 DTDs. The ordering of the sub-elements within an Choice element has no effect. 2.3.8 Sequence Content Model The Sequence content model allows for the sequential appearance of sub-elements. Elements, if they are required to appear, must appear in the order of the Choice and Ref sub-elements in the Seq element. The Seq element may also indicate a frequency, allowing the content model defined by the Seq model to appear one, one or zero, one or more, or zero or more times. The simplest Seq element will contain two Ref elements in the order in which they should appear and a frequency attribute. By default, the Seq element's content model is required to appear once. To declare that the Species element requires a common name and a Latin name, in that order, use the following declaration: The Ref elements in an Seq element may also specify the frequency with which they appear, as may the Choice elements. The Seq element is the equivalent of the sequence group (element, element) in XML 1.0 DTDs. 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 simonstl.com Thu Aug 20 17:12:56 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:07 2004 Subject: XSchema Spec - Namespaces (Section 3), Draft 3 Message-ID: <199808201512.LAA04573@hesketh.com> The latest version of the namespaces section follows. Because many more namespace issues are already addressed in section 2 of the spec, there is less to do here. The XSC:Namespace element has been retired. 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 3.0 XSchema and Namespaces XSchema uses namespaces for its own operations and also supports schemas that take advantage of namespace facilities. XSchema processors are responsible only for elements that use the XSchema namespace appropriate to the version of XSchema they are processing. Information in other namespaces may be used in the XSC:Doc and XSC:More elements and passed to other applications as the processor deems appropriate. Please note: the information in this section is based on the 2 August 1998 "Namespaces in XML" Working Draft and is will change to maintain conformance with that specification. 3.1 The XSchema Namespace XSchemas created using XSchema 1.0 have their namespace declaration built into the DTD as default xmlns and xmlns:XSC attributes of the XSchema element. Note that XSC:Doc and XSC:More must use the XSC: prefix because they declare other values for the default namespace name. Any XSchema element may use the XSC: prefix if desired, but it is not necessary. 3.2 Interaction with Other Namespaces XSchemas will often support document sets that have their own namespaces. To maintain interoperability with DTDs, XSchema provides mechanisms for declaring the namespace prefixes of elements declared by XSchemas. This allows documents and the XSchemas used to verify them to track the same namespace using different prefixes if necessary. XSchema-to-DTD converters should use the prefix attribute of an ElementDecl, AttGroup, or AttDef element to create DTD element and attribute declarations containing that prefix. DTD-to-XSchema converters should use the prefixes assigned in the DTD, and request further information about the 'real' namespace for the ns attribute. This may be accomplished by parsing a sample document instance, or by direct input from the person doing the conversion. The ns attribute is not required, but it does provide the XSchema with a level of understanding about namespaces that DTDs presently lack. If an XSchema contains the correct ns attributes, it is far better equipped to process documents that use namespaces without concern for the variability of prefixes. 3.3 Note Regarding Namespace Usage Namespaces are still in development at this time, and as such are subject to dramatic change. This specification was written making several assumptions, which may or may not prove to be true as the Namespaces draft evolves: 1. The only part of a namespace declaration that genuinely identifies the namespace is the ns production. The prefix only serves as a proxy for the full ns production. 2. The URLs in a namespace declaration will not need to be retrieved. The XSchema namespace declaration uses a PURL (permanent URL) provided by the OCLC. (For details on PURLs, visit http://purl.org.) PURLs use redirection to maintain a permanent address for sites that may change address. While XSchema specification information may be stored at the location to which the PURL server redirects visitors, XSchema applications should not rely on any of that information being there. 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 roddey at us.ibm.com Thu Aug 20 20:19:14 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:04:07 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces... Message-ID: <5030300024263518000002L082*@MHS> >True - but does anyone else need that stuff either? Okay, that's going too >far. But does everyone else need it? I don't think so. This train is moving >too fast, and apparently has no brakes. I never thought I'd complain about >standards moving too _quickly_, but XML seems to be breaking new ground in >many different ways. And what are the odds of getting any real compliance and interoperability with so many specs moving in so many directions so quickly? The odds of two tools being at the same 'XML Place' at the same 'XML Time' is probably pretty low if they weren't written by the same person. But isn't this the way it always works? Non-programmers get frustrated and decide to create something of their own. Then, if it catches on, it has to be expanded to be able to do everything the old system could do, by which time it is too complex and then non-programmers get frustrated and decide to create something of their own? At some point you have a programming language and could have just used one to begin with, and left the other tool alone to stake out the low ground. I'm reading a couple hours a day and I still feel like I only barely understand the most basic issues, and I'm a hard core *C++* programmer. I think that the inability of a hard core C++ programmer to understand some other language could be a legal definition of 'too dang complicated' :-) Just my opinion of course... ---------------------------------------- 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 Sung_Nguyen at datacard.com Thu Aug 20 21:02:27 1998 From: Sung_Nguyen at datacard.com (Sung Nguyen) Date: Mon Jun 7 17:04:07 2004 Subject: Internationalization in XML? Message-ID: <001145A5.3096@datacard.com> Hi all: I am trying to create an sample prototype in XML that has international contents. Several questions has arised as follows: 1. in what form we want to store user input (internationally) * a structure or just simple Unicode 2. Does Unicode really work in XML ? I used Near&Far Design to create XML DTD - there are 3 encoding schemes: UTF-8 , IOS 8859-1 and UNICODE. I don't know how is it look like in XML which contains interational data. Please enlighten me, Greatly appreciate Sean Ng xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Thu Aug 20 21:44:20 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:04:07 2004 Subject: Announce: Frontier 5.1.3 In-Reply-To: <001145A5.3096@datacard.com> Message-ID: <3.0.5.32.19980820124453.0104f730@scripting.com> Major XML-related enhancements in this release: http://www.scripting.com/frontier5/changes/513.html Dave PS: Greetings! I've been lurking on this list for about two weeks. -------------------------------------- http://www.userland.com/directory.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Fri Aug 21 03:26:17 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:04:07 2004 Subject: Is XML getting too hard? (was: Re: More on Namespaces...) References: <199808190025.KAA29591@fep2.mail.ozemail.net> Message-ID: <35DCCC40.3480@hiwaay.net> James Robertson wrote: > > So I ask: what happened to XML being simple? Unconstrained requirements. This one was thrashed in the SIG when XML as SGML On The Web was first proposed. Spilt milk now, but keep it in mind. Over the years many things were proposed for SGML. Some of them lead to the complexity of SGML and others were wisely rejected because although they made this or that system more flexible, more robust, more saleable, they were essentially "out of scope" and the SGML WG rejected them. When I read the requirements used for W3C documents, I see unbridled license for mischief and know only the individuals can keep things on track. But it becomes a game of raw power, and that is something ISO does better than MIT. It requires experience and savvy beyond logic. We know the story. Something is the "next new thing on the net" and the feeding frenzy begins as each interest tries to get something added. So far, other than namespaces and the various schema proposals, most of what has "XML" somewhere in the "note" has been recrunched work from the SGML projects since 1986. This has been mostly a good thing in that it benefits from the work done among individuals who know one another and are aware of positions, concepts, ideas, etc. It has resulted in some cases in excellent refinement of the ideas and concepts plus some very lucid positions and statements. For example, I found XLL and Xpointers much easier going than the first time I worked through these ideas when they were HyTime, DSSSL, and TEI. Is XML too hard? Was SGML too hard? I can't say. They aren't to me. Yet I can easily get into something like namespaces and lose my way. Part of that is the feeling of nudging and winking about schemas, part of that is that unless one looks at all the pieces of the X-docs, one can't get a sense of some of the pieces. It is a lot to understand and as with other standards, the usual terminology ambiguities pop up. Will XML be harder than SGML? If you look at XML The Syntax, no. If you try to grasp all of the other pieces, it is considerably harder. Again, the XML requirements are too loose to be bounded and the normative relationships were cast away. This is problematic and now we can see the results of that. I caution those in the W3C to be sometimes less "logical" and more "pragmatic". As the twig is bent, gentlemen, so grows the tree. This tree has a kudzu effect and it is spawning serious issues among other language communities. Call it what you will, you are responsible for sorting that out. It is hard to be Benedictine in a land of samurai. Is it worth it? I think so. While this project is spawning complexity and maybe it is time to review the notes, work out the dependencies, and pause to consider, I know from the work done in SGML, HyTime, DSSSL, various objectIVE SGML systems, MID, and so on, that the community is in many ways closer to the system it has desired for the last two decades. That's a good deal. Congratulations on getting this far. Some are trumpeting the death of SGML, but they missed the point. XML is SGML. It is the fruit of those who built SGML, DSSSL, HyTime, and it is worthy. What we could lose and it is a real danger, are the ideas behind markup technologies, and the requirements that made SGML the preeminent expression of those requirements. Lifecycle support, independence of platform, language neutrality (the reason objects have not had much of a role in SGML), preservation of information, lossless translation, all of these are intertwined. Do not lose sight of them. The best selling point of SGML is its lifecycle support. It is a very real problem for complex document lifecycles that last decades. Don't make XML applications that cannot be validated by some means. That is a mistake of serious proportion. Don't depend on editors and claim "people don't edit the markup by hand". They do and they always will. Lastly, don't abandon the community. Some of you are very new and have not had the privilege to know personally, the elders of your community. It is easy to be young and full of ideas. Those ideas are always welcome, but whether you want to admit it or not, you are adding to an existing body created by brilliant minds who labored long, hard, and without that promise of easy riches made possible by the Internet. Those who came before have to make sure the torch is passed; those who receive it have to understand their time will come to do the same. Break that chain and XML is worthless. XML is too hard. Integrated open hypermedia is a hard problem. Always was. 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 tyler at infinet.com Fri Aug 21 03:34:30 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:07 2004 Subject: DOM Entity Value? Message-ID: <35DCCEB6.FB57BE4A@infinet.com> In the current DOM spec, in the table for NodeValues, the Entity node should return null for its node value. Shouldn't it return the value of the entity or in the case the entity has not been expanded then return null? Really, an entity with just a name, but no data associated with it is pretty useless unless the entity is an external parsed entity where the system id and notation name actually have some real relevance. Can someone please clarify why entities in the DOM tree have no real value associated with them? Thanx in advance, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Aug 21 05:02:13 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:07 2004 Subject: DOM Entity Value? In-Reply-To: <35DCCEB6.FB57BE4A@infinet.com> from "Tyler Baker" at Aug 20, 98 09:34:47 pm Message-ID: <199808200302.XAA16208@locke.ccil.org> Tyler Baker scripsit: > In the current DOM spec, in the table for NodeValues, the Entity node > should return null for its node value. Shouldn't it return the value of > the entity or in the case the entity has not been expanded then return > null? The value of an entity appears as the children of the Entity node. This can be arbitrarily complex, with Text nodes or Element nodes or whatever (see the draft); it doesn't make sense to capture it as a "value" string. > Really, an entity with just a name, but no data associated with it is > pretty useless unless the entity is an external parsed entity where the > system id and notation name actually have some real relevance. Agreed. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Aug 21 05:12:36 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:07 2004 Subject: DOM Entity Value? References: <199808200302.XAA16208@locke.ccil.org> Message-ID: <35DCE5AC.F8981CFB@infinet.com> John Cowan wrote: > Tyler Baker scripsit: > > > In the current DOM spec, in the table for NodeValues, the Entity node > > should return null for its node value. Shouldn't it return the value of > > the entity or in the case the entity has not been expanded then return > > null? > > The value of an entity appears as the children of the > Entity node. This can be arbitrarily complex, with Text nodes or Element nodes > or whatever (see the draft); it doesn't make sense to capture it as > a "value" string. > > > Really, an entity with just a name, but no data associated with it is > > pretty useless unless the entity is an external parsed entity where the > > system id and notation name actually have some real relevance. Thanks for the clarification. I suppose an annoted version of the DOM draft would help out a lot of developers such as myself on these sort of questions just like the annotated draft of the XML 1.0 spec that Tim Bray created has helped out a lot of developers already. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Aug 21 15:34:26 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:08 2004 Subject: XSchema Specification Available for Review Message-ID: <199808211334.JAA15115@hesketh.com> A specification draft containing the complete text of Sections 1-3 and Appendix A of the XSchema specification is available at http://www.simonstl.com/xschema/spec/xscspecv1.htm. Section 4, XSchema Transformation to XML 1.0 DTD, and Section 5, Connecting XSchemas to XML Documents, are still under development. This draft presented for review; no changes will be made to these sections until 8 September, 1998. All comments and suggestions are welcome. The full site at http://purl.oclc.org/NET/xschema/ is still active. The spec is 21 pages (55K) right now, so I'm not posting it to the list. The HTML is a bit messy as well. I will be cleaning it up - promise - just not today. Work on Sections 4 and 5 will continue during the review period; I hope to have drafts of both up early next week. Section 2 is the core of the spec, in my view at least. Thank you very much to _all_ the people who have contributed to this project. 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 smangat at Adobe.COM Fri Aug 21 19:06:18 1998 From: smangat at Adobe.COM (Satwinder Mangat) Date: Mon Jun 7 17:04:08 2004 Subject: XML Parser - COM component In-Reply-To: <35DCE5AC.F8981CFB@infinet.com> Message-ID: <002901bdcd25$7826ba90$8f9e2099@dsds3.corp.adobe.com> Hi, Has anyone tried to make XML parser (publically avialable) as a COM component? Is is possible to use SAX with parser (now COM component)? Any related work or reference will be appreciated. Thanks Satwinder Mangat xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 22 01:25:58 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:04:08 2004 Subject: VRML/XML Integration Message-ID: <35DE018F.65C4@hiwaay.net> For those who do not keep up with other language communities, Daniel Lipkin from Oracle has posted a proposal for a VRML EXTERNPROTO that enables a VRML author to use XML as a source for metadata through DOM interfaces. It is simple but it is a good beginning. It also shows that other langugage communities are working towards integration with XML sources and that augurs well for the content. 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 robin at ACADCOMP.SIL.ORG Sat Aug 22 05:11:51 1998 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 17:04:08 2004 Subject: VRML and DOM Message-ID: <199808220319.WAA09062@ACADCOMP.SIL.ORG> The Oracle Len Bullard (not of Oracle) said on XML-DEV: > Date: Fri, 21 Aug 1998 18:23:59 -0500 > From: len bullard > > For those who do not keep up with other language communities, > Daniel Lipkin from Oracle has posted a proposal for a VRML EXTERNPROTO > that enables a VRML author to use XML as a source for metadata > through DOM interfaces. It is simple but it is a good beginning. A hint may be: http://www.sil.org/sgml/xml.html#xml-vrml though other trails may lead to the same spot. -rcc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Aug 22 05:27:40 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:08 2004 Subject: XPointer support for PSGML/Emacs Message-ID: <199808220324.XAA00402@unready.megginson.com> This morning (Friday 21 August 1998), at the XML Developers' Conference in Montreal, Tim Bray complained about the difficulty of calculating XPointers by hand in Emacs. In response, I have written a short add-on to PSGML to calculate a (reasonably optimal) XPointer to the containing element of any arbitrary point in an XML or SGML document. If you're Tim, or you're anyone else interested enough in XPointers that you've read this far, you can download the psgml-xpointer.el module from http://www.megginson.com/Software/ 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 cybes at hd1.vsnl.net.in Sat Aug 22 09:33:08 1998 From: cybes at hd1.vsnl.net.in (cybes) Date: Mon Jun 7 17:04:08 2004 Subject: XSL -Display Message-ID: <35DE7295.7D49E18E@hd1.vsnl.net.in> Hi, When I tried to display XML file using msXSL ActiveX control I got the following error. Browser(IE4.0) is always displaying "UNDEFINED". Please suggest some method to overcome this problem. Sumanth. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Sat Aug 22 11:05:35 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:08 2004 Subject: Namespaces design implementation? Message-ID: <35DE89FF.8BCFB10F@infinet.com> I am sure this question has come up in private circles, but on this particular list the question of whether to integrate the current namespaces draft into the core of an XML parser/XML framework or else put it all in a layer on top of the parser/framework has not come up to date. Many XML documents will not take advantage of namespaces, so having namespaces support in this case would be bad since the namespace processing involved to support namespaces could seriously slow down an XML parser (depending on the implementation of course). On the other hand, integrating namespaces support into the core of an XML parser could allow the parser writer to process documents that utilize namespaces much more efficiently than if the namespaces processing were done at a layer on top of the parser. I think the main question I have is, will the namespaces draft ever eventually be integrated into a future draft of XML, e.g. XML 1.1? If namespaces are to be regarded now as a core de-facto part of XML (the current XSL spec seems to make this case) then I would think that all parsers will in a sense need to have namespaces support integrated into directly into them. In this sense namespaces support would be on par with entity support. If on the other hand, namespaces will always be a separate and distinct layer on top of XML, then I suppose that aside from processing efficiency considerations, it would make sense for parser writers to have samespace support as an optional layer on top of an XML parser. The reason I ask this is that right now I have to make a major design decision about how to integrate namespaces support into the parser/formatter I have been working on. I have about 5 different implementation designs that I have worked up, each with their own memory, speed, and API ease of use tradeoffs, so figuring out the answer to this question is quite important. XML can do a lot of great things without namespaces, so keeping namespaces as a separate and distinct layer gets my personal vote. Nevertheless, I am a peon in the whole scheme of things who has no real input into this particular issue so any help in obtaining an answer to the previously stated questions would be greatly appreciated. Thanx in advance, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Sat Aug 22 14:08:31 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:08 2004 Subject: Namespaces design implementation? References: <35DE89FF.8BCFB10F@infinet.com> Message-ID: <35DEB69C.221E9C89@mecomnet.de> Tyler Baker wrote: > > I am sure this question has come up in private circles, but on this > particular list the question of whether to integrate the current > namespaces draft into the core of an XML parser/XML framework or else > put it all in a layer on top of the parser/framework has not come up to > date. The topic has come up. So far as I've been able to tell, the "resounding" preference has been for layering it on top of the parser. The opinion has not been universal, but I believe, I am correct in reporting that a very limited number of correspondents have spoken up for alternatives. :) > The reason I ask this is that right now I have to make a major design > decision about how to integrate namespaces support into the > parser/formatter I have been working on. I have about 5 different > implementation designs that I have worked up, each with their own > memory, speed, and API ease of use tradeoffs, so figuring out the answer > to this question is quite important. XML can do a lot of great things > without namespaces, so keeping namespaces as a separate and distinct > layer gets my personal vote. Nevertheless, I am a peon in the whole > scheme of things who has no real input into this particular issue so any > help in obtaining an answer to the previously stated questions would be > greatly appreciated. You do not describe your alternatives, but I would suggest that the real issue is not whether namespace support is in a separate layer, but whether the application operates on names which are strings or "something else". If the application does not need namespaces, it should well use a parser which makes no assertions about the content of a name, other than (perhaps) that it contain no more than one colon. If, on the other hand, the application operates on a dom-like model, unless the application is "about" namespaces, then it is not necessary that any part of the application know about namespaces except that part which decodes and encodes objects. which part is the interface to the parser - and the only interface to the parser. Since, in that case the part of the "application" which handles namespaces is effectively inseparable from the parser and, integral with it, from the point of view of such an application, an explicit layering has no advantage. This is, in any case, a minor issue. The model for names is the more significant issue. My experience is that, if the application performs operations (a) on a document model which (b) require that it observe namespaces, then it is going to perform comparisons over collections of (at least) element names and attribute names, and that these collections constitute a structured store, not temporary operands for comparisons "on the fly". Once this is true, then it is more effective for the parser to have interned the name at the point where it was parsed and to pass such interned names through its interface to/from the application, than it is for it to pass strings. The names are interned into collections which, in turn, are identified by uri. This mechanism puts the application in the position to 1) perform comparisons as an identity comparison rather than a string compare; 2) cache additional information (eg the dtd, the uri, the prefix at the time interned, ...) directly on the interned name; 3) avoid having to manage element-specific prefix bindings - as is, for example, suggested in the latest xsl draft. (for those following the namespace discussion, this was the "indefinite extent" issue which I raised in one of my six questions.) > > ... > > I think the main question I have is, will the namespaces draft ever > eventually be integrated into a future draft of XML, e.g. XML 1.1? > This does not change the arguments above. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 22 14:30:49 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:04:08 2004 Subject: Namespaces design implementation? Message-ID: <3.0.32.19980822053034.00e9d9e0@207.34.179.21> At 05:06 AM 8/22/98 -0400, Tyler Baker wrote: >I am sure this question has come up in private circles, but on this >particular list the question of whether to integrate the current >namespaces draft into the core of an XML parser/XML framework or else >put it all in a layer on top of the parser/framework has not come up to >date. I'm convinced that a high proportion of the XML docs flowing around the web are going to have namespace apparatus in them, thus if I were building a parsing system I'd build that right in at a low level. I'd be surprised if the extra cost of doing namespace processing were significant or in fact noticeable. -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 robin at ACADCOMP.SIL.ORG Sat Aug 22 22:19:06 1998 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 17:04:08 2004 Subject: XMI - OMG Update Message-ID: <199808222027.PAA09582@ACADCOMP.SIL.ORG> I recently updated the entry for XML Metadata Interchange Format (XMI) - Open Management Group (OMG) in the SGML/XML Web Page, based upon the release of two significant specifications documents. A summary is available in the What's New page: http://www.sil.org/sgml/sgmlnew.html and details are in the main XML document: http://www.sil.org/sgml/xml.html#xml-omg This seems like a pretty significant initiative, unless one does not care about object/component modeling, (STEP) schemas, and the unification of several important industry standards,including XML. The two most relevant documents are available in PDF and Postscript. Enjoy. -rcc PS. Don't write to say that the XML document is "too long" - I'm about to start fixing it... sorry. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Aug 23 00:57:03 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:08 2004 Subject: Namespaces design implementation? References: <3.0.32.19980822053034.00e9d9e0@207.34.179.21> Message-ID: <35DF4CAB.D8542029@infinet.com> Tim Bray wrote: > At 05:06 AM 8/22/98 -0400, Tyler Baker wrote: > >I am sure this question has come up in private circles, but on this > >particular list the question of whether to integrate the current > >namespaces draft into the core of an XML parser/XML framework or else > >put it all in a layer on top of the parser/framework has not come up to > >date. > > I'm convinced that a high proportion of the XML docs flowing around > the web are going to have namespace apparatus in them, thus if I > were building a parsing system I'd build that right in at a low level. > > I'd be surprised if the extra cost of doing namespace processing were > significant or in fact noticeable. -Tim > Well for the parser I have (written in Java) is about 2x-3x as fast as XP right now when run in non-validating mode (it is a validating parser), so any additional processing, unless done elegantly could impact performance by as much as 10-20%. Right now without a JIT on a P-120 with 64 megs of RAM the Lark.xml file in your Lark parser (32K) gets parsed with my parser at around 280-300 milliseconds. XP does this in about 700-800 milliseconds, Aelfred in around 1200-1500 millseconds, and IBM's XML 4 Java in about 2800-3000 milliseconds. XML 4 Java is a validating parser so this might be some of the reason for the speed decrease as well as the overhead of building the in-memory parse tree that XML for Java uses. Nevertheless, building a DOM tree using my parser takes roughly the same amount of time (400 milliseconds with no JIT) as the timer test I have. The tests were done without a JIT because on the first pass, the speed of parsing a file is significantly increased because the JIT must compile all of the bytecodes into native form. For example, without a JIT XP runs at 700-800 milliseconds and with a JIT XP it runs at around 2100-2200 milliseconds. So the point is that whenever you add a new feature into XML you will either be slowing down the performance of parsers, increasing the memory overhead, or both. Or you may in effect force parsers to use inefficient implementations to support all of the features. I tried dabbling with streaming in XML data into the XSL processor I was working on and streaming it back out. The idea was to do this so you would not need to build an in memory parse tree like the DOM to parse the XML data into some sort of output using an XSL stylesheet. This would be possible if some of the built-in functions were removed as well as ECMAScript. Perhaps an XSL lite could be developed for systems where the output of a stylesheet and an XML document are simple, yet the performance needs let alone the memory needs are of great performance. I would like to keep namespaces as a totally separate part of the parser, but this would seem pointless if namespaces are expected to be a de-facto part of XML 1.0 anyways and may in the future be part of the official standard in XML 1.1. The main question I still have is: are namespaces ever likely to be a core part of XML, or will their utility be kept as a separate layer on top of XML? 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 creitzel at mediaone.net Sun Aug 23 18:00:25 1998 From: creitzel at mediaone.net (Charles Reitzel) Date: Mon Jun 7 17:04:08 2004 Subject: No subject Message-ID: <199808231600.MAA06341@chmls05.mediaone.net> James Clark wrote: >>Charles Reitzel wrote: >> Namespaces are an inherently global construct and I can see no >> reason why document writers cannot live with a single prefix >> per global identifier within a document. > > See http://www.w3.org/TR/NOTE-webarch-extlang#Local for > some reasons. Thanks for the pointer. It is just what I had been looking for. I read the section you referenced, and have given the reasons a good deal of thought, but I cannot agree with the premises put forward. Knowing in advance what namespaces will be combined in a document does not prevent tractable (I submit, better) solutions to each of the three problems mentioned. Before addressing each case, I think I have found an underlying difference in how folks view the namespace prefix. One camp sees the prefix being defined *by* the DTD and therefore as a global identifier itself. The other camp wants to define the prefix *for* a DTD and, thus, only within a document. Specifically, if the namespace is set as a #FIXED attribute for an element in the DTD, then prefix collision is likely (unless the entire global ID is used as a prefix). This is an inherent shortcoming of the prefix notation and inhibits DTD reuse. IMHO, a more useful approach for most developers is as I posted (based on others' previous posts): prior to "including" each DTD, set the default namespace. The objective is to associate a DTD with that namespace without changing the DTD. Perhaps a new syntax is needed to make this association explicit. An analogy might be using VMS logical names or Unix environment variables (e.g. $DATAHOME=//Host/Dir/Sub") to point to a resource that can move or change. David Megginson wrote: >Some people imagine that parts of large XML documents will be >constructed by many subprocesses spawned by a master process. These >subprocesses may need to declare and use their own namespaces -- the >thinking is that it would be unacceptable to require them to >communicate with the master process to negotiate a >namespace-declaration and prefix, so they must be able to declare >namespaces that are applicable only to the fragments under their >control. Thanks for the explanation. I have trouble understanding this concept. It sounds a bit like adding a chapter to the book but leaving it out of the table of contents. The three cases laid out in the "Extensible Documents" note referenced above are: a) legacy documents (the CGI example) b) Long documents c) Document concatenation The short answer to each of these "requirements" is for the author of the composite document type to create wrapper elements. This is analogous to the programming practice of hiding 3rd party library calls within a thin, locally defined layer of function calls. Thus, allowing the application to (more easily) substitute the external resource should the need arise. a) legacy documents (the CGI example) One should be able to declare, in the DTD, the element types used by such sub-document and associate each with its global namespace id and a locally unique prefix. Where validation is not used, simply wrap the legacy elements within a wrapper element that uses a declared namespace prefix. All child-elements then default to that namespace - no fuss, no muss. b) Long documents If a document is truly huge, a few namespace declarations at the top are the least of your worries. Certainly, the example of a new namespace for each paragraph is degenerate and should not be the basis for design. As for "working set" size (i.e. per process memory), I submit that normalizing the namespace declarations (i.e. once each at the top of the document) can make the space cost of namespaces much less. Each element that belongs to a different namespace than its parent need only concatenate the local prefix to its name and not re-declare the global identifier. Say a large document has ~100K elements. Wouldn't it be a misuse of namespaces if the number of unique global namespace id's was more than ~1K? Thus, we have just eliminated the text of the 99% redundant global identifiers. If one is seriously constrained, break up the document and link the separately parsed parts (as David M. and others have suggested). Again, the extreme case should not be used as a basis for design. Optimize the typical case; allow the odd case. c) Document concatenation Why is it inherently desireable to concatenate arbitrary XML documents? Certainly real applications will construct complete documents from prepared fragments (after all, this is one of the primary motivations for namespaces). But any arbitrary documents? Is this a pressing concern to any prospective XML implementers? If you must concatentate, simply create a wrapper element. === I may be all wet on this stuff. Really, the only way to make good decisions about these things is to use real-world examples. Has anyone compiled a set of "use cases" to validate prospective xml designs? The two main ones I keep hearing about are complex content publishing (one document, many output media) and ECommerce/EDI. What are some others? Charlie P.S. The XSL WD looks excellent. I need to study it more before I can appreciate the details (pattern matching!). The basic transform/render architecture is real clean and will make XSL useful for many non-visual applications (generate UN/EDITFACT from XML/EDIFACT!). The requirements doc was very helpful. Anyway, I look forward to using XSL. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From creitzel at mediaone.net Sun Aug 23 19:13:57 1998 From: creitzel at mediaone.net (Charles Reitzel) Date: Mon Jun 7 17:04:08 2004 Subject: Element-Level NS Declaration Message-ID: <199808231713.NAA24771@chmls05.mediaone.net> James Clark wrote: >>Charles Reitzel wrote: >> Namespaces are an inherently global construct and I can see no >> reason why document writers cannot live with a single prefix >> per global identifier within a document. > > See http://www.w3.org/TR/NOTE-webarch-extlang#Local for > some reasons. Thanks for the pointer. It is just what I had been looking for. I read the section you referenced, and have given the reasons a good deal of thought, but I cannot agree with the premises put forward. Knowing in advance what namespaces will be combined in a document does not prevent tractable (I submit, better) solutions to each of the three problems mentioned. Before addressing each case, I think I have found an underlying difference in how folks view the namespace prefix. One camp sees the prefix being defined *by* the DTD and therefore as a global identifier itself. The other camp wants to define the prefix *for* a DTD and, thus, only within a document. Specifically, if the namespace is set as a #FIXED attribute for an element in the DTD, then prefix collision is likely (unless the entire global ID is used as a prefix). This is an inherent shortcoming of the prefix notation and inhibits DTD reuse. IMHO, a more useful approach for most developers is as I posted (based on others' previous posts): prior to "including" each DTD, set the default namespace. The objective is to associate a DTD with that namespace without changing the DTD. Perhaps a new syntax is needed to make this association explicit. An analogy might be using VMS logical names or Unix environment variables (e.g. $DATAHOME=//Host/Dir/Sub") to point to a resource that can move or change. David Megginson wrote: >Some people imagine that parts of large XML documents will be >constructed by many subprocesses spawned by a master process. These >subprocesses may need to declare and use their own namespaces -- the >thinking is that it would be unacceptable to require them to >communicate with the master process to negotiate a >namespace-declaration and prefix, so they must be able to declare >namespaces that are applicable only to the fragments under their >control. Thanks for the explanation. I have trouble understanding this concept. It sounds a bit like adding a chapter to the book but leaving it out of the table of contents. The three cases laid out in the "Extensible Documents" note referenced above are: a) legacy documents (the CGI example) b) Long documents c) Document concatenation The short answer to each of these "requirements" is for the author of the composite document type to create wrapper elements. This is analogous to the programming practice of hiding 3rd party library calls within a thin, locally defined layer of function calls. Thus, allowing the application to (more easily) substitute the external resource should the need arise. a) legacy documents (the CGI example) One should be able to declare, in the DTD, the element types used by such sub-document and associate each with its global namespace id and a locally unique prefix. Where validation is not used, simply wrap the legacy elements within a wrapper element that uses a declared namespace prefix. All child-elements then default to that namespace - no fuss, no muss. b) Long documents If a document is truly huge, a few namespace declarations at the top are the least of your worries. Certainly, the example of a new namespace for each paragraph is degenerate and should not be the basis for design. As for "working set" size (i.e. per process memory), I submit that normalizing the namespace declarations (i.e. once each at the top of the document) can make the space cost of namespaces much less. Each element that belongs to a different namespace than its parent need only concatenate the local prefix to its name and not re-declare the global identifier. Say a large document has ~100K elements. Wouldn't it be a misuse of namespaces if the number of unique global namespace id's was more than ~1K? Thus, we have just eliminated the text of the 99% redundant global identifiers. If one is seriously constrained, break up the document and link the separately parsed parts (as David M. and others have suggested). Again, the extreme case should not be used as a basis for design. Optimize the typical case; allow the odd case. c) Document concatenation Why is it inherently desireable to concatenate arbitrary XML documents? Certainly real applications will construct complete documents from prepared fragments (after all, this is one of the primary motivations for namespaces). But any arbitrary documents? Is this a pressing concern to any prospective XML implementers? If you must concatentate, simply create a wrapper element. === I may be all wet on this stuff. Really, the only way to make good decisions about these things is to use real-world examples. Has anyone compiled a set of "use cases" to validate prospective xml designs? The two main ones I keep hearing about are complex content publishing (one document, many output media) and ECommerce/EDI. What are some others? Charlie P.S. The XSL WD looks excellent. I need to study it more before I can appreciate the details (pattern matching!). The basic transform/render architecture is real clean and will make XSL useful for many non-visual applications (generate UN/EDITFACT from XML/EDIFACT!). The requirements doc was very helpful. Anyway, I look forward to using XSL. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Aug 24 15:50:36 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:08 2004 Subject: Element-Level NS Declaration References: <199808231600.MAA06341@chmls05.mediaone.net> Message-ID: <35E1718B.F1FEAD40@mecomnet.de> Charles Reitzel wrote: > > Before addressing each case, I think I have found an underlying difference > in how folks view the namespace prefix. One camp sees the prefix being > defined *by* the DTD and therefore as a global identifier itself. The other > camp wants to define the prefix *for* a DTD and, thus, only within a > document. There is also a third "camp" (more an outpost), which expressed the need to do both. > Specifically, if the namespace is set as a #FIXED attribute for > an element in the DTD, then prefix collision is likely (unless the entire > global ID is used as a prefix). The #FIXED attribute binding does not lead to a problem which element or attribute names, since the element constitutes a scoping boundary. It may lead to confusion with "captured" entities, but that issues is not directly related to the attribute-based prefix binding mechanism. > This is an inherent shortcoming of the > prefix notation and inhibits DTD reuse. > IMHO, a more useful approach for most developers is as I posted (based on > others' previous posts): prior to "including" each DTD, set the default > namespace. A dtd may well include names which designate more than one namespace. A means to specify a default binding with a scope which includes the DTD is not sufficient. > The objective is to associate a DTD with that namespace without > changing the DTD. Perhaps a new syntax is needed to make this association > explicit. An analogy might be using VMS logical names or Unix environment > variables (e.g. $DATAHOME=//Host/Dir/Sub") to point to a resource that can > move or change. > The previous (PI-based) proposal already permitted this. No new "syntax" is needed. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Aug 24 16:24:27 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:08 2004 Subject: Namespaces and validation Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C035FDA@WROX3> You'll have to excuse my inexperience with things XML (I've only been at this a few weeks) but... When I mailed the list earlier questioning the presence of a qualified name in the Is there a formal rule for the use of Atrributes vs Elements? The assumption I am going on (per The XML Primer) is that Attributes are best used to communicate information to the browser/application, and Elements are best used for actual Data. Is this a valid assumption? In an EDI transaction, I was going to put the Header and Trailer information in attributes, with the actual Detail Segments as Elements... Any thoughts? 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 GMCKIERN at gwgate.lib.iastate.edu Mon Aug 24 23:28:09 1998 From: GMCKIERN at gwgate.lib.iastate.edu (Gerry Mckiernan) Date: Mon Jun 7 17:04:09 2004 Subject: XML/RDF for HyperThesauri(sm) Message-ID: XML/RDF for HyperThesauri(sm) In my review of projects and applications that make use of standard or innovative implementations of thesauri for Managed Conceptual Navigation in digital collection [See my recent posting: _Brave New Word_], I have learned about the Virtual HyperGlossary project of Peter Murray-Rust and Lesley West [http://www.gca.org/conf/meta98/xmldev98/peterm-r.htm ] . According to their project description, Murray-Rust and West have developed a "simple but scalable DTD for terminology based on ISO 12620 (Data Categories for Terminology). This DTD uses a deliberartively small subset of about 12 categories (e.g., , , , , )" [Snip] In their implementation, Murray-Rust and West make use of XML and note: "Because XML is tree-based it supports hierarchical collections (e.g., thesauri, catalogs, etc.)" Although their implementation _appears_ to be currently limited to glossaries, it has occurred to me that their model and/or XML (or RDF) would be the ideal means of creating HyperTextEd thesauri for electronic resources, most notably Managed Conceptual Navigation to Web/Net resources that I envisioned in a concept I called HyperThesauri(sm) in concluding one of my first print Web-related articles: New/Old World Wide Order: The application of 'neo-conventional' functionality to facilitate access and use of a WWW database of science and technology Internet resources. _Journal of Internet Cataloging_ 1(1), 47-55, 1997 For the survey article I am in the process of preparing, I would very much appreciate learning about any current or pending projects that have or are considering the use of XML or RDF to create thesauri for Managed Conceptual Navigation of digital collection, as well as any reactions to this approach. As Always, Any and All Contributions, Queries, Questions, Concerns, or Critiques, or Comments are Most Welcolme. Joy! Gerry McKiernan Theoretical Librarian Iowa State University Ames IA 50011 gerrymck@iastate.edu http://www.public.iastate.edu/~CYBERSTACKS/ "The Best Way to Predict the Future is To Invent It!" Alan Kay cc: Peter Murray-Rust xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sblackbu at erols.com Mon Aug 24 23:38:08 1998 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:04:09 2004 Subject: Newbie Q Message-ID: <003d01bdcfa7$6f9cd880$432e0318@cc221812-a.hwrd1.md.home.com> My rule of thumb is attributes contains data that is unique to that particular object. Let's say you have a database of people. You output a list of names from that database in XML (this could be the result of a database query such as "show me a list of people between the ages of 18 and 24"). This list may contain duplicates. For example: Smith John Smith John How do you tell them apart? You could use an attribute: Smith John Smith John Now you can tell them apart. HTH, Sam -----Original Message----- From: Frank Blau To: xml-dev@ic.ac.uk Date: Monday, August 24, 1998 5:30 PM Subject: Newbie Q >Is there a formal rule for the use of Atrributes vs Elements? The >assumption I am going on (per The XML Primer) is that Attributes are >best used to communicate information to the browser/application, and >Elements are best used for actual Data. Is this a valid assumption? > >In an EDI transaction, I was going to put the Header and Trailer >information in attributes, with the actual Detail Segments as >Elements... > >Any thoughts? > >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) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Aug 25 00:57:00 1998 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 17:04:09 2004 Subject: Newbie Q Message-ID: <199808242305.SAA11748@ACADCOMP.SIL.ORG> Frank Blau wrote: > Is there a formal rule for the use of Atrributes vs Elements? Some hints are recorded in the documents with these URLs: http://www.sil.org/sgml/elementAttr9804.html http://www.sil.org/sgml/elementsAndAttrs.html These documents are referenced from the dedicated section: http://www.sil.org/sgml/topics.html#elementsAndAttrs Elements versus attributes - How do I decide? > that Attributes are > best used to communicate information to the browser/application, and > Elements are best used for actual Data. Is this a valid assumption? I do not think this assumption has any basis whatever in the XML 1.0 specification, and it certainly has no basis in the parent standard, ISO 8879. There is some basis in HTML browser behavior, but that is (in my opinion) a Bad Thing, and not to be perpetuated as a standard agreement. It is dangerous for all the same reasons as in "HTML": the industry got stuck with hard-coded application processing semantics. XML encoding itself should used with the semantic opacity that the specification implies, in my judgment; styles and other (separate) processing specifications should determine how/whether certain (character) data in an XML document is acted upon (displayed, suppressed, etc.). The distinction between "information [for the browser/application]" and "actual Data" is specious, at least from the perspective of XML itself. Why? because what you think is your "metadata" (today) will become your data tomorrow; your metadata is someone else's data even today. "Metadata" does not map conceptually to attribute - for many reasons, the most obvious of which is that some metadata is highly complex, and cannot be structured using SGML/XML attributes (flat strings). And, of course, we know that XML is now being designed for use in all kinds of ('Internet') applications which do not involve any "browser" or human viewing of the data in its tagged format; DTDs are generated from database schemas, and tagged data is passed between applications (then discarded) without being seen by humans. My 2 cents. The documents referenced above contain excellent summaries of considerations that might be taken into account when deciding how to model your data in a markup representation. -robin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From njyoon at mail.disc.co.kr Tue Aug 25 01:52:29 1998 From: njyoon at mail.disc.co.kr (À±³²ÁÖ) Date: Mon Jun 7 17:04:09 2004 Subject: What is HyTime? Message-ID: <35E1FD13.D51DC54B@mail.disc.co.kr> Many document says hytime. Would you tell me what is hytime? thank you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Aug 25 02:36:52 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:09 2004 Subject: What is HyTime? In-Reply-To: <35E1FD13.D51DC54B@mail.disc.co.kr> References: <35E1FD13.D51DC54B@mail.disc.co.kr> Message-ID: <199808250031.UAA04709@unready.megginson.com> ?????? writes: > Many document says hytime. > > Would you tell me what is hytime? Start at the following URL: http://www.hytime.org/ All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dan at intervista.com Tue Aug 25 03:33:09 1998 From: dan at intervista.com (Dan Ancona) Date: Mon Jun 7 17:04:09 2004 Subject: XML Parser - COM component Message-ID: <3.0.32.19980824184256.00cc205c@mail.intervista.com> You can use MSXML as a COM component, especially the one that comes with IE5. The API for the one that comes with IE4 looks a little goofy. I've gotten to the IE5 one from VB (so far) and it's very nice. I have no idea how SAXish the interface is or how it differs from other parser interfaces, yet. /d At 10:02 AM 8/21/98 -0700, Satwinder Mangat wrote: >Hi, > >Has anyone tried to make XML parser (publically avialable) as a COM >component? > >Is is possible to use SAX with parser (now COM component)? > >Any related work or reference will be appreciated. > >Thanks >Satwinder Mangat > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > >>>> you might still see it in the desert <<<< dan.ancona.platinum.technology.goto.burningman http://www.ultrablue.com/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 papresco at technologist.com Tue Aug 25 05:37:07 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:04:09 2004 Subject: Newbie Q References: <003d01bdcfa7$6f9cd880$432e0318@cc221812-a.hwrd1.md.home.com> Message-ID: <35E22EFD.318A4E2A@technologist.com> Samuel R. Blackburn wrote: > > My rule of thumb is attributes contains data that is unique to that > particular object. Do I understand you correctly if I parapharse your post as "attributes are only useful for unique identifiers?" That's as good a "rule of thumb" as any other, I guess, but it is a much more radical one than any I have heard before. It seems just as arbitrary as any other rule of thumb I've heard. Paul Prescod - http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Aug 25 05:38:51 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:04:09 2004 Subject: What is HyTime? References: <35E1FD13.D51DC54B@mail.disc.co.kr> <199808250031.UAA04709@unready.megginson.com> Message-ID: <35E22E78.B977CDEE@technologist.com> David Megginson wrote: > > > Would you tell me what is hytime? > > Start at the following URL: > > http://www.hytime.org/ That might scare him off! HyTime is an international standard that contains many extensions to the basic structures in SGML and XML. Consider: there are an infinite number of ways to express the concept of "hyperlink" or "address" or "use-by-reference" in SGML and XML. HyTime represents a standards-based way to express all of these concepts (and many, many more). Many people are afraid of HyTime because it is very large, (which is the case because there are many of these types of reusable concepts) In my opinion, however, the cost of reinventing these things is higher than the cost of figuring out how to use HyTime. (and being standards-based has various benefits...) The trick is recoginzing when you have a problem that HyTime can help to solve, without reading all of HyTime in advance. A partial solution to the problem is to poke around the "HyTime users guide" at the URL David mentioned. Another partial solution is to ask questions in XML-DEV and hope that a HyTime expert will speak up and point you to a section that applies. Paul Prescod - http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jeremy.Calles at sophia.inria.fr Tue Aug 25 10:08:56 1998 From: Jeremy.Calles at sophia.inria.fr (Jeremy CALLES) Date: Mon Jun 7 17:04:09 2004 Subject: First beta release of a Java XSL Processor (WD 1.0) Message-ID: <35E27107.9AF4F1E5@sophia.inria.fr> This is an XSL processor written in Java that conforms to the WD 1.0 (http://www.w3.org/TR/1998/WD-xsl-19980818), using the Simple API for XML (SAX 1.0) and the Document Object Model (DOM 1.0) API. (FreeDOM implementation of Don Park (donpark@quake.net)) This package also contains xslSlideMaker, a post-processor that can quickly make slides with XML & XSL. Limitations: This Processor won't implement any Flow Objects. Supported features: It supports every template rules and xsl:process rules except the Parent Anchor(../), Alternative Pattern , IdAnchor, Matching on Position and priority. It support xsl:process-children, xsl:value-of. I have some problems to implement xsl:number : I need some examples to understand what multi and any level should really do. You can download my XSL processor at: http://www.mygale.org/07/jcalles/XML Thanks Jeremy. -- Jeremy CALLES --- Jeremy.Calles@sophia.inria.fr home page --- http://www.mygale.org/07/jcalles KOALA/DYADE/BULL @ INRIA - XML Activities -- http://www.inria.fr/koala/XML/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Tue Aug 25 12:21:08 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:09 2004 Subject: Newbie Q Message-ID: <012f01bdd012$4bd9de00$b86118cb@caleb> >Is there a formal rule for the use of Atrributes vs Elements? The >assumption I am going on (per The XML Primer) is that Attributes are >best used to communicate information to the browser/application, and >Elements are best used for actual Data. Is this a valid assumption? > >In an EDI transaction, I was going to put the Header and Trailer >information in attributes, with the actual Detail Segments as >Elements... > >Any thoughts? Definitely see Robin Cover's page on this [cited by another responder]. It seems to me that issue of Attributes vs Elements becomes trickier as the thing you are marking up becomes more data-like and less document-like. The value of attributes are technically markup rather than content (at least by my reading of the spec) so the clearer the distinction is between what should be content and what should be markup, the clearer the attribute vs element issue is. This isn't too bad when you are marking up already existing content but it gets progressively worse as the markup language is used less and less for 'marking up' and more and more for other things. As my paper at SGML/XML Asia Pacific (or is it XML Asia now?) will discuss, one is always drawing the line between content and markup on an application by application basis. Content generally contains (or perhaps *is*) markup that's not XML. Consider spaces between words. They are a form of (non-XML) markup. They are also a presentational style. In some applications (such as corpus linguistics) word boundaries are marked up and it is a stylesheet issue to display the spaces. The moral is that even an important distinction like markup vs content vs presentation depends on the application. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Tue Aug 25 14:22:41 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:09 2004 Subject: Query about doc well-formedness Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C035FDC@WROX3> In my inexperience, can anyone help me with the following: In the XML 1.0 spec there is a well-formedness constraint upon the document which reads, "Each of the parsed entities which is referenced directly or indirectly within the document is well-formed." Does this mean A) That a well-formed document can contain declarations without ceasing to be merely a well-formed doc and becoming a validatable one? B) Indeed, such declarations must be made within the base document for any entity reference (not directly accessible as supplied with the computer's OS) to avoid violating the well-formedness constraint? Aid much appeciated, 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 david at megginson.com Tue Aug 25 14:37:46 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:09 2004 Subject: Query about doc well-formedness In-Reply-To: <29AA5A0E3A0CD21196F300A0C9D8575C035FDC@WROX3> References: <29AA5A0E3A0CD21196F300A0C9D8575C035FDC@WROX3> Message-ID: <199808251231.IAA00247@unready.megginson.com> Peter Jones writes: > In the XML 1.0 spec there is a well-formedness constraint upon the > document which reads, "Each of the parsed entities which is referenced > directly or indirectly within the document is well-formed." > > Does this mean > A) That a well-formed document can contain declarations > without ceasing to be merely a well-formed doc and becoming a > validatable one? All valid documents must be well-formed; or, in other words, anything allowed in a valid document is by definition allowed in a well-formed document (or else the valid document would fail to be well-formed). Well-formedness is simply a lower level of syntactic checking for a document; it is not a restricted subset of XML. > B) Indeed, such declarations must be made within the base document > for any entity reference (not directly accessible as supplied with > the computer's OS) to avoid violating the well-formedness > constraint? I am not certain that I really understand the question. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Tue Aug 25 14:49:29 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:04:10 2004 Subject: Query about doc well-formedness In-Reply-To: David Megginson's message of Tue, 25 Aug 1998 08:31:27 -0400 References: <29AA5A0E3A0CD21196F300A0C9D8575C035FDC@WROX3> <199808251231.IAA00247@unready.megginson.com> Message-ID: I second David's remarks, and am likewise not clear what you're asking. Note that entity REFERENCE (which is what the WFC you cite is about) is independent of entity DECLARATION. Entity reference occurs when &...; is encountered in parsed text content. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Tue Aug 25 15:18:51 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:10 2004 Subject: Query about doc well-formedness Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C035FDF@WROX3> I'm not quite sure if you're agreeing with me here so I'll run through the process as I see it and you can correct my mistakes: i) I have a well-formed document thus: Blah blah blah &ent1; &ent2; &ent1; and &ent2; are by definition parsed entities. But within the above document there is no indication as to whether the 'contents' of the entity (the substitution which occurs at parse time) are well-formed. So Q1) will a non-validating parser flag an error when it encounters either of the entity references above? My thinking here is that it should, as parsing means that the substitution should occur. Am I wrong here? So (ii) in order to avoid the referencing problem I put declarations in the doc above to provide the 'answers' to the entity references. Q2) Will a non-validating parser know how to deal with such declarations and thus not flag errors on the entity references at parse time? I.e. will I avoid being forced to use a validating parser to deal with the document. regards, 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: Henry S. Thompson [SMTP:ht@cogsci.ed.ac.uk] > Sent: Tuesday, August 25, 1998 2:03 PM > To: Peter Jones > Subject: RE: Query about doc well-formedness > > Ah, I see a source of your confusion. PARSED entity doesn't > necessarily mean VALIDATED, just processed as XML as the processor is > processing XML in the matrix document, so in the case of a > well-formedness-checking-only processor, PARSED means well-formed. > > 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 papresco at technologist.com Tue Aug 25 15:31:20 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:04:10 2004 Subject: XML Parser - COM component References: <3.0.32.19980824184256.00cc205c@mail.intervista.com> Message-ID: <35E2B992.80615981@technologist.com> It would be relatively easy to wrap up any of the SAX-compliant parsers written in and for Python in a COM object. Turning a Python object into a COM object seems to be about 15 minutes work. I admit that I haven't done it myself yet because the only project I would have done it for is switching from VB to Python. But I did do the research a few weeks ago and it looked easy, if you are familiar with COM. And of course, you could also make a COM wrapper for a C++ parser in C++. Paul Prescod - http://itrc.uwaterloo.ca/~papresco "You have the wrong number." "Eh? Isn't that the Odeon?" "No, this is the Great Theater of Life. Admission is free, but the taxation is mortal. You come when you can, and leave when you must. The show is continuous. Good-night." -- Robertson Davies, "The Cunning Man" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Tue Aug 25 15:50:26 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:10 2004 Subject: XPointer WD comments Message-ID: <199808251350.PAA08879@ifi.uio.no> I've just returned to my XPointer implementation and updated it, adding support for more of the specification. Because of this I have some new questions and reflections on the draft: - The definition of the term 'resource' in section 1.3 seems to me both circular with 'locator' and also rather unclear. - The WD says nothing whatever about what kinds of errors exist and what to do with them. To me it seems sensible to operate with three kinds of errors: - syntactic ones, where the locator fails to conform to the grammar - semantic ones, where the locator does not make sense, such as root().child(1,#comment).attr(id) - simple failures, where the locator attempts to locate non-existent nodes, such as child(4) on an element with three child elements - The WD does not say anything about how to interpret locator terms using nodes located with the 'string', 'attr' or 'span' keywords as the source of a locator. Ie: what is the child(1) of a span? - Similarly, nothing is said about how to continue locating from a list of candidate nodes, such as in root().child(all).child(1) - According to the WD, a 'string' location term can locate a string that stretches across several different nodes. This seems to me both difficult to implement and somewhat unecessary, since as far as I can see the same could be achieved by use of the 'span' term. - Maybe a non-normative appendix to the spec should add something about how to represent 'span' results in terms of the DOM? Should one use a nodelist or a new node class? - Does the A.2 section indicate that a future version of the XPointer spec will include a formal description of XPointer semantics in terms of the DOM? - Nothing whatever is said about the data model on which XPointers operate, which means that issues like entity handling and attribute defaulting are not covered. For instance, would the XPointer string("lars") match anywhere in the following instance? ]> l&a;rs --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 Tue Aug 25 15:52:42 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:04:10 2004 Subject: Namespaces design implementation? Message-ID: <199808251351.PAA09095@ifi.uio.no> * Tyler Baker | | The main question I still have is: are namespaces ever likely to be | a core part of XML, or will their utility be kept as a separate | layer on top of XML? Well, all declarations in an XML DTD, or schema, or whatever, depend on names to identify which element/attribute/whatever declarations concern. This means that you can't do validation or even attribute defaulting without taking namespaces into account. I'm all for a layered approach, but I don't see how namespaces can be layered on top of XML 1.0 as it stands. --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 david at megginson.com Tue Aug 25 16:06:54 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:10 2004 Subject: XPointer WD comments In-Reply-To: <199808251350.PAA08879@ifi.uio.no> References: <199808251350.PAA08879@ifi.uio.no> Message-ID: <199808251401.KAA00739@unready.megginson.com> Lars Marius Garshol writes: > I've just returned to my XPointer implementation and updated it, > adding support for more of the specification. Because of this I have > some new questions and reflections on the draft: [Excellent comments omitted.] I strongly encourage Lars and anyone else with specific technical comments about XLink and XPointer to send the comments directly to any or all of the following people: Bill Smith, chair Bill.Smith@eng.sun.com Steve DeRose, editor Steven_DeRose@brown.edu, sjd@eps.inso.com Eve Maler, editor eve@doctools.com While XML-Dev is an excellent place to bring up implementation problems like these, the members of the XML Linking WG do not all read this group. The people listed above can make certain that your comments get to the right place. 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 Tue Aug 25 16:12:20 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:10 2004 Subject: query about well-formedness Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C035FE0@WROX3> Thanks folks. I've figured it out 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 richard at cogsci.ed.ac.uk Tue Aug 25 16:26:19 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:04:10 2004 Subject: Query about doc well-formedness In-Reply-To: Peter Jones's message of Tue, 25 Aug 1998 14:13:16 +0100 Message-ID: <199808251426.PAA27221@cogsci.ed.ac.uk> > I have a well-formed document thus: > > Blah blah blah &ent1; > &ent2; > If this is the whole document - there is no DTD - then it is *not* well-formed, by the WFC on production 68. Here is my understanding of the issue. Essentially, all entities must be declared. But as a concession to processors that do not process the external subset or external parameter entities, they do not have to detect undeclared entities in documents where they can't tell (because the declaration might be in the part they don't process). Since the standard doesn't want to say "this is a well-formedness constraint but you don't have to detect it", it instead makes the lack of a declaration a validity error. If there is no external subset and no external PEs, or if the document has standalone="yes", then even a non-validating processor can be sure that it really is undeclared and must report the WF error. > Q1) will a non-validating parser flag an error when it encounters either > of the entity references above? Yes; the document is not well-formed. If the document had this DTD: and *didn't* have and "foo" did not declare the entities, then the error would become a validity error and a non-validating processor would not have to report it (though it can if it chooses to process the external susbset). > (ii) in order to avoid the referencing problem I put > declarations in the doc above to provide the 'answers' to the entity > references. > Q2) Will a non-validating parser know how to deal with such > declarations and thus not flag errors on the entity references at parse > time? Provided you put them in the internal subset, even a non-validating processor is required to process them. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Tue Aug 25 16:50:12 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:04:10 2004 Subject: Parameter entities - inconsistency in standard? In-Reply-To: Richard Tobin's message of Tue, 25 Aug 1998 15:26:03 +0100 (BST) Message-ID: <199808251449.PAA28116@cogsci.ed.ac.uk> In responding to Peter Jones's question about undeclared entities, I noticed what appears to be an inconsistency in the standard. Section 4.4.8 says that parameter entities need only be "included if validating". Note that it doesn't limit this to external PEs. The well-formedness constraint [WFC: Entity Declared] on production 68 is consistent with this: In a document without any DTD, a document with only an internal DTD subset which contains no parameter entity references, or a document with "standalone='yes'", the Name given in the entity reference must match that in an entity declaration [...] But the corresponding validity constraint [VC: Entity Declared] says: In a document with an external subset or external parameter entities with "standalone='no'" [...] If it's really intended that non-validating processors need not expand references to internal PEs, then "external parameter entities" should be changed to "parameter entities". As it stands, it appears that it is both well-formed and valid for entities not to be declared in documents with standalone="no" that contain internal PE references but no external ones! -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Tue Aug 25 19:40:21 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:04:10 2004 Subject: Newbie Q Message-ID: <5030300024416185000002L052*@MHS> >Is there a formal rule for the use of Atrributes vs Elements? The >assumption I am going on (per The XML Primer) is that Attributes are >best used to communicate information to the browser/application, and >Elements are best used for actual Data. Is this a valid assumption? > >In an EDI transaction, I was going to put the Header and Trailer >information in attributes, with the actual Detail Segments as >Elements... > >Any thoughts? There are also practical issues I guess. If you need to validate the document with a DTD, there is much more control available to control the content of subelements. You can say that the parent element's content model allows this or that, or this, that or the other, etc... With attributes, there is less flexibility. Each attribute is either there or not. There is no way to indicate that if you provide this one, you can't provide that one, or if these two are present, then you can't have that one, or if this one is present, then that one has to also be present, and so on (at least there is no way that I know of :-) Beyond that I think its purely an issue of what works best for what you want to do. And there is sometimes an issue of readability and writeability if the documents are ever dealt with by actual humans :-) Attributes with large values are kind of funky (IMHO) to make very readable, so I'd make any property that could have large values an element if all other things were equal (which of course they often aren't.) Overall, I guess the best rule of thumb is that attributes should hold stuff that either you need to get to fast without wanting to iterate the sub elements, or which provide 'control information' as you indicated, or which need to have ID/IDREF semantics enforced, or that you might want to provide implicit defaults for, and probably some others that I can't think of :-) ---------------------------------------- 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 Tue Aug 25 19:42:44 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:04:10 2004 Subject: Newbie Q Message-ID: <5030300024416253000002L032*@MHS> >I do not think this assumption has any basis whatever in the XML 1.0 >specification, and it certainly has no basis in the parent standard, >ISO 8879. There is some basis in HTML browser behavior, but that is >(in my opinion) a Bad Thing, and not to be perpetuated as a standard >agreement. It is dangerous for all the same reasons as in "HTML": >the industry got stuck with hard-coded application processing semantics. >XML encoding itself should used with the semantic opacity that the >specification implies, in my judgment; styles and other (separate) >processing specifications should determine how/whether certain (character) >data in an XML document is acted upon (displayed, suppressed, etc.). So does anyone have any opinions on whether something like XSL will be more convenient to deal with attributes than elements? Are the semantics of XSL such that one would be more easily and compactly notated than the other? ---------------------------------------- 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 dave at userland.com Tue Aug 25 19:47:57 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:04:10 2004 Subject: Announce: XML validator page In-Reply-To: <199808251449.PAA28116@cogsci.ed.ac.uk> References: Message-ID: <3.0.5.32.19980825104851.01004d20@scripting.com> Last week we put up an XML Validator page: http://www.scripting.com/frontier5/xml/code/xmlValidator.html You can run tagged text thru two different XML parsers. One is the built-in Frontier 5.1.3 parser, and the other is Brian Andresen's adaptation of James Clark's expat parser. I thought it would be of interest and use to the people on this list. Dave -------------------------------------- http://www.userland.com/directory.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Tue Aug 25 21:07:55 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:04:10 2004 Subject: Ann: XML Syntax Checker Message-ID: <3.0.5.32.19980825120852.00fc7bb0@scripting.com> Let's try this again... Here's the URL for our new XML Syntax Checker: http://www.scripting.com/frontier5/xml/code/syntaxChecker.html And thanks to the people who sent private email pointing this out. It was an honest mistake, coming from the tradition of HTML Validators, neither parser is a validating parser, glad to get a chance to correct this. Also we would appreciate results of any tests that show bugs in our parser. Part of the reason for putting this page up is to get a thorough review of our parser by people who don't work in Frontier. The purpose of XML is to enable interchange of information, so it makes a ton of sense to get our functionality reviewed by people who aren't in our community of users and developers. Also, one other thing, that one of the correspondents didn't pick up on. You have a choice of parsers, either the one built into Frontier 5.1.3, or Brian Andresen's adaptation of James Clark's expat parser, running in the Frontier environment. There's a pair of radio buttons just above the Submit button that allows you to make a choice. Programmers working in Frontier have the same choice. Dave -------------------------------------- http://www.userland.com/directory.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Aug 25 22:50:52 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:11 2004 Subject: [stds] browser war - starting over In-Reply-To: Message-ID: <199808252049.QAA23863@hesketh.com> YinSo Chen writes on the Web Standards Project (WSP) List: >I am not sure if an _independent_ developer will have _any chance in the >browser market right now. The browser war is all out, and anyone >participating better have a vastly deep pocket to compete. The browser war is indeed over, if you require that all browsers be bloated beasts that support everything an Internet user might want to do, from to email to news to JavaScript. If you don't, there may be hope, and it may be compatible with the goals of the WSP. A number of folks been talking on the XML-L list (archives at http://listserv.hea.ie/xml-l.html) about the possibility of creating a _small_ browser based around an XML parser and supporting CSS1 or a reasonable subset. Focusing on XML makes this _much_ easier - there's no need to waste processing cycles on broken markup. The structure can be built with a fairly minimal toolset, thanks to the much stricter rules XML places on documents. Implementing CSS in any significant way will, of course, require some hard work creating displays that accurately reflect the spec. While this doesn't achieve all the goals of the WSP, since this browser isn't going to support every weird dream that's currently possible in the HTML soup, it might provide an opportunity to show the major vendors that it's possible to build a browser right. XML + CSS is the easiest way to go for a lot of XML projects that are just getting started, and which have been hampered so far by the lack of browser support. IE5 has some XML support, but not a simple XML+CSS -> display XML, and Mozilla is still a long ways from completion. What I've got in mind is a simple Java HTTP engine + XML parser and a set of tools for other code to plug in and handle the display. Working in Java will enforce keeping this small, among other things. The DOM spec could provide a foundation for reading and manipulating the parsed XML, and Swing already provides a lot of the interface gizmos needed. Depending on how well the modularity is implemented, it might not be too hard to plug other things like JavaScript into the browser. It's not a perfect idea - Netscape and Microsoft probably won't lose sleep over it - but it seems like a good way to get things moving, especially in XML. Keeping it an open source project would make it easy for the maximum number of people to examine and fix the implementation. While implementing a subset of CSS won't necessarily make designers happy, it would probably be enough to get XML-based client apps rolling. If anyone's interested in writing up an initial spec for this or contributing programming time to it, please let me know. I've got too many non-paying projects already, and I'm not enough of a programmer to pull this off myself, but it seems like an idea whose time has come, and one I'd like to work on. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Wed Aug 26 00:30:10 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:04:11 2004 Subject: [stds] browser war - starting over References: <199808252049.QAA23863@hesketh.com> Message-ID: <35E343E8.C0EC4865@finetuning.com> The browser wars are just getting going again: both technological and informatical. It will be up to those of us know know the difference to stop the disinformation before the propaganda gets too out of control. Fight well brave soldiers ;-) lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dent at highway1.com.au Wed Aug 26 01:10:24 1998 From: dent at highway1.com.au (Andy Dent) Date: Mon Jun 7 17:04:11 2004 Subject: An XML report-writer/viewer Message-ID: We have a cross-platform report-writer product which images GUI on Mac and Windows and also renders to RTF and HTML. I'm in the early stages of a project to create a standalone document format for the report-writer, which allows re-opening of editable reports. These report documents must be a single, wholly self-sufficient document, eg: so users can copy around on a floppy. For this first release, report editing will be confined to a DTP model of editing content in the frames, NOT adding extra elements. I was about 3 days into a spec for the standalone document when I realised it sounded a lot like the little I'd read about XML, so I spent my weekend digesting XML Handbook. So far, with the extension of XML-Binary, it sounds like XML will meet our needs. My only major problems are with the content of page headers and footers triggered by soft page breaks. The report-writer allows you to define a header in terms of a "current field" (eg: an Account Name) which would of course change in content as you go down the pages. The best alternative I've so far thought of for handling this is the idea of some form of "current page break" floating as "hidden text" in the XML document. Within a given range, if you NEED to insert a soft page break, you would use the 'current page break'. However, if you are rendering to a page so long that it doesn't break, then you ignore these hidden breaks. It's almost a 2-dimensional data model - ancillary data supplied that may or may not be shown. Your feedback is very welcome. I suspect we are working in an area a little outside the norm for XML developers in that our focus is on a single document rather than collection. Andy Dent, Software Designer, A.D. Software, Western Australia OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.highway1.com.au/adsoftware/crossplatform.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smith at interlog.com Wed Aug 26 05:01:44 1998 From: smith at interlog.com (Chris Smith) Date: Mon Jun 7 17:04:11 2004 Subject: Newbie Q (Attributes and Elements) In-Reply-To: <35E1D874.DE5EDBE5@nina.snohomish.wa.gov> Message-ID: On Mon, 24 Aug 1998, Frank Blau wrote: > Is there a formal rule for the use of Atrributes vs Elements? The > assumption I am going on (per The XML Primer) is that Attributes are > best used to communicate information to the browser/application, and > Elements are best used for actual Data. Is this a valid assumption? Whatever seems to work best for your application is the best assumption. In addition, I have found that sometimes I want to *prevent* further structuring of data (and make this clear to users), and those items get placed in attributes. They're flat and they stay that way. You should also check the attribute normalization sections - if you are doing validation, then you can get the parser to do more work for you in some cases - and if it is justified by your application. > In an EDI transaction, I was going to put the Header and Trailer > information in attributes, with the actual Detail Segments as > Elements... My specific reaction here is that all of the Header and Trailer and Detail Segments information is always there - XML or not. As such, I would try to treat all of these items equally. If you are coming from a 'record' model of data, you can either have 'one element = one record' where all the fields are attributes, or you could have 'one field = one element' and records are grouped by parent elements. You as the designer have to decide which model serves your needs better. You should also pay attention to the ongoing namespaces work, since it seems (myu opinion) to affect the degree of control you can exert on content through the DTD and validation. I'm beginning to suspect that this might be one underlying reason for the (again, my opinion) increased polarization on namespaces following the most recent Working Draft. --------------------------------------------------------------------------- Chris Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Wed Aug 26 05:04:35 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:04:11 2004 Subject: Is XML getting too hard? References: <3.0.1.16.19980818151048.2be7bcdc@pop3.demon.co.uk> <199808181652.MAA01923@unready.megginson.com> Message-ID: <35E37A80.4AA8@hiwaay.net> David Megginson wrote: > > Note also that packaging does not concern only XML entities -- there's > also the problem of bundling non-XML entities, such as vector and > raster graphics, audio and video clips, VRML worlds, etc., that are > referenced from within an XML document. > > In the end, then, this is a problem that we have to solve anyway. Yes. What happened to the various proposals for SGML (eg, bentos)? This problem should be solved with other languages as hubs. The VRML metadata node uses EXTERNPROTOs to define the interface by which the VRML can consume and route the XML property values in its event model. This is exciting stuff because enables appCommunities who apply VRML to create sharable, validatible properties (eg, for vrml-lit, we need ways to keep persistent data about characters, stages, relationships, etc). The packaging issues apply there as well. The tug toward common solutions being felt as each language community tries to adapt to XML is a fascinating and welcome feeling. BTW, VRML uses gzip for single instances (in lieu of a binary). BTWBTW: There is a serious discussion on HTMLTextures again. Chrome proved it works. Tim Bray should remember this one from the last time it came up. What say you, XMLers? Should VRML create an HTMLTexture node or an XMLTexture node and why? Serious question. Help appreciated. 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 jjc at jclark.com Wed Aug 26 06:13:02 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:04:11 2004 Subject: Newbie Q References: <5030300024416253000002L032*@MHS> Message-ID: <35E37D33.947EC706@jclark.com> Dean Roddey wrote: > So does anyone have any opinions on whether something like XSL will be more > convenient to > deal with attributes than elements? Are the semantics of XSL such that one > would be more easily > and compactly notated than the other? We've been trying in XSL to make both equally convenient. 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 peterj at wrox.com Wed Aug 26 13:19:11 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:11 2004 Subject: Appendix D XML 1 spec Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C035FE3@WROX3> I'm having trouble figuring things out again... Can anyone tell me why in the following example in the spec Appdx D An ampersand (&#38;) may be escaped numerically (&#38;#38;) or with a general entity (&amp;).

" > when parsed the &#38;#38; is replaced with &#38; which when referenced gives & but &amp; when is parsed it remains &amp; in the examples given, and only becomes & when referenced. An error? 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 Wed Aug 26 14:22:37 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:04:11 2004 Subject: Appendix D XML 1 spec In-Reply-To: Peter Jones's message of Wed, 26 Aug 1998 12:13:49 +0100 Message-ID: <199808261222.NAA17991@cogsci.ed.ac.uk> > An ampersand (&#38;) may be escaped > numerically (&#38;#38;) or with a general entity > (&amp;).

" > When the entity declaration is parsed, character entities are expanded but general entities (including &) are not. (The table in section 4.4 is first place you should look in questions of this kind.) So (as described in appendix D) the entity's value is ... (&) ... (&#38;) ... (&amp;) ... When this is expanded in the instance, both character and general entities are expanded (again, as specified in the table), producing ... (&) ... (&38;) ... (&) ... in the text passed to the application. -- 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 jgarrett at navix.net Wed Aug 26 17:04:48 1998 From: jgarrett at navix.net (Jim Garrett (NAVIX)) Date: Mon Jun 7 17:04:11 2004 Subject: Future Of Browsers - Business Model Perspective Message-ID: <000101bdd0ff$c1668040$14c8c8c8@jgnt40> The "Future of Browsers" from a business model perspective. FACT: There are so many people who do not have computers but do have televisions, will cause the following to occur. 1.) Mass in numbers = massive potential market demand for information access. 2.) They all want email like everyone else. 3.) They want access to web information like everyone else. 4.) The "Industry Cable and Telephone" entities will compete with each other to tap that market and deliver a hardware solution that is not a traditional desktop. 5.) Example: Omaha, NE has 2 true service providers to everyone's house. COX cable is 30 percent complete in true fiber to the user, and will be offering all the services (local phone, long distance, 2way-cable, xDSL internet). U.S.West is the local teleco and has experimented w/ fiber in West Omaha and gave it up because of their shortsightedness. But U.S.West can't afford to lose the Omaha subscriber base so will be forced to compete. 6.) The above example will provide a model for all the others to ramp up high speed internet access, using HDTV set top boxes that will run a new OS. Which will cause developers to target that OS at mass quantities. 7.) This will cause a major vacuum and we all know what that causes. 8.) Therefore the Future of Browsers is still transforming itself until you have fulfilled all potential web access and email demand. The OS and browser that captures the most customer base will absolutely affect the future browser structure. 9.) True real-time 30 fps video/audio consumption and production will occur within that hardware structure and standards will be pushed out and all browsers will conform to item #9. 10.) Digital T.V.'s will be physically separated out into 2 parts. The tuner slash computer and the display. Allowing owners to upgrade their tuner slash computer while keeping their 16x9 digital thin panel display's. 11.) Currently MPEG2 encoders/decoders can deliver item #9 at 6.5MB/sec. Current uses are distance learning....current cost of hardware MPEG2 encoder/decoders is $15,000. per channel. High end Pentium II's can decode on the fly, so Pentium II class desktop tuner/computer's can sub for the decoder's. 12.) This will allow home's and buildings and vehicles and individuals to be permanently linked to the net, and allow people to interface in real time to each other, their home, their business, no matter where they are. 13.) Finally, the information revolution will have peaked out and information appliances will be as common and as mundane as the touch tone telephone is to us today. 14.) And all the accumulation of wealth that comes from being a proactive information market miner will be exhausted, similarly as the Gold Rush day's of the later 19th century. This is how I see the overall view of the future of browsers....within that overall framework...you all doing all the current XML research will provide the structure for those who use XML to create content for the current stage of the ongoing information revolution... JD Garrett xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Wed Aug 26 17:10:37 1998 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:04:11 2004 Subject: Future Of Browsers - Business Model Perspective In-Reply-To: <000101bdd0ff$c1668040$14c8c8c8@jgnt40> Message-ID: <3.0.5.32.19980826081101.00fe9470@scripting.com> >>FACT: There are so many people who do not have computers but do have televisions, will cause the following to occur. The web may be more ubiquitous than you think: http://www.msnbc.com/news/190591.asp Study: 1/3 of U.S. adults on Internet Women over 50 among fastest-growing group online Dave At 09:42 AM 8/26/98 -0500, you wrote: >The "Future of Browsers" from a business model perspective. > >FACT: There are so many people who do not have computers >but do have televisions, will cause the following to occur. > >1.) Mass in numbers = massive potential market demand for information >access. >2.) They all want email like everyone else. >3.) They want access to web information like everyone else. >4.) The "Industry Cable and Telephone" entities will compete > with each other to tap that market and deliver a > hardware solution that is not a traditional desktop. >5.) Example: > Omaha, NE has 2 true service providers to everyone's > house. COX cable is 30 percent complete in true fiber > to the user, and will be offering all the services > (local phone, long distance, 2way-cable, xDSL internet). > U.S.West is the local teleco and has experimented w/ > fiber in West Omaha and gave it up because of their > shortsightedness. But U.S.West can't afford to lose > the Omaha subscriber base so will be forced to compete. >6.) The above example will provide a model for all the others > to ramp up high speed internet access, using HDTV set top > boxes that will run a new OS. Which will cause developers > to target that OS at mass quantities. >7.) This will cause a major vacuum and we all know what that > causes. >8.) Therefore the Future of Browsers is still transforming > itself until you have fulfilled all potential web access > and email demand. The OS and browser that captures the most > customer base will absolutely affect the future browser structure. >9.) True real-time 30 fps video/audio consumption and production will > occur within that hardware structure and standards will be pushed > out and all browsers will conform to item #9. >10.) Digital T.V.'s will be physically separated out into 2 parts. > The tuner slash computer and the display. Allowing owners to > upgrade their tuner slash computer while keeping their 16x9 digital > thin panel display's. >11.) Currently MPEG2 encoders/decoders can deliver item #9 at 6.5MB/sec. > Current uses are distance learning....current cost of hardware > MPEG2 encoder/decoders is $15,000. per channel. High end Pentium II's > can decode on the fly, so Pentium II class desktop tuner/computer's > can sub for the decoder's. >12.) This will allow home's and buildings and vehicles and individuals > to be permanently linked to the net, and allow people to interface > in real time to each other, their home, their business, no matter > where they are. >13.) Finally, the information revolution will have peaked out and > information appliances will be as common and as mundane as the touch > tone telephone is to us today. >14.) And all the accumulation of wealth that comes from being a proactive > information market miner will be exhausted, similarly as the Gold Rush > day's of the later 19th century. > >This is how I see the overall view of the future of browsers....within that >overall framework...you all doing all the current XML research will provide >the structure for those who use XML to create content for the current stage >of the ongoing information revolution... > >JD Garrett > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > -------------------------------------- http://www.userland.com/directory.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jgarrett at navix.net Wed Aug 26 18:40:10 1998 From: jgarrett at navix.net (Jim Garrett (NAVIX)) Date: Mon Jun 7 17:04:11 2004 Subject: Future Of Browsers - Business Model Perspective In-Reply-To: <3.0.5.32.19980826081101.00fe9470@scripting.com> Message-ID: <000001bdd10c$04a8dc70$14c8c8c8@jgnt40> Dave: The study of course also shows that 2/3 are not yet on. Using the 2/3 raw number thought.... for sake of argument....then 66 percent of those in the study are not yet on the internet.... Which means that the potential market is huge... The issue is, that since DTV (digital television) is fast approaching and will be here in it's most expensive form in 4th quarter '98, the computer tuner in box outside of the TV display will cause many to decide..do I spend $1500 to $2000 on a computer and have an old analog t.v. or do I spend $1500 to $2000 on a new digital television that has a computer/tuner box that can get email and browse the web. T.V. people do not want to sit upright at a desk in a chair when they can do this from a new digital display from the comfort of their sofa's... TV tuner computer manufacturers will build central storage for these new digital t.v. tuner computer owners, similar to hotmail.com. They will also build in central processing as well, driving the network computer into the home television. I just see a massive shift about to occur because home users will have to make a purchasing choice when it comes to digital television upgrade. They won't be buying both a new digital t.v. tuner/computer w/ external display and a computer... 1.) when they can only fund one of the two... 2.) both devices will do email and surf the web... This being said....even people who now have computers will be tossing out their computers and moving to digital t.v. tuner computers making the market for the new digital t.v. tuner computer O.S. even larger than the 66 percent who are not surfing now. Digital Television can break the back of many computer hardware/software developers now if they don't get set for the PHASE II of the information revolution... JD Garrett > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Dave Winer > Sent: Wednesday, August 26, 1998 10:11 AM > To: xml-dev@ic.ac.uk > Subject: Re: Future Of Browsers - Business Model Perspective > > > >>FACT: There are so many people who do not have computers but do have > televisions, will cause the following to occur. > > The web may be more ubiquitous than you think: > > http://www.msnbc.com/news/190591.asp > > Study: 1/3 of U.S. adults on Internet > > Women over 50 among fastest-growing group online > > Dave > > > At 09:42 AM 8/26/98 -0500, you wrote: > >The "Future of Browsers" from a business model perspective. > > > >FACT: There are so many people who do not have computers > >but do have televisions, will cause the following to occur. > > > >1.) Mass in numbers = massive potential market demand for information > >access. > >2.) They all want email like everyone else. > >3.) They want access to web information like everyone else. > >4.) The "Industry Cable and Telephone" entities will compete > > with each other to tap that market and deliver a > > hardware solution that is not a traditional desktop. > >5.) Example: > > Omaha, NE has 2 true service providers to everyone's > > house. COX cable is 30 percent complete in true fiber > > to the user, and will be offering all the services > > (local phone, long distance, 2way-cable, xDSL internet). > > U.S.West is the local teleco and has experimented w/ > > fiber in West Omaha and gave it up because of their > > shortsightedness. But U.S.West can't afford to lose > > the Omaha subscriber base so will be forced to compete. > >6.) The above example will provide a model for all the others > > to ramp up high speed internet access, using HDTV set top > > boxes that will run a new OS. Which will cause developers > > to target that OS at mass quantities. > >7.) This will cause a major vacuum and we all know what that > > causes. > >8.) Therefore the Future of Browsers is still transforming > > itself until you have fulfilled all potential web access > > and email demand. The OS and browser that captures the most > > customer base will absolutely affect the future browser structure. > >9.) True real-time 30 fps video/audio consumption and production will > > occur within that hardware structure and standards will be pushed > > out and all browsers will conform to item #9. > >10.) Digital T.V.'s will be physically separated out into 2 parts. > > The tuner slash computer and the display. Allowing owners to > > upgrade their tuner slash computer while keeping their 16x9 digital > > thin panel display's. > >11.) Currently MPEG2 encoders/decoders can deliver item #9 at 6.5MB/sec. > > Current uses are distance learning....current cost of hardware > > MPEG2 encoder/decoders is $15,000. per channel. High end > Pentium II's > > can decode on the fly, so Pentium II class desktop tuner/computer's > > can sub for the decoder's. > >12.) This will allow home's and buildings and vehicles and individuals > > to be permanently linked to the net, and allow people to interface > > in real time to each other, their home, their business, no matter > > where they are. > >13.) Finally, the information revolution will have peaked out and > > information appliances will be as common and as mundane as the touch > > tone telephone is to us today. > >14.) And all the accumulation of wealth that comes from being a proactive > > information market miner will be exhausted, similarly as > the Gold Rush > > day's of the later 19th century. > > > >This is how I see the overall view of the future of > browsers....within that > >overall framework...you all doing all the current XML research > will provide > >the structure for those who use XML to create content for the > current stage > >of the ongoing information revolution... > > > >JD Garrett > > > > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > >(un)subscribe xml-dev > >To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > >subscribe xml-dev-digest > >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > > > > -------------------------------------- > http://www.userland.com/directory.html > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 26 19:14:58 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:04:12 2004 Subject: Another XML Syntax Checker Message-ID: <199808261714.SAA27728@cogsci.ed.ac.uk> Not wanting to be left out, I've put up an RXP-based well-formedness checker at http://www.cogsci.ed.ac.uk/~richard/xml-check.html -- 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 tyler at infinet.com Wed Aug 26 20:00:08 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:12 2004 Subject: Future Of Browsers - Business Model Perspective References: <000101bdd0ff$c1668040$14c8c8c8@jgnt40> Message-ID: <35E44D37.1FDEB878@infinet.com> Jim Garrett (NAVIX) wrote: > The "Future of Browsers" from a business model perspective. > > FACT: There are so many people who do not have computers > but do have televisions, will cause the following to occur. > > 1.) Mass in numbers = massive potential market demand for information > access. > 2.) They all want email like everyone else. > 3.) They want access to web information like everyone else. > 4.) The "Industry Cable and Telephone" entities will compete > with each other to tap that market and deliver a > hardware solution that is not a traditional desktop. > 5.) Example: > Omaha, NE has 2 true service providers to everyone's > house. COX cable is 30 percent complete in true fiber > to the user, and will be offering all the services > (local phone, long distance, 2way-cable, xDSL internet). > U.S.West is the local teleco and has experimented w/ > fiber in West Omaha and gave it up because of their > shortsightedness. But U.S.West can't afford to lose > the Omaha subscriber base so will be forced to compete. > 6.) The above example will provide a model for all the others > to ramp up high speed internet access, using HDTV set top > boxes that will run a new OS. Which will cause developers > to target that OS at mass quantities. > 7.) This will cause a major vacuum and we all know what that > causes. > 8.) Therefore the Future of Browsers is still transforming > itself until you have fulfilled all potential web access > and email demand. The OS and browser that captures the most > customer base will absolutely affect the future browser structure. > 9.) True real-time 30 fps video/audio consumption and production will > occur within that hardware structure and standards will be pushed > out and all browsers will conform to item #9. > 10.) Digital T.V.'s will be physically separated out into 2 parts. > The tuner slash computer and the display. Allowing owners to > upgrade their tuner slash computer while keeping their 16x9 digital > thin panel display's. > 11.) Currently MPEG2 encoders/decoders can deliver item #9 at 6.5MB/sec. > Current uses are distance learning....current cost of hardware > MPEG2 encoder/decoders is $15,000. per channel. High end Pentium II's > can decode on the fly, so Pentium II class desktop tuner/computer's > can sub for the decoder's. > 12.) This will allow home's and buildings and vehicles and individuals > to be permanently linked to the net, and allow people to interface > in real time to each other, their home, their business, no matter > where they are. > 13.) Finally, the information revolution will have peaked out and > information appliances will be as common and as mundane as the touch > tone telephone is to us today. > 14.) And all the accumulation of wealth that comes from being a proactive > information market miner will be exhausted, similarly as the Gold Rush > day's of the later 19th century. > > This is how I see the overall view of the future of browsers....within that > overall framework...you all doing all the current XML research will provide > the structure for those who use XML to create content for the current stage > of the ongoing information revolution... I agree with most of this, but this is if you look at the web browser as the pinnacle of the internet, even the pinnacle of technology. Monopolies like phone companies rarely do any innovation and it seems like standardizing on a relatively old web technology like the browser would be a logical step. I would highly doubt that there will not be better technologies to come out which do all that a web browser does, but much better in the future, even near future. HTML is an abomination from a developer's perspective, but it is hip, popular, and everyone uses it. Before anyone starts taking XML seriously, other than for using it as a tool for stylesheets that output HTML, a new class of content viewer will need to be popularized that puts HTML to shame. Anything less, and the world is doomed to HTML land and the monopolies that will control it forever. Mr Laurent already made this plea which I think is right on target. Why should XML be constrained by HTML? 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 jgarrett at navix.net Wed Aug 26 21:08:17 1998 From: jgarrett at navix.net (Jim Garrett (NAVIX)) Date: Mon Jun 7 17:04:12 2004 Subject: Future Of Browsers - Business Model Perspective In-Reply-To: <35E44D37.1FDEB878@infinet.com> Message-ID: <000001bdd121$7a443be0$14c8c8c8@jgnt40> Tyler: Yes I whole heartedly agree that HTML is one pathetic mess...I hate it, when it is compared to the languages....to me it was the light bulb going out when it first appeared...and we are seeing a huge vacuum in developement occur because of it....(Move It To The Web say the project managers...yet the coders say..GROAN GROAN GROAN). Sincerely JD Garrett > -----Original Message----- > From: Tyler Baker [mailto:tyler@infinet.com] > Sent: Wednesday, August 26, 1998 1:00 PM > To: Jim Garrett (NAVIX) > Cc: xml-dev@ic.ac.uk > Subject: Re: Future Of Browsers - Business Model Perspective > > > > I agree with most of this, but this is if you look at the web > browser as the > pinnacle of the internet, even the pinnacle of technology. > Monopolies like phone > companies rarely do any innovation and it seems like standardizing on a > relatively old web technology like the browser would be a logical > step. I would > highly doubt that there will not be better technologies to come > out which do all > that a web browser does, but much better in the future, even near future. > > HTML is an abomination from a developer's perspective, but it is > hip, popular, > and everyone uses it. Before anyone starts taking XML seriously, > other than for > using it as a tool for stylesheets that output HTML, a new class > of content > viewer will need to be popularized that puts HTML to shame. > Anything less, and > the world is doomed to HTML land and the monopolies that will control it > forever. Mr Laurent already made this plea which I think is > right on target. > Why should XML be constrained by HTML? > > 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 fblau at nina.snohomish.wa.gov Wed Aug 26 22:22:52 1998 From: fblau at nina.snohomish.wa.gov (Frank Blau) Date: Mon Jun 7 17:04:12 2004 Subject: Attribute Question Message-ID: <35E46CF1.66CCB082@nina.snohomish.wa.gov> If I have 3 attributes ("Format", "Usage", and "Loop") that I want every element in my DTD to have, is there a way to globally declare them? Do subelements inherit the attributes of the parent element? 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 Philippe.Le_Hegaret at sophia.inria.fr Wed Aug 26 22:42:02 1998 From: Philippe.Le_Hegaret at sophia.inria.fr (Philippe Le Hégaret) Date: Mon Jun 7 17:04:12 2004 Subject: Attribute Question References: <35E46CF1.66CCB082@nina.snohomish.wa.gov> Message-ID: <35E47308.7A2FF8D6@sophia.inria.fr> Frank Blau wrote: > > If I have 3 attributes ("Format", "Usage", and "Loop") that I want every > element in my DTD to have, is there a way to globally declare them? Do > subelements inherit the attributes of the parent element? No, there is no way to do this with XML. One solution is to use entities : 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 donpark at quake.net Wed Aug 26 23:02:47 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:12 2004 Subject: Future Of Browsers - Business Model Perspective Message-ID: <00c601bdd133$8a5a4170$2ee044c6@arcot-main> Jim, I think you are getting too caught up with web browsers which are, IMHO, just a small part of things to come. XML is bigger than web browsers. XML is to information what electricity is to modern society. People without access to the Net will be using XML-based technologies. Everytime a cash register rings, a garage door opens, a heart stops beating, a bomb falls, information packaged as XML will travel back and forth to let others know and get things done. It is my belief that no more than 60% of the world population will ever use a web browser even if the net-capable computer cost is brought down to $100. There are lots of people out there who don't know how to read, don't want to read, or don't have the time to read. They will not use a browser and they will not care if XML is superior to HTML. They will still be using XML unknowingly, however. 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 Curt.Arnold at hyprotech.com Wed Aug 26 23:08:59 1998 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:04:12 2004 Subject: Attribute Question Message-ID: The XSchema and XML-Data efforts both attempt (or foreshadow) more effective ways of having common attributes and content. But in XML DTD, you typically define an entity with common fragments and expand it later in the DTD. The ATTGROUP element in XSchema is an attempt to package this type of information but XSchema 1.0 does not give you a way to reference a existing ATTGROUP in a later element definition. That functionality is anticipated in a future release. p.s. Your return address does not appear to be valid. I attempted to mail you a response to an early question privately and it bounced. -----Original Message----- From: Frank Blau [mailto:fblau@nina.snohomish.wa.gov] Sent: Wednesday, August 26, 1998 3:16 PM To: XML Subject: Attribute Question If I have 3 attributes ("Format", "Usage", and "Loop") that I want every element in my DTD to have, is there a way to globally declare them? Do subelements inherit the attributes of the parent element? 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 jtauber at jtauber.com Wed Aug 26 23:55:20 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:12 2004 Subject: Attribute Question Message-ID: <004d01bdd13c$62d65ae0$e56118cb@caleb> -----Original Message----- From: Frank Blau >If I have 3 attributes ("Format", "Usage", and "Loop") that I want every >element in my DTD to have, is there a way to globally declare them? No. >Do subelements inherit the attributes of the parent element? Not as far as the processor is concerned, although an application might behave this way. Common practice is to declare a parameter entity representing that part of an ATTLIST declaration you want to use globally and then reference that parameter entity in a separate ATTLIST declaration for each element. For example: ... ... %global.atts; > James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Aug 27 01:00:42 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:12 2004 Subject: XML/RDF for HyperThesauri(sm) In-Reply-To: Message-ID: <3.0.1.16.19980825233632.0aa70d1e@pop3.demon.co.uk> At 16:26 24/08/98 -0500, Gerry Mckiernan wrote: > XML/RDF for HyperThesauri(sm) > >In my review of projects and applications that make use of standard or >innovative implementations of thesauri for Managed Conceptual Navigation in digital >collection [See my recent posting: _Brave New Word_], I have learned about the Virtual >HyperGlossary project of Peter Murray-Rust and Lesley West > > [http://www.gca.org/conf/meta98/xmldev98/peterm-r.htm ] . [...] I shall be posting the HTML/XML 'slides' from Montreal on our web site (http://www.vhg.org.uk). A major design feature for the VHG was that it should be easily accessible to people with little or no terminological experience (i.e. they are only familiar with the commonest terms ('synonym', 'acronym', etc.). The full DTD is on the WWW site and a few examples. We hope to post additional content, especially from learned societies and similar orgs. 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 Thu Aug 27 02:33:12 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:12 2004 Subject: ANN: Docuverse DOM SDK Message-ID: <001701bdd150$f1adf3e0$2ee044c6@arcot-main> First preview of the Docuverse DOM SDK is available at: http://www.docuverse.com/domsdk/index.html This version implements the W3C Proposed Recommendation for DOM API. Your comments are welcome. Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Thu Aug 27 02:43:27 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:04:12 2004 Subject: Future Of Browsers - Business Model Perspective References: <00c601bdd133$8a5a4170$2ee044c6@arcot-main> Message-ID: <35E4AB7F.CC703E2A@allette.com.au> Don Park wrote: > It is my belief that no more than 60% of the world population will ever use > a web browser even if the net-capable computer cost is brought down to $100. > There are lots of people out there who don't know how to read, don't want to > read, or don't have the time to read. They will not use a browser and they > will not care if XML is superior to HTML. They will still be using XML > unknowingly, however. I think this is very true. To put what Don says into a slightly different perspective, I was recently given an interesting but third-hand statistic that two thirds of the people alive on the earth at this point in time have never made a telephone call. If true, you have to wonder what "serving the masses" really means - probably not who has the nicest GUI. -- 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 dan at intervista.com Thu Aug 27 03:44:29 1998 From: dan at intervista.com (Dan Ancona) Date: Mon Jun 7 17:04:12 2004 Subject: Future Of Browsers - Business Model Perspective Message-ID: <3.0.32.19980826185422.01107d98@mail.intervista.com> >At 10:42 AM 8/27/98 +1000, Marcus Carr wrote: > >I think this is very true. To put what Don says into a slightly different >perspective, I was recently given an interesting but third-hand statistic that >two thirds of the people alive on the earth at this point in time have never made >a telephone call. If true, you have to wonder what "serving the masses" really >means - probably not who has the nicest GUI. No, "serving the masses" means smart content that adapts cleanly to a broad range of clients. Usability Matters, whether it's an API, a file format, an OS, or a piece of software. Just ask my Mom -- windows doesn't make a damn bit of sense to her. HTML happened because it was simple enough that when you did "View Source..." in Mosaic the first time, you could figure it out. Windows happened because it was a lot easier to grok than the command line. Isn't helping us climb out of the muck of always having to design for some lowest common denominator one of XML's reasons for existence? Cheers, Dan >>>> you might still see it in the desert <<<< dan.ancona.platinum.technology.goto.burningman http://www.ultrablue.com/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 donpark at quake.net Thu Aug 27 04:46:07 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:04:12 2004 Subject: FYI: Free-DOM Message-ID: <003301bdd163$82627520$2ee044c6@arcot-main> To current Free-DOM users: It turns out that FreeDOM is a trademark of Siaware Inc. (http://www.thepattern.com/freedom) so Free-DOM has been renamed and repackaged as Docuverse DOM SDK (http://www.docuverse.com/domsdk/index.html). I would like to thank Siaware Inc. for defer the name change until the release of Docuverse DOM SDK. One important difference between Docuverse DOM SDK and its predecessor is that the DOM SDK is a commercial product instead of being a freeware. I appologize if this change affects your plans. My only defense is the desire to improve the product quality and support. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Thu Aug 27 12:42:00 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:12 2004 Subject: Constraints on Attvalues Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C035FEC@WROX3> In my ongoing struggle to master the XML 1.0 spec can anyone help me with the following: Concerning production [41] in sect 3.1 there is a well-formedness constraint which says that the Attvalue cannot contain any direct or indirect references to an external entity. So for my element: &ent; can only refer to an internally declared entity, and the literal in the entity value, EntValue, cannot contain "....&Another_ent;...." where &Another_ent; is an external general entity. Am I on the right lines? 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 cowan at locke.ccil.org Thu Aug 27 17:28:22 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:12 2004 Subject: Constraints on Attvalues In-Reply-To: <29AA5A0E3A0CD21196F300A0C9D8575C035FEC@WROX3> from "Peter Jones" at Aug 27, 98 11:36:37 am Message-ID: <199808271530.LAA04194@locke.ccil.org> Peter Jones scripsit: > So for my element: > > > &ent; can only refer to an internally declared entity, and the literal > in the entity value, EntValue, cannot contain > "....&Another_ent;...." > where &Another_ent; is an external general entity. You are quite right, provided you keep firmly in mind the distinction between *being* an internal or external entity, and being internally or externally *declared*. Internal entities are those whose replacement text appears in the declaration, and external entities are those whose replacement text is referenced by a URI or Publicid. Either kind can be declared either internally (in the internal subset) or externally (in the external subset or in an external parameter entity). It's the first property (*being* an external entity) that is forbidden in references from attribute values. External parsed entities can only be referenced from content. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Aug 28 00:39:08 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:12 2004 Subject: Attribute Question In-Reply-To: <35E46CF1.66CCB082@nina.snohomish.wa.gov> Message-ID: <3.0.1.16.19980826230424.3c87aef6@pop3.demon.co.uk> At 13:15 26/08/98 -0700, Frank Blau wrote: >If I have 3 attributes ("Format", "Usage", and "Loop") that I want every >element in my DTD to have, is there a way to globally declare them? Do >subelements inherit the attributes of the parent element? As several people have said, no. But there are signs of similar things in the specs already. The values of xml:lang and xml:space 'apply' to the children of the containing element (unless superseded). And xml:link and some other attributes (still in draft) *are* required to be inherited. This leads to some pressure to provide 'inheritance-like' software for attributes. It's wasteful and error-prone if every application has to think about a (probably growing) set of inheritance-like phenomena and I'd certainly like it to be addressed in the layered APIs we are starting to discuss. 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 eliot at dns.isogen.com Fri Aug 28 02:34:56 1998 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:04:12 2004 Subject: Namespaces Not Necessarily Unrepentant Evil Message-ID: <3.0.5.32.19980827193117.008e5100@dns.isogen.com> All, At the recent XML Developer's Day I made a bit of a pest of myself by challenging the use of namespaces at every opportunity. However, after listening to a number of people whose opinions I respect who told me that my complaints were largely misguided and after a bit of reflection on my own emotional reactions to the subject, I've decided that perhaps I was not being entirely rational on the subject and that perhaps I owe at least a partial apology to those I pestered. First, David Megginson's XAF (XML architectural forms) implementation demonstrates that name spaces provide a necessary facility for making architectures generally usable in a constrained processing environment, namely giving you a defined syntax for qualifying names for communication to downstream processes. In the full architectural processing model you don't need this because the processing systems have access to all the data and everything is maintained in its original context. However, as David points out, this is not reasonable for typical XML processing environments (e.g., Web browsers and server-side pipe segments). In putting together a system of architectures for a client, I found that it was a practical necessity to use essentially David's XAF trick (see his paper on XAF once it's put up wherever the XML Dev Day papers end up getting put) to maintain knowledge of the original document's GIs in the down-stream architectural instances. I had to do this because I know that, at least in the short term, they'll be using non-architecture-aware processing tools to do architecture-based processing. The technique is a simple one: in the architecture provide an attribute whose value is the original ("client") gi. In the client document, set the value of the attribute to the client GI plus a prefix representing the architecture/doctype that governs the client document. For example, in my target architecture I would use a declaration like this: ... And in my client document's DTD I would do this: ]> ... The "architectural instance" you get by processing the "mydoc" document in terms of the gendoc architecture would look like this: ... I need the architecture name prefix because different parts of a document could come from different architectures, so just providing the original GI is not enough--it has to be bound to its original architecture/doctype context. So the idea of formalized qualified names does have real value, solving practical problems in a standardized way. Hmmph. BUT... BUT... BUT... I still have some concerns about namespaces that I think are legitimate: 1. The use of name spaces alone does not satisfy requirements that an architecture-like approach does satisfy. In particular, using name spaces alone the same element type cannot be mapped to multiple taxonomic classes at once. However, as David made so clear in his talk, most useful objects exist in a variety of taxonomies at once and it is often useful or necessary to be able to view an object with respect to different classifications at the same time. Qualified GIs alone cannot do this. 2. I see some enterprises and people overselling the power of namespaces in a way that seems to be both dangerous and irresponsible, if not downright unethical. For example, if I can save Word documents as XML but only if every element type starts "msword:" then what have I gained? Not a great deal more than I already have with RTF. "You can have any name space you want as long as it's black" is not an acceptable answer. 3. The effectively compulsory use of name spaces unnecessarily complicates XML parsers and processors. One of the advantages of architecture-like approaches is that parsers and processors need not be aware of them because they don't modify the basic syntax of documents. The specter of qualified names becoming part of the base XML language frightens me. 4. Name spaces take away authorial choice of element type and attribute names. This is not a problem when documents serve only machines, but is unacceptable in an authoring environment. I would like to see people who talk about and champion the use of name spaces in place of architecture-like mechanisms to make this clear. It's important. Again, my apologies to those who I badgered inappropriately. I will endeavor in the future to reign in my emotional reaction to the subject of name spaces and focus only on technical issues, of which there are many. Finally, my thanks to David Megginson for doing an amazing job of putting the name space and architecture mechanisms into a common context in which their respective strengths and weaknesses became clearer and for providing useful, working code for taking advantage of architectures in an XML/namespace context. 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 Fri Aug 28 03:18:19 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:04:13 2004 Subject: Namespaces Not Necessarily Unrepentant Evil Message-ID: <3.0.32.19980827181802.00c5a280@207.34.179.21> At 07:31 PM 8/27/98 -0500, W. Eliot Kimber wrote: >I still have some concerns about namespaces that I think are legitimate: > >1. The use of name spaces alone does not satisfy requirements that an >architecture-like approach does satisfy Granted. Hence the following is serious: >2. I see some enterprises and people overselling the power of namespaces Yes. Fortunately, at this point most such people collapse instantly given the slightest technical challenge. Four words: "Namespaces don't do that." It is our responsibility as community leaders to get out there and make this clear to the world. >3. The effectively compulsory use of name spaces unnecessarily complicates >XML parsers and processors. I don't buy it. The extra work is hardly noticeable and I don't expect it to affect performance in the slightest. >4. Name spaces take away authorial choice of element type and attribute >names. No, just of the prefix. I expect that once we have namespace-aware schemas, they will never contain a prefix, so the document designer and author should think entirely in terms of and and so on, and if when a chunk of that markup gets assembled into a package for delivery, if those become and who cares? >Again, my apologies to those who I badgered inappropriately. Not required. -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 28 03:34:10 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:13 2004 Subject: Attribute Question In-Reply-To: <3.0.1.16.19980826230424.3c87aef6@pop3.demon.co.uk> from "Peter Murray-Rust" at Aug 26, 98 11:04:24 pm Message-ID: <199808280136.VAA02034@locke.ccil.org> Peter Murray-Rust scripsit: > It's wasteful and > error-prone if every application has to think about a (probably growing) > set of inheritance-like phenomena and I'd certainly like it to be addressed > in the layered APIs we are starting to discuss. Still working on InheritanceFilter, a SAX filter that supports a global set of inherited attributes to which the application can add, and the document too (via a PI). -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at US.IBM.COM Fri Aug 28 03:37:10 1998 From: roddey at US.IBM.COM (Dean Roddey) Date: Mon Jun 7 17:04:13 2004 Subject: No subject Message-ID: <5030300024510561000002L012*@MHS> >The issue is, that since DTV (digital television) is >fast approaching and will be here in it's most expensive >form in 4th quarter '98, the computer tuner in box outside >of the TV display will cause many to decide..do I spend >$1500 to $2000 on a computer and have an old analog t.v. >or do I spend $1500 to $2000 on a new digital television >that has a computer/tuner box that can get email and browse >the web. There is a good bit of "convergence" activity from the Home Theater side of the aisle as well. Products like the Phillips (?) box, which is a PC, a DVD transport, a line double, A/V Reciever all in one box. Its not totally cooked yet, but things will probably soon get to the point where people who just want a computer for the web access aspects will be able to buy a home theater and PC all in one. Evidentally the Phillips product has an awesome picture becuause its DVD output goes straight to its internal line double via digital connection (unlike the common situation where very expensive electronics are required to make up for the many D/A/D/A conversions required with external line doubles.) ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Fri Aug 28 06:12:50 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:04:13 2004 Subject: Namespaces Not Necessarily Unrepentant Evil References: <3.0.32.19980827181802.00c5a280@207.34.179.21> Message-ID: <35E62E3C.9D6EFA8B@technologist.com> > >Again, my apologies to those who I badgered inappropriately. > > Not required. -Tim Aren't we a cosy little family. I'm glad to take humility from Eliot whenever I can get it. Tim Bray wrote: > > >4. Name spaces take away authorial choice of element type and attribute > >names. > > No, just of the prefix. I expect that once we have namespace-aware > schemas, they will never contain a prefix, so the document designer > and author should think entirely in terms of and > and so on, and if when a chunk of that markup gets assembled into a > package for delivery, if those become and > who cares? I think that Eliot's point is that architectural forms and other, similar mechanisms, allow name remapping in constrained ways which allow authors to use their own names and still be confident that their document conforms to some industry or departmental DTD. In my mind, markup users always walk a fine line between "doing their own thing" and "following the standard." "Doing their own thing" is crucial, because generic markup exists *precisely* to allow them to do their own thing -- they know their data better than some industry consortium (or department manager). But standard exist because doing too much of your own thing imposes unreasonable burdens on the cost effectiveness fo the system. Let's call this the "Balance of Power" problem. To me, this is the fundamental problem of generic markup. Little guy needs to protect his/her data from overstandardization. Big brother needs to protect his/her system from creative rebels. I think that this is the root of Eliot's complaint about namespaces. They increase one side of the equation but leave the other side gasping. They should be balanced by a counter-move that increases the freedom of the author/department/corporation inside the department/corporation/consortia. Subclassing: Subclassing in modern schema proposals is *supposed* to increase the freedom of the author/department etc., but mechanisms in existing proposals go only half-way. They do not seem to allow renaming, reordering, etc. of elements in subclasses. I admit that this is a hard problem, and would not vote against a proposal that does not tackle it. Let's just be clear that we are only solving half of the problem. Eventually, we must allow these sorts of "language redesigns" to take place as close to the author as possible, but also offer Big Brother the assurance that the language redesign does not destroy the consistency of the system. Oh yeah, and open content models suck rocks. Big time. Really. XSL: Does the XSL transformation language help? I believe that given our current level of knowledge, the XSL transformation language goes too far the *other* way. Nobody currently knows how to verify that a document that conforms to a DTD A will conform to a DTD B after going through an XSL transformation without doing the transformation. This means that authors who use XSL transformations to get to industry standard DTDs must constantly do the transformation to check that they still conform. This is unacceptable for solving the problem I described. In this context, XSL is a gun aimed at the foot. If someone wants to sponsor 3 months of research, I will be happy to develop algorithms that can predict whether an input document will conform to an output DTD after an XSL transformation, without doing the transformation (as long as XSL doesn't get more complex in the meantime!). Paul Prescod - http://itrc.uwaterloo.ca/~papresco Everything I touch turns into Python. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matt at veosystems.com Fri Aug 28 09:28:57 1998 From: matt at veosystems.com (matt@veosystems.com) Date: Mon Jun 7 17:04:13 2004 Subject: Namespaces Not Necessarily Unrepentant Evil In-Reply-To: <35E62E3C.9D6EFA8B@technologist.com> from "Paul Prescod" at Aug 27, 98 11:12:44 pm Message-ID: <19980828072846.5213.qmail@veosystems.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 2020 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980828/c481905a/attachment.bat From Usha_R2 at verifone.com Fri Aug 28 11:02:35 1998 From: Usha_R2 at verifone.com (Usha_R2@verifone.com) Date: Mon Jun 7 17:04:13 2004 Subject: XML- Data Schema Message-ID: <7BA6E16CF180D111944700A0C9979DE51D4F70@blr-nt-mail2.verifone.com> Hi! All, I am very new this XML and do not have much knowledge on it. I know how to use and write DTDs and XML files. Currently I am validating all my XML files using MSXML parser for Java. My application is not a web based application, so I do not use IE 4.0 or 5.0 I want more validation to be built into my system. I want to even check the data type of the content in the XML file. for example : 8 i.e when I parse it, the parser should give me an error if I have any thing other than an integer for size. I came to know that using XML-Data schemas we can specify data types. I have absolutely no idea as to how to write these schemas and where to put them in the document. Can anybody please help as to how to go about it and can I still use MSXML parser for validating my XML files. Thanks in advance usha. K. Usha Rani Dept : Applications Phone : (080) - 2869920 Email : usha_r2@verifone.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Fri Aug 28 11:06:34 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:13 2004 Subject: Namespaces Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C035FFE@WROX3> Eliot Kimber writes: 2. I see some enterprises and people overselling the power of namespaces in a way that seems to be both dangerous and irresponsible, if not downright unethical. For example, if I can save Word documents as XML but only if every element type starts "msword:" then what have I gained? Not a great deal more than I already have with RTF. "You can have any name space you want as long as it's black" is not an acceptable answer. Indeed. Well said. 3. The effectively compulsory use of name spaces unnecessarily complicates XML parsers and processors. One of the advantages of architecture-like approaches is that parsers and processors need not be aware of them because they don't modify the basic syntax of documents. The specter of qualified names becoming part of the base XML language frightens me. Ditto. 3. The effectively compulsory use of name spaces unnecessarily complicates XML parsers and processors. One of the advantages of architecture-like approaches is that parsers and processors need not be aware of them because they don't modify the basic syntax of documents. The specter of qualified names becoming part of the base XML language frightens me. Bravo! Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Aug 28 11:18:27 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:13 2004 Subject: XML- Data Schema Message-ID: <047601bdd264$e5dbed00$c96118cb@caleb> -----Original Message----- From: Usha_R2@verifone.com [...] >I want more validation to be built into my system. I want to even check >the data type of the content in the XML file. > >for example : > > 8 > >i.e when I parse it, the parser should give me an error if I have any >thing other than an integer for size. I came to know that using XML-Data >schemas we can specify data types. I have absolutely no idea as to how >to write these schemas and where to put them in the document. Can >anybody please help as to how to go about it and can I still use MSXML >parser for validating my XML files. Alternative schemata languages for XML are works in progress so you are probably best off handling this sort of validation in your application for now. That way you can use any parser you like (it can be a non-validating parser if your constraints can be more easily handled by your application) and have as simple or complex constraints as you like. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Usha_R2 at verifone.com Fri Aug 28 13:42:44 1998 From: Usha_R2 at verifone.com (Usha_R2@verifone.com) Date: Mon Jun 7 17:04:13 2004 Subject: Help needed in XMl - Data Message-ID: <7BA6E16CF180D111944700A0C9979DE51D4F71@blr-nt-mail2.verifone.com> Hi! All, I put the following in a .xml file say book.xml and tried to parse it using MSXML parser. I got the following erro parsing it. Can anybody please help me how to fix it. C:\xml\test>jview /cp c:\micxml\classes c:\micxml\msxml -d book1.xml Expected comments, PI, or EOF instead of start tag(<) Location: file:/C:/xml/test/book1.xml(29,1) Context: book.xml -------- Henry Ford Samuel Crowther My Life and<titlePart>Work</titlePart> Thank you Usha K. Usha Rani Dept : Applications Phone : (080) - 2869920 Email : usha_r2@verifone.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peterj at wrox.com Fri Aug 28 14:36:26 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:13 2004 Subject: <& in internal entity values Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C03600B@WROX3> Can anyone tell me why productions [9] of the XML 1 spec says that the & char is not allowed within an entity declaration but the section 2.4 on Char Data below says that they are. Section 2.4 seems to suggest that the following is o.k. Is it? 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 jtauber at jtauber.com Fri Aug 28 14:50:33 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:13 2004 Subject: Help needed in XMl - Data Message-ID: <001e01bdd282$7bf558e0$d66118cb@caleb> An XML document has the form: XML Declaration (optional) Prolog (optional) Document Element Miscellaneous Comments and/or PIs (optional) In your case, ... is the Document Element. (There can only be one). So the only thing allowed after is a comment or PI, hence mxsml's error. Also, the XML Declaration should be (ie lower case xml) James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ > > [...] > > > Henry Ford > Samuel Crowther > My Life and<titlePart>Work</titlePart> > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 28 14:57:35 1998 From: peterj at wrox.com (Peter Jones) Date: Mon Jun 7 17:04:13 2004 Subject: Entity declarations Message-ID: <29AA5A0E3A0CD21196F300A0C9D8575C03600C@WROX3> Can anyone also confirm whether, for a document instance without a DTD, I can have free-standing declarations. I.e. entity declarations that are not inside a Doctype declaration? Thanks, Peter Jones WebDev Technical Editor Wrox Press mailto:peterj@wrox.com *************** Wrox Press UK Ltd. http://www.wrox.co.uk Tel 44 121 706 6826 Fax 44 121 706 2967 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Aug 28 15:10:23 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:13 2004 Subject: <& in internal entity values Message-ID: <004701bdd285$63482e00$d66118cb@caleb> -----Original Message----- From: Peter Jones >Can anyone tell me why productions [9] of the XML 1 spec says that the & >char is not allowed within an entity declaration but the section 2.4 on >Char Data below says that they are. Section 2.4 seems to suggest that >the following is o.k. > > > >Is it? No. I am guessing that what confused the issue was the sentence "They are also legal within the literal entity value of an internal entity declaration". The reason for this sentence is that AT THE TIME OF DECLARATION, < and & in a literal entity value are not treated as markup delimiters. 2.4 says that "The ampersand character (&) and the left angle bracket (<) may appear in their literal form only when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section". Now because < and & are not markup delimiters in a literal entity value at the time of declaration, the additional sentence "They are also legal within the literal entity value of an internal entity declaration" is added. < and & are treated as markup delimiters only at the point of reference. Hope this helps. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Aug 28 15:12:50 1998 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:04:13 2004 Subject: Entity declarations Message-ID: <005001bdd285$a5f01560$d66118cb@caleb> -----Original Message----- From: Peter Jones >Can anyone also confirm whether, for a document instance without a DTD, >I can have free-standing declarations. I.e. entity >declarations that are not inside a Doctype declaration? No you can not. Note that you can havea doctype declaration without there being a DTD as such (apart from the entity declarations). James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjaakkol at cs.Helsinki.FI Fri Aug 28 16:04:55 1998 From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola) Date: Mon Jun 7 17:04:13 2004 Subject: ANNOUNCE: sgrep-1.71a - search and index SGML, XML and HTML files Message-ID: This announcement has been posted to comp.text.sgml and comp.text.xml as well. I'm also forwarding this to xml-dev, since sgrep is nowadays XML-aware tool and still in development. I'd very much like to hear comments about sgreps new XML-query and indexing features. Announcement follows: I have made available binary versions of sgrep-1.71a for both Win32 and i386-Linux. Sgrep is a tool to search and index text, SGML, XML and HTML files using structured patterns. Sgrep-1.71a should be considered as a prerelease of Sgrep-2, which is still under development. This means that: - New features might be included before final release. - Existing features might be changed. - It is guaranteed to have bugs. - Sources are not yet available. - All suggestions are welcome. --------------------------------------------------------------------------- NEW FEATURES --------------------------------------------------------------------------- Major new features since sgrep-1.0 which are already present: - Indexing of both structure and content. - SGML/XML/HTML scanner. - Official W32 binary. - sgtool has been dumped. It never really worked and even when it did, it wasn't very useful. - Should be completely compatible with older versions of sgrep. Features which will be present in sgrep-2.0: - Proper documentation - Support for querying notations, element type declarations and attribute list declarations inside SGML/XML document prolog - Parsing of all well-formed XML-documents. Features which might be present in sgrep-2.0: - Regular expressions. - Nearness operators. - Unicode support. For more information about sgrep: http://www.cs.helsinki.fi/~jjaakkol/sgrep.html For complete description of new features: http://www.cs.helsinki.fi/~jjaakkol/sgrep/README.txt For downloading sgrep: http://www.cs.helsinki.fi/~jjaakkol/sgrep/downloading.html Sgrep was made by: Jani Jaakkola Jani.Jaakkola@cs.helsinki.fi Pekka Kilpelainen Pekka.Kilpelainen@cs.helsinki.fi Enjoy! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Eckhart.Koeppen at uni-essen.de Fri Aug 28 16:44:34 1998 From: Eckhart.Koeppen at uni-essen.de (Eckhart Koeppen) Date: Mon Jun 7 17:04:13 2004 Subject: [stds] browser war - starting over References: <199808252049.QAA23863@hesketh.com> Message-ID: <35E6C240.DE9FF8F2@uni-essen.de> Well... the simple browser Simon St.Laurent ist talking about is not too far away (maybe...) I am currently working on my Ph.D. thesis about active hyperlinked documents (AHDs, see the WWW7 proceedings for a first idea, link for online version below). In this process, I am using and extending the Kino widget (an Xt widget), which has the following characteristics (positive and negative): + XML: parsing, markup declarations, entity references + HTML: standard 3.2 tags, but no frames, table processing is very weak (though it used to work pretty good, design changes broke it) + CSS1: mostly complete + parser interface: SAX-like via Xt callbacks - not really complete: all of the above works somehow, but could need some more work, documentation is very poor - no Java/JavaScript - written in C (which I hate more and more over the years, I wish I could have used Eiffel instead) - usable only in Xt programs - not exactly what you would call an example for excellent software design: not enough time, too many requirements... Since the Kino widget does nothing with respect to networking, we wrote the Cineast browser. It is written in Tcl/OTcl using the prototyping environment Wafe and provides additional GUI and networking capabilities (mostly HTTP). This makes it possible to implement XLink, where links like ACTUATE="AUTO" SHOW="EMBED" are resolved during parsing. It allows us further to directly implement client-side scripting with Tcl and OTcl There are lots of technical issues, limitations and design decisions, but if anybody is interested, I'd discuss these and try to release a semi-public alpha-version of this beast (for a previous version of the Cineast browser, see below). Right now, it serves only as a tool to demonstrate the AHD model... sort of an 80/20 solution. Regards, Eckhart AHDM: http://nestroy.wi-inf.uni-essen.de/Forschung/Publikationen/WWW7/original/ Wafe: http://nestroy.wi-inf.uni-essen.de/wafe/ Cineast (old version): http://nestroy.wi-inf.uni-essen.de/wafe/Cineast/ Universit?t GH Essen - Wirtschaftsinformatik und Softwaretechnik Eckhart.Koeppen@uni-essen.de http://nestroy.wi-inf.uni-essen.de/Koeppen/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 28 17:01:30 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:13 2004 Subject: Entity declarations In-Reply-To: <29AA5A0E3A0CD21196F300A0C9D8575C03600C@WROX3> from "Peter Jones" at Aug 28, 98 01:52:07 pm Message-ID: <199808281503.LAA17380@locke.ccil.org> Peter Jones scripsit: > Can anyone also confirm whether, for a document instance without a DTD, > I can have free-standing declarations. I.e. entity > declarations that are not inside a Doctype declaration? No, you can't. Declarations other than DOCTYPE declarations can only occur within a DOCTYPE declaration (the internal subset) or within an external entity referred to from a DOCTYPE declaration (the external subset). The DTD (document type definition) is precisely the set of declarations, so talking of declarations in a document instance "without a DTD" is a contradiction in terms. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From David.Rosenborg at xsse.se Fri Aug 28 17:42:13 1998 From: David.Rosenborg at xsse.se (David Rosenborg) Date: Mon Jun 7 17:04:14 2004 Subject: Namespaces Not Necessarily Unrepentant Evil References: <3.0.5.32.19980827193117.008e5100@dns.isogen.com> Message-ID: <35E6CAB6.1C8ED0C3@xsse.se> W. Eliot Kimber wrote: > > 3. The effectively compulsory use of name spaces unnecessarily complicates > XML parsers and processors. One of the advantages of architecture-like > approaches is that parsers and processors need not be aware of them because > they don't modify the basic syntax of documents. In what way do you mean that namespaces modify the syntax of documents? From an XML perspective they are just names and attributes. If you just view it as another level above XML, I think it's not a problem. Implementing namspace-awareness on top of an XML parser is actually rather trivial. However, namespaces does not match well with the original intention of DTDs, is that what you mean? It's true that architectural forms can be used without modifying existing XML/SGML software, but it implies that you use entities or the copy-paste paradigm, which I find less attractive. By copy-paste I mean that if you want to use an AF and rename elements, you have to rewrite the corresponding element type definitions. Also, in general, if you introduce new paradigms at the data level, like AF and namespaces, how useful are they if not also the applications are aware of them? It's true that you can use AF for validation purposes without changing the applications, but validation is just validation how important it may ever be. (Maybe a bit off topic:) One problem I see with names in XML is that there is really only type names (except for attribute names). In programming languages you normally have at least both variable names and type names. Just type names work if the data you are dealing with is sequential in some sense. This is often the case in traditional documents. For example, a document may consist of a sequence of chapters which in turn consist of sequences of paragraphs. In this case, just type is enough. There would be little meaning in naming the individual paragraphs. This is analogous to arrays in programming languages. The problem arises when you start to use XML for other kind of data (and more-than-basic documents too, for that matter). Imagine the following hypothetical example of a GUI component encoded in XML:

Some default text

 In this case you can think of color as a name of an "attribute" being of type color. Fine, often the name and the type can be the same. Now, if I want a second color:

Some default text

 Clearly the foreground and background names are only "attribute" names, i.e. named instances of colors, and not type names. The type is still color but you cannot express this relationship/distinction easily in a DTD. Also, from a data perspective, the order of the two is not interesting. You could argue that you should use real XML attributes in those situations, and rgb colors can indeed be encoded as strings, but this is just a simple example. The types could be far more complex. So, I guess AF can be used for this, but it isn't clean enough in my opinion. First, it requires you to use copy-paste to really us it. Secondly, AF doesn't make the distinction between types of elements and names of instances of element types. In fact, nor does the other ongoing schema activities (that I know of). What I would like to express is: (in pseudo language/syntax) In Namespace MyNS declare abstract ElementType Color; ElementType TextPad as foreground of type Color; background of type Color; (TextItem*) end ElementType Rgb implements Color as attribute red of type Integer; attribute green of type Integer; attribute blue of type Integer; end end ... text-pad of type MyNS:TextPad; In such an environment you wouldn't have to rewrite the element type definitions to use your own names on the actual instances. I don't claim these are any new thoughts at all, I just haven't come across this topic on this list before, but then, I haven't read everything. The reason why I brought this up in this thread is that I think the problem above is a common problem, and that you often try to solve it with namespaces and/or architectural forms. It is IMHO a less than optimal approach. Any thoughts? Cheers, ______________________________________________________________________ David Rosenborg OM Exchange Technology xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From creitzel at mediaone.net Fri Aug 28 18:41:33 1998 From: creitzel at mediaone.net (Charles Reitzel) Date: Mon Jun 7 17:04:14 2004 Subject: Programmer Interface Message-ID: <199808281641.MAA07279@chmls05.mediaone.net> >At 10:42 AM 8/27/98 +1000, Marcus Carr wrote: >>... two thirds of the people ... have never made a telephone call. Dan Ancona wrote: >... >Usability Matters, whether it's an API, a file format, an OS, or a piece of >software. Just ask my Mom ... > >Cheers, >Dan 10-4. Programmers are people too! I like sockets, myself. ODBC is ok. OCI is ugly but it gets the job done. These all have stood the test of millions of lines of code. Microsoft's object-like database interfaces look good from 10' going 20mph., but always have implementation problems. Object frameworks are either too big (er, MFC) or seem to solve somebody else's problem, or you are using SAP/Baan/Peoplesoft. Usually I kill two birds and write wrapper classes around the API: both to provide API insulation and make the app code easier to read and harder to goof up. A talented C++ programmer can make it look just like Java! Does SAX support the notion of a low-level/full-control interface with high-level/app-safe layers over it? Is this what filters do? Does anyone have a pointer to a conceptual overview of the SAX object hierarchy? regards, Charlie Charles Reitzel Independent Consultant creitzel@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 James.Anderson at mecomnet.de Fri Aug 28 18:43:56 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:14 2004 Subject: Namespaces Not Necessarily Unrepentant Evil References: <3.0.5.32.19980827193117.008e5100@dns.isogen.com> <35E6CAB6.1C8ED0C3@xsse.se> Message-ID: <35E6DFF1.273D6DB7@mecomnet.de> David Rosenborg wrote: > One problem I see with names in XML is that there is really only > type names (except for attribute names). > > In programming languages you normally have at least both variable > names and type names. Just type names work if the data you are > dealing with is sequential in some sense. This is often > the case in traditional documents. For example, a document may > consist of a sequence of chapters which in turn consist of > sequences of paragraphs. In this case, just type is enough. > There would be little meaning in naming the individual paragraphs. > This is analogous to arrays in programming languages. > > The problem arises when you start to use XML for other > kind of data (and more-than-basic documents too, for that matter). Yes, the "name identity" problem has, for reasons which I've yet to comprehend, been declared to pertain to attribute and element names only. That one cannot qualify entity and notation names would appear to be just as much of a problem in compound documents as that which arises with attributes and element, but I am advised that practice does not bear this out. In any event, the issue has little bearing on the question which you raise, since elements can be identified independent of both position and type by virtue of attribute values. The standard ID attributes are specified to have a scope of and uniqueness within a document, which property, in combination with the qualification on the attribute name, ensures that an unambiguous interpretation is possible. > What I would like to express is: (in pseudo language/syntax) > > In Namespace MyNS declare > > abstract ElementType Color; > > ElementType TextPad as > foreground of type Color; > background of type Color; > > (TextItem*) > end > > ... > end > > ... > Any thoughts? yes; You are not subtyping the color elements, but instead binding them to storage elements named "foreground" and "background". they are not subtyped, since neither their structure nor their behaviour is modified by the relation to the respective name. In this situation, either of the encodings express the relations which you describe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 28 18:58:58 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:14 2004 Subject: Programmer Interface In-Reply-To: <199808281641.MAA07279@chmls05.mediaone.net> References: <199808281641.MAA07279@chmls05.mediaone.net> Message-ID: <199808281653.MAA01203@unready.megginson.com> Charles Reitzel writes: > Does SAX support the notion of a low-level/full-control interface > with high-level/app-safe layers over it? Is this what filters do? > Does anyone have a pointer to a conceptual overview of the SAX > object hierarchy? SAX provides no explicit support for doing so, but what you suggest is implicit in the design: SAX was intended to provide very low-level parse information that middle layers (such as a DOM implementation or some other object model) can present to application writers in a more palatable form. In the end, I bent a little to the wishes of the masses and included a few friendly helper classes, but for the most part, SAX is still more IP than HTTP. There are two major advantages to keeping SAX relatively stupid: 1. Parser writers do not need to implement too much, so they're more likely to support SAX (as has happened almost universally among Java parser writers). 2. Application writers aren't stuck with a single, high-level object model. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Fri Aug 28 19:34:25 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:04:14 2004 Subject: Namespaces Not Necessarily Unrepentant Evil In-Reply-To: <19980828072846.5213.qmail@veosystems.com> Message-ID: On 28 Aug 1998 matt@veosystems.com wrote: > Paul, you know very well that this is generally an unsolveable > problem. I haven't had a chance to read the latest XSL spec, but > unless the programatic aspects have been considerably reduced, I think > you'll be disappointed at the end of the 3 months - no matter how > brilliant (and Paul is brilliant) you are. Of course, if they have > made those changes, then you might have success in 3 months, but then > XSL will fail for the general formatting problem. The new XSL has no scripting. Extensibility is an item that they still must decide upon -- scripting may reappear. I have been thinking recently that they could leave all programmatic issues to a post proces. Then the line between "behaviour sheets" and "style sheets" would be clear: stylesheets do everything that can be done non-programmatically and behaviour sheets will do the rest. I don't honestly know if this system will be too layered to be easy to use. But perhaps it will be easier to use. Anyhow, if they add scripting back into XSL, then I would, of course, restrict my proof to XSL stylesheets that do not use programmatic features. XSL goes much farther towards making that reasonable than DSSSL did. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Fri Aug 28 19:38:00 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:04:14 2004 Subject: Constraints on Attvalues Message-ID: <5030300024569666000002L062*@MHS> >Internal entities are those whose replacement text appears in the >declaration, and external entities are those whose replacement text >is referenced by a URI or Publicid. Either kind can be declared >either internally (in the internal subset) or externally (in the >external subset or in an external parameter entity). In that last parenthetical phrase... can you give an example of the latter scenario, i.e. "in an external parameter entity"? Just want to make sure I understand what's being said. 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 matt at veosystems.com Fri Aug 28 21:26:20 1998 From: matt at veosystems.com (matt@veosystems.com) Date: Mon Jun 7 17:04:14 2004 Subject: Namespaces Not Necessarily Unrepentant Evil In-Reply-To: <35E6CAB6.1C8ED0C3@xsse.se> from "David Rosenborg" at Aug 28, 98 04:20:22 pm Message-ID: <19980828192601.29099.qmail@veosystems.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 4467 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980828/ab794391/attachment.bat From James.Anderson at mecomnet.de Fri Aug 28 21:39:06 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:14 2004 Subject: XSL: scripting v/s rewriting References: Message-ID: <35E70932.B228C1F4@mecomnet.de> Paul Prescod wrote: > > On 28 Aug 1998 matt@veosystems.com wrote: > > The new XSL has no scripting. Extensibility is an item that they still > must decide upon -- scripting may reappear. I have been thinking recently > that they could leave all programmatic issues to a post proces. Then the > line between "behaviour sheets" and "style sheets" would be clear: > stylesheets do everything that can be done non-programmatically and > behaviour sheets will do the rest. Another possible view is that there is no "post process". The distinction between the rewriting and the scripting aspects of the earlier draft was short-sited and I welcomed its elimination from the current version. Since a rewriting system, in general, can be sufficiently powerful as to act as the basis for a general programming language, the distinction "behaviour" v/s "style" brings no inherent benefit. There are publications from several years back on constraint-based programming environments, (Wm Leler, ...Constraint Programming Languages...) which demonstrated this for term rewriting systems. Where the "styling" forms describe rewriting operations all the way to "machine code", there is no need for a "scripting" language. If you're curious, a quick search turned up what appears to be an active URL for him (http://wm.simplenet.com/wm/) and a pointer to a source for the language he described (http://www.cirl.uoregon.edu/constraints/systems/bertrand.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 matt at veosystems.com Fri Aug 28 21:47:34 1998 From: matt at veosystems.com (matt@veosystems.com) Date: Mon Jun 7 17:04:14 2004 Subject: XSL: scripting v/s rewriting In-Reply-To: <35E70932.B228C1F4@mecomnet.de> from "james anderson" at Aug 28, 98 09:48:21 pm Message-ID: <19980828194717.30038.qmail@veosystems.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 2076 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980828/147887dc/attachment.bat From peter at ursus.demon.co.uk Fri Aug 28 23:58:57 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:14 2004 Subject: XML- Data Schema In-Reply-To: <7BA6E16CF180D111944700A0C9979DE51D4F70@blr-nt-mail2.verifo ne.com> Message-ID: <3.0.1.16.19980827224515.29df7ee0@pop3.demon.co.uk> At 14:32 28/08/98 +0530, Usha_R2@verifone.com wrote: > >I want more validation to be built into my system. I want to even check >the data type of the content in the XML file. > >for example : > > 8 > >i.e when I parse it, the parser should give me an error if I have any >thing other than an integer for size. I came to know that using XML-Data >schemas we can specify data types. I have absolutely no idea as to how >to write these schemas and where to put them in the document. Can >anybody please help as to how to go about it and can I still use MSXML >parser for validating my XML files. I think we are a few months away from having schemata that will be universally interoperable - if you are an early adopter I am sure that the XSchema groups will be thinking of how to extend the functionality. If you are validating particular types of data then the routines I have written for JUMBO2 may fit the bill. An element (Node) has routines such as isCorrectFormat() and isValid() which are no-ops for a generic element but can be subclassed. So I have a FloatNode class which can have max and min values and when these are reached the entry field goes red. The main purpose is to extend it to more complex things like molecules and graphs, so don't look for shrink-wrapped quality. However I expect this will be commonplace in many tools fairly soon. 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 28 23:58:57 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:15 2004 Subject: Help needed in XML - Data In-Reply-To: <7BA6E16CF180D111944700A0C9979DE51D4F71@blr-nt-mail2.verifo ne.com> Message-ID: <3.0.1.16.19980827225228.36cf403a@pop3.demon.co.uk> At 17:12 28/08/98 +0530, Usha_R2@verifone.com wrote: >Hi! All, > >I put the following in a .xml file say book.xml and tried to parse it >using MSXML parser. I got the following erro parsing it. Can anybody >please help me how to fix it. [... problem snipped ...] I often find it useful to use more than one parser if I can't immediately find what's going on. There are now many parsers that you can install in minutes and have very different styles of error messages which can be quite helpful. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Sat Aug 29 08:58:12 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:15 2004 Subject: Validating IDREFS... Message-ID: <35E7A6C4.E5F394CD@infinet.com> When validating IDREF and IDREFS values for an attribute the following constraint is stated: Validity Constraint - IDREF Values of type IDREF must match the Name production, and values of type IDREFS must match the Names) production; each Name must match the value of an ID attribute on some element in the XML document; i.e. IDREF values must match the value of some ID attribute. Does this mean that you need to have the entire document parsed before you can make the check that the value of the ID matches the ID of some element in the document? If this is true, then for validating parser implementations you will first need to build an in memory parse tree using a non-validating parser and then validate the document by recursively traversing the parse tree. For large documents that wish to be validated, this seems like a major performance and memory problem, especially in memory hungry languages like Java. Besides this production, I cannot see any other production in the spec which prevents a validating parser from just validating the document from a stream (at least for the implementation I am working on). Perhaps this particular constraint should be relaxed so that this sort of validating can be done at a higher level as many application developers may want the benefits of validation without the obvious memory expense. I am not an SGML expert, so maybe someone here can give me some historical reason for why the XML spec needs to have ID's or at least ID's that have not previously been declared in the document when an IDREF is encountered. Thanx in advance, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sat Aug 29 09:09:52 1998 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:04:15 2004 Subject: Validating IDREFS... References: <35E7A6C4.E5F394CD@infinet.com> Message-ID: <35E7A5AF.241AD2E4@jclark.com> Tyler Baker wrote: > Does this mean that you need to have the entire document parsed before > you can make the check that the value of the ID matches the ID of some > element in the document? Yes. > If this is true, then for validating parser implementations you will > first need to build an in memory parse tree using a non-validating > parser and then validate the document by recursively traversing the > parse tree. For large documents that wish to be validated, this seems > like a major performance and memory problem, especially in memory hungry > languages like Java. You need to maintain a hash table of IDs in order to enforce the ID VC (uniqueness of IDs). To check matching of IDs you just add a boolean that says whether the ID has been defined yet. At the end of the document, iterate over the hash table and give an error for each undefined ID. 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 avirr at LanMinds.Com Sun Aug 30 00:53:48 1998 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:04:15 2004 Subject: XML-QL In-Reply-To: <35E7A6C4.E5F394CD@infinet.com> Message-ID: I just discovered the XML Query Language proposal at http://www.w3.org/TR/NOTE-xml-ql/, and find it very interesting. It looks a lot like SQL, which could be handy, but also somewhat limiting. What do you'all think about it? 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 tyler at infinet.com Sun Aug 30 03:18:35 1998 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:04:15 2004 Subject: Validating IDREFS... References: <35E7A6C4.E5F394CD@infinet.com> <35E7A5AF.241AD2E4@jclark.com> Message-ID: <35E8A8AC.8BD993E8@infinet.com> James Clark wrote: > Tyler Baker wrote: > > > Does this mean that you need to have the entire document parsed before > > you can make the check that the value of the ID matches the ID of some > > element in the document? > > Yes. > > > If this is true, then for validating parser implementations you will > > first need to build an in memory parse tree using a non-validating > > parser and then validate the document by recursively traversing the > > parse tree. For large documents that wish to be validated, this seems > > like a major performance and memory problem, especially in memory hungry > > languages like Java. > > You need to maintain a hash table of IDs in order to enforce the ID VC > (uniqueness of IDs). To check matching of IDs you just add a boolean > that says whether the ID has been defined yet. At the end of the > document, iterate over the hash table and give an error for each > undefined ID. > > James This I know is one idea to get around this problem and this is basically my current implementation as well, but shouldn't a validating XML parser flag an error if an IDREF does not have a corresponding ID when the error occurs. In other words, I would think that deferring errors before the content is passed to the document would be illegal. Basically, I just need to know if it is OK to pass errors to the application after all of the content has already been parsed and passed to the application. Thanx, 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 tbray at textuality.com Sun Aug 30 03:24:42 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:04:15 2004 Subject: Validating IDREFS... Message-ID: <3.0.32.19980829182432.00bd6100@207.34.179.21> At 09:19 PM 8/29/98 -0400, Tyler Baker wrote: >Basically, I just need to know if it is OK to pass errors to the application >after all of the content has already been parsed and passed to the application. Yes; the semantics of ID/IDREF as defined make this not only OK but pretty well compulsory. That's why this is a validity, not a well-formedness, error. -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 Sun Aug 30 03:43:27 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:15 2004 Subject: Validating IDREFS... In-Reply-To: <35E7A6C4.E5F394CD@infinet.com> from "Tyler Baker" at Aug 29, 98 02:59:16 am Message-ID: <199808300145.VAA06076@locke.ccil.org> Tyler Baker scripsit: > Does this mean that you need to have the entire document parsed before > you can make the check that the value of the ID matches the ID of some > element in the document? Yes. > If this is true, then for validating parser implementations you will > first need to build an in memory parse tree using a non-validating > parser and then validate the document by recursively traversing the > parse tree. Not really. All you need to keep is a list of IDs and IDREFs seen so far. At the end of the document, they had better pair up correctly. > I am not an SGML expert, so maybe someone here can give me some > historical reason for why the XML spec needs to have ID's or at least > ID's that have not previously been declared in the document when an > IDREF is encountered. The whole point of ID and IDREF is to have a simple intra-document link, so that documents that have non-hierarchical natural structures can be fitted into SGML/XML hierarchies. For that requirement, forward references and even loops are sometimes essential. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sun Aug 30 03:55:38 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:15 2004 Subject: Constraints on Attvalues In-Reply-To: <5030300024569666000002L062*@MHS> from "Dean Roddey" at Aug 28, 98 01:45:03 pm Message-ID: <199808300158.VAA06476@locke.ccil.org> Dean Roddey scripsit: > In that last parenthetical phrase... can you give an example of the latter > scenario, i.e. "in an > external parameter entity"? Just want to make sure I understand what's being > said. Sure. I'm going to declare some entities internal and external, hopefully with self-explanatory names. Here is the main document, example.xml: ]> etc. etc. Then here is the external subset, example.dtd: %externalParameterEntity; etc. etc. Then here is a parameter entity, example.par: And so on. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sun Aug 30 13:25:29 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:04:15 2004 Subject: Validating IDREFS... In-Reply-To: <35E8A8AC.8BD993E8@infinet.com> References: <35E7A6C4.E5F394CD@infinet.com> <35E7A5AF.241AD2E4@jclark.com> <35E8A8AC.8BD993E8@infinet.com> Message-ID: <199808301117.HAA00214@unready.megginson.com> Tyler Baker writes: > > You need to maintain a hash table of IDs in order to enforce the ID VC > > (uniqueness of IDs). To check matching of IDs you just add a boolean > > that says whether the ID has been defined yet. At the end of the > > document, iterate over the hash table and give an error for each > > undefined ID. > > This I know is one idea to get around this problem and this is > basically my current implementation as well, but shouldn't a > validating XML parser flag an error if an IDREF does not have a > corresponding ID when the error occurs. In other words, I would > think that deferring errors before the content is passed to the > document would be illegal. Here are three points to note: 1. It is more important to pass information to the application about _where_ the error occurs, and you can keep that information in the hash table. 2. In a tree-based API, the error will be spotted before the tree is completed, so the application will know about the error right at the start before it can work with the tree. 3. In a stream-based API, the error will be obvious when you have parsed the end tag of the document element -- you can report the error before you report the element end. 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 ruchig at iitk.ac.in Sun Aug 30 14:03:36 1998 From: ruchig at iitk.ac.in (ruchig) Date: Mon Jun 7 17:04:15 2004 Subject: Please..... Message-ID: Hello Everybody: I am very new for this list. Can any one help he from where I can get introduction of xml and other stuff. Thanks ruchig xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Sun Aug 30 16:06:58 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:04:15 2004 Subject: Please..... In-Reply-To: Message-ID: >Hello Everybody: > >I am very new for this list. Can any one help he from where I can get >introduction of xml and other stuff. >Thanks >ruchig We are creating one collection at http://www.xml-cml.org/ Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sdahl at goshawk.com Sun Aug 30 22:19:52 1998 From: sdahl at goshawk.com (Steve Dahl) Date: Mon Jun 7 17:04:15 2004 Subject: XML Namespace Message-ID: <35E9B34E.358F75DC@goshawk.com> I've got a confusion of sorts about what the intention is, in the separation of Namespace URI versus prefix. At the end of Section 1 and in Section 2, it says that Namespaces are identified by URI, because these names have the properties of uniqueness and persistence, and that the prefix used commonly in qualified names is merely a proxy for the URI, because the URI contains characters that are illegal in XML names (and maybe also to reduce clutter, since prefixes are much shorter than URIs. >From that, I inferred that prefixes are assumed to lack either uniqueness or persistence (or both), or else they could have been used as the namespace name to begin with. This means that it's not impossible that I might have a collision between two different Namespaces being associated with the same prefix. In that case, what would I need to do if I wanted to mix element types from two different DTDs that had the same prefix but which are intended to be bound to different Namespaces? For example, if the file a.dtd declared one element ns:x, and the file b.dtd declared another element ns:x, how could I use both of them in the same document, without copying one of the DTDs and changing the prefixes in the copy? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sun Aug 30 22:51:44 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:04:15 2004 Subject: XML Namespace Message-ID: <3.0.32.19980830135035.00bd7860@207.34.179.21> At 04:17 PM 8/30/98 -0400, Steve Dahl wrote: >For example, if the file a.dtd declared one element ns:x, and the file >b.dtd declared another element ns:x, how could I use both of them in the >same document, without copying one of the DTDs and changing the prefixes >in the copy? The namespace draft clearly forbids mapping one namespace to two different prefixes. So in the instance, you'd probably have to change the ns:x to ns_2:x or something. Which meant that if you wanted to validate it against b.dtd, you'd have to change it in b.dtd as well. BUT (and this is the hard part) you couldn't validate the merged document against b.dtd anyhow because it won't know about the elements from a.dtd. So you're going to have to figure out how to make a merged dtd. Which is hard. But once you've figured that out, fix up the namespace collisions while you're doing the merge. -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 Sun Aug 30 23:23:24 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:04:15 2004 Subject: XML Namespace In-Reply-To: <35E9B34E.358F75DC@goshawk.com> from "Steve Dahl" at Aug 30, 98 04:17:18 pm Message-ID: <199808302126.RAA25790@locke.ccil.org> Steve Dahl scripsit: > From that, I inferred that prefixes are assumed to lack either > uniqueness or persistence (or both), or else they could have been used > as the namespace name to begin with. This means that it's not impossible > that I might have a collision between two different Namespaces being > associated with the same prefix. In that case, what would I need to do > if I wanted to mix element types from two different DTDs that had the > same prefix but which are intended to be bound to different Namespaces? Learn to relax and live without DTDs. The new namespace proposal makes them useless anyway, so people are now trying to develop various replacements for them. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Sun Aug 30 23:33:17 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:04:15 2004 Subject: XML-QL In-Reply-To: References: <35E7A6C4.E5F394CD@infinet.com> Message-ID: <3.0.3.32.19980830173250.00b97e4c@nexus.polaris.net> [My first attempt at a reply doesn't seem to have gone through. Let's try this again....] At 03:53 PM 8/29/98 -0700, you wrote: >I just discovered the XML Query Language proposal at >http://www.w3.org/TR/NOTE-xml-ql/, and find it very interesting. It looks >a lot like SQL, which could be handy, but also somewhat limiting. What do >you'all think about it? Yes, it is interesting. The tag minimization (using the "" end tag) is very troublesome, though. Troublesome enough that I hope they either dispense with it altogether or stop referring to XML-QL queries as though they were well-formed XML and adopt terminology such as "XML-like" instead. ================================================= John E. Simpson simpson@flixml.org http://www.flixml.org Just XML - coming in September from Prentice-Hall xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rhanson at blast.net Mon Aug 31 00:06:35 1998 From: rhanson at blast.net (Robert Hanson) Date: Mon Jun 7 17:04:15 2004 Subject: XML-QL Message-ID: <008501bdd462$8df26b00$4fe8c6cf@Harry.Handjob> If you read the end of the spec on what the "wish list" is for the final version of the spec, it mentions that like XSL, they want it to be XML complient. Undoubtedly, this means the the tag minimization will be tossed. ...and I agree that making the query language XML complient is of importance. Besides that, I thought it was very good and useful. As a programmer though, I see a few ways on how it could be implemented... 1. Matches could be made on the XML as a stream., and return it as such. So you invoke a method on the Query control which asks for a single match. The application would that find the first match and return only that one. From there you could recursively ask for the next match. 2. Return all of the matches in a single action as a single XML document. The problem is that if the XML document is very long, this could take some time (even days... if the XML document was big enough). 3. The query application acts as a search engine where is indexes the XML documents before a query is made to increase the speed for the search. This could be combined with the interface I mentioned in #1 or #2. Does anyone have any thoughts on this?? I was actually thinking about creating a search application based on the current XML-QL note, and have not decided on how the interface should work. For those familiar with Microsoft's ADO control, I was thinking something like that. In which case, the search would be return a single match for each call to the query engine. The query would also be optimised based on what the options the user wanted... like forward only, 1 match at a time (with a READ command, then a MoveNext command) -OR- backwards and forwards ( involved caching previous matches) -OR- forward, backward, first, last ( involves caching all of the matches before allowing reads ). Robert Hanson -----Original Message----- From: John E. Simpson To: xml-dev@ic.ac.uk Date: Sunday, August 30, 1998 5:39 PM Subject: Re: XML-QL >[My first attempt at a reply doesn't seem to have gone through. Let's try >this again....] > >At 03:53 PM 8/29/98 -0700, you wrote: >>I just discovered the XML Query Language proposal at >>http://www.w3.org/TR/NOTE-xml-ql/, and find it very interesting. It looks >>a lot like SQL, which could be handy, but also somewhat limiting. What do >>you'all think about it? > >Yes, it is interesting. The tag minimization (using the "" end tag) is >very troublesome, though. Troublesome enough that I hope they either >dispense with it altogether or stop referring to XML-QL queries as though >they were well-formed XML and adopt terminology such as "XML-like" instead. > >================================================= >John E. Simpson >simpson@flixml.org >http://www.flixml.org >Just XML - coming in September from Prentice-Hall > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Mon Aug 31 00:56:20 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:04:15 2004 Subject: XML Namespace References: <199808302126.RAA25790@locke.ccil.org> Message-ID: <35E9D86B.469E8875@allette.com.au> John Cowan wrote: > Learn to relax and live without DTDs. The new namespace proposal > makes them useless anyway, so people are now trying to develop > various replacements for them. Although DTDs can be replaced at some stages of the data lifecycle, I don't believe that they'll ever be completely replaced unless they're written out of the standard - a move that many would see as extraordinary. The authoring of documents is still likely to remain somewhat independent from the eventual usage - for this task, a DTD may be just as useful as a schema. Also, in the short-term absense of high-end XML tools, applications like FrameMaker+XML (or whatever they call it) will be held up as shining examples, not forced into immediate redesign. The recent nervousness over when browsers will be delivered leads me to believe that the XML community isn't cocky enough to start killing it's babies yet. -- 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 dent at highway1.com.au Mon Aug 31 05:32:18 1998 From: dent at highway1.com.au (Andy Dent) Date: Mon Jun 7 17:04:16 2004 Subject: XML Namespace In-Reply-To: <35E9D86B.469E8875@allette.com.au> References: <199808302126.RAA25790@locke.ccil.org> Message-ID: At 6:55 AM +0800 31/8/98, Marcus Carr wrote: >Although DTDs can be replaced at some stages of the data lifecycle, I don't >believe that they'll ever be completely replaced unless they're written out of >the standard Not finalised yet, but the way that I'm planning for our report-writer to output data is using DTD's, XML and XSL as per the current standard(s). I don't want to futz around with namespaces and I'm more interested in a single document being wholly self-sufficient. I'm treating XML and XSL as being reasonably well-defined meta protocols that we can use right now. If other tools remain compliant all well and good. I've not yet decided if XML-Data is worth pursuing for schema description - I'd like to hear what Oracle et al have intended along those lines before believing in it as a standard. Just because Microsoft are supposedly backing it doesn't fill me with confidence (the games they play with RTF alone have wasted much of my time). Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.highway1.com.au/adsoftware/crossplatform.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shin at comeng.chungnam.ac.kr Mon Aug 31 07:40:58 1998 From: shin at comeng.chungnam.ac.kr (Dongwook Shin) Date: Mon Jun 7 17:04:16 2004 Subject: XML-QL References: <008501bdd462$8df26b00$4fe8c6cf@Harry.Handjob> Message-ID: <35EA3655.28802BAF@comeng.chungnam.ac.kr> Robert Hanson wrote: > As a programmer though, I see a few ways on how it could be implemented... > 1. Matches could be made on the XML as a stream., and return it as such. So > you invoke a method on the Query control which asks for a single match. The > application would that find the first match and return only that one. From > there you could recursively ask for the next match. > > 2. Return all of the matches in a single action as a single XML document. > The problem is that if the XML document is very long, this could take some > time (even days... if the XML document was big enough). > > 3. The query application acts as a search engine where is indexes the XML > documents before a query is made to increase the speed for the search. This > could be combined with the interface I mentioned in #1 or #2. > > Does anyone have any thoughts on this?? I was actually thinking about > creating a search application based on the current XML-QL note, and have not > decided on how the interface should work. For those familiar with > Microsoft's ADO control, I was thinking something like that. In which case, > the search would be return a single match for each call to the query engine. > The query would also be optimised based on what the options the user > wanted... like forward only, 1 match at a time (with a READ command, then a > MoveNext command) -OR- backwards and forwards ( involved caching previous > matches) -OR- forward, backward, first, last ( involves caching all of the > matches before allowing reads ). > > Robert Hanson XML-QL is quite interesting, but I thing it should allow IR queries as well as database queries. It is because XML documents can be viewed as a set of collections as well as a database, where a user can retrieve relevant documents as well as get exact ones. Look the SQL/MM Full text part. It allows Boolean operators and other operators frequently used in information retrieval systems. In this sense, I prefer the approach (3) that Robert Hanson proposed. It would be better to index XML documents and serve the queries fast. Without the indices, it would be difficult to compute the similarity between XML documents and user queries on the fly. As I posted earlier, BUS is an efficient indexing and retrieval engine for this purpose. See the page http://savage.comeng.chungnam.ac.kr/~sgml 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 majayg at iitk.ac.in Mon Aug 31 09:32:06 1998 From: majayg at iitk.ac.in (Ajay Gangwar) Date: Mon Jun 7 17:04:16 2004 Subject: Viewing XML documents Message-ID: <002301bdd4b1$544bde00$52a21090@cse.iitk.ernet.in> Hello, 1. I am a new comer to the domain of XML. Can someone please tell me how I can view a XML document given an associated style sheet. Are there any browsers yet that support viewing XML documents? 2. I have downloaded MSXSL, a command line utility from Microsoft ,along with its sample .xml and .xsl files. But when I run MSXSL on sample.xml and sample.xsl provided by Microsoft I get the following error: Error parsing document 'sample.xml' Exception: hr = 0x80070057 The sample.xml is as follows: Belgian Waffles $6.95 two of our famous Belgian Waffles with plenty of real maple syrup 650 Strawberry Belgian Waffles $7.95 light Belgian waffles coverred with strawberrys and whipped cream 900 Berry-Berry Belgian Waffles $8.95 light Belgian waffles coverred with an assortment of fresh berries and whipped cream 900 French Toast $4.50 thick slices made from our homemade sourdough bread 600 Homestyle Breakfast $6.95 two eggs, bacon or sausage, toast, and our ever-popular hash browns 950 I could figure out that line one has error and should read: But even after correcting it, I get the same error. Can someone please help me figure out as to what is going wrong? The document seems to be well formed. I am running win NT and IE 5.0(beta) if that is of any help. -Ajay Gangwar xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From arcdev at mail.matav.hu Mon Aug 31 11:36:16 1998 From: arcdev at mail.matav.hu (Attila Torcsvari) Date: Mon Jun 7 17:04:16 2004 Subject: Validating IDREFS... Message-ID: <01BDD40A.50BDF630@wingate> Recently I wanted to make more checkable my SGML/XML source, and I have similar troubles mentioned on this thread. What should I do if my IDs and IDREFs contain non-name characters? Why is it so?! (My pages should be reachable for external databases, which use identifiers with the same syntax, so I can not just convert the values to something else.) Thanks Attila xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Aug 31 13:22:32 1998 From: David.Rosenborg at xsse.se (David Rosenborg) Date: Mon Jun 7 17:04:16 2004 Subject: Namespaces Not Necessarily Unrepentant Evil References: <3.0.5.32.19980827193117.008e5100@dns.isogen.com> <35E6CAB6.1C8ED0C3@xsse.se> <35E6DFF1.273D6DB7@mecomnet.de> Message-ID: <35EA8711.F7D8D8F4@xsse.se> james anderson wrote: > > In this situation, either of the encodings > [snip] > > express the relations which you describe. > and One person wrote (in a directed reply): > > Note that you can name an element by giving it an ID attribute. > I'm not sure if this solves your problem, though. > Thanx for your answers. Perhaps I wasn't clear, but my question was on the conceptual level, not about a particular problem instance. I sought a discussion of how DTDs, AFs and other Schemas deal with the distinction of type names and named instances of types. And this distinction is also valid for traditional documents not just encoded data. One person wrote (in a directed reply): > > XML came via SGML from a document-centric world and isn't really intended > to model object-oriented polymorphic languages. I'm from both worlds, but I see no reason why you cannot apply polymorphism and other pardigms of object-oriented languages to even plain old documents. Also, the lines between programming languages, data and documents are getting fuzzier all the time. And I hope it gets even fuzzier :-) Cheers, _____________________________________________________________________ David.Rosenborg@xsse.se OM Exchange Technology xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rogersba at cs.rose-hulman.edu Mon Aug 31 13:29:19 1998 From: rogersba at cs.rose-hulman.edu (Brian A Rogers) Date: Mon Jun 7 17:04:16 2004 Subject: Viewing XML documents In-Reply-To: <002301bdd4b1$544bde00$52a21090@cse.iitk.ernet.in> Message-ID: On Mon, 31 Aug 1998, Ajay Gangwar wrote: > 2. I have downloaded MSXSL, a command line utility from > Microsoft ,along with its sample .xml and .xsl files. But when I run > MSXSL on sample.xml and sample.xsl provided by Microsoft I get the > following error: > > Error parsing document 'sample.xml' > Exception: hr = 0x80070057 > > [sample XML deleted] > > I am running win NT and IE 5.0(beta) if that is of any help. IE 5.0 is the problem. It does not appear to be compatible with MSXSL. I ran into this a couple of months ago. The only fix that I found was to go back to IE 4.0. Hope that helps! -------------------------------------------------------------------- | Brian A. Rogers | | | CS '99 | "There are no problems, | | Rose-Hulman Institute of Technology | only solutions." | | (812) 877-0247 | | | http://www.rose-hulman.edu/~rogersba | | -------------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Aug 31 14:46:04 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:16 2004 Subject: Reminder: XSchema spec under review Message-ID: <199808311245.IAA21123@hesketh.com> We're now halfway through the review period for Sections 1-3 of the XSchema spec, and I've received some very detailed comments. I'd like to hear from more folks, if you have the time, about how the draft looks. A specification draft containing the complete text of Sections 1-3 and Appendix A of the XSchema specification is available at http://www.simonstl.com/xschema/spec/xscspecv1.htm. Section 4, XSchema Transformation to XML 1.0 DTD, and Section 5, Connecting XSchemas to XML Documents, are still under development. This draft is presented for review; no changes will be made to these sections until 8 September, 1998. All comments and suggestions are welcome. The full site at http://purl.oclc.org/NET/xschema/ is still active. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Mon Aug 31 14:51:56 1998 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:04:16 2004 Subject: XML Namespace In-Reply-To: <199808302126.RAA25790@locke.ccil.org> References: <35E9B34E.358F75DC@goshawk.com> Message-ID: <199808311251.WAA04436@fep2.mail.ozemail.net> At 07:26 31/08/1998, John Cowan wrote: | Steve Dahl scripsit: | | > From that, I inferred that prefixes are assumed to lack either | > uniqueness or persistence (or both), or else they could have been used | > as the namespace name to begin with. This means that it's not impossible | > that I might have a collision between two different Namespaces being | > associated with the same prefix. In that case, what would I need to do | > if I wanted to mix element types from two different DTDs that had the | > same prefix but which are intended to be bound to different Namespaces? | Learn to relax and live without DTDs. The new namespace proposal | makes them useless anyway, so people are now trying to develop | various replacements for them. Doesn't this statement make people scared?!? First off, I still remember Tim Bray's statement at the Sydney XML conference last year, to the effect that he was worried that having XML without DTDs was going to cause a lot of problems down the track. More significantly to me, I _want_ DTDs. The whole point to me, and to a whole lot of other people, is that SGML/XML enforces consistency of structure. You need a DTD to ensure that. So, great, we can send a whole lot of unstructured tags (as long as they are well-formed) about the place. What does this do for us? We end up with a whole lot of documents that are "XML", that cannot be converted, published, validated or anything else that requires structure, because we don't have a DTD. Instant legacy data! Doesn't this worry _anyone_? Apologies for the rant, James ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cvonsee at onramp.net Mon Aug 31 15:13:45 1998 From: cvonsee at onramp.net (Chris von See) Date: Mon Jun 7 17:04:16 2004 Subject: XML-QL Message-ID: <199808311313.IAA06184@mailhost.onramp.net> > Robert Hansen wrote: > >As a programmer though, I see a few ways on how it could be implemented... >1. Matches could be made on the XML as a stream., and return it as such. So >you invoke a method on the Query control which asks for a single match. The >application would that find the first match and return only that one. From >there you could recursively ask for the next match. The SQL cursor mechanism is perfect for this - it would allow you to select a solution set of elements from an XML document, and then iterate through them one at a time. Having such a mechanism would also allow you to retrieve a set of elements, do some selective editing (i.e. INSERT/UPDATE/DELETE WHERE CURRENT OF in cursor parlance) and then put the elements into a new document. Having a cursor mechanism would be a huge benefit to XML-QL. > >2. Return all of the matches in a single action as a single XML document. >The problem is that if the XML document is very long, this could take some >time (even days... if the XML document was big enough). Cursors could solve this as well, I think. >Does anyone have any thoughts on this?? I was actually thinking about >creating a search application based on the current XML-QL note, and have not >decided on how the interface should work. For those familiar with >Microsoft's ADO control, I was thinking something like that. In which case, You might be better off creating something akin to Microsoft's ODBC driver mechanism, where you could not only issue queries against documents but also retrieve info about the document's metadata (like the SQL_COLUMNS and SQL_TABLES mechanisms in ODBC). Also, an ODBC-like mechansim would be much better suited to use on non-Windows systems. Chris von See ------------------------------------------------------ "Don't *say* things. What you *are* stands over you the while, and thunders so that I cannot hear what you say to the contrary." --- Emerson, "Social Aims" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 31 15:16:04 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:16 2004 Subject: XML Namespace References: <35E9B34E.358F75DC@goshawk.com> <199808311251.WAA04436@fep2.mail.ozemail.net> Message-ID: <35EAA398.EEFFFC7E@mecomnet.de> James Robertson wrote: > > At 07:26 31/08/1998, John Cowan wrote: > > | Steve Dahl scripsit: > | > | > From that, I inferred that prefixes are assumed to lack either > | > uniqueness or persistence (or both), or else they could have been used > | > as the namespace name to begin with. This means that it's not impossible > | > that I might have a collision between two different Namespaces being > | > associated with the same prefix. In that case, what would I need to do > | > if I wanted to mix element types from two different DTDs that had the > | > same prefix but which are intended to be bound to different Namespaces? > > | Learn to relax and live without DTDs. The new namespace proposal > | makes them useless anyway, so people are now trying to develop > | various replacements for them. > > Doesn't this statement make people scared?!? > > First off, I still remember Tim Bray's statement at the Sydney > XML conference last year, to the effect that he was worried > that having XML without DTDs was going to cause a lot > of problems down the track. > > More significantly to me, I _want_ DTDs. The whole point > to me, and to a whole lot of other people, is that SGML/XML > enforces consistency of structure. You need a DTD to > ensure that. > agreed. > ... > > Instant legacy data! > > Doesn't this worry _anyone_? > yes. I've already been berated for suggesting that the problem is solved by supporting a binding form with a scope over the dtd, but, since I need the information, that's the path I'm following until the DTD-replacement appears over the horizon. In particular, since the namespace pi is no longer covered by the spec, I understand that I'm free to go ahead and use it as the necessary binding expression. Given it, the DTD-merges are possible and I can get at the default information which I need. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 31 18:04:51 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:04:16 2004 Subject: Reminder: XSchema spec under review In-Reply-To: <199808311245.IAA21123@hesketh.com> Message-ID: <3.0.1.16.19980830170242.348f43fa@pop3.demon.co.uk> At 08:47 31/08/98 -0400, Simon St.Laurent wrote: >We're now halfway through the review period for Sections 1-3 of the XSchema >spec, and I've received some very detailed comments. I'd like to hear from >more folks, if you have the time, about how the draft looks. I may have got this wrong but I seem to remember that at some stage you were going to publish a complete draft (i.e. covering all the sections) and then we would have a week or so to have a hack at it. It's only at that stage that I would think about actually trying to implement it in JUMBO (or bolt in the xsc2dtd and dtd2xsc stuff). Am I right in thinking we haven't quite reached that stage yet? [I'm still rather punch-drunk from myriad spec changes so am reluctant to have a go at anything now (including XSchema) until it gets firmed up. For example I still find bits of my code that reference old SAX stuff, etc. and I tend to have deleted the old SAX *.jars - naturally.] 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 mct at foyt.indyrad.iupui.edu Mon Aug 31 18:19:19 1998 From: mct at foyt.indyrad.iupui.edu (Mark Tucker) Date: Mon Jun 7 17:04:16 2004 Subject: Help with Namespace Defaulting Message-ID: <199808311606.LAA17541@foyt.indyrad.iupui.edu> Hello, Can I define xmlns = "....." as a fixed attribute of an element? Suppose I have Person_Data (PD) and Book (BK), both of which would like to use an element called NAME. To keep the XML Elements unique, I could use namespaces to keep PD:NAME distinct from BK:NAME. MY QUESTION: Can I use NAMESPACE defaulting via a fixed xmlns attribute (as seen in the second example) to get rid of most of my namespace prefixes? =======================: With Namespaces :====================== /> John Doe 50 Xml Made Easy Now its all clear ========================: With Namespace Defaulting :==================== /> John Doe 50 Xml Made Easy Now its all clear xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Aug 31 18:43:36 1998 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:04:16 2004 Subject: Reminder: XSchema spec under review In-Reply-To: <3.0.1.16.19980830170242.348f43fa@pop3.demon.co.uk> References: <199808311245.IAA21123@hesketh.com> Message-ID: <199808311643.MAA23693@hesketh.com> Peter Murray-Rust writes: >I may have got this wrong but I seem to remember that at some stage you >were going to publish a complete draft (i.e. covering all the sections) and >then we would have a week or so to have a hack at it. It's only at that >stage that I would think about actually trying to implement it in JUMBO (or >bolt in the xsc2dtd and dtd2xsc stuff). Am I right in thinking we haven't >quite reached that stage yet? That's right; this two-week review of the first three parts does two things: 1) Lets us make sure that the foundations are strong before we write the funkier material. The review so far has been useful for that. 2) Lets Ron Bourret, who's done most of the implementation so far, get back from his vacation. I have some rough material for Section 4, but he's the main impetus on that section and hasn't yet seen some of the changes we've made. Section 4 in particular is going to be sticky; 5 is mostly a matter of a PI that I'm getting under control. After it's all here, we'll have another review of the whole thing. We're almost there... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer Cookies / Sharing Bandwidth (November) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sdahl at goshawk.com Mon Aug 31 18:59:33 1998 From: sdahl at goshawk.com (Steve Dahl) Date: Mon Jun 7 17:04:17 2004 Subject: XML Namespace References: <3.0.32.19980830135035.00bd7860@207.34.179.21> Message-ID: <35EAD5E0.27F98D01@goshawk.com> Tim Bray wrote: > At 04:17 PM 8/30/98 -0400, Steve Dahl wrote: > >For example, if the file a.dtd declared one element ns:x, and the file > >b.dtd declared another element ns:x, how could I use both of them in the > >same document, without copying one of the DTDs and changing the prefixes > >in the copy? > > The namespace draft clearly forbids mapping one namespace to two > different prefixes. So in the instance, you'd probably have to > change the ns:x to ns_2:x or something. Which meant that if you > wanted to validate it against b.dtd, you'd have to change it > in b.dtd as well. > > BUT (and this is the hard part) you couldn't validate the merged > document against b.dtd anyhow because it won't know about the elements > from a.dtd. So you're going to have to figure out how to make > a merged dtd. Which is hard. But once you've figured that out, > fix up the namespace collisions while you're doing the merge. -Tim I don't think that the draft forbids mapping one URI to different prefixes, or mapping one prefix to different URIs. I'm not sure what the effect is if a nested element maps an already mapped prefix to a different URI, as in: ... If it worked, the effect is obvious enough, but it's not clear that it should, or that most parsers would necessarily handle it correctly unless the spec points it out as something to watch out for. Certainly, a prefix that keeps changing its binding through the document is going to result in a document that is very hard for a human to read. As far as validating the document goes, I could create a copy of one of my DTDs and within that copy, I could change all occurrences of the old prefix (ns) to the new one (ns_2), then use ns_2: in my document wherever I want to use elements or attributes from the second DTD. This is quite feasible if I am the author of at least one of the DTDs. It's less reasonable if _both_ of the DTDs are standards from different standards bodies, because now my copy of the standard DTD will begin to diverge from the standard over time, and is no longer "standard". If DTDs had the same sort of scoping rules as documents, and had to map the prefix to a URI before they could use it, I can imagine several solutions to my hypothetical conflict: --- The document might be able to map one of the two URIs to a different prefix. Since the DTD's elements and attributes would now be defined relative to a URI, and not defined relative to a prefix, the two DTDs would now fall into different Namespaces, and the document can assign those Namespaces any prefixes it wishes. Where this breaks down is that general entities contain literal text, which may include prefixes, and these prefixes would have to be remapped if the document were using different prefixes than the DTD. This is feasible, but it suggests that an entity no longer has replacement _text_, but replacement _structure_. It may also suggest that entities are no longer global, but are defined in a Namespace, and that they should be allowed to have qualified names. --- The document could use the same prefixes as the DTDs, but remap the prefix on almost an element by element basis, as in the example I mentioned earlier: ... This approach is very ugly, but it also fails to work if you have a tag like: The above tag is inexpressible if the element belongs to one namespace ("http://www.foo.com/ns1"), and the attribute belongs to the other ("http://www.baz.com/ns2"). --- Both of these require that the DTD declare which URI it wants to associate with its prefix (if it uses multiple prefixes, it would have to declare all of them). If Namespaces are not deployed commercially until we have a replacement for DTDs in which the document is not required to use the same prefix as the data description, then this may be a non-issue. But if Namespaces are not going to presuppose what the replacement for DTDs will be, or when it will arrive, it might be useful to think about how Namespaces could be a little more bullet-proof about prefix collisions. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gjones at vsi.com Mon Aug 31 19:35:09 1998 From: gjones at vsi.com (Gila Jones) Date: Mon Jun 7 17:04:17 2004 Subject: Please..... In-Reply-To: Message-ID: <3.0.5.32.19980831103047.008d38d0@trance.vsi.com> My company has a very consise explanation of XML available at http://vsi.com/Xml-f/extensions/what_is_xml.html . Gila Jones At 05:33 PM 8/30/98 +0530, ruchig wrote: > >Hello Everybody: > >I am very new for this list. Can any one help he from where I can get >introduction of xml and other stuff. >Thanks >ruchig > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 James.Anderson at mecomnet.de Mon Aug 31 19:48:53 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:04:17 2004 Subject: XML Namespace References: <3.0.32.19980830135035.00bd7860@207.34.179.21> Message-ID: <35EAE3D8.1D338D96@mecomnet.de> Tim Bray wrote: > > ... > > The namespace draft clearly forbids mapping one namespace to two > different prefixes. So in the instance, you'd probably have to > change the ns:x to ns_2:x or something. Which meant that if you > wanted to validate it against b.dtd, you'd have to change it > in b.dtd as well. If this is intended, then the draft might express the constraint more clearly. It also would appear to work counter to the modularity goal, that distinct processes be able to augment a document without knowledge of the prefixes used by other processes. It's just the flip-side of different URI's bound to the same prefix: if the URI's already have registered prefixes in order that the application can pick the uniquely correct one, then the registry can constrain the prefixes to avoid collisions. If you intended to say, that two distinct prefixes may not be simultaneously associated with a given URI, that's a slightly different story, but it has the same ending. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Aug 31 19:48:54 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:04:17 2004 Subject: XML Namespace References: <35E9B34E.358F75DC@goshawk.com> <199808311251.WAA04436@fep2.mail.ozemail.net> Message-ID: <35EAD4AD.72A0@allette.com.au> James Robertson wrote: > > At 07:26 31/08/1998, John Cowan wrote: > | Learn to relax and live without DTDs. The new namespace proposal > | makes them useless anyway, so people are now trying to develop > | various replacements for them. > > Doesn't this statement make people scared?!? No, because it simply isnt so. Having namespaces merely expands the richness of the vocabulary available to document system designers. Applications for which XML DTDs are best suited will continue to use DTDs. Applications which can stand 100s of Ks of schema data will use instance syntax. Applications for which existing AFDR syntax (attributes for architectural forms) are clearly appropriate will use AFDR syntax. People who find that PIs fit will use them; people who like embedding markup in comments or creating their own embedded markup landuages will find some excuse to do that. The important thing is that document system designers understand when it is appropriate to use each one. Namespaces as now proposed do not make DTDs useless: as far as I can see the proposal does not really impact on whether a full DTD is useful or not much at all (except for the limited case of fixed or defualting attributes for the prefix and namespace name themselves, which has hardly been the prime use of DTDs up to now). The fact that DCD takes the namespace URI and uses it to key which DTD or schema to use is no different from what people do with attributes all the time: they use attribute values to figure out what processing is required for an element. XML wasnt designed on a minimalist principle (what is the smallest we can get away with?) but more on the optimalist principle (can we satisfy 80% of needs with something only 20% of the complexity?). As far as I can see, the XML WG has placed quite a high emphasis on keeping (SGML's) richness; the provision of Namespaces only confirms this impression (that richness is more important to the WG than terseness or minimalism). DTDs have proved themselves in the field for many years and dont require more defense; if other syntaxes arrive which are more appropriate in their own circumstances than DTDs, that is no slur on DTDs. Namespaces certainly provide a good set of hooks for external schemas, but such hooks can be provided in fixed attributes in DTDs just as readily as in attribute values in the instance. In fact, for size reasons, having namespace attributes declared in fixed attributes in DTDs may be more preferable than bloating the instance with repeated attributes. Counter to John Cowan, namespaces may, for some document types, make an explicit DTD *more* attractive, not less! Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mct at foyt.indyrad.iupui.edu Mon Aug 31 21:38:24 1998 From: mct at foyt.indyrad.iupui.edu (Mark Tucker) Date: Mon Jun 7 17:04:17 2004 Subject: XML ATTRIBUTES : Are they attribute Names or Type Names? Message-ID: <199808311925.OAA21202@foyt.indyrad.iupui.edu> Hi David, I'm not sure what you said about typenames and attribute names, but I wonder if it is this problem. XML ELEMENT names are confused about whether they are acting as programming language "type names", or as programming language "field names". In a "data oriented schema" (aka, Type Definition Language) we might write TYPE POINT { x : INT y : INT } TYPE RECTANGLE { lower-left : POINT upper-right : POINT } and then we might have instances: -- Point is the Type Name 3 -- X is a field name 4 -- type -- field -- type 3 -- field 4 30 40 Programming languages make it clear when an identifier defines a type (POINT), and when it uses a type (lower-left). -- Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)